ietf
[Top] [All Lists]

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

2016-06-02 05:12:56
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(_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.



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail