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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 03 June 2016 15:28 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAD612D1BD; Fri, 3 Jun 2016 08:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level:
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52pLwdu_uaHa; Fri, 3 Jun 2016 08:28:20 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB712D6D4; Fri, 3 Jun 2016 08:28:20 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id B75A41B00259; Fri, 3 Jun 2016 16:40:30 +0100 (BST)
Message-ID: <5751A209.70601@erg.abdn.ac.uk>
Date: Fri, 03 Jun 2016 16:28:09 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ca By <cb.list6@gmail.com>
Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guidelines) to Best Current Practice
References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> <CAD6AjGROkQb76zHLb91WtJPUom+MsktYYDSbWc1N=oWdU6DpQQ@mail.gmail.com>
In-Reply-To: <CAD6AjGROkQb76zHLb91WtJPUom+MsktYYDSbWc1N=oWdU6DpQQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/OT_KsUME2YxSctYewQMsWvIED0w>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-tsvwg-rfc5405bis@ietf.org" <draft-ietf-tsvwg-rfc5405bis@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, spud <spud@ietf.org>, "quic@ietf.org" <quic@ietf.org>, tsvwg WG <tsvwg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jun 2016 15:28:23 -0000

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@trammell.ch 
> <mailto:ietf@trammell.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 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@ietf.org
>     <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@ietf.org <javascript:;> mailing lists by 2016-05-31.
>     Exceptionally, comments may be
>     > sent to iesg@ietf.org <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