_____
From: syslog-bounces(_at_)ietf(_dot_)org
[mailto:syslog-bounces(_at_)ietf(_dot_)org] On
Behalf Of Tim Evens
Sent: Wednesday, May 05, 2010 4:02 PM
To: cfinss(_at_)dial(_dot_)pipex(_dot_)com; jsalowey(_at_)cisco(_dot_)com;
turners(_at_)ieca(_dot_)com;
clonvick(_at_)cisco(_dot_)com
Cc: syslog(_at_)ietf(_dot_)org
Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls
Hopefully this isn't too late for a review comment...
It appears to me that DTLS as a SYSLOG-MSG transport introduces a new
variable that isn't present with traditional TCP and UDP based
transports with regards to SYSLOG-MSG fragments.
IP/UDP transport allows for IPv4 based fragmentation, even though it
should be avoided for several reasons, there could be useful and valid
application uses for fragmenting UDP packets. IP/TCP as a transport
supports message segments that can span multiple packets. Per RFC4347
section 4.1.1, "each DTLS record MUST fit within a single datagram."
DTLS introduces a sequence_number field to the record layer, which
facilitates reassembly providing the receiving station queues and
reorders.
In this draft, section 5.1 suggests that it's optional for the
implementer to adopt a queue mechanism to resolve reordering. Later
in section 5.4 it suggests that a single SYSLOG-MSG can be transferred
in multiple DTLS records.
If it is optional to implement DTLS sequence numbers, how does the
originator of the SYSLOG-MSG know that the collector will not reorder
messages? If the originator knows that the collector will not reorder
DTLS fragments, then it can truncate messages prior to transmission.
In lieu of truncation, the originator could generate multiple
SYSLOG-MSG's using structured data that enables the collector to piece
them together.
There doesn't appear to be a SYSLOG-FRAME ID as part of each DTLS
application-data record. If a message of say 1400 bytes is sent in 3
packets/DTLS records, and if packet 2 of the 3 was dropped by the
network, how does the collector know that those packets were to be
concatenated as a single SYSLOG-MSG? Without a SYSLOG-FRAME
identifier, the collector would have to assume invalid based on
messages not structured per RFC5424. Also, if there is no frame ID
and sequence reordering isn't implemented, a out-of-sequence DTLS
record could possibly inadvertently be prepended or appended to the
wrong message, causing a valid message to be corrupt. It seems this
would be moot if when using DTLS a SYSLOG-MSG must not span multiple
DTLS records.
Thanks,
Tim
-----Original Message-----
From: "Chris Lonvick" [clonvick(_at_)cisco(_dot_)com]
Date: 05/03/2010 06:49 AM
To: "tom.petch" , "Joe Salowey" , "Sean Turner"
CC: syslog(_at_)ietf(_dot_)org
Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls
Hi,
I'm good with that as well.
Joe, can you edit and resubmit a new ID?
Sean, if this covers all of your edits, when can we expect to see it
on
the IESG agenda, and when can we see IETF LC?
Thanks,
Chris
On Tue, 27 Apr 2010, tom.petch wrote:
----- Original Message -----
From: "Joseph Salowey (jsalowey)" <jsalowey(_at_)cisco(_dot_)com
<javascript:window.top.openSendEmail('jsalowey(_at_)cisco(_dot_)com>','','','');>
;
To: "Sean Turner" <turners(_at_)ieca(_dot_)com
<javascript:window.top.openSendEmail('turners(_at_)ieca(_dot_)com>','','','');>
;; "Chris Lonvick (clonvick)"
<clonvick(_at_)cisco(_dot_)com
<javascript:window.top.openSendEmail('clonvick(_at_)cisco(_dot_)com>','','','');>
;
Cc: <syslog(_at_)ietf(_dot_)org
<javascript:window.top.openSendEmail('syslog(_at_)ietf(_dot_)org>','','','');>
;
Sent: Friday, April 23, 2010 5:02 PM
Anybody on the list have objection to adding the Chris' suggested
text
and the DCCP service code SYLG?
I see SYSL used as a four character code for syslog in other
settings and would
prefer that. Else, following the principle of dropping vowels, SSLG,
but I
think that not as good.
Tom Petch
Thanks,
Joe
-----Original Message-----
From: Sean Turner [mailto:turners(_at_)ieca(_dot_)com
<javascript:window.top.openSendEmail('turners(_at_)ieca(_dot_)com','','','');> ]
Sent: Thursday, April 22, 2010 3:55 PM
To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick)
Cc: syslog(_at_)ietf(_dot_)org
<javascript:window.top.openSendEmail('syslog(_at_)ietf(_dot_)org','','','');>
Subject: Re: [Syslog] 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: syslog-bounces(_at_)ietf(_dot_)org
<javascript:window.top.openSendEmail('syslog-bounces(_at_)ietf(_dot_)org','','','
');> [mailto:syslog-bounces(_at_)ietf(_dot_)org
<javascript:window.top.openSendEmail('syslog-bounces(_at_)ietf(_dot_)org','','','
');> ] On
Behalf
Of Chris Lonvick (clonvick)
Sent: Monday, April 12, 2010 6:40 AM
To: syslog(_at_)ietf(_dot_)org
<javascript:window.top.openSendEmail('syslog(_at_)ietf(_dot_)org','','','');>
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
Syslog(_at_)ietf(_dot_)org
<javascript:window.top.openSendEmail('Syslog(_at_)ietf(_dot_)org','','','');>
https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf