Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guidelines) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It is certainly not too late, many thanks - to both Brian and you!

We have various pending comments to look through, and will make sure all comments are also taken into consideration, - next week we'll be resolving the conflicts between comments and seeing how best to accommodate these in updated text, comments then may be late!

Gorry

On 03/06/2016 16:15, Ca By wrote:


On Thursday, June 2, 2016, Brian Trammell <ietf@xxxxxxxxxxx <mailto:ietf@xxxxxxxxxxx>> wrote:

    Greetings, all,

    Apologies for the late last call comment; I have only one,
    relatively minor. I hope it's still useful.

    I understand that Section 3 was written to encourage application
    developers not to roll their own transports ("trust us when we say
    this is hard, this document is a list of reasons why") but as
    written it would seem to discourage transport innovation atop UDP
    (e.g. QUIC, the RTCWEB data channel, anything-over-PLUS), which I
    very much hope was not the intent. The problematic recommendation
    is in the second paragraph:

       These mechanisms are difficult to implement correctly.  For most
       applications, the use of one of the existing IETF transport
    protocols
       is the simplest method of acquiring the required mechanisms.  Doing
       so also avoids issues that protocols using a new IP protocol number
       face when being deployed over the Internet, where middleboxes that
       only support TCP and UDP are not rare.  Consequently, the
    RECOMMENDED
       alternative to the UDP usage described in the remainder of this
       section is the use of an IETF transport protocol such as TCP
       [RFC0793], Stream Control Transmission Protocol (SCTP)
    [RFC4960], and
       SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram
       Congestion Control Protocol (DCCP) [RFC4340] with its different
       congestion control types [RFC4341][RFC4342][RFC5622].

    First, this paragraph ignores potential deployment issues with any
    of these other than TCP, which risks seeming out of touch, but
    this is a minor point and probably not worth a late edit. Second,
    I'm concerned this recommendation could be taken as broader than
    intended, against the definition of any new transport protocol
    encapsulated within UDP that performs substantially the same
    function as the listed protocols.

    I think this can be made clearer by simply adding to the list of
    examples:

    NEW:

       These mechanisms are difficult to implement correctly.  For most
       applications, the use of one of the existing IETF transport
    protocols
       is the simplest method of acquiring the required mechanisms.  Doing
       so also avoids issues that protocols using a new IP protocol number
       face when being deployed over the Internet, where middleboxes that
       only support TCP and UDP are not rare.  Consequently, the
    RECOMMENDED
       alternative to the UDP usage described in the remainder of this
       section is the use of an IETF transport protocol such as TCP
       [RFC0793], Stream Control Transmission Protocol (SCTP)
    [RFC4960], and
       SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram
       Congestion Control Protocol (DCCP) [RFC4340] with its different
       congestion control types [RFC4341][RFC4342][RFC5622], or transport
       protocols specified by the IETF in the future.

    and removing the examples from the summary in section 7:

    OLD:

| SHOULD use a full-featured transport (TCP, SCTP, DCCP) | |

    NEW:

| SHOULD use a full-featured transport | |

    Thanks, cheers,

    Brian


    > On 18 May 2016, at 02:17, The IESG <iesg-secretary@xxxxxxxx
    <javascript:;>> wrote:
    >
    >
    > The IESG has received a request from the Transport Area Working
    Group WG
    > (tsvwg) to consider the following document:
    > - 'UDP Usage Guidelines'
    > <draft-ietf-tsvwg-rfc5405bis-13.txt> as Best Current Practice
    >
    > The IESG plans to make a decision in the next few weeks, and
    solicits
    > final comments on this action. Please send substantive comments
    to the
    > ietf@xxxxxxxx <javascript:;> mailing lists by 2016-05-31.
    Exceptionally, comments may be
    > sent to iesg@xxxxxxxx <javascript:;> instead. In either case,
    please retain the
    > beginning of the Subject line to allow automated sorting.
    >
    > Abstract
    >
    >
    >   The User Datagram Protocol (UDP) provides a minimal
    message-passing
> transport that has no inherent congestion control mechanisms. This
    >   document provides guidelines on the use of UDP for the
    designers of
> applications, tunnels and other protocols that use UDP. Congestion
    >   control guidelines are a primary focus, but the document also
    >   provides guidance on other topics, including message sizes,
    >   reliability, checksums, middlebox traversal, the use of ECN,
    DSCPs,
    >   and ports.
    >
    >   Because congestion control is critical to the stable operation
    of the
    >   Internet, applications and other protocols that choose to use
    UDP as
    >   an Internet transport must employ mechanisms to prevent congestion
    >   collapse and to establish some degree of fairness with concurrent
    >   traffic.  They may also need to implement additional mechanisms,
    >   depending on how they use UDP.
    >
    >   Some guidance is also applicable to the design of other protocols
    >   (e.g., protocols layered directly on IP or via IP-based tunnels),
    >   especially when these protocols do not themselves provide
    congestion
    >   control.
    >
    >   This document obsoletes RFC5405 and adds guidelines for
    multicast UDP
    >   usage.
    >
    >
    >
    >
    > The file can be obtained via
    > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/
    >
    > IESG discussion can be tracked via
    > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/
    >
    >
    > No IPR declarations have been submitted directly on this I-D.
    >
    >


I disagree. The text as-is is best and represents a prudent period of review in the WG. As suggested many times to both spud and quic, extending udp is not recommended. We have multiple L4 transport protocols for a reason, you should innovative in that space without UDP.

CB




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]