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

[Gorry Fairhurst <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <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
>     > [e-mail] <javascript:;> mailing lists by 2016-05-31.
>     Exceptionally, comments may be
>     > sent to [e-mail] <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