Re: AD review comments for draft-ietf-syslog-dtls

I'm fine with either.  Regardless, the IANA considerations section needs 
to be updated to register the service code - unless some other document 
that I don't know about already did.  Notes for the registration can be 
found here: 
http://www.iana.org/assignments/service-codes/service-codes.xhtml

But, all that I think is needed is some text asking IANA to register the 
following DCCP service code:

   1398361159   SYLG   SYSLOG Protocol    [TBD]

spt

Joseph Salowey (jsalowey) wrote:
> Hi Chris,
> 
> CCID 3 looks good to me, I'm OK with the text. 
> 
> We could just use the port number, 6514, as the service code. Since the
> service identifier applies to more than DCCP, it probably makes more
> sense the follow the scheme defined in RFC4340 where a 4 letter string
> is used as the service identifier, such as the following:
> 
> SC:SYLG
> SC=x53594C47
> SC=1398361159
> 
> Cheers,
> 
> Joe
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
> Behalf
>> Of Chris Lonvick (clonvick)
>> Sent: Monday, April 12, 2010 6:40 AM
>> To: [email protected]
>> Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls
>>
>> Hi Folks,
>>
>> I'll suggest CCID 3 because that's my lucky number.  ;-)
>>
>> Seriously, here is a relevant point from RFC 5238:
>> ===vvv===
>>     In addition to the retransmission issues, if the throughput needs
> of
>>     the actual application data differ from the needs of the DTLS
>>     handshake, it is possible that the handshake transference could
> leave
>>     the DCCP congestion control in a state that is not immediately
>>     suitable for the application data that will follow.  For example,
>>     DCCP Congestion Control Identifier (CCID) 2 ([RFC4341]) congestion
>>     control uses an Additive Increase Multiplicative Decrease (AIMD)
>>     algorithm similar to TCP congestion control.  If it is used, then
> it
>>     is possible that transference of a large handshake could cause a
>>     multiplicative decrease that would not have happened with the
>>     application data.  The application might then be throttled while
>>     waiting for additive increase to return throughput to acceptable
>>     levels.
>>
>>     Applications where this might be a problem should consider using
> DCCP
>>     CCID 3 ([RFC4342]).  CCID 3 implements TCP-Friendly Rate Control
>>     (TFRC, [RFC3448])).  TFRC varies the allowed throughput more
> slowly
>>     than AIMD and might avoid the discontinuities possible with CCID
> 2.
>> ===^^^===
>>
>> My reasoning for choosing CCID 3 is that when some devices start up
> they
>> will queue up syslog messages until the network is up, and then they
> will
>> start to deliver them.  I don't want a large handshake to throttle
> that
>> initial burst of messages.  (Please challenge this assumption if you
> have
>> a better understanding of the process.)
>>
>> I'll suggest that the specific wording will need to be: "MUST
> implement
>> CCID 3 and SHOULD implement CCID 2 to ensure interoperability".  Does
> that
>> sound OK to everyone?
>>
>>
>> Joe: can you look at Sean's second question and let us know about
> that?
>> Thanks,
>> Chris
>>
>> On Thu, 8 Apr 2010, Sean Turner wrote:
>>
>>> I have one major comment and it relates to DCCP:
>>>
>>> The DCCP chairs tell me that to specify the use of DCCP the ID needs
> to
>>> decide which CCID it will use (CCID 2 is AIMD and CCID 3 is TFRC).
> I
>> was
>>> hoping that the DTLS over DCCP RFC addressed this, but that RFC
> doesn't
>> pick
>>> one it leaves this choice to the "application".
>>>
>>> Can you also confirm that the Port # is used as the DCCP service
> code?
>>> spt
>>>
>>>
>>>
>>> _______________________________________________
>>> Syslog mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/syslog
>>>
>> _______________________________________________
>> Syslog mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/syslog
> _______________________________________________
> Syslog mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/syslog
> 
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog