[Syslog] Issue 10 - Jari Arrko DISCUSS

[Chris Lonvick <[e-mail]>]

Issue 10 - Jari Arrko DISCUSS

Discuss:
This is an excellent document and I was ready to post a Yes vote
on the ballot. However, there is one detail. The document says:

    When mapping onto different
    transports, DTLS has different record size limitations.  The
    application implementer SHOULD determine the maximum record size
    allowed by DTLS protocol running over the transport in use.  The
    message size SHOULD NOT exceed the DTLS maximum record size
    limitation of 2^14 bytes.  To be consistent with RFC 5425, in
    establishing a baseline for interoperability, this specification
    requires that a transport receiver MUST be able to process messages
    with a length up to and including 2048 octets.  Transport receivers
    SHOULD be able to process messages with lengths up to and including
    8192 octets.

This guidance seems quite weak in terms of avoiding excessive
fragmentation. Or am I misunderstanding how DTLS records map to
UDP packets? I am assuming its a 1-1 mapping, but maybe I'm
mistaken.

In any case, the document should say something about tuning applications
and configurations to avoid excessively long packets due to
inefficiencies and other problems that fragmentation may cause.
^^^^

Sean proposes:
vvv
As this I-D is about two transports and they do somethings
differently, I suggest we point to both sets of considerations.

How about a multi-pronged approach:

#1) Specifically mention UDP/DCCP message size/length text in 5.1.

WRT DCCP and tuning, RFC 4340 (DCCP) says "A DCCP application
interface SHOULD let the application discover DCCP's current" maximum
packet size.  So I'm not sure we should go stronger (i.e., make it a
MUST).  In the text below, RFC 5426 is syslog over UDP:

OLD:

    When mapping onto different
    transports, DTLS has different record size limitations.  The
    application implementer SHOULD determine the maximum record size
    allowed by DTLS protocol running over the transport in use.  The
    message size SHOULD NOT exceed the DTLS maximum record size
    limitation of 214 bytes. ...

NEW

    When mapping onto different transports, DTLS has different record
    size limitations.   For UDP, see section 3.2 of [RFC5426].  For
    DCCP, the application implementer SHOULD determine the maximum
    record size allowed by DTLS protocol running over DCCP, as
    specified in [RFC4340]. The message size SHOULD NOT exceed the
    DTLS maximum record size limitation of 214 bytes.  ...

#2) Add new text in Section 5.1 that points to the syslog message
fragmentation implementation guidance:

    See section A.2 of [RFC5424] for implementation guidance on message
    length, including fragmentation.
^^^

Sean's proposed resolution:
Jari's points about message size/length/fragmentation in Section
5.4.1:

OLD:

    DTLS can run over multiple transports.  Implementations of this
    specification MUST support DTLS over UDP and SHOULD support DTLS
    over DCCP [RFC5238].  Transports, such as UDP or DCCP do not
    provide session multiplexing and session-demultiplexing.  In such
    cases, the application implementer provides this functionality by
    mapping a unique combination of the remote address, remote port
    number, local address and local port number to a session.

NEW:

    When mapping onto different transports, DTLS has different record
    size limitations.   For UDP, see section 3.2 of [RFC5426].  For
    DCCP, the application implementer SHOULD determine the maximum
    record size allowed by DTLS protocol running over DCCP, as
    specified in [RFC4340]. Regardless of the transport, the message
    size SHOULD NOT exceed the DTLS maximum record size limitation of
    214 bytes.  To be consistent with RFC 5425, in establishing a
    baseline for interoperability, this specification requires that a
    transport receiver MUST be able to process messages with a length
    up to and including 2048 octets. Transport receivers SHOULD be able
    to process messages with lengths up to and including 8192 octets.

    See section A.2 of [RFC5424] for implementation guidance on message
    length, including fragmentation.


ACTION:  Authors to review and discuss on list before committing to a 
plan.