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

Tom Herbert <tom@herbertland.com> Sun, 05 June 2016 00:25 UTC

Return-Path: <tom@herbertland.com>
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 489D212D5E9 for <ietf@ietfa.amsl.com>; Sat, 4 Jun 2016 17:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 R4SLr12XO3ZK for <ietf@ietfa.amsl.com>; Sat, 4 Jun 2016 17:25:42 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF5F12D539 for <ietf@ietf.org>; Sat, 4 Jun 2016 17:25:40 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id f67so17531518ith.1 for <ietf@ietf.org>; Sat, 04 Jun 2016 17:25:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=Tr9nltT73o9INI2kp840W1290VmBxSOBrHWqjzzCmZE=; b=JbafQv+6RcTTveWpgFwnlmWjldtJijYi6YOkNX5czrV8ePdOx3GKDicjj7hJf9bQKI OBBeH+Hjiy/z82gRL1s3x0q1oBbn8dbk0TLoSBvRWJdRy7kvrM/15tbfZL1VbRBO02GF +LlKPvo20g2VRTr9uoJU36k5Uxfb8Aaj348w5W5GJFPNlTJQ2F+b35dfkDybA9JfQT/P fyrM4P4K7xss3JSfZflk1dqYaVdRCxVOmT0stuMdSmwTSgV158cGKCcQnb8hg6+mgzmi Q4IY8YG256gyLU2ZklcGlN0NqzrHFfb7SmBpOhe30YrpBljlIb99iZMGYXEOhQ9eFOa0 K51w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Tr9nltT73o9INI2kp840W1290VmBxSOBrHWqjzzCmZE=; b=kQlWwYPewGSeXAmfxd4UBCaqzYya1Byek2D1YW4G91tE0/TzNZ8jrJ+E9i0OYWqWxA pms01Ajt9ClsggJl+PDZhGWL1MdrUbUMi5TgiMDs6xtosN/a1UWn4Zm0bZsFUgnGJD2u RcDiJy5gsb3vfGpl2jhCdfpDnOMR3FCPT5fI9TFuFkzHfZbyzGFn2OH4B+kFLdB2T35f BtKqNHIKFZoAGOw5GKP9OdVJyphhnNvGiXH5A845uyq9tC+DJPXBtjFQPjHbJCb5YPn0 uRaA5HRD1NmRXy2lsTtihHPRz+KdQfRYRqEiRjd7rVAMwXH95b7H+UORKj0MrISm9mFb ZqhA==
X-Gm-Message-State: ALyK8tLKff3lqsb7wgDBnjcH6FbJg+uJWMGTAqJ5M62+zPJzwuuWjeV63qfrqkCD9KQCxzZp+ZOowKXHfUe4TQ==
MIME-Version: 1.0
X-Received: by 10.36.73.219 with SMTP id e88mr656270itd.88.1465086339582; Sat, 04 Jun 2016 17:25:39 -0700 (PDT)
Received: by 10.107.31.202 with HTTP; Sat, 4 Jun 2016 17:25:39 -0700 (PDT)
In-Reply-To: <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch>
References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch>
Date: Sat, 4 Jun 2016 17:25:39 -0700
Message-ID: <CALx6S34abJNgPM6w-U9=AwNs-wu9LeoE9uezni-c7scbxEHtdA@mail.gmail.com>
Subject: Re: [Spud] Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guidelines) to Best Current Practice
From: Tom Herbert <tom@herbertland.com>
To: Brian Trammell <ietf@trammell.ch>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/YZ4VzHenxkVljDZlkvgcb_W5dBc>
Cc: tsvwg WG <tsvwg@ietf.org>, draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, spud <spud@ietf.org>, quic@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Sun, 05 Jun 2016 00:25:44 -0000

On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell <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 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.

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@ietf.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@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may be
>> sent to iesg@ietf.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@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>