[tsvwg] Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guide

On Sunday, June 5, 2016, Jim Roskind <JimRoskind(_at_)gmail(_dot_)com
<javascript:_e(%7B%7D,'cvml','JimRoskind(_at_)gmail(_dot_)com');>> wrote:

> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <tom(_at_)herbertland(_dot_)com> 
> wrote:
>
> > On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell <ietf(_at_)trammell(_dot_)ch> 
> > 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 would agree, this paragraph also seems a little self
> > contradictory.There is an acknowledgment that "middleboxes that only
> > support TCP and UDP are not rare", but then the next sentence
> > recommends the use of several other protocols besides UDP and TCP. If
> > I put these two together, the only congested controlled protocol that
> > is recommended and expected to work on the Internet is TCP.
> +1   TCP (implemented in kernel space) can't possibly evolve congestion
> avoidance as fast as the Internet has changed, or will change (example:
> good handling of middle boxes that use "policers" rather than some flavor
> of buffer-size based packet-drop).
> The rationale for using UDP for QUIC was indeed that a new IP number would
> never make it through the Internet (other protocol deployment attempts have
> commonly verified this).  It turns out that even UDP is partially blocked
> (as recently as 2011) by paths to 5-7% of all chrome clients, which lead to
> the "automated fallback" elements of QUIC,
I think this changes with ipv6, no?  Google sees over 26% ipv6 in the usa
and growing quickly

http://www.google.com/intl/en/ipv6/statistics.html

And there is evidence that middle boxes go away in ipv6. .... So perhaps
the world is changing and your assuptions do not hold



>
Hopefully the benefits that QUIC is bringing to the Internet will not be
> outlawed (precluded by such commentary).
>
> Jim
>
>
> > Tom
> >
> > > 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(_at_)ietf(_dot_)org> 
> > > > 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(_at_)ietf(_dot_)org mailing lists by 2016-05-31. Exceptionally, 
> > > > comments
> > may be
> > > > sent to iesg(_at_)ietf(_dot_)org 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.
> > >
> > > _______________________________________________
> > > Spud mailing list
> > > Spud(_at_)ietf(_dot_)org
> > > https://www.ietf.org/mailman/listinfo/spud
> > _______________________________________________
> > QUIC mailing list
> > QUIC(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/quic