Re: [tsvwg] Protocol Action: 'UDP Usage Guidelines' to Best Current Practice (draft-ietf-tsvwg-rfc5405bis-19.txt)

"Black, David" <David.Black@dell.com> Mon, 14 November 2016 02:09 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927CF1293EE; Sun, 13 Nov 2016 18:09:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=bKhxZlCm; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=GIQLd/gX
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 QpxlsE8BeiGJ; Sun, 13 Nov 2016 18:09:31 -0800 (PST)
Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C9312956E; Sun, 13 Nov 2016 18:09:30 -0800 (PST)
DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=exTgBy/ZAzahOFz+wn6yOzTuRw7yfyQ6lskGHGw+CGJzCBr7JJBXOPt4 4B6yGF3ynV0vJ3RbtxXa+I0TC5cFtLXKdHrN147D58cdm9Oten2oEnIfj BbprTMp9lUnOWjze2G012Std/HFkB6S/xp6/h/j/im6pOBfrsouit9Q0x c=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1479089370; x=1510625370; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zScyCj5yuyN3l56ng9381t4NG0vqddf9Zz+D+KPCi+g=; b=bKhxZlCmcf43A65qP0Zvjfg12Pb+JnmC/40bKiW2gKqIiSQenDI/BskW ojb59Ye3BS94OBZMdVAysu9CBO04/IjPsspoPCH4JSW21UkXS1/dmCjc3 jtlWh3DCdK9a/Ptfpot+62qEYq2KQ/3E+10WabeDaFP7N4QEp7dsysmwY c=;
Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2016 20:09:30 -0600
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2016 08:09:29 +0600
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uAE29S6v023787 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Nov 2016 21:09:29 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com uAE29S6v023787
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1479089369; bh=ksLQhhIsJHjzUjkrnrKW31UPbY8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GIQLd/gXGNuqzDJdCXMeVErm/qJ+jBvennrFYb5m5I57zHIb/RqoA99PRj0o2r9X0 MUwMfBfPTq/97drLiL12CyJqdMONok8391b5Whfb7mKH2WS8iev4UY4/sGMwxtl1uU 9UwzYFYzJwoq87j574yit3B/ESwfdbLuYobsYtMs=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com uAE29S6v023787
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Sun, 13 Nov 2016 21:07:33 -0500
Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uAE29ER5008850 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sun, 13 Nov 2016 21:09:15 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Sun, 13 Nov 2016 21:09:14 -0500
To: "draft-ietf-tsvwg-rfc5405bis@ietf.org" <draft-ietf-tsvwg-rfc5405bis@ietf.org>
Thread-Topic: Protocol Action: 'UDP Usage Guidelines' to Best Current Practice (draft-ietf-tsvwg-rfc5405bis-19.txt)
Thread-Index: AQHSPhfux2Hw/+tyrUif9t1BtYiRT6DXuoCQ
Date: Mon, 14 Nov 2016 02:09:13 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F728E83@MX307CL04.corp.emc.com>
References: <147908756151.5627.11405713025831295684.idtracker@ietfa.amsl.com>
In-Reply-To: <147908756151.5627.11405713025831295684.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.105.8.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/feC6yDMctp01HszcAJnx7aQk_UI>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [tsvwg] Protocol Action: 'UDP Usage Guidelines' to Best Current Practice (draft-ietf-tsvwg-rfc5405bis-19.txt)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2016 02:09:33 -0000

Congratulations to the long-serving (suffering?) authors of this draft, and many thanks
to everyone who contributed.   This will be an important RFC for the IETF, e.g., as
there are already multiple drafts at the RFC Editor waiting for this one to arrive.

Thanks, --David


> -----Original Message-----
> From: The IESG [mailto:iesg-secretary@ietf.org]
> Sent: Sunday, November 13, 2016 8:39 PM
> To: IETF-Announce
> Cc: Black, David; tsvwg@ietf.org; Black, David; draft-ietf-tsvwg-
> rfc5405bis@ietf.org; spencerdawkins.ietf@gmail.com; The IESG; rfc-editor@rfc-
> editor.org; tsvwg-chairs@ietf.org
> Subject: Protocol Action: 'UDP Usage Guidelines' to Best Current Practice (draft-
> ietf-tsvwg-rfc5405bis-19.txt)
> 
> The IESG has approved the following document:
> - 'UDP Usage Guidelines'
>   (draft-ietf-tsvwg-rfc5405bis-19.txt) as Best Current Practice
> 
> This document is the product of the Transport Area Working Group.
> 
> The IESG contact persons are Mirja K??hlewind and Spencer Dawkins.
> 
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/
> 
> 
> 
> 
> Technical Summary
> 
>    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.
> 
> Working Group Summary
> 
>     The Transport Area WG (TSVWG) is a collection of people with varied
>     interests that don't individually justify their own working groups.
> 
>    This draft is supported by the portion of the TSVWG working group that
>    is familiar with and interested in UDP and congestion control.  The
>    draft has received significant review and critique from a number of
>    WG members and has undergone significant modification as a result.  A
>    significant area of expansion over RFC 5405 is the addition of multicast
>    guidelines; this UDP multicast guideline work began in a separate draft
>    that was merged into this draft by the WG so that protocol designers
>    would have one place to look for UDP guidelines.
> 
>    Recent discussion in the WG has focused on issues related to the
>    increasing use of UDP to encapsulate other protocols; an important
>    outcome is the addition of Section 3.6 on Limited Applicability
>    and Controlled Environments where aspects such as equipment robustness
>    and operator traffic management may substitute for protocol features
>    (e.g., checksums, congestion management) that are necessary in
>    unrestricted environments such as the Internet in general.  This
>    draft incorporates guidelines based on lessons learned from
>    MPLS/UDP (RFC 7510), GRE/UDP (recent TSVWG WG Last Call) and the
>    routing area encapsulation design team's work (much broader draft
>    in the RTGWG WG).
> 
> Document Quality
> 
>    In addition to Last Call reviews by Martin Stiemerling (for TSV-ART),
>    Ronald Bonica (for RTG-DIR), Paul Kyzivat (for Gen-ART),
>    Takeshi Takahashi (for SEC-DIR), and Tim Chown (for OPS-DIR),
>    Mark Allman helped to reconcile protocol timer guidelines in this draft
>    (for UDP) with the protocol timer guidelines from TCPM (for TCP).
> 
> Personnel
> 
>    Document Shepherd: David Black
>    Responsible AD: Spencer Dawkins