From nobody Sun May 5 13:54:56 2019 Return-Path: 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 295FC1200A4 for ; Sun, 5 May 2019 13:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] 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 ZCPtVY-bw2QK for ; Sun, 5 May 2019 13:54:52 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 3AA8812001E for ; Sun, 5 May 2019 13:54:52 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x45KslHG008819; Sun, 5 May 2019 21:54:47 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 14B6A22044; Sun, 5 May 2019 21:54:47 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id F396622042; Sun, 5 May 2019 21:54:46 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.228.68]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x45KsjDI020321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 May 2019 21:54:46 +0100 Reply-To: From: "Adrian Farrel" To: "'Magnus Westerlund'" , "'tsvwg'" References: In-Reply-To: Date: Sun, 5 May 2019 21:54:48 +0100 Organization: Old Dog Consulting Message-ID: <083b01d50384$c7325a70$55970f50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_083C_01D5038D.28F93370" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHW182zf5RVzpUn3/6+gLIgAGKSVgGxNJIdpkvNxhA= Content-Language: en-gb X-Originating-IP: 87.112.228.68 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24594.002 X-TM-AS-Result: No--19.515-10.0-31-10 X-imss-scan-details: No--19.515-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24594.002 X-TMASE-Result: 10--19.515000-10.000000 X-TMASE-MatchedRID: cxtZ8fwm3r/xIbpQ8BhdbAArNgt5xpQYt07/cudGAntBL//DKiVczudz d4Xg+cO5ptiFgxvHaW+d1tDvJsDZRIlZv19QmqyQlVHM/F6YkvTfUHAE9gT/4Ezz+HyIOnyiV6G JyRPLfOLwnyQYOXB6W+HOHmbNVg++CLTFoW0rIaq1PiMh4ZF39SDPOgHqOrGCcVGXoLjwQ0EjQv VIOqDwSthRpC0f1aNeZ7n+EfuKBg9L8zeWanPW8rxygpRxo469MUUuEZQPwBYwplGJ7NxS0xyMU 5KHsmt2MqXIprsw7E9JpV9rHFX3jzblc6Gei4nl9TVembY3XZL8BlbXy+O/WjqI/Q1zONHSW+v0 m5ycBq/OQf/S1XvtEBm20HYf5Ey/CRueYusp1xy2FK5J1KhC+9MxD/3e8TxdRtqpRW8sWyI9CUo n0NTGeaH/0NvSton7Xb8neq6EmT2fRSghnfviF9sfxZpQv2qMtPGelsKOu4hB06yZQQa9pbQREY Zm2yyngD7NlsAV2tKkLSzpHNTR2t5ZokMflaoNhDK4kXfgEbocDDLReGt4PfmUDxpFogQXo8WMk QWv6iXgT2zXYa9/nVwtzewu2M633FYX00nSXLgrN8z0HohG3kUYJ3RLQ0KyUksfa0BkH1ZHCJHK ZxXmn8BydtylvojGMW3zgs56HdJgO21BQaodlQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [tsvwg] RSVP Related Errata X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 20:54:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_083C_01D5038D.28F93370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey Magnus, Of course, this is right. But it is very minor and no one has been confused by it. You can probably mark it Held for Document Update. Thanks, Adrian From: tsvwg On Behalf Of Magnus Westerlund Sent: 27 March 2019 09:14 To: tsvwg Subject: Re: [tsvwg] RSVP Related Errata Hi, Correct link is: https://www.rfc-editor.org/errata/eid4732 /Magnus On 2019-03-27 10:02, Magnus Westerlund wrote: Hi, There are an editorial Errata https://trac.ietf.org/trac/iesg/wiki/CoaffiliatedADs that correct: Section Appendix A.5 says: Error Value A two-octet field containing additional information about the error. Its contents depend upon the Error Type. The "Error Type" is proposed to be corrected to "Error Code". To me this appears to be correct Errata and can be approved. If you have any opinions please state within the next week. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------=_NextPart_000_083C_01D5038D.28F93370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey = Magnus,

 

Of course, this is = right. But it is very minor and no one has been confused by = it.

 

You can probably = mark it Held for Document Update.

 

Thanks,<= /span>

Adrian

 

From: tsvwg = <tsvwg-bounces@ietf.org> On Behalf Of Magnus = Westerlund
Sent: 27 March 2019 09:14
To: tsvwg = <tsvwg@ietf.org>
Subject: Re: [tsvwg] RSVP Related = Errata

 

Hi,

 

 

/Magnus

 

 

On 2019-03-27 10:02, Magnus Westerlund = wrote:

Hi,

Th= ere are an editorial Errata https://tra= c.ietf.org/trac/iesg/wiki/CoaffiliatedADs that = correct:

Section Appendix A.5 says: =

      Error =
Value
 
   =
        A two-octet field containing =
additional information about =
the
        =
        error.  Its contents =
depend upon the Error =
Type.
 
 <=
/pre>
The "Error Type" is proposed to be corrected to =
"Error Code". =
 
To me this appears to =
be correct Errata and can be approved. If you have any =
opinions please state within the next week. =
Cheers =
 
Magnus Westerlund =
 
-----------------------=
-----------------------------------------------
Netw=
ork Architecture & Protocols, Ericsson =
Research
-------------------------------------------=
---------------------------
Ericsson =
AB            =
;     | Phone  +46 10 =
7148287
Torshamnsgatan =
23           | Mobile =
+46 73 0949079
SE-164 80 Stockholm, Sweden | =
mailto: magnus.westerlund@ericsson=
.com
-------------------------------------------=
---------------------------

 

-- 
 
Magnus =
Westerlund =
 
-----------------------=
-----------------------------------------------
Netw=
ork Architecture & Protocols, Ericsson =
Research
-------------------------------------------=
---------------------------
Ericsson =
AB            =
;     | Phone  +46 10 =
7148287
Torshamnsgatan =
23           | Mobile =
+46 73 0949079
SE-164 80 Stockholm, Sweden | =
mailto: magnus.westerlund@ericsson=
.com
-------------------------------------------=
---------------------------
------=_NextPart_000_083C_01D5038D.28F93370-- From nobody Sun May 5 19:17:37 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2901120025; Sun, 5 May 2019 19:17:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155710905577.5227.13183949961648036552@ietfa.amsl.com> Date: Sun, 05 May 2019 19:17:35 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 02:17:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Tunnel Congestion Feedback Authors : Xinpeng Wei Yizhou Li Sami Boutros Liang Geng Filename : draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt Pages : 18 Date : 2019-05-05 Abstract: This document describes a method to measure congestion on a tunnel segment based on recommendations from RFC 6040, "Tunneling of Explicit Congestion Notification", and to use IPFIX to communicate the congestion measurements from the tunnel's egress to a controller which can respond by modifying the traffic control policies at the tunnel's ingress. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-tunnel-congestion-feedback/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-tunnel-congestion-feedback-07 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-tunnel-congestion-feedback-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-tunnel-congestion-feedback-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 5 19:40:21 2019 Return-Path: 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 9CB8212003E; Sun, 5 May 2019 19:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 KOe3rAYFEv55; Sun, 5 May 2019 19:40:16 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F22EE12001B; Sun, 5 May 2019 19:40:15 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1B293369D86462D158AC; Mon, 6 May 2019 03:40:14 +0100 (IST) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 6 May 2019 03:40:13 +0100 Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 6 May 2019 03:40:13 +0100 Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 6 May 2019 03:40:12 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Mon, 6 May 2019 10:40:07 +0800 From: "Weixinpeng (Jackie)" To: "tsvwg@ietf.org" CC: "loops@ietf.org" Thread-Topic: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt Thread-Index: AQHVA7Hk3nBKZLQ6KkaWvp6cfd34LqZdYbLg Date: Mon, 6 May 2019 02:40:06 +0000 Message-ID: References: <155710905607.5227.1766692799016230284.idtracker@ietfa.amsl.com> In-Reply-To: <155710905607.5227.1766692799016230284.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.191] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 02:40:19 -0000 SGksDQoNCldlIGFyZSByZWFjdGl2YXRpbmcgdGhlIGZvbGxvd2luZyBkb2N1bWVudCBhcyBpdCBo YXMgYmVlbiBmb3VuZCBvdXQgdXNlZnVsIGZvciBzb21lIG9uZ29pbmcgd29yaywgaS5lLiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1uc2gtZWNuLXN1cHBv cnQvICBhbmQgTE9PUFMgKExvY2FsaXplZCBPcHRpbWl6YXRpb24gb2YgUGF0aCBTZWdtZW50cyku DQoNCkkgY2MnZWQgdG8gTE9PUFMgbWFpbGluZyBsaXN0IGFzIEkgdGhpbmsgdGhpcyBtZWNoYW5p c20gcHJvdmlkZXMgc3VwcGxlbWVudGFyeSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgdHVubmVsICAo cGF0aCBzZWdtZW50IGluIExPT1BTIHRlcm1pbm9sb2d5KSAgY29uZ2VzdGlvbiBsZXZlbCB3aGlj aCBtaWdodCBiZW5lZml0IExPT1BTIHRvIGRldGVybWluZSBpZiBhIGxvY2FsIHJlY292ZXJ5IGlz IG5lY2Vzc2FyeSBhbmQgaWYgYSBsb3NzIHNpZ25hbCBzaG91bGQgYmUgcmVsYXllZCBiYWNrIHRv IGVuZCBob3N0IHNlbmRlciBmdXJ0aGVyLiAgV2l0aCBMT09QUywgaXQgY2FuIGJlIHVzZWQgdG9n ZXRoZXIgd2l0aCBzZWdtZW50IGJhc2VkIGxvY2FsIFJUVCBtZWFzdXJlbWVudCBpbmZvcm1hdGlv bi4gIE5vcm1hbGx5IENFIG1hcmtpbmcgc2hvdWxkIGhhcHBlbiBiZWZvcmUgYSByZWFsIHBhY2tl dCBsb3NzIGlmIGNvbmdlc3Rpb24gb2NjdXJzLiBTbyB3aGVuIHRoZXJlIGlzIGEgbG9zcyBkZXRl Y3RlZCBidXQgd2l0aCBsb3cgQ0UgbWFya2luZyByYXRpbywgbG9jYWwgcmVjb3ZlcnkgaXMgcmVh c29uYWJsZSB0byBiZSBwZXJmb3JtZWQgYW5kIHNpZ25hbCBvZiBhIGxvc3MgZXZlbnQgbWF5IG5v dCBiZSBuZWNlc3NhcmlseSByZWxheWVkIHRvIGVuZCBob3N0IHNlbmRlciB0byB0cmlnZ2VyIHdp bmRvdyByZWR1Y3Rpb24uIA0KSWYgRkVDIGlzIHVzZWQsIHRoaXMgaW5mb3JtYXRpb24gd291bGQg YmUgdXNlZnVsIGZvciB0dW5uZWwgRkVDIHBhcmFtZXRlciBzZXR0aW5ncywgc3VjaCBhcyB0aGUg bnVtYmVyIG9mIHN5bWJvbHMgaW4gYSBzb3VyY2UgYmxvY2sgYW5kIG51bWJlciBvZiByZXBhaXIg cGFja2V0cy4gSXQgbWlnaHQgYmUgd29ydGggbm90aW5nIHRoYXQgYSByYXRlIGxpbWl0ZXIgYXQg dHVubmVsIGluZ3Jlc3Mgd291bGQgYmUgcmVxdWlyZWQgdG8gYXZvaWQgb3ZlcnNob290aW5nIGlm IGNvbmdlc3Rpb24gb2NjdXJzLg0KDQpDdXJyZW50bHkgd2UgYXJlIHVzaW5nIElQRklYIHRvIGNh cnJ5IGJhY2sgdGhlIGluZm9ybWF0aW9uIGZyb20gdHVubmVsIGVncmVzcyB0byBpbmdyZXNzLiBM T09QUyBndXlzIG1heSB3YW50IHRvIHVzZSBzb21lIG90aGVyIGVuY2Fwc3VsYXRpb25zLiBZb3Ug YXJlIHdlbGNvbWUgdG8gYnJpbmcgaXQgdXAuDQoNClRoYW5rcywNCi0gWGlucGVuZyANCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE1heSAwNiwg MjAxOSAxMDoxOCBBTQ0KVG86IExpeWl6aG91IDxsaXlpemhvdUBodWF3ZWkuY29tPjsgU2FtaSBC b3V0cm9zIDxib3V0cm9zc0B2bXdhcmUuY29tPjsgV2VpeGlucGVuZyAoSmFja2llKSA8d2VpeGlu cGVuZ0BodWF3ZWkuY29tPjsgTGlhbmcgR2VuZyA8Z2VuZ2xpYW5nQGNoaW5hbW9iaWxlLmNvbT47 IExpeWl6aG91IDxsaXlpemhvdUBodWF3ZWkuY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNr LTA3LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXRzdndnLXR1bm5l bC1jb25nZXN0aW9uLWZlZWRiYWNrLTA3LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBZaXpob3UgTGkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpO YW1lOgkJZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFjaw0KUmV2aXNp b246CTA3DQpUaXRsZToJCVR1bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrDQpEb2N1bWVudCBkYXRl OgkyMDE5LTA1LTA2DQpHcm91cDoJCXRzdndnDQpQYWdlczoJCTE4DQpVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdHN2d2ctdHVu bmVsLWNvbmdlc3Rpb24tZmVlZGJhY2stMDcudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlv bi1mZWVkYmFjay8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFjay0wNw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10 c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFjaw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0 aW9uLWZlZWRiYWNrLTA3DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg YSBtZXRob2QgdG8gbWVhc3VyZSBjb25nZXN0aW9uIG9uIGEgdHVubmVsDQogICBzZWdtZW50IGJh c2VkIG9uIHJlY29tbWVuZGF0aW9ucyBmcm9tIFJGQyA2MDQwLCAiVHVubmVsaW5nIG9mDQogICBF eHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiIsIGFuZCB0byB1c2UgSVBGSVggdG8gY29t bXVuaWNhdGUNCiAgIHRoZSBjb25nZXN0aW9uIG1lYXN1cmVtZW50cyBmcm9tIHRoZSB0dW5uZWwn cyBlZ3Jlc3MgdG8gYSBjb250cm9sbGVyDQogICB3aGljaCBjYW4gcmVzcG9uZCBieSBtb2RpZnlp bmcgdGhlIHRyYWZmaWMgY29udHJvbCBwb2xpY2llcyBhdCB0aGUNCiAgIHR1bm5lbCdzIGluZ3Jl c3MuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue May 7 00:08:03 2019 Return-Path: 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 4FA1812010C; Tue, 7 May 2019 00:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 SrGVE9Ff2yal; Tue, 7 May 2019 00:07:50 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 32B9B1200A2; Tue, 7 May 2019 00:07:50 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7860EFFEAAEEFAC6BB48; Tue, 7 May 2019 08:07:47 +0100 (IST) Received: from dggeme705-chm.china.huawei.com (10.1.199.101) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 7 May 2019 08:07:09 +0100 Received: from dggeme758-chm.china.huawei.com (10.3.19.104) by dggeme705-chm.china.huawei.com (10.1.199.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Tue, 7 May 2019 15:07:07 +0800 Received: from dggeme758-chm.china.huawei.com ([10.6.80.69]) by dggeme758-chm.china.huawei.com ([10.6.80.69]) with mapi id 15.01.1591.008; Tue, 7 May 2019 15:07:07 +0800 From: "Zhouxingwang (Joe)" To: "Weixinpeng (Jackie)" , "tsvwg@ietf.org" CC: "loops@ietf.org" Thread-Topic: [LOOPS] FW: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt Thread-Index: AQHVBD4RuMGGfgHsCkm2PcR/q3lXNKZfKKGw Date: Tue, 7 May 2019 07:07:07 +0000 Message-ID: <27dbdbef64ad4681a80631add54109e2@huawei.com> References: <155710905607.5227.1766692799016230284.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.27.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] [LOOPS] FW: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 07:07:54 -0000 SGksIA0KDQpPbmUgY2hhbGxlbmdlIExPT1BTIGlzIGZhY2luZyBpcyB3aGV0aGVyIHRvIHBlcmZv cm0gbG9jYWwgcmVjb3Zlcnkgd2hlbiBwYWNrZXQgbG9zcyBoYXBwZW5zLCBhbmQgd2hldGhlciB0 byByZWxheSB0aGUgc2lnbmFsIG9mIGxvc3MgZXZlbnQgdG8gVENQICh2aWEgbWFya2luZyBFQ04p IHRvIHJlZHVjZSBzZW5kaW5nIHJhdGUgYWZ0ZXIgbG9jYWwgcmVjb3ZlcnkgcGVyZm9ybWVkLiBM T09QUyBtYXkgYm9ycm93IGVuZCBob3N0J3MgY3VycmVudCB0cmFuc3BvcnQgbGF5ZXIgaWRlYSB0 byBkbyBjb25nZXN0aW9uIGRldGVjdGlvbiB2aWEgbG9jYWwgbWVhc3VyZW1lbnQsIGxpa2UgUlRU IHZhcmlhdGlvbiwgcGFja2V0IGxvc3MgcmF0ZSwgZ29vZHB1dCwgZXRjLC4gT25jZSBMT09QUyBn b3QgdGhlIGNvbmdlc3Rpb24gaW5mb3JtYXRpb24gdGhlbiBpdCB3aWxsIGJlIGhlbHBmdWwgZm9y IGhhbmRsaW5nIHRoZSBjaGFsbGVuZ2UuDQoNClR1bm5lbC1Db25nZXN0aW9uLUZlZWRiYWNrIHBy b3ZpZGVzIExPT1BTIGEgc3RyYWlnaHQgZm9yd2FyZCB3YXkgdG8gZG8gdGhpcy4gSWYgQ0UgbWFy a2luZyBkb2VzIG5vdCBoYXBwZW4gYnV0IHBhY2tldCBsb3NzIGhhcHBlbnMsIExPT1BTIG1heSBw ZXJmb3JtIGxvY2FsIHJlY292ZXJ5IHNhZmVseSwgb3RoZXJ3aXNlIExPT1BTIHNob3VsZCByZWxh eSB0aGUgc2lnbmFsIG9mIGxvc3MgZXZlbnQgdG8gVENQIHRvIHJlZHVjZSBpdHMgc2VuZGluZyBy YXRlLiBUbyByZWxheSBzdWNoIGEgc2lnbmFsLCB3aGVuIHJldHJhbnNtaXNzaW9uIGlzIHVzZWQg Zm9yIGxvY2FsIHJlY292ZXJ5IG1lY2hhbmlzbSwgdHVubmVsIGVncmVzcyBub2RlIG1heSBjaG9v c2Ugbm90IHRvIGFzayB0aGUgaW5ncmVzcyBub2RlIHRvIGRvIHJldHJhbnNtaXNzaW9uOyB3aGVu IEZFQyBpcyB1c2VkLCBlZ3Jlc3Mgbm9kZSBtYXkgY2hvb3NlIG5vdCB0byByZWNvdmVyIHRoZSBs b3N0IHBhY2tldCB3aGVuIGUyZSBpcyBub24tRUNUIG9yIGNob29zZSB0byByZWNvdmVyeSB0aGUg bG9zcyBwYWNrZXRzIGFuZCBtYXJrIENFIGJpdCBvZiBpdCB3aGVuIGUyZSBpcyBFQ1QuDQoNClRv IG1lLCBmb3IgTE9PUFMsIGl0IGxvb2tzIGxpa2UgY2FycnlpbmcgdGhpcyBpbmZvcm1hdGlvbiBm cm9tIGVncmVzcyB0byBpbmdyZXNzIG1heSBub3QgYmUgbmVjZXNzYXJ5IHdoZW4gcmV0cmFuc21p c3Npb24gaXMgdXNlZC4gVGhlIGVncmVzcyBtYXkgZGVjaWRlIGJ5IGl0c2VsZiB3aGV0aGVyIHRv IGFzayBmb3IgYSByZXRyYW5zbWlzc2lvbiBieSBjb250cm9sbGluZyBob3cgdG8gYWNrbm93bGVk Z2UgdGhlIHJlY2VpdmVkIHBhY2tldHMuIEl0IG1heSBwcmV0ZW5kIGEgcGFja2V0IGhhcyBiZWVu IHJlY2VpdmVkIHRvIGluZ3Jlc3Mgc28gdGhhdCB0aGUgaW5ncmVzcyBkb2VzIG5vdCByZXRyYW5z bWl0IGl0LiANCg0KSWYgRkVDIGlzIHVzZWQsIGNhcnJ5aW5nIHRoaXMgaW5mb3JtYXRpb24gZnJv bSB0dW5uZWwgZWdyZXNzIGJhY2sgdG8gaW5ncmVzcyBzZWVtcyBoZWxwZnVsLiBBbnlvbmUgY291 bGQgcG9pbnQgb3V0IGFueSBleGlzdGluZyBleGFtcGxlcyBvbiBob3cgdGhlIEZFQyBjYW4gcG9z c2libHkgcmVhY3Qgb24gc3VjaCBpbmZvcm1hdGlvbiAobWF5IG5vdCBiZSBsaW1pdGVkIHRvIGlu Zm9ybWF0aW9uIG1lbnRpb25lZCBieSB0aGlzIGRyYWZ0LCBidXQgYWxzbyBvdGhlciBpbmZvcm1h dGlvbiBsaWtlIHNlZ21lbnQgUlRULCBnb29kcHV0LCBsb3NzIHJhdGUsIGV0Yyk/DQoNClRoYW5r cw0KSm9lDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXZWl4aW5wZW5nIChK YWNraWUpIFttYWlsdG86d2VpeGlucGVuZ0BodWF3ZWkuY29tXSANClNlbnQ6IE1vbmRheSwgTWF5 IDA2LCAyMDE5IDEwOjQwIEFNDQpUbzogdHN2d2dAaWV0Zi5vcmcNCkNjOiBsb29wc0BpZXRmLm9y Zw0KU3ViamVjdDogW0xPT1BTXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrLTA3LnR4dA0KDQpIaSwNCg0K V2UgYXJlIHJlYWN0aXZhdGluZyB0aGUgZm9sbG93aW5nIGRvY3VtZW50IGFzIGl0IGhhcyBiZWVu IGZvdW5kIG91dCB1c2VmdWwgZm9yIHNvbWUgb25nb2luZyB3b3JrLCBpLmUuIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC1lY24tc3VwcG9ydC8gIGFu ZCBMT09QUyAoTG9jYWxpemVkIE9wdGltaXphdGlvbiBvZiBQYXRoIFNlZ21lbnRzKS4NCg0KSSBj YydlZCB0byBMT09QUyBtYWlsaW5nIGxpc3QgYXMgSSB0aGluayB0aGlzIG1lY2hhbmlzbSBwcm92 aWRlcyBzdXBwbGVtZW50YXJ5IGluZm9ybWF0aW9uIGFib3V0IHRoZSB0dW5uZWwgIChwYXRoIHNl Z21lbnQgaW4gTE9PUFMgdGVybWlub2xvZ3kpICBjb25nZXN0aW9uIGxldmVsIHdoaWNoIG1pZ2h0 IGJlbmVmaXQgTE9PUFMgdG8gZGV0ZXJtaW5lIGlmIGEgbG9jYWwgcmVjb3ZlcnkgaXMgbmVjZXNz YXJ5IGFuZCBpZiBhIGxvc3Mgc2lnbmFsIHNob3VsZCBiZSByZWxheWVkIGJhY2sgdG8gZW5kIGhv c3Qgc2VuZGVyIGZ1cnRoZXIuICBXaXRoIExPT1BTLCBpdCBjYW4gYmUgdXNlZCB0b2dldGhlciB3 aXRoIHNlZ21lbnQgYmFzZWQgbG9jYWwgUlRUIG1lYXN1cmVtZW50IGluZm9ybWF0aW9uLiAgTm9y bWFsbHkgQ0UgbWFya2luZyBzaG91bGQgaGFwcGVuIGJlZm9yZSBhIHJlYWwgcGFja2V0IGxvc3Mg aWYgY29uZ2VzdGlvbiBvY2N1cnMuIFNvIHdoZW4gdGhlcmUgaXMgYSBsb3NzIGRldGVjdGVkIGJ1 dCB3aXRoIGxvdyBDRSBtYXJraW5nIHJhdGlvLCBsb2NhbCByZWNvdmVyeSBpcyByZWFzb25hYmxl IHRvIGJlIHBlcmZvcm1lZCBhbmQgc2lnbmFsIG9mIGEgbG9zcyBldmVudCBtYXkgbm90IGJlIG5l Y2Vzc2FyaWx5IHJlbGF5ZWQgdG8gZW5kIGhvc3Qgc2VuZGVyIHRvIHRyaWdnZXIgd2luZG93IHJl ZHVjdGlvbi4gDQpJZiBGRUMgaXMgdXNlZCwgdGhpcyBpbmZvcm1hdGlvbiB3b3VsZCBiZSB1c2Vm dWwgZm9yIHR1bm5lbCBGRUMgcGFyYW1ldGVyIHNldHRpbmdzLCBzdWNoIGFzIHRoZSBudW1iZXIg b2Ygc3ltYm9scyBpbiBhIHNvdXJjZSBibG9jayBhbmQgbnVtYmVyIG9mIHJlcGFpciBwYWNrZXRz LiBJdCBtaWdodCBiZSB3b3J0aCBub3RpbmcgdGhhdCBhIHJhdGUgbGltaXRlciBhdCB0dW5uZWwg aW5ncmVzcyB3b3VsZCBiZSByZXF1aXJlZCB0byBhdm9pZCBvdmVyc2hvb3RpbmcgaWYgY29uZ2Vz dGlvbiBvY2N1cnMuDQoNCkN1cnJlbnRseSB3ZSBhcmUgdXNpbmcgSVBGSVggdG8gY2FycnkgYmFj ayB0aGUgaW5mb3JtYXRpb24gZnJvbSB0dW5uZWwgZWdyZXNzIHRvIGluZ3Jlc3MuIExPT1BTIGd1 eXMgbWF5IHdhbnQgdG8gdXNlIHNvbWUgb3RoZXIgZW5jYXBzdWxhdGlvbnMuIFlvdSBhcmUgd2Vs Y29tZSB0byBicmluZyBpdCB1cC4NCg0KVGhhbmtzLA0KLSBYaW5wZW5nIA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgTWF5IDA2LCAyMDE5IDEw OjE4IEFNDQpUbzogTGl5aXpob3UgPGxpeWl6aG91QGh1YXdlaS5jb20+OyBTYW1pIEJvdXRyb3Mg PGJvdXRyb3NzQHZtd2FyZS5jb20+OyBXZWl4aW5wZW5nIChKYWNraWUpIDx3ZWl4aW5wZW5nQGh1 YXdlaS5jb20+OyBMaWFuZyBHZW5nIDxnZW5nbGlhbmdAY2hpbmFtb2JpbGUuY29tPjsgTGl5aXpo b3UgPGxpeWl6aG91QGh1YXdlaS5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2stMDcudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdl c3Rpb24tZmVlZGJhY2stMDcudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFlpemhvdSBMaSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlk cmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrDQpSZXZpc2lvbjoJMDcN ClRpdGxlOgkJVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2sNCkRvY3VtZW50IGRhdGU6CTIwMTkt MDUtMDYNCkdyb3VwOgkJdHN2d2cNClBhZ2VzOgkJMTgNClVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29u Z2VzdGlvbi1mZWVkYmFjay0wNy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRi YWNrLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrLTA3DQpIdG1saXplZDogICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXR1 bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVl ZGJhY2stMDcNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhv ZCB0byBtZWFzdXJlIGNvbmdlc3Rpb24gb24gYSB0dW5uZWwNCiAgIHNlZ21lbnQgYmFzZWQgb24g cmVjb21tZW5kYXRpb25zIGZyb20gUkZDIDYwNDAsICJUdW5uZWxpbmcgb2YNCiAgIEV4cGxpY2l0 IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIiwgYW5kIHRvIHVzZSBJUEZJWCB0byBjb21tdW5pY2F0 ZQ0KICAgdGhlIGNvbmdlc3Rpb24gbWVhc3VyZW1lbnRzIGZyb20gdGhlIHR1bm5lbCdzIGVncmVz cyB0byBhIGNvbnRyb2xsZXINCiAgIHdoaWNoIGNhbiByZXNwb25kIGJ5IG1vZGlmeWluZyB0aGUg dHJhZmZpYyBjb250cm9sIHBvbGljaWVzIGF0IHRoZQ0KICAgdHVubmVsJ3MgaW5ncmVzcy4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed May 8 05:52:18 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C94120116; Wed, 8 May 2019 05:52:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant via Datatracker To: Cc: ietf@ietf.org, draft-ietf-tsvwg-tinymt32.all@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stewart Bryant Message-ID: <155731992421.22706.18402243276597862967@ietfa.amsl.com> Date: Wed, 08 May 2019 05:52:04 -0700 Archived-At: Subject: [tsvwg] Genart last call review of draft-ietf-tsvwg-tinymt32-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 12:52:05 -0000 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tsvwg-tinymt32-01 Reviewer: Stewart Bryant Review Date: 2019-05-08 IETF LC End Date: 2019-05-13 IESG Telechat date: Not scheduled for a telechat Summary: A well written document. There are a few review comments below that the authors should consider. Major issues: None Minor issues: According to statistical tests (BigCrush in TestU01 and AdaptiveCrush ) the quality of the outputs of TinyMT seems pretty good, SB> It would be useful to the reader to specify "pretty good" ========= The TinyMT32 PRNG initialization depends, among other things, on a parameter set -- namely (mat1, mat2, tmat) -- SB> These probably need a few words of explanation on introduction. ======== static void tinymt32_next_state (tinymt32_t * s); SB> I assume that this notation is good C, but SB> type space star space name does not seem common. SB> This may confuse some readers. One more often SB> sees one of the spaces omitted. ========= Nits/editorial comments: This specialisation aims at having a simple-to-use and deterministic PRNG, as explained below. SB> I assume that "deterministic PRNG" is a term of the art, but the SB> it sounds like an oxymoron to the uninitiated. Perhaps a word SB> or two would clarify. ======= From estellnb@elstel.org Wed May 8 08:03:43 2019 Return-Path: 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 096F8120123 for ; Wed, 8 May 2019 08:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=elstel.org 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 bIC7uL8bHYSi for ; Wed, 8 May 2019 08:03:39 -0700 (PDT) Received: from mailout2.dotplex.com (mailout2.dotplex.com [IPv6:2a0c:5f00:1:114::]) (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 3E2DD12012B for ; Wed, 8 May 2019 08:03:26 -0700 (PDT) Received: from remote.ip.hidden (remote.ip.hidden [127.0.0.1]) (Authenticated sender: estellnb@elstel.org) by mailout.dotplex.com (Postfix) with ESMTPSA id 88EFA20803 for ; Wed, 8 May 2019 17:03:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elstel.org; s=dotplex190506; t=1557327803; bh=u4wce8jw8aep7AZHTTCjLdHE0IH4rvjmIzr/PlnudqA=; h=To:From:Subject:Date:From; b=axxb9XftsodW3bcR88tcXOj3vYiHMwplX75GWJYV5pDSI6h5XSmxO4iLT8pzM7KCU GYqRtTWe6av1emWJxDv0MP2UBPk0VjtHaMafl/5VjKDiDTjEgDTr3Pk8AtvBbX6Jen U05uOXLxm15uwPHEGQ4QaHgjxvbsFSiZsVxKrhCW8pk7Msh0rdeUZv7mXslrA9Noqy R4zyXNynf6+FuNXI82r819fXJnG1rQt63HtN0Cx6zsgFkfjpVC6X6yqea6eI9jVJVA DRt+hlt9BzpFG/tQjOR+AcqWw76gNoKL3u7PRlVKvqMPF+M1d5qXx5/2oXrAke+3BD vN+2w6+niFjvQ== To: tsvwg@ietf.org From: Elmar Stellnberger Message-ID: <1d70503b-62cd-fe9a-118f-4ea36f148d1e@elstel.org> Date: Wed, 8 May 2019 17:03:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 08 May 2019 12:54:57 -0700 Subject: [tsvwg] SSL connections with SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 15:05:17 -0000 I am planning to write a proxy for localhost which relays incoming tcp connections via an SCTP connection to a remote host. That way it should be possible to overcome lacking SCTP support for browsers. Now my question is how to best use SSL with SCTP. If I have established an open SSL SCTP connection and want to fork a new flow for the same connection do I have to repeat the SSL cipher negotiation or may I simply fork an existing SSL SCTP flow? From nobody Wed May 8 13:19:27 2019 Return-Path: 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 891C01200CE for ; Wed, 8 May 2019 13:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 Ky8HdTUrr4c3 for ; Wed, 8 May 2019 13:19:22 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8226012004B for ; Wed, 8 May 2019 13:19:21 -0700 (PDT) Received: from [IPv6:2003:cd:6f38:4a00:c9a9:efbf:2cfd:8c0a] (p200300CD6F384A00C9A9EFBF2CFD8C0A.dip0.t-ipconnect.de [IPv6:2003:cd:6f38:4a00:c9a9:efbf:2cfd:8c0a]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id EAD2B721E280D; Wed, 8 May 2019 22:19:17 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Michael Tuexen In-Reply-To: <1d70503b-62cd-fe9a-118f-4ea36f148d1e@elstel.org> Date: Wed, 8 May 2019 22:19:15 +0200 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d70503b-62cd-fe9a-118f-4ea36f148d1e@elstel.org> To: Elmar Stellnberger X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [tsvwg] SSL connections with SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 20:19:26 -0000 > On 8. May 2019, at 17:03, Elmar Stellnberger = wrote: >=20 > I am planning to write a proxy for localhost which relays incoming tcp = connections via an SCTP connection to a remote host. That way it should = be possible to overcome lacking SCTP support for browsers. Now my = question is how to best use SSL with SCTP. If I have established an open = SSL SCTP connection and want to fork a new flow for the same connection = do I have to repeat the SSL cipher negotiation or may I simply fork an = existing SSL SCTP flow? >=20 I would suggest to use DTLS/SCTP. This is supported by OpenSSL and you = can find some examples at https://github.com/nplab/DTLS-Examples. Best regards Michael= From nobody Wed May 8 17:11:10 2019 Return-Path: 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 C1A1E12019B for ; Wed, 8 May 2019 17:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=ybuGYOyG; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=On+wGbCz 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 zECrn6fX-tk5 for ; Wed, 8 May 2019 17:11:03 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 4544412014E for ; Wed, 8 May 2019 17:11:03 -0700 (PDT) Received: from pps.filterd (m0170393.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x48Nxg1k001931 for ; Wed, 8 May 2019 20:11:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=p3KqtqXL+8S8UKdBeRvDxwOcd5vS9XJPpDjQutmcNy8=; b=ybuGYOyGG4sJ5eS/LFgxw7L/nyahEZODdwmBa09UUTwF9BHBkTDVslv/KBapLQMKHpqe x4Ql1TLETiDlPo3hLft02MqwwQbTevPk0m/8PdHsuFo4KdMn+GZQMVyPUd0f7NBOjXAl j/Zk+i/MJbN7XyVrYI0+MMCY+Ilgq9i2Fbn2Of9b+zyT4kMVEMPrv9AlvqE1ej/tFFA6 9qSsZ2obXWwCi9RE/RHMhl8S7HomfSDBPOp4DUGNyf7YuW8LiNMYCjC22luxzP7c/ofi EA/UuSv5BAbNZIdI8k02Q2LM62whDwdtYNCH9XsyLeJVMbeWH4w88zSg6jy2pmpQLxE1 3Q== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2sbtcgkcru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 May 2019 20:11:01 -0400 Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4903ef2059955 for ; Wed, 8 May 2019 20:11:01 -0400 Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by mx0a-00154901.pphosted.com with ESMTP id 2sc6xqhmdt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 08 May 2019 20:11:00 -0400 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x490AwUE032147 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 May 2019 20:10:59 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x490AwUE032147 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1557360659; bh=c/JXP6RcNHoSQRKM+R71de55cbA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=On+wGbCzzdtgWbA8YULioa4kHpfU1rsM0IkyaHX3LMGbacZ+Yvf9Hk9lMmCz4QnqA 06H2ptF/k8ZZGEGpqoEw7H1neJzSpEYxqRGISiVErDX06DnbsqtisbSmfc+K2s4/gq gu1kTCcfj92HiSuWdEE/ycXwo18qaO7DJAu710yA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x490AwUE032147 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd52.lss.emc.com (RSA Interceptor) for ; Wed, 8 May 2019 20:10:36 -0400 Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x490AaKt009158 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 8 May 2019 20:10:37 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB308.corp.emc.com ([10.146.3.34]) with mapi id 14.03.0439.000; Wed, 8 May 2019 20:10:36 -0400 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12 Thread-Index: AdUF+PJKfYny0XdBSEe2JZXBy1PR5A== Date: Thu, 9 May 2019 00:10:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.130] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363055BB8DMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-08_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905080143 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905080143 Archived-At: Subject: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 00:11:09 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363055BB8DMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First of all, this is a well-written and comprehensive draft on ECN encapsu= lation design guidelines. I found no major issues, and all of the minor issues are truly minor - some= border on editorial, and all can be dealt with via relatively minor edits. --- Minor --- [A] Need an explicit statement of exactly what the update to RFC 3819 is, preferably in a section whose name uses "RFC 3819" and appears in the table of contents. Do this before some AD tells you to ;-). This is also the only thing that idnits found that needs attention. [B] 1. Introduction, first paragraph, last sentence The phrase "egress at any layer" is too general, hence incorrect (e.g., layer 7 was not intended to be included) - "lower layer" needs to be used for clarity. OLD If an egress at any layer is not ECN-aware, or if the ultimate receiver or sender is not ECN-aware, congestion needs to be indicated by dropping a packet, not marking it. NEW If a lower layer header that may contain ECN congestion indications is removed by an egress that is not ECN-aware, or if the ultimate receiver = or sender is not ECN-aware, then lower layer congestion needs to be indicat= ed by dropping a packet, not marking it. END [C] 1.1 Scope Second paragraph and the two-bullet list imply that RFC 4774 states that us= e of ECT(1) to signal alternative ECN semantics is a best current practice. That's not correct, as RFC 4774 covers only the first bullet on use of DSCP= , not the second bullet on use of ECT(1), as that second bullet is based sole= ly on RFC 8311. Some rewriting is in order to disconnect the second bullet fro= m RFC 4774. Based on this, all other places where RFC 4774 is mentioned or cited should be checked to determine whether RFC 8311 also ought to be mentioned or cite= d. [D] Page 5, first complete paragraph Alternative semantics for the ECN field can be defined to depend on the traffic class indicated by the DSCP. Therefore correct propagation of congestion signals could depend on correct propagation of the DSCP between the layers. This also depends on correct propagation across diffserv boundaries - that and the potential damage wrought by bleaching DSCPs to zero at such boundar= ies both deserve mention here. [E] 1.1 Scope, end of section In the feed-backward mode, propagation of congestion signals for multicast and anycast packets is out-of-scope (because it would be so complicated that it is hoped no-one would attempt such an abomination). Much as I may agree with it :-), the parenthetical remark is inappropriate for an archival RFC, and hence needs to be removed. [F] 2. Terminology ECN-PDU: A PDU that is part of a feedback loop within which all the nodes that need to propagate explicit congestion notifications back to the Load Regulator are ECN-capable. That first sentence is too broad as it includes both the forward and reverse directions of the feedback loop, whereas only the forward direction is intended (FWIW, the definition of PDU does not suffice to narrow this to the forward direction only). For example, a TCP packet with the ECE flag set in the TCP header and Not-ECT in the ECN field in the IP header would be an ECN-PDU under this definition, which is not what was intended. The immediately following definition of Not-ECN-PDU has the same problem. The narrowing concept that needs to be added is that if the PDU carries a congestion indication, then that congestion indication participates in such a feedback loop, and even that is subtle when there are multiple possible congestion indication locations. An example of the subtlety is that the same PDU may be an ECN-PDU in feed-up-and-forward mode because the layer 3 and 4 protocols support ECN but may be a Not-ECN-PDU for feed-forward-and-up mode because the L2 decapsulator ignores and discards L2 congestion indications. [G] 2. Terminology Congestion Baseline: The location of the function on the path that initialised the values of all congestion notification fields in a sequence of packets, before any are set to the congestion experienced (CE) codepoint if they experience congestion further downstream. Typically the original data source at layer-4. That's counter-intuitive - a baseline is a level, not a location. I've tagged this as a minor issue as opposed to editorial because it causes severe confusion in the only place that this term is used, namely item 3 in Section 4.3. That item 3 is about a Monitoring Baseline which is a level not a location. The Congestion Baseline term should be removed, and item 3 in Section 4.3 revised accordingly. The term "Congestion Baseline" is used twice there, but only the latter of those two uses needs to be retained and expanded after deletion of this definition. [H] 3. Modes of Operation Feed-Up-and-Forward: A lower layer switch feeds-up congestion notification directly into the ECN field in the higher layer (e.g. IP) header, irrespective of whether the node is at the egress of a subnet. Remove "the ECN field in" as that's too restrictive, even though that's a common case, and move it into the example - "(e.g., ECN field in the IP header)" where "header" moved inside the parentheses. [I] 3.3. Feed-Backward Mode Please make it clear that the critique of the ATM ABR relative rate control mechanism also applies to Ethernet QCN, as that's a more current example. This should be connected to the QCN discussion at the end of Section 4.2. [J] 4.3 Encapsulation Guidelines Resolving minor issue [G] requires some edits to item 3 in this section: - Remove "(the Congestion Baseline)" from the third paragraph. - Rewrite start of fourth paragraph: OLD Most information can be extracted if the Congestion Baseline is standardised at the node that is regulating the load (the Load Regulator--typically the data source). NEW More information can be extracted if the protocol specification requires that congestion fields be initialized to indicate no congestion only by the node that is regulating the load (the Load Regulator--typically the data source). END [K] 12.2 Informative References Please check the references to 802.1Qah and 802.1Qau with IEEE. The correct references to use now may be the latest version of 802.1Q with specific functionality and/or clauses identified. --- Editorial/Nits --- Abstract, last sentence Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. between new -> among IP layer and 1. Introduction, first paragraph Suggest removing use of the word "buffer" - "lower layer" suffices in all of the places where this word is used in this paragraph. 1. Introduction, second paragraph The purpose of this document is to guide the addition of congestion notification to any subnet technology or tunnelling protocol, so that lower layer equipment can signal congestion explicitly and it will propagate consistently into encapsulated (higher layer) headers, otherwise the signals will not reach their ultimate destination. Suggest: "equipment" -> "functionality" Page 5, first full paragraph: If a particular protocol design chooses to contradict a 'SHOULD (NOT)' given in the advice below, it MUST include a sound justification. chooses to contradict -> chooses not to follow 1.1. Scope, first paragraph This document only concerns wire protocol processing of explicit notification of congestion. Remove "wire" Section 3.1, second paragraph In these cases, ECN may best be supported by standardising explicit notification of congestion into the lower layer protocol that carries the data forwards. It will then also be necessary to define how the egress of the lower layer subnet propagates this explicit signal into the forwarded upper layer (IP) header. It can then continue forwards until it finally reaches the destination transport (at L4). Then typically the destination will feed this congestion notification back to the source transport using an end-to-end protocol (e.g. TCP). This is the arrangement that has already been used to add ECN to IP- in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129]. The referents of "It" at the start of the second and third sentences are unclear and different. Suggested rephrasings: It will then also be necessary to define -> This necessitates also specifying It can then continue -> This signal continues Section 3.1, first paragraph after Figure 1 Cite one or more of the 3GPP references for GTP tunnels, as this is the first occurrence of that concept in this draft. Section 3.1, second paragraph after Figure 1 Cite a Frame Relay reference for the FECN bit. Moving the [Buck00] citation up to immediately follow "Frame Relay" in the first line suffices. Section 3.2 first paragraph These are Ethernet switches that bury into the Ethernet payload ... bury -> burrow [Spelling checker is missing "read user's mind" feature :-)] Section 3.4 The second paragraph could be improved by citing references for fat-tree and Clos network topologies. Section 4.1, second paragraph Therefore section 4 of [I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to configure the ingress of a non-ECN tunnel so that it zeros the ECN field in the outer IP header. non-ECN tunnel -> tunnel that does not support ECN Section 4.1, third paragraph Even if the shim(s) encapsulate a L2 header, it is often possible to find an inner IP header within the L2 header Latter instance of "L2 header" should be "L2 PDU" Section 4.1, last paragraph Instead a companion specification [I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has sufficient standards track status to update standards track protocols. sufficient -> the appropriate Authors Addresses Please check these - Pat Thaler's contact info probably needs to be updated= . Thanks, --David ---------------------------------------------------------------- David L. Black, Senior Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (774) 350-9323 New Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949363055BB8DMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First of all, this is a well-written and comprehensi= ve draft on ECN encapsulation design guidelines.

 

I found no major issues, and all of the minor issues= are truly minor – some border on editorial,

and all can be dealt with via relatively minor edits= .

 

--- Minor ---

 

[A] Need an explicit statement of exactly wha= t the update to RFC 3819 is,

preferably in a section whose name uses "= ;RFC 3819" and appears in the

table of contents.  Do this before some = AD tells you to ;-).  This is

also the only thing that idnits found that ne= eds attention.

 

[B] 1. Introduction, first paragraph, last se= ntence

 

The phrase "egress at any layer" is= too general, hence incorrect (e.g.,

layer 7 was not intended to be included) - &q= uot;lower layer" needs to be

used for clarity.

 

OLD

   If an egress at any layer is not= ECN-aware, or if the

   ultimate receiver or sender is n= ot ECN-aware, congestion needs to be

   indicated by dropping a packet, = not marking it.

NEW

   If a lower layer header that may= contain ECN congestion indications is

   removed by an egress that is not= ECN-aware, or if the ultimate receiver or

   sender is not ECN-aware, then lo= wer layer congestion needs to be indicated

   by dropping a packet, not markin= g it.

END

 

[C] 1.1 Scope

 

Second paragraph and the two-bullet list impl= y that RFC 4774 states that use

of ECT(1) to signal alternative ECN semantics= is a best current practice.

That's not correct, as RFC 4774 covers only t= he first bullet on use of DSCP,

not the second bullet on use of ECT(1), as th= at second bullet is based solely

on RFC 8311. Some rewriting is in order to di= sconnect the second bullet from

RFC 4774.

 

Based on this, all other places where RFC 477= 4 is mentioned or cited should

be checked to determine whether RFC 8311 also= ought to be mentioned or cited.

 

[D] Page 5, first complete paragraph

 

   Alternative semantics for the EC= N field can be defined to depend on

   the traffic class indicated by t= he DSCP.  Therefore correct

   propagation of congestion signal= s could depend on correct propagation

   of the DSCP between the layers.<= o:p>

 

This also depends on correct propagation acro= ss diffserv boundaries - that

and the potential damage wrought by bleaching= DSCPs to zero at such boundaries

both deserve mention here.<= /p>

 

[E] 1.1 Scope, end of section

 

   In the feed-backward mode, propa= gation of

   congestion signals for multicast= and anycast packets is out-of-scope

   (because it would be so complica= ted that it is hoped no-one would

   attempt such an abomination).

 

Much as I may agree with it :-), the parenthe= tical remark is inappropriate

for an archival RFC, and hence needs to be re= moved.

 

[F] 2. Terminology

 

   ECN-PDU:  A PDU that is par= t of a feedback loop within which all the

      nodes that nee= d to propagate explicit congestion notifications

      back to the Lo= ad Regulator are ECN-capable.

 

That first sentence is too broad as it includ= es both the forward and

reverse directions of the feedback loop, wher= eas only the forward
direction is intended (FWIW, the definition of PDU does not suffice to=

narrow this to the forward direction only).&n= bsp; For example, a TCP packet

with the ECE flag set in the TCP header and N= ot-ECT in the ECN field in

the IP header would be an ECN-PDU under this = definition, which is not

what was intended.  The immediately foll= owing definition of Not-ECN-PDU

has the same problem.

 

The narrowing concept that needs to be added = is that if the PDU carries

a congestion indication, then that congestion= indication participates in

such a feedback loop, and even that is subtle= when there are multiple

possible congestion indication locations.&nbs= p; An example of the subtlety is

that the same PDU may be an ECN-PDU in feed-u= p-and-forward mode because

the layer 3 and 4 protocols support ECN but m= ay be a Not-ECN-PDU for

feed-forward-and-up mode because the L2 decap= sulator ignores and discards

L2 congestion indications.<= /p>

 

[G] 2. Terminology

 

   Congestion Baseline:  The l= ocation of the function on the path that

      initialised th= e values of all congestion notification fields in a

      sequence of pa= ckets, before any are set to the congestion

      experienced (C= E) codepoint if they experience congestion further

      downstream.&nb= sp; Typically the original data source at layer-4.

That's counter-intuitive - a baseline is a le= vel, not a location. I've

tagged this as a minor issue as opposed to ed= itorial because it causes

severe confusion in the only place that this = term is used, namely item 3

in Section 4.3.  That item 3 is about a = Monitoring Baseline which is

a level not a location.

 

The Congestion Baseline term should be remove= d, and item 3 in Section

4.3 revised accordingly.  The term "= ;Congestion Baseline" is used twice

there, but only the latter of those two uses = needs to be retained and

expanded after deletion of this definition.

 

[H] 3. Modes of Operation

 

      Feed-Up-and-Fo= rward:  A lower layer switch feeds-up congestion

       &nb= sp; notification directly into the ECN field in the higher layer=

       &nb= sp; (e.g.  IP) header, irrespective of whether the node is at the=

       &nb= sp; egress of a subnet.

 

Remove "the ECN field in" as that's= too restrictive, even though that's

a common case, and move it into the example &= #8211; “(e.g., ECN field in the

IP header)" where "header" mov= ed inside the parentheses.

 

[I] 3.3.  Feed-Backward Mode<= /span>

 

Please make it clear that the critique of the= ATM ABR relative rate

control mechanism also applies to Ethernet QC= N, as that's a more

current example.  This should be connect= ed to the QCN discussion at

the end of Section 4.2.

 

[J] 4.3 Encapsulation Guidelines

 

Resolving minor issue [G] requires some edits= to item 3 in this section:

- Remove "(the Congestion Baseline)"= ; from the third paragraph.

- Rewrite start of fourth paragraph:

 

OLD

       Most inf= ormation can be extracted if the Congestion Baseline is

       standard= ised at the node that is regulating the load (the Load

       Regulato= r--typically the data source).

NEW

       More inf= ormation can be extracted if the protocol specification

       requires= that congestion fields be initialized to indicate no

       congesti= on only by the node that is regulating the load (the

       Load Reg= ulator--typically the data source).

END

 

[K] 12.2 Informative References

 

Please check the references to 802.1Qah and 8= 02.1Qau with IEEE.  The

correct references to use now may be the late= st version of 802.1Q with

specific functionality and/or clauses identif= ied.

 

 

--- Editorial/Nits ---

 

Abstract, last sentence

 

   Following these guidelines shoul= d assure

   interworking between new lower l= ayer congestion notification

   mechanisms, whether specified by= the IETF or other standards bodies.

 

between new -> among IP layer and

 

1. Introduction, first paragraph

 

Suggest removing use of the word "buffer= " - "lower layer" suffices in

all of the places where this word is used in = this paragraph.

 

1. Introduction, second paragraph<= /span>

 

   The purpose of this document is = to guide the addition of congestion

   notification to any subnet techn= ology or tunnelling protocol, so that

   lower layer equipment can signal= congestion explicitly and it will

   propagate consistently into enca= psulated (higher layer) headers,

   otherwise the signals will not r= each their ultimate destination.

 

Suggest: "equipment" -> "fu= nctionality"

 

Page 5, first full paragraph:

 

   If a particular protocol design = chooses to contradict a

   'SHOULD (NOT)' given in the advi= ce below, it MUST include a sound

   justification.=

 

chooses to contradict -> chooses not to fo= llow

 

1.1. Scope, first paragraph=

 

   This document only concerns wire= protocol processing of explicit

   notification of congestion.=

 

Remove "wire"

 

Section 3.1, second paragraph

 

   In these cases, ECN may best be = supported by standardising explicit

   notification of congestion into = the lower layer protocol that carries

   the data forwards.  It will= then also be necessary to define how the

   egress of the lower layer subnet= propagates this explicit signal into

   the forwarded upper layer (IP) h= eader.  It can then continue forwards

   until it finally reaches the des= tination transport (at L4).  Then

   typically the destination will f= eed this congestion notification back

   to the source transport using an= end-to-end protocol (e.g.  TCP).

   This is the arrangement that has= already been used to add ECN to IP-

   in-IP tunnels [RFC6040], IP-in-M= PLS and MPLS-in-MPLS [RFC5129].

 

The referents of "It" at the start = of the second and third sentences are

unclear and different.  Suggested rephra= sings:

 

It will then also be necessary to define ->= ;

     This necessitates al= so specifying

 

It can then continue -> This signal contin= ues

 

Section 3.1, first paragraph after Figure 1

 

Cite one or more of the 3GPP references for G= TP tunnels, as this is the

first occurrence of that concept in this draf= t.

 

Section 3.1, second paragraph after Figure 1<= o:p>

 

Cite a Frame Relay reference for the FECN bit= .  Moving the [Buck00]

citation up to immediately follow "Frame= Relay" in the first line
suffices.

 

Section 3.2 first paragraph=

 

   These are Ethernet switches that= bury into the Ethernet payload ...

 

bury -> burrow

[Spelling checker is missing “read user= ’s mind” feature :-)]

 

Section 3.4

 

The second paragraph could be improved by cit= ing references for fat-tree

and Clos network topologies.

 

Section 4.1, second paragraph

 

   Therefore section 4 of

   [I-D.ietf-tsvwg-rfc6040update-sh= im] requires network operators to

   configure the ingress of a non-E= CN tunnel so that it zeros the ECN

   field in the outer IP header.

 

non-ECN tunnel -> tunnel that does not sup= port ECN

 

Section 4.1, third paragraph

 

   Even

   if the shim(s) encapsulate a L2 = header, it is often possible to find

   an inner IP header within the L2= header

 

Latter instance of "L2 header" shou= ld be "L2 PDU"

 

Section 4.1, last paragraph=

 

   Instead a companion specificatio= n

   [I-D.ietf-tsvwg-rfc6040update-sh= im] has been prepared that has

   sufficient standards track statu= s to update standards track

   protocols.

sufficient -> the appropriate

 

Authors Addresses

 

Please check these - Pat Thaler's contact inf= o probably needs to be updated.

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (774) 350-9323 New    M= obile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------= ------------

 

--_000_CE03DB3D7B45C245BCA0D243277949363055BB8DMX307CL04corpem_-- From nobody Wed May 8 17:50:36 2019 Return-Path: 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 EF1111201E8 for ; Wed, 8 May 2019 17:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=iuki/rBZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=eRghhbDT 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 14netgCTXC9d for ; Wed, 8 May 2019 17:50:26 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 D9D2012026C for ; Wed, 8 May 2019 17:50:26 -0700 (PDT) Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x490jt6n022844 for ; Wed, 8 May 2019 20:50:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=HsnXmNA9v+y7sp/HmS2TDj9lUfAHKU5zJ4cdLpsd1rk=; b=iuki/rBZO0oEBKhsw2RmYPdfS8clCKBjMsWK1X1He0ufWkXVyaNt/XQi5JVUdTVFW45K FKM6TR4ZIcLrILy8AX7xNLN7VYNccmRq6SiX8cGmJ5uGUog4wXet0aXaCejk9BUOkMZt hW+aGBszBb47K3FyTPYmsXbm4O42ValhIbTgnwyxiJXxjEl1imCokceUj7olDq1VJWL+ AXyjJvWzAgO63JSsQFmzuQc4IvmutICdQShviiJVInMWr4rBhFPih+O3YFzUB27w5tfc o4pmYd5uL9ZGVkoFqFhAtntFI4BIelJKUm58TdEPVV8XTu69bbCDZjqxIJUNctHRosTa 5w== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2sc9uhg0ng-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 May 2019 20:50:26 -0400 Received: from pps.filterd (m0133268.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x490lgwn009416 for ; Wed, 8 May 2019 20:50:25 -0400 Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0a-00154901.pphosted.com with ESMTP id 2s94ys16p3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 08 May 2019 20:50:25 -0400 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x490oM40011349 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 May 2019 20:50:23 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x490oM40011349 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1557363024; bh=H/HZ8q7IEu6F/ENtnFIZ2IfG9e8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=eRghhbDTJ/DOF52I6HtZN34m8oWi9TvlbLdjnq8ik1gu0dRSF/bKgNT4t6iO49/P6 xDavvabanfeS1zaGjeFlP4uNGlqSb5lOeWcFy2dyC0vfyp+A3S1luwMxG6jfoDMCs+ wycn/NdnrOoYA5Z3krANiBJ7ho1tEqPXfhL8hfR0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x490oM40011349 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Wed, 8 May 2019 20:49:53 -0400 Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x490o7I5000477 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 8 May 2019 20:50:08 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0439.000; Wed, 8 May 2019 20:50:07 -0400 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 Thread-Index: AdUGAGT4Th8zbG5rQXClmZ/2hSiF0g== Date: Thu, 9 May 2019 00:50:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.130] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363055BC3FMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-08_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=997 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905090002 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905090002 Archived-At: Subject: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 00:50:34 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363055BC3FMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a solidly written draft on updating tunnel protocols that use shim = headers to propagate ECN according to RFC 6040. Unfortunately, I found a major issue with the updates [1] along with a few = minor issues (easily dealt with) and a bunch of editorial items. The major issue [1] on updates creating non-compliant implementations looks= like it will need WG discussion on what should be done, as the "right thin= g to do" appears to be in potential conflict with deployed "running code". --- Major --- [1] Compliance with RFC 6040 update Section 3.1 says: However, an RFC has no jurisdiction over implementations that choose not to comply with it or cannot comply with it, including all those implementations that pre-dated the RFC. Therefore it would have been unreasonable to add such a requirement to RFC 6040. But then Section 4 goes on to do exactly that by updating RFC 6040 to add this text: In order that the network operator can comply with the above safety rules, even if an implementation of a tunnel ingress does not claim to support RFC 6040, RFC 4301 or the full functionality mode of RFC 3168: * it MUST make propagation of the ECN field between inner and outer IP headers independent of any configuration of Diffserv codepoint propagation; * it SHOULD be able to be configured to zero the outer ECN field. followed by this attempt to excuse the result: There might be concern that the above "MUST" makes compliant equipment non-compliant at a stroke. However, any equipment that is still treating the former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field is already non-compliant, and has been since 1998 when the upper 6 bits were separated off for the Diffserv field [RFC2474], [RFC3260]. For instance, copying the ECN field as a side-effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel. These three chunks of text need to be aligned. I'm not sure what should be done here, as the concern about updating RFC 6040 to cause non-complianc= e is an important concern. Analogous non-compliance concerns apply to the updates to other RFCs in Section 5 to varying degrees. --- Minor --- [A] Updated RFCs. Need to be explicit about what the updates are to each of the updated RFCs. The updates are scattered throughout the draft - a possible approach is to add a section that summarizes the update(s) to each RFC and provides pointe= rs to the section(s) that contain the update(s). [B] Section 4 * if it is known that the tunnel egress does not support propagation of the ECN field (RFC 6040, RFC 4301 or the full functionality mode of RFC 3168) The parenthetical listing of RFCs is unclear - I think these all do support ECN field propagation, so edits are needed to make this clear. [C] Section 4 For instance, copying the ECN field as a side-effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel. This text comes immediately after the text in issue [1]. The problem with this text is that it's implicitly assuming that the tunnel egress discards the outer header including any congestion indication that it may contain. That needs to be stated/explained. [D] Section 5 Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains that a tunnel that encapsulates an IP header directly within a UDP/IP datagram needs to follow RFC 6040 when propagating the ECN field between inner and outer IP headers. The requirements in Section 4 update RFC 6040 so, by reference, they automatically update RFC 8085 to add the important but previously unstated requirement that, if the UDP tunnel egress does not, or might not, support ECN propagation, a legacy UDP tunnel ingress has to clear the outer IP ECN field to 0b00, e.g. by configuration. That's too clever/subtle - this draft should explicitly update RFC 8085. [E] Have the L2TP changes been reviewed by L2TP experts? [F] Have the AMT changes been reviewed by AMT experts? --- Editorial --- Abstract It surveys widely deployed IP tunnelling protocols separated by such shim header(s) separated by -> that use Section 4 Permanently zeroing the outer ECN field is safe, but it is not sufficient to claim compliance with RFC 6040 because it does not meet the aim of introducing ECN support to tunnels (see Section 4.3 of [RFC6040]). "Permanently" is not the right word. Suggest rephrasing start of paragraph= to Zeroing the ECN field in the outer header of all packets is safe, ... IANA Considerations The "[TO BE REMOVED: ..." text is not the "right thing to do" - do this ins= tead: OLD IANA is requested to assign the following L2TP Control Message Attribute Value Pair: NEW IANA is requested to assign the following L2TP Control Message Attribute Value Pair in the Layer Two Tunneling Protocol "L2TP" registry (https://www.iana.org/assignments/l2tp-parameters/l2tp- parameters.xhtml): END IANA will edit this text after performing the assignment and can remove the link if appropriate. Thanks, --David ---------------------------------------------------------------- David L. Black, Senior Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (774) 350-9323 New Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949363055BC3FMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a solidly written draft on updating tunnel p= rotocols that use shim headers to propagate ECN according to RFC 6040.=

 

Unfortunately, I found a major issue with the update= s [1] along with a few minor issues (easily dealt with) and a bunch of edit= orial items.

 

The major issue [1] on updates creating non-complian= t implementations looks like it will need WG discussion on what should be d= one, as the “right thing to do” appears to be in potential conf= lict with deployed “running code”.

 

--- Major ---

 

[1] Compliance with RFC 6040 update

 

Section 3.1 says:

 

   However, an RFC has no jurisdict= ion over implementations that choose

   not to comply with it or cannot = comply with it, including all those

   implementations that pre-dated t= he RFC.  Therefore it would have been

   unreasonable to add such a requi= rement to RFC 6040.

 

But then Section 4 goes on to do exactly that= by updating RFC 6040 to

add this text:

 

      In order that = the network operator can comply with the above

      safety rules, = even if an implementation of a tunnel ingress does

      not claim to s= upport RFC 6040, RFC 4301 or the full functionality

      mode of RFC 31= 68:

 

      *  it MUS= T make propagation of the ECN field between inner and

       &nb= sp; outer IP headers independent of any configuration of Diffserv

       &nb= sp; codepoint propagation;

 

      *  it SHO= ULD be able to be configured to zero the outer ECN field.=

 

followed by this attempt to excuse the result= :

 

   There might be concern that the = above "MUST" makes compliant

   equipment non-compliant at a str= oke.  However, any equipment that is

   still treating the former ToS oc= tet (IPv4) or the former Traffic

   Class octet (IPv6) as a single 8= -bit field is already non-compliant,

   and has been since 1998 when the= upper 6 bits were separated off for

   the Diffserv field [RFC2474], [R= FC3260].  For instance, copying the

   ECN field as a side-effect of co= pying the DSCP is a seriously unsafe

   bug that risks breaking the feed= back loops that regulate load on a

   tunnel.

 

These three chunks of text need to be aligned= .  I'm not sure what should

be done here, as the concern about updating R= FC 6040 to cause non-compliance

is an important concern.

 

Analogous non-compliance concerns apply to th= e updates to other RFCs in

Section 5 to varying degrees.

 

--- Minor ---

 

[A] Updated RFCs.

 

Need to be explicit about what the updates ar= e to each of the updated RFCs.

The updates are scattered throughout the draf= t - a possible approach is to

add a section that summarizes the update(s) t= o each RFC and provides pointers

to the section(s) that contain the update(s).=

 

[B] Section 4

 

      *  if it = is known that the tunnel egress does not support

       &nb= sp; propagation of the ECN field (RFC 6040, RFC 4301 or the full=

       &nb= sp; functionality mode of RFC 3168)

 

The parenthetical listing of RFCs is unclear = - I think these all do support

ECN field propagation, so edits are needed to= make this clear.

 

 

[C] Section 4

 

   For instance, copying the

   ECN field as a side-effect of co= pying the DSCP is a seriously unsafe

   bug that risks breaking the feed= back loops that regulate load on a

   tunnel.

 

This text comes immediately after the text in= issue [1].  The problem with

this text is that it's implicitly assuming th= at the tunnel egress discards

the outer header including any congestion ind= ication that it may contain.

 

That needs to be stated/explained.=

 

[D] Section 5

 

   Section 3.1.11 of the UDP usage = guidelines [RFC8085] already explains

   that a tunnel that encapsulates = an IP header directly within a UDP/IP

   datagram needs to follow RFC 604= 0 when propagating the ECN field

   between inner and outer IP heade= rs.  The requirements in Section 4

   update RFC 6040 so, by reference= , they automatically update RFC 8085

   to add the important but previou= sly unstated requirement that, if the

   UDP tunnel egress does not, or m= ight not, support ECN propagation, a

   legacy UDP tunnel ingress has to= clear the outer IP ECN field to

   0b00, e.g. by configuration.

 

That's too clever/subtle - this draft should = explicitly update RFC 8085.

 

[E] Have the L2TP changes been reviewed by L2= TP experts?

 

[F] Have the AMT changes been reviewed by AMT= experts?

 

 

--- Editorial ---

 

Abstract

 

It surveys widely deployed IP tunnelling=

   protocols separated by such shim= header(s)

 

separated by -> that use=

 

Section 4

 

   Permanently zeroing the outer EC= N field is safe, but it is not

   sufficient to claim compliance w= ith RFC 6040 because it does not meet

   the aim of introducing ECN suppo= rt to tunnels (see Section 4.3 of

   [RFC6040]).

 

"Permanently" is not the right word= .  Suggest rephrasing start of paragraph to

 

   Zeroing the ECN field in the out= er header of all packets is safe, ...

 

IANA Considerations

 

The "[TO BE REMOVED: ..." text is n= ot the "right thing to do" - do this instead:

 

OLD
   IANA is requested to assign the following L2TP Control Message=

   Attribute Value Pair:=

NEW

   IANA is requested to assign the = following L2TP Control Message

   Attribute Value Pair in the Laye= r Two Tunneling Protocol "L2TP"

   registry (https://www.iana.org/a= ssignments/l2tp-parameters/l2tp-

   parameters.xhtml):

END

 

IANA will edit this text after performing the= assignment and can

remove the link if appropriate.

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (774) 350-9323 New    M= obile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------= ------------

 

--_000_CE03DB3D7B45C245BCA0D243277949363055BC3FMX307CL04corpem_-- From nobody Wed May 8 18:08:44 2019 Return-Path: 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 974D61201F0 for ; Wed, 8 May 2019 18:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=JaYVSvKb; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=mRwXJsQu 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 zXFOwvPI_MRU for ; Wed, 8 May 2019 18:08:39 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 9199D1200C7 for ; Wed, 8 May 2019 18:08:39 -0700 (PDT) Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x491585t007575 for ; Wed, 8 May 2019 21:08:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=bpxmBzttyfs2vDGYLGypvukbBi/mIFlGxFv7mJRqIs8=; b=JaYVSvKbsGtfio75vUnJqbuTytDCXQBAV7MfRmiUbmZZ//oQZYSGMf0EdntQR/ZZ8mhq nGxX49c0a2zLY6Yb0WXX9EU17vvQnw8E46j4kbyUzGmjkAUAXuRdvOenlMdlNkpZ3SMo jtDRHtCBkulZh2m5COwrMxWDdF40GmgGwM9MIIESzk4LY9mKmENHCPzd2zu/ThzBlufk IpBp1j93fLXEMuz43q/SpjDaiMxkS4YFtK7SsMsSisqv8p7Mbl9SOmpIfDpvnuu2MphA AEVsqbuAxFXnQcynBbMOQ2g7j/BqIWnuD0sb+KTVssLmhk1En+Uk91nx6kM2zhs1aTlF 0A== Received: from mx0b-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2sc9gv82wx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 May 2019 21:08:36 -0400 Received: from pps.filterd (m0090350.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4918Ig1014979 for ; Wed, 8 May 2019 21:08:35 -0400 Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2sc34gdjnw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 08 May 2019 21:08:34 -0400 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4918VmU016117 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 May 2019 21:08:32 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x4918VmU016117 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1557364113; bh=E6v56O1vG1dRkioxFsfzIOFLwoY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=mRwXJsQuZIkyVge4BHvSWnkCsGRg3yhit+U9kJErL5A74njOavjQr40cbKZpQe8Gi ZCVbmN5X5gu8ns5tTtJLuXC9TQvzObxzDdH2J28Pj76u07zn+LJTClehWfKD4f30UU 27tUr9DrXHeKJ7c3ZmKjmCTqdOr9M3VDrbZdggrg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x4918VmU016117 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd06.lss.emc.com (RSA Interceptor) for ; Wed, 8 May 2019 21:08:18 -0400 Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4918Npx003302 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 8 May 2019 21:08:24 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0439.000; Wed, 8 May 2019 21:08:23 -0400 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 Thread-Index: AdUGAGT4Th8zbG5rQXClmZ/2hSiF0gAAs+7g Date: Thu, 9 May 2019 01:08:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.130] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363055BDDCMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-09_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905090004 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905090004 Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 01:08:43 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363055BDDCMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable idnits found a couple of minor things: * Current reference for IKEv2 is RFC 7296 instead of RFC 5996 * If any text was copied from pre-5378 RFCs, an additional boilerplate = disclaimer is required. Thanks, --David From: Black, David Sent: Wednesday, May 8, 2019 8:50 PM To: tsvwg@ietf.org Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-0= 8 This is a solidly written draft on updating tunnel protocols that use shim = headers to propagate ECN according to RFC 6040. Unfortunately, I found a major issue with the updates [1] along with a few = minor issues (easily dealt with) and a bunch of editorial items. The major issue [1] on updates creating non-compliant implementations looks= like it will need WG discussion on what should be done, as the "right thin= g to do" appears to be in potential conflict with deployed "running code". --- Major --- [1] Compliance with RFC 6040 update Section 3.1 says: However, an RFC has no jurisdiction over implementations that choose not to comply with it or cannot comply with it, including all those implementations that pre-dated the RFC. Therefore it would have been unreasonable to add such a requirement to RFC 6040. But then Section 4 goes on to do exactly that by updating RFC 6040 to add this text: In order that the network operator can comply with the above safety rules, even if an implementation of a tunnel ingress does not claim to support RFC 6040, RFC 4301 or the full functionality mode of RFC 3168: * it MUST make propagation of the ECN field between inner and outer IP headers independent of any configuration of Diffserv codepoint propagation; * it SHOULD be able to be configured to zero the outer ECN field. followed by this attempt to excuse the result: There might be concern that the above "MUST" makes compliant equipment non-compliant at a stroke. However, any equipment that is still treating the former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field is already non-compliant, and has been since 1998 when the upper 6 bits were separated off for the Diffserv field [RFC2474], [RFC3260]. For instance, copying the ECN field as a side-effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel. These three chunks of text need to be aligned. I'm not sure what should be done here, as the concern about updating RFC 6040 to cause non-complianc= e is an important concern. Analogous non-compliance concerns apply to the updates to other RFCs in Section 5 to varying degrees. --- Minor --- [A] Updated RFCs. Need to be explicit about what the updates are to each of the updated RFCs. The updates are scattered throughout the draft - a possible approach is to add a section that summarizes the update(s) to each RFC and provides pointe= rs to the section(s) that contain the update(s). [B] Section 4 * if it is known that the tunnel egress does not support propagation of the ECN field (RFC 6040, RFC 4301 or the full functionality mode of RFC 3168) The parenthetical listing of RFCs is unclear - I think these all do support ECN field propagation, so edits are needed to make this clear. [C] Section 4 For instance, copying the ECN field as a side-effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel. This text comes immediately after the text in issue [1]. The problem with this text is that it's implicitly assuming that the tunnel egress discards the outer header including any congestion indication that it may contain. That needs to be stated/explained. [D] Section 5 Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains that a tunnel that encapsulates an IP header directly within a UDP/IP datagram needs to follow RFC 6040 when propagating the ECN field between inner and outer IP headers. The requirements in Section 4 update RFC 6040 so, by reference, they automatically update RFC 8085 to add the important but previously unstated requirement that, if the UDP tunnel egress does not, or might not, support ECN propagation, a legacy UDP tunnel ingress has to clear the outer IP ECN field to 0b00, e.g. by configuration. That's too clever/subtle - this draft should explicitly update RFC 8085. [E] Have the L2TP changes been reviewed by L2TP experts? [F] Have the AMT changes been reviewed by AMT experts? --- Editorial --- Abstract It surveys widely deployed IP tunnelling protocols separated by such shim header(s) separated by -> that use Section 4 Permanently zeroing the outer ECN field is safe, but it is not sufficient to claim compliance with RFC 6040 because it does not meet the aim of introducing ECN support to tunnels (see Section 4.3 of [RFC6040]). "Permanently" is not the right word. Suggest rephrasing start of paragraph= to Zeroing the ECN field in the outer header of all packets is safe, ... IANA Considerations The "[TO BE REMOVED: ..." text is not the "right thing to do" - do this ins= tead: OLD IANA is requested to assign the following L2TP Control Message Attribute Value Pair: NEW IANA is requested to assign the following L2TP Control Message Attribute Value Pair in the Layer Two Tunneling Protocol "L2TP" registry (https://www.iana.org/assignments/l2tp-parameters/l2tp- parameters.xhtml): END IANA will edit this text after performing the assignment and can remove the link if appropriate. Thanks, --David ---------------------------------------------------------------- David L. Black, Senior Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (774) 350-9323 New Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949363055BDDCMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

idnits found a couple = of minor things:

  • Current reference for IKEv2 is RFC 7296 instead of RFC 5996
  • =
  • If any text was copied from pre-5378 RFCs, an additional boilerplate discla= imer is required.

 

Thanks, --David

 

From: Black, David
Sent: Wednesday, May 8, 2019 8:50 PM
To: tsvwg@ietf.org
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update= -shim-08

 

This is a solidly written draft on updating tunnel p= rotocols that use shim headers to propagate ECN according to RFC 6040.=

 

Unfortunately, I found a major issue with the update= s [1] along with a few minor issues (easily dealt with) and a bunch of edit= orial items.

 

The major issue [1] on updates creating non-complian= t implementations looks like it will need WG discussion on what should be d= one, as the “right thing to do” appears to be in potential conf= lict with deployed “running code”.

 

--- Major ---

 

[1] Compliance with RFC 6040 update

 

Section 3.1 says:

 

   However, an RFC has no jurisdict= ion over implementations that choose

   not to comply with it or cannot = comply with it, including all those

   implementations that pre-dated t= he RFC.  Therefore it would have been

   unreasonable to add such a requi= rement to RFC 6040.

 

But then Section 4 goes on to do exactly that= by updating RFC 6040 to

add this text:

 

      In order that = the network operator can comply with the above

      safety rules, = even if an implementation of a tunnel ingress does

      not claim to s= upport RFC 6040, RFC 4301 or the full functionality

      mode of RFC 31= 68:

 

      *  it MUS= T make propagation of the ECN field between inner and

       &nb= sp; outer IP headers independent of any configuration of Diffserv

       &nb= sp; codepoint propagation;

 

      *  it SHO= ULD be able to be configured to zero the outer ECN field.=

 

followed by this attempt to excuse the result= :

 

   There might be concern that the = above "MUST" makes compliant

   equipment non-compliant at a str= oke.  However, any equipment that is

   still treating the former ToS oc= tet (IPv4) or the former Traffic

   Class octet (IPv6) as a single 8= -bit field is already non-compliant,

   and has been since 1998 when the= upper 6 bits were separated off for

   the Diffserv field [RFC2474], [R= FC3260].  For instance, copying the

   ECN field as a side-effect of co= pying the DSCP is a seriously unsafe

   bug that risks breaking the feed= back loops that regulate load on a

   tunnel.

 

These three chunks of text need to be aligned= .  I'm not sure what should

be done here, as the concern about updating R= FC 6040 to cause non-compliance

is an important concern.

 

Analogous non-compliance concerns apply to th= e updates to other RFCs in

Section 5 to varying degrees.

 

--- Minor ---

 

[A] Updated RFCs.

 

Need to be explicit about what the updates ar= e to each of the updated RFCs.

The updates are scattered throughout the draf= t - a possible approach is to

add a section that summarizes the update(s) t= o each RFC and provides pointers

to the section(s) that contain the update(s).=

 

[B] Section 4

 

      *  if it = is known that the tunnel egress does not support

       &nb= sp; propagation of the ECN field (RFC 6040, RFC 4301 or the full=

       &nb= sp; functionality mode of RFC 3168)

 

The parenthetical listing of RFCs is unclear = - I think these all do support

ECN field propagation, so edits are needed to= make this clear.

 

 

[C] Section 4

 

   For instance, copying the

   ECN field as a side-effect of co= pying the DSCP is a seriously unsafe

   bug that risks breaking the feed= back loops that regulate load on a

   tunnel.

 

This text comes immediately after the text in= issue [1].  The problem with

this text is that it's implicitly assuming th= at the tunnel egress discards

the outer header including any congestion ind= ication that it may contain.

 

That needs to be stated/explained.=

 

[D] Section 5

 

   Section 3.1.11 of the UDP usage = guidelines [RFC8085] already explains

   that a tunnel that encapsulates = an IP header directly within a UDP/IP

   datagram needs to follow RFC 604= 0 when propagating the ECN field

   between inner and outer IP heade= rs.  The requirements in Section 4

   update RFC 6040 so, by reference= , they automatically update RFC 8085

   to add the important but previou= sly unstated requirement that, if the

   UDP tunnel egress does not, or m= ight not, support ECN propagation, a

   legacy UDP tunnel ingress has to= clear the outer IP ECN field to

   0b00, e.g. by configuration.

 

That's too clever/subtle - this draft should = explicitly update RFC 8085.

 

[E] Have the L2TP changes been reviewed by L2= TP experts?

 

[F] Have the AMT changes been reviewed by AMT= experts?

 

 

--- Editorial ---

 

Abstract

 

It surveys widely deployed IP tunnelling=

   protocols separated by such shim= header(s)

 

separated by -> that use=

 

Section 4

 

   Permanently zeroing the outer EC= N field is safe, but it is not

   sufficient to claim compliance w= ith RFC 6040 because it does not meet

   the aim of introducing ECN suppo= rt to tunnels (see Section 4.3 of

   [RFC6040]).

 

"Permanently" is not the right word= .  Suggest rephrasing start of paragraph to

 

   Zeroing the ECN field in the out= er header of all packets is safe, ...

 

IANA Considerations

 

The "[TO BE REMOVED: ..." text is n= ot the "right thing to do" - do this instead:

 

OLD
   IANA is requested to assign the following L2TP Control Message=

   Attribute Value Pair:=

NEW

   IANA is requested to assign the = following L2TP Control Message

   Attribute Value Pair in the Laye= r Two Tunneling Protocol "L2TP"

   registry (https://www.iana.org/assignmen= ts/l2tp-parameters/l2tp-

   parameters.xhtml):

END

 

IANA will edit this text after performing the= assignment and can

remove the link if appropriate.

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (774) 350-9323 New    M= obile: +1 (978) 394-7754

David.Black@= dell.com

----------------------------------------------------= ------------

 

--_000_CE03DB3D7B45C245BCA0D243277949363055BDDCMX307CL04corpem_-- From nobody Thu May 9 11:56:45 2019 Return-Path: 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 CB091120131 for ; Thu, 9 May 2019 11:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft3309700.onmicrosoft.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 ykMvFh89HfOE for ; Thu, 9 May 2019 11:56:41 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720139.outbound.protection.outlook.com [40.107.72.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B12F120110 for ; Thu, 9 May 2019 11:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT3309700.onmicrosoft.com; s=selector1-asomi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4wPbLiDKF4EkXaccgUnc/5UJdm7v6mNlPZwPPYb+q0Y=; b=rjTiOlY+WCzfnvI9gstUw3FTAo0/9wNiOg0uFHrnsf3eVnTE6K4+s3L/cnBT+YePA6U1zCuPD9MQjB0CeXI5PbidHuc+UzzatVH7tufyEKQxuKruKP8QlPUXyDK9Icf8OOh27swHGYS2aMz6atKr+fR6A+bl/5z9OIv7kIh9E1A= Received: from DM6PR11MB3435.namprd11.prod.outlook.com (20.177.220.28) by DM6PR11MB2538.namprd11.prod.outlook.com (20.176.98.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Thu, 9 May 2019 18:56:39 +0000 Received: from DM6PR11MB3435.namprd11.prod.outlook.com ([fe80::c52b:73e1:4211:5ec7]) by DM6PR11MB3435.namprd11.prod.outlook.com ([fe80::c52b:73e1:4211:5ec7%3]) with mapi id 15.20.1878.019; Thu, 9 May 2019 18:56:39 +0000 From: Caitlin Bestler To: Michael Tuexen , Elmar Stellnberger CC: tsvwg Thread-Topic: [tsvwg] SSL connections with SCTP Thread-Index: AQHVBdfwsgF035Kgc0ikYLIvbn98y6Zhqu2AgAF6t7A= Date: Thu, 9 May 2019 18:56:39 +0000 Message-ID: References: <1d70503b-62cd-fe9a-118f-4ea36f148d1e@elstel.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cait@asomi.com; x-originating-ip: [2600:8803:400:74f:e9cd:7a4f:4a8b:cdbf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23039261-58fc-4535-a6aa-08d6d4b011c6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM6PR11MB2538; x-ms-traffictypediagnostic: DM6PR11MB2538: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(136003)(396003)(346002)(376002)(199004)(189003)(66446008)(52536014)(64756008)(8936002)(236005)(99286004)(1015004)(81166006)(81156014)(8676002)(2906002)(14454004)(4326008)(33656002)(256004)(733005)(55016002)(54896002)(6306002)(9686003)(6606003)(74316002)(966005)(316002)(110136005)(229853002)(11346002)(476003)(71200400001)(6246003)(7696005)(25786009)(446003)(486006)(66946007)(76176011)(53936002)(73956011)(606006)(53546011)(6506007)(102836004)(5660300002)(66476007)(66556008)(68736007)(508600001)(6436002)(7736002)(86362001)(76116006)(46003)(19627405001)(186003)(71190400001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB2538; H:DM6PR11MB3435.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: asomi.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5TjlTnqsL7uXMXP6M2lKJVgdKRcW56M99OKTukVsAcrIX5fxcDPC51il7Z/ilmzaMoGAFGGi1vHPkTbaj3GIvQMVq198B466ykRoR/h3J2JoT/J4drCoCJ4QoMks3vDwSQg+PGclS1v9KXI1g1l5ISO5Fxl4n/q/cx0+bqMlJy9J3wIcv6fEpEiF0uL4PLxWnerjNe08uRIzDfN7HW09j3V8j9amQU32bke5S80t/i5WfbI55THVmDTkBT9jmkXKMegz8qcVoR2H4inPYLF9DmBs1xtoZ+e0IGm9TcPDUmy76+kzzJnRjhD4L47PnnxIhumTw8V0PwFw0zAhB9cKRnBbtn8LDUpmp3GKEpIh/3NsZ6syfrpnHGwnGEcn+ITprKToT34IKeIRr3phAthbcGRcAw21GnPpEdNma4fHado= Content-Type: multipart/alternative; boundary="_000_DM6PR11MB343506E5F2B9435D36084121D3330DM6PR11MB3435namp_" MIME-Version: 1.0 X-OriginatorOrg: asomi.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23039261-58fc-4535-a6aa-08d6d4b011c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 18:56:39.6717 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a90e44c6-9570-49f9-9cdb-dff096fd98a3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2538 Archived-At: Subject: Re: [tsvwg] SSL connections with SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 18:56:44 -0000 --_000_DM6PR11MB343506E5F2B9435D36084121D3330DM6PR11MB3435namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Who is supplying the identity information? If it is the host then you want = to secure the SCTP association. If it is the specific application then it w= ould make so to do so on a per-Stream basis. What would make no sense isto = have the host apply a host-wide policy on a per-stream basis. ________________________________ From: tsvwg on behalf of Michael Tuexen Sent: Wednesday, May 8, 2019 1:19 PM To: Elmar Stellnberger Cc: tsvwg Subject: Re: [tsvwg] SSL connections with SCTP > On 8. May 2019, at 17:03, Elmar Stellnberger wrote: > > I am planning to write a proxy for localhost which relays incoming tcp co= nnections via an SCTP connection to a remote host. That way it should be po= ssible to overcome lacking SCTP support for browsers. Now my question is ho= w to best use SSL with SCTP. If I have established an open SSL SCTP connec= tion and want to fork a new flow for the same connection do I have to repea= t the SSL cipher negotiation or may I simply fork an existing SSL SCTP flow= ? > I would suggest to use DTLS/SCTP. This is supported by OpenSSL and you can find some examples at https://github.com/nplab/DTLS-Examples. [https://avatars0.githubusercontent.com/u/12073177?s=3D400&v=3D4] GitHub - nplab/DTLS-Examples: DTLS Examples for OpenSSL github.com DTLS Examples for OpenSSL. This repository contains examples for DTLS via S= CTP and UDP. Each application in src can be used as client or server.. Our = examples are developed against the OpenSSL 1.1.x API. Best regards Michael --_000_DM6PR11MB343506E5F2B9435D36084121D3330DM6PR11MB3435namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Who is supplying the identity inf= ormation? If it is the host then you want to secure the SCTP association. I= f it is the specific application then it would make so to do so on a per-St= ream basis. What would make no sense isto have the host apply a host-wide policy on a per-stream basis.





From: tsvwg <tsvwg-bounc= es@ietf.org> on behalf of Michael Tuexen <michael.tuexen@lurchi.frank= en.de>
Sent: Wednesday, May 8, 2019 1:19 PM
To: Elmar Stellnberger
Cc: tsvwg
Subject: Re: [tsvwg] SSL connections with SCTP
 
> On 8. May 2019, at 17:03, Elmar Stellnberger = <estellnb@elstel.org> wrote:
>
> I am planning to write a proxy for localhost which relays incoming tcp= connections via an SCTP connection to a remote host. That way it should be= possible to overcome lacking SCTP support for browsers. Now my question is= how to best use SSL with SCTP. If I have established an open  SSL SCTP connection and want to fork a ne= w flow for the same connection do I have to repeat the SSL cipher negotiati= on or may I simply fork an existing SSL SCTP flow?
>
I would suggest to use DTLS/SCTP. This is supported by OpenSSL and you can<= br> find some examples at https://github.com/nplab/DTLS-Examples.
github.com
DTLS Examples for OpenSSL. This repository contains examples for DTLS via S= CTP and UDP. Each application in src can be used as client or server.. Our = examples are developed against the OpenSSL 1.1.x API.



Best regards
Michael
--_000_DM6PR11MB343506E5F2B9435D36084121D3330DM6PR11MB3435namp_-- From nobody Fri May 10 02:17:42 2019 Return-Path: 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 E66821200F9; Fri, 10 May 2019 02:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3nu2DD18Gml2; Fri, 10 May 2019 02:17:24 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 23B85120086; Fri, 10 May 2019 02:17:24 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id g16so3941421iom.9; Fri, 10 May 2019 02:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xScfaUrQKvsGlzniWNCzx/dtX7bad1TZ87HK4J4bLXc=; b=d7tFQd2EQgx2NvOflsGXNRXwB/Foo3uM+5GHsDQpOMmmV0AvA70ovqa5U4yFQX7csE IysNYOV6H4SqPJc+JVlZkcFY1RJzUdbBw9JsXYMPUns6N33tY0J/4ZhGN1LscJew0exW g6OgRlDdF4mZD9C+a0+kZraEgk145qU5V035zYAiswXrU4tAl88MKTcjXpRun2G/EQ33 1zB4Bt6iYirUp2pr0s3htvDLaP8A0eURDaiKftQQRtzwu8H7O7ZCNHuTvBPi2UYa1PNF 3cYgOtFckcSKBdhXIPPn6v7W3yKlNH18vWEr8uzi3o1vNvc1woinu/1K90sQNxU3nbm4 w4fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xScfaUrQKvsGlzniWNCzx/dtX7bad1TZ87HK4J4bLXc=; b=qBZCmlmOdPRsJZTRjwAEDLYtDT2qnEqnrIrAnQYQjnbtnAUwfSzWS/ueIlhw1HQV2r u68MzFW5jARzF19EcncR19wDVUgM6AuPyv+6GOmShLcJNDQ+ML0C/7MzA0Ciz0B+VHcK UDqgPUyabYwLdUjwVtEoxrnuYgh9GccaaWBWliOQlimoYkJp8RFuMSsRdGe0PLu7OlG4 kyDdX5bzjYgCnti3czshhv56oCWhFI1oqdb83gudhBef9SgBa5BxIr8xATsCh/5QxvqW sD77dEyGL2WZ8x8Xlkg6iwhzaXF10LPcSdv6006Qjk2s3kzM7QQ5/nBBqEPkpMFtv63U RC3A== X-Gm-Message-State: APjAAAULz93VL/JE9djS7MQm22Z7YlcGGIgBjpMRuBlosZZrRoQlRaae 98wGfVKF0WnqtmrIzORLaFB0IaU5DcdU7858zOc= X-Google-Smtp-Source: APXvYqwUZ1Z6/cjPoUn0GqFBSndvot3fyBD6U5e/+UMnpqVMJX54pe8T6s4mnUiRqymLJuNSw36DlGPy/McTUElwO9U= X-Received: by 2002:a6b:6d06:: with SMTP id a6mr5995124iod.11.1557479843202; Fri, 10 May 2019 02:17:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Fri, 10 May 2019 11:17:11 +0200 Message-ID: To: Magnus Westerlund Cc: IETF Discussion Mailing List , tsvwg IETF list , Andrew Sullivan , The IESG , ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 09:17:26 -0000 On Mon, Apr 29, 2019 at 5:32 PM Magnus Westerlund wrote: > > Hi Dave, > > Thanks for bring this work to the IETF. Yes, I would also like to encoura= ge you to discuss your proposal in TSVWG using the mailing list and eventua= lly present this work at the next TSVWG meeting. However, there is not requ= ired to participate in-person. We frequently have remote presentations and = from my experience that works well. I=E2=80=99m sure the TSVWG chairs can f= urther advise you on this. This is one of those replies that I had to sit on for a while because it was so mind-boggling. If you haven't noticed a few hundred messages about reforming the ietf on the IETF mailing list to allow remote participants to have *a vote* in how the ietf operates, you might want to review those. A remote presentation is not enough to get a vote in how the ietf operates. Remote participation on the mailing lists, in this case, was certainly not enough. Externally it looked like the l4s/dualpi/tcpprague effort was spiraling down the drain with a pesky FRAND patent, no integrated, running code, and 4 as-yet unresolved theoretical problems weighing it down. But... it really did feel like matters were being settled in smoky back rooms when this set of drafts, pitched to the IETF as a (rather dubious) experiment, when it came out (hours after we submitted our SCE draft) that cablelabs had announced their new standard (no doubt expecting a rubber stamp from the ietf) a few weeks prior, and had, indeed, been working in secret for 16 months to take over the "last half bit" of the ECN header for their own use. Radically enough, I do tend to think that the open source community does need MUCH better *representation* within the ietf, and to leverage Thomas Paine's writings, there should be "no standardization without representation", particularly in cases where the code has to be universally deployed. This requires actual IETF attendance, by the coders or their representatives, at least presently. Unlike all the other conferences we attend, speakers are not recompensed for their costs in the IETF, either. I still doubt that our new competing, backwards compatible alternate proposal, will get any pull in various smoky backrooms, but being there in person, giving a preso, and wandering the hallways still seems to help. Especially... when the ideas and their implications are so difficult to express to people outside the narrow field of congestion control in the first place, and don't fit easily into an RFC format without useful code, repeatable benchmarks, public experiments and graphs as guides. > Cheers > > Magnus Westerlund > > > > On 2019-04-28 15:54, Dave Taht wrote: > > Several members of the open source "bufferbloat.net" group do > > regularly participate in ietf mailing lists and remote meetings, but > > it is rare that any of us > > can actually afford to attend IETF. In fact, we've had no travel > > budget for 3 years running. I'd mostly reduced my involvement to BABEL > > after the AQM wg closed, and that remotely only. > > > > This past IETF, we had to hold a bake sale on the bloat mailing list > > as well as melt all my credit cards in order to get our new SCE "Some > > Congestion Experienced" AQM concept in front of the tsvwg and iccrg > > working groups in contrast to the cablelabs dualpi proposal. > > > > (if anyone cares, the TSVWG talk and slides are here: > > https://www.youtube.com/watch?v=3DJQmWyr0JDJM&t=3D1h3m50s ) - > > > > The controversy in the open source community, covered here: > > https://lwn.net/Articles/783673/ > > > > We've been *very strongly encouraged* to present again at the upcoming > > ietf in montreal, but I'm now in no position to sponsor the 2-3 core > > people again that need to present the follow-on results in the 5 or so > > related wgs. Is there an org, a fund, a means, a way, to get a bunch > > of rather poor, but innovative, open source devs and theorist, out > > there, that we can apply to? raise the ~9k needed? isoc? Something? > > > > (and if it were possible i'd rather like to have what I had had to > > spend back, so I can pour it into recreating a network testbed for > > this work. I'm not planning to attend, myself. The one trip alone > > wiped out ecn-sane's budget for the year) > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Fri May 10 04:35:52 2019 Return-Path: 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 B324F120033; Fri, 10 May 2019 04:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 bYbn7rGv0rkM; Fri, 10 May 2019 04:35:33 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150074.outbound.protection.outlook.com [40.107.15.74]) (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 B8967120026; Fri, 10 May 2019 04:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LORavvyKQxRhvVvkAGl5I6buTnwO0e41B8vQzav3GQE=; b=gaw4f49t67EntlmE/Z/zkEcOCr5ptQ2cJj2RNdzKdQ3Fur9g8q6BkwZCkI/EFNlY8MgWmPUwQR/3Kop3AtURcGRvncUzyA7EYp7vVUGwJf7Te0Va81ldb0b6E6k7tKlfx8oYCzwm29eaQPSUZ/a4/e53dCEH5sl0vaFU86yNTlA= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2460.eurprd07.prod.outlook.com (10.168.128.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.7; Fri, 10 May 2019 11:35:29 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1878.022; Fri, 10 May 2019 11:35:29 +0000 From: Magnus Westerlund To: Dave Taht CC: The IESG , ECN-Sane , IETF Discussion Mailing List , tsvwg IETF list Thread-Topic: travel funds for ietf for the next SCE talk? Thread-Index: AQHU/cneO/MepbMfKEimxUTyWE/Y/Q== Date: Fri, 10 May 2019 11:35:29 +0000 Message-ID: References: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2ba6ba0a-52f4-4aad-2a3d-08d6d53b9aa1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2460; x-ms-traffictypediagnostic: HE1PR0701MB2460: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0033AAD26D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(136003)(39860400002)(376002)(189003)(199004)(25786009)(4326008)(6116002)(3846002)(256004)(478600001)(14454004)(86362001)(14444005)(486006)(44832011)(446003)(476003)(53936002)(5660300002)(6246003)(9686003)(6506007)(316002)(66446008)(71190400001)(55016002)(81156014)(71200400001)(6436002)(99286004)(66946007)(73956011)(66556008)(76116006)(6916009)(64756008)(53546011)(66476007)(7696005)(54906003)(66066001)(229853002)(76176011)(561944003)(2906002)(68736007)(102836004)(26005)(8936002)(8676002)(186003)(81166006)(305945005)(7736002)(52536014)(33656002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2460; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GRPPobMBRNvI4AguWNtzygG0kkwI7urQ57XmdiQFdoVTb68txsuLy7Cs4hxWXMmQSUgs435PbFIMy/DNJhpLUs/O5+Ajx6Xicc4qf0YCw0hjzYQ001Wvg+bRspx9Ieu5KlU9fLjN93RTxkgMaVbk3rYLc7nGQ3JkMJOmdyNM4ZLUj6Ri3QsgrCRsR+VNOZDQhO4/jQV9KtgBc52Z7hVDlaRgISFdMVlm9VDKW8MaVooSZ27iVAlsHfzi7AkfsJwWCx/IEVb/t14opcnsMfc3Bh9q1TEPs0SvtR8ntcr9y/r9bpvMlqohBbXb12+EqsR9wAChEBJEvAu48IyXdQcromhSndmvXCW9cW/1cSwmkSnY5Ixd33lqxyIG96lYy/vlFYdfXqzWmpsM6APRcAI3y3VZQOctdbA/zO/IzqyqRxQ= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ba6ba0a-52f4-4aad-2a3d-08d6d53b9aa1 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 11:35:29.2122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2460 Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 11:35:36 -0000 Hi Dave,=0A= =0A= Please see inline.=0A= =0A= On 2019-05-10 11:17, Dave Taht wrote:=0A= > On Mon, Apr 29, 2019 at 5:32 PM Magnus Westerlund=0A= > wrote:=0A= >> Hi Dave,=0A= >>=0A= >> Thanks for bring this work to the IETF. Yes, I would also like to encour= age you to discuss your proposal in TSVWG using the mailing list and eventu= ally present this work at the next TSVWG meeting. However, there is not req= uired to participate in-person. We frequently have remote presentations and= from my experience that works well. I=92m sure the TSVWG chairs can furthe= r advise you on this.=0A= > This is one of those replies that I had to sit on for a while because=0A= > it was so mind-boggling.=0A= >=0A= > If you haven't noticed a few hundred messages about reforming the ietf=0A= > on the IETF mailing list to allow remote participants to have *a vote*=0A= > in how the ietf operates, you might want to review those.=0A= =0A= I have noticed that discussion. Process changes are hard, and the one=0A= thing I am certain over is that we need to have an open discussion about=0A= what changes should happen to facilitate remote only participants to=0A= have nomcom eligibility, right to sign recall petitions etc. Remote=0A= participants are most definitely not on equal footing on that part. If=0A= you think the IESG is obstructionist in this discussion, then it comes=0A= from the position that if we would simply jump on something without=0A= ensuring consensus on things we equally would be called bad things. We=0A= can facilitate the discussion and ensure that it is given room. For=0A= example a virtual BOF for these topics do make sense.=0A= =0A= >=0A= > A remote presentation is not enough to get a vote in how the ietf operate= s.=0A= =0A= However, when it comes to be able to influence the technical work in a=0A= WG a remote participant do have a fair chance. The one to one=0A= discussions that happens in the hallways are hard to cover. That=0A= requires spending a lot of time trying to reach out to people between=0A= the meeting for those conversations. =0A= =0A= =0A= >=0A= > Remote participation on the mailing lists, in this case, was certainly=0A= > not enough. Externally it looked like the l4s/dualpi/tcpprague effort=0A= > was spiraling down the drain with a pesky FRAND patent, no integrated,=0A= > running code, and 4 as-yet unresolved theoretical problems weighing it=0A= > down.=0A= =0A= I don't know what your expectations where here from what I would=0A= consider a rather limited engagement you have had so far on the TSVWG=0A= mailing list. I don't share the same view of L4S, although I would have=0A= hoped for more rapid progress and more available running code.=0A= =0A= =0A= >=0A= > But... it really did feel like matters were being settled in smoky=0A= > back rooms when this set of drafts, pitched to the IETF as a (rather=0A= > dubious) experiment, when it came out (hours after we submitted our=0A= > SCE draft) that cablelabs had announced their new standard (no doubt=0A= > expecting a rubber stamp from the ietf) a few weeks prior, and had,=0A= > indeed, been working in secret for 16 months to take over the "last=0A= > half bit" of the ECN header for their own use.=0A= =0A= I have no insight into what has happened in CableLabs. However, it=0A= fairly obvious from mailing list traffic and presentations that=0A= Cablelabs had an interest in L4S. What I know is that we have discussed=0A= L4S for a significant time in IETF. There was a BOF at IETF 96 which=0A= resulted in the inclusion of the work in TSVWG. The framework for the=0A= experiment was discussed, documented and approved in RFC 8311. Yes, the=0A= specification of L4S as being developed have made slow progress, but it=0A= has been making progress.=0A= =0A= =0A= >=0A= > Radically enough, I do tend to think that the open source community=0A= > does need MUCH better *representation* within the ietf, and to=0A= > leverage Thomas Paine's writings, there should be "no standardization=0A= > without representation", particularly in cases where the code has to=0A= > be universally deployed. This requires actual IETF attendance, by the=0A= > coders or their representatives, at least presently.=0A= =0A= I definitely like more participation from people implementing the=0A= protocols in the IETF and Open Source contributors are important part of=0A= that. Certain things can most definitely be done on the mailing list and=0A= interacting with authors and being an author of proposals, even if not=0A= present. There are challenges of not being present at meetings when=0A= topics becomes controversial. Building a contact network is also more=0A= challenging when not present at the meetings.=0A= =0A= =0A= >=0A= > Unlike all the other conferences we attend, speakers are not=0A= > recompensed for their costs in the IETF, either.=0A= =0A= IETF is not a conference. We don't have speakers, we have participants=0A= that drives proposals. I do not know of any standardization forum where=0A= participants get reimbursed for contributing to the specifications.=0A= =0A= >=0A= > I still doubt that our new competing, backwards compatible alternate=0A= > proposal, will get any pull in various smoky backrooms, but being=0A= > there in person, giving a preso, and wandering the hallways still=0A= > seems to help. Especially... when the ideas and their implications are=0A= > so difficult to express to people outside the narrow field of=0A= > congestion control in the first place, and don't fit easily into an=0A= > RFC format without useful code, repeatable benchmarks, public=0A= > experiments and graphs as guides.=0A= =0A= =0A= Yes, it is an alternative proposal. Where both SCE and L4S desires to=0A= use the same half-bit of the ECN codepoint space. That is what makes=0A= this topic really hard as it appears difficult to run the solutions in=0A= parallel, at least outside of specific DSCPs, and thus especially for=0A= the Best Effort class.=0A= =0A= Your proposal has its challenges in respect to providing a clear=0A= specification of what SCE are and provide that supportive material that=0A= would sway people that your proposal are a better one. To my=0A= understanding the TSVWG chairs have been encouraging a constructive=0A= discussion on the matter.=0A= =0A= It might be that to reach maximum efficiency from your perspective on=0A= this matter you need to have representatives attend the upcoming meeting=0A= in person. Remote participant is an option as the previous email pointed=0A= out and will have some impact. However, I hope you see that there are a=0A= significant fairness issue for IETF as organization to provide monetary=0A= support to some participants and implicitly their proposals. I wish you=0A= luck in finding financial support, however I would kindly request that=0A= you don't use IETF's mailing lists for such requests.=0A= =0A= =0A= Cheers=0A= =0A= Magnus Westerlund =0A= (as TSV AD responsible for TSVWG)=0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Fri May 10 05:02:21 2019 Return-Path: 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 67380120086; Fri, 10 May 2019 05:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 x1zKzF5qiSE2; Fri, 10 May 2019 05:02:01 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 2E50512001B; Fri, 10 May 2019 05:02:01 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id u186so8749024ith.0; Fri, 10 May 2019 05:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6AU1CdjzelYASVPk6+BXG+Ek0sK4P3TfMF58VKQHuOU=; b=LBIsEj52ImvYjXkELr2Fw5ouNjnDg6pAcUss31Np529OZwR8TGtOSTOYd2liju3+AE Z3KTjX3tLzADjrSRq+fuN74KExoBxsJjHzYXwUCsHw54bwOK+1DXcxVbMIo6qcddCi13 yMCAxu2Oo2OKXHrrFIUUdKr5L4s7m308jNAdQvGuXR1hwk7IMGF9fk7K6hGHLWXOWd65 reBPs75BbX4aG0Pd6ZKtOo75xhYHnCv2ZvcwtTbA3K6BaZh/v4Nwt0UiDYDZxEIxUmio bnkTCN4R2P3HmhfD4fAXLaT2rvu1t5KClIkyu9pL5HDyZSS33JPhD4vFcfvFDWYSp9uQ bn5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6AU1CdjzelYASVPk6+BXG+Ek0sK4P3TfMF58VKQHuOU=; b=C9PYku0tEHZnS+pBGaBeOJU4xAdHk5ypN8WZF1j55n8KkujubNEXRwdT2VokGwEIo/ M5l12zsMW3IFtNaKRrSViacM8bmIWuT8ZVDGBHdu5c5pAf6WwRKdnXaEI0aoeziqPJpJ 0PPRdjztd/kDtG5OfJdV7/Wq4of1rCD7a1adxl5x7HrhQLjFaMOWWInm8OykIBy3+Bon k2lyxP06q0L00kX4n4UsWjvHcqPTMMjwPBvb+5GwBumukMs+z5e+qGJ9opR65UnuGqwU VewUr/TTS9Dfr6iE9z2fHsZdRyQfQXNTPZIz46mpvpomdX+QNXerYI+SrAAj7sV7uvzP /ABg== X-Gm-Message-State: APjAAAVxCRw4t3ji8EtGMdQGgRZITb5w1q2H28xonIAYbSnQZnGmVPBH tJezaKgpWDMjiCgCZqOmRDE3jeq2MzIOtHJjmf4= X-Google-Smtp-Source: APXvYqzkrEcuoQ7D75dOursSh/0BioErfoOebxegwkXXyIeg3CxkVbirE12s2H1ltpQeGLqUCAAXoHYgGalzP4RDcIE= X-Received: by 2002:a02:b88b:: with SMTP id p11mr7474614jam.82.1557489720236; Fri, 10 May 2019 05:02:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Fri, 10 May 2019 14:01:39 +0200 Message-ID: To: Magnus Westerlund Cc: The IESG , ECN-Sane , IETF Discussion Mailing List , tsvwg IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 12:02:05 -0000 On Fri, May 10, 2019 at 1:35 PM Magnus Westerlund wrote: > > Hi Dave, > > Please see inline. > > On 2019-05-10 11:17, Dave Taht wrote: > > On Mon, Apr 29, 2019 at 5:32 PM Magnus Westerlund > > wrote: > >> Hi Dave, > >> > >> Thanks for bring this work to the IETF. Yes, I would also like to enco= urage you to discuss your proposal in TSVWG using the mailing list and even= tually present this work at the next TSVWG meeting. However, there is not r= equired to participate in-person. We frequently have remote presentations a= nd from my experience that works well. I=E2=80=99m sure the TSVWG chairs ca= n further advise you on this. > > This is one of those replies that I had to sit on for a while because > > it was so mind-boggling. > > > > If you haven't noticed a few hundred messages about reforming the ietf > > on the IETF mailing list to allow remote participants to have *a vote* > > in how the ietf operates, you might want to review those. > > I have noticed that discussion. Process changes are hard, and the one > thing I am certain over is that we need to have an open discussion about > what changes should happen to facilitate remote only participants to > have nomcom eligibility, right to sign recall petitions etc. Remote > participants are most definitely not on equal footing on that part. If > you think the IESG is obstructionist in this discussion, then it comes I don't consider the IESG to be an entity with one mind. > from the position that if we would simply jump on something without > ensuring consensus on things we equally would be called bad things. We > can facilitate the discussion and ensure that it is given room. For > example a virtual BOF for these topics do make sense. Reform from within moves slowly. > > > > A remote presentation is not enough to get a vote in how the ietf opera= tes. > > However, when it comes to be able to influence the technical work in a > WG a remote participant do have a fair chance. The one to one > discussions that happens in the hallways are hard to cover. That > requires spending a lot of time trying to reach out to people between > the meeting for those conversations. > > > > > > Remote participation on the mailing lists, in this case, was certainly > > not enough. Externally it looked like the l4s/dualpi/tcpprague effort > > was spiraling down the drain with a pesky FRAND patent, no integrated, > > running code, and 4 as-yet unresolved theoretical problems weighing it > > down. > > I don't know what your expectations where here from what I would > consider a rather limited engagement you have had so far on the TSVWG > mailing list. Most of my interactions pre-date that work, on the aqm mailing list, that we closed in part, because it seemed the aqm work had moved to maintenence mode. We were off creating and shipping code, in qty (10s) of millions, based on the accepted standards. Things had got stable enough after releasing sch_cake to start considering an rfc8290bis with what we'd learned from shipping all that code, in real products, particularly on wifi, and to take a harder look at ecn, in general. > I don't share the same view of L4S, although I would have > hoped for more rapid progress and more available running code. > > > > > > But... it really did feel like matters were being settled in smoky > > back rooms when this set of drafts, pitched to the IETF as a (rather > > dubious) experiment, when it came out (hours after we submitted our > > SCE draft) that cablelabs had announced their new standard (no doubt > > expecting a rubber stamp from the ietf) a few weeks prior, and had, > > indeed, been working in secret for 16 months to take over the "last > > half bit" of the ECN header for their own use. > > I have no insight into what has happened in CableLabs. However, it > fairly obvious from mailing list traffic and presentations that > Cablelabs had an interest in L4S. What I know is that we have discussed > L4S for a significant time in IETF. There was a BOF at IETF 96 which > resulted in the inclusion of the work in TSVWG. The framework for the > experiment was discussed, documented and approved in RFC 8311. Yes, the > specification of L4S as being developed have made slow progress, but it > has been making progress. It was the total lack of any integrated useful code from the L4S people, the dodgy benchmarks, lack of third party verification of the benchmarks, and the long-nagging issues never resolved on the IETF AQM mailing list that kicked off the ecn-sane design group ( https://www.bufferbloat.net/projects/ecn-sane/wiki/ ) and its charter last august. SCE is just the first of several outputs of that project. There are several other projects going on in various states of completion which we'll bring to the ietf once the code is in a usuable state, or the papers gone through peer review. > > > > > Radically enough, I do tend to think that the open source community > > does need MUCH better *representation* within the ietf, and to > > leverage Thomas Paine's writings, there should be "no standardization > > without representation", particularly in cases where the code has to > > be universally deployed. This requires actual IETF attendance, by the > > coders or their representatives, at least presently. > > I definitely like more participation from people implementing the > protocols in the IETF and Open Source contributors are important part of > that. And I would like more representation. I've largely stayed out of those threads, because, really, I vastly prefer to just do the technical stuff. I hope that progress is made. >Certain things can most definitely be done on the mailing list and > interacting with authors and being an author of proposals, even if not > present. There are challenges of not being present at meetings when > topics becomes controversial. Building a contact network is also more > challenging when not present at the meetings. Yes. > > > > > Unlike all the other conferences we attend, speakers are not > > recompensed for their costs in the IETF, either. > > IETF is not a conference. We don't have speakers, we have participants > that drives proposals. I do not know of any standardization forum where > participants get reimbursed for contributing to the specifications. To clarify, I should not have said recompense. Elsewhere, speakers are usually not charged conference fees when speaking. Their other costs they eat. > > > > I still doubt that our new competing, backwards compatible alternate > > proposal, will get any pull in various smoky backrooms, but being > > there in person, giving a preso, and wandering the hallways still > > seems to help. Especially... when the ideas and their implications are > > so difficult to express to people outside the narrow field of > > congestion control in the first place, and don't fit easily into an > > RFC format without useful code, repeatable benchmarks, public > > experiments and graphs as guides. > > > Yes, it is an alternative proposal. Where both SCE and L4S desires to > use the same half-bit of the ECN codepoint space. That is what makes > this topic really hard as it appears difficult to run the solutions in > parallel, at least outside of specific DSCPs, and thus especially for > the Best Effort class. > > Your proposal has its challenges in respect to providing a clear > specification of what SCE are and provide that supportive material that > would sway people that your proposal are a better one. To my > understanding the TSVWG chairs have been encouraging a constructive > discussion on the matter. Yes, but 'round here, it's running code first, specs later. Usually. > > It might be that to reach maximum efficiency from your perspective on > this matter you need to have representatives attend the upcoming meeting > in person. Remote participant is an option as the previous email pointed > out and will have some impact. However, I hope you see that there are a > significant fairness issue for IETF as organization to provide monetary > support to some participants and implicitly their proposals. I wish you > luck in finding financial support, however I would kindly request that > you don't use IETF's mailing lists for such requests. My request here was informational. We got offers of airmiles from two ietfers, and that's a help. We're pursuing other sources of travel funds. There will be no further financial requests by us here, and this ends this thread, as far as I'm concerned. > > > Cheers > > Magnus Westerlund > (as TSV AD responsible for TSVWG) > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Fri May 10 06:47:37 2019 Return-Path: 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 7CCDC120020; Fri, 10 May 2019 06:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 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_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 qBwJb91IB18l; Fri, 10 May 2019 06:47:14 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 69FD012001E; Fri, 10 May 2019 06:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e72av8SBoyOlChWXTZCh4JIzOxJpWr9Sk+3L/g6BitI=; b=pkEE7yjJLrmP7Fpd1LBof7vm0 U6BCr++BB+OEtTyhFl3LlAIK6KgvaUOlmimVS7wUdkPwoRG7oW/eJYG4WIqSLUNdqsF8+d37dAeni omoy784BzUtSiywmEdCCA4bHeX1brxdYUoZnT+j5ztagd4NjCM/KZaqVcol9wLAoPSpgNGdP/GdoM SFpC4HMO+gbeNCR4PpMDTjsWj/nsprHrKfMnUDn/7bKiaHcis+amLXybYFJNA/E1XMKjuk8U4jkOX tpj5hEWtlm/2SLKh8B7vSwYDmoBidzuF9vuvtuN/ZGeDI8aDOVRrg5FL5b9AzJeV6id1eWg8XOg6V rSgkshaOQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64001 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hP5re-003aoC-RT; Fri, 10 May 2019 09:47:11 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16E227) In-Reply-To: Date: Fri, 10 May 2019 06:47:06 -0700 Cc: Magnus Westerlund , The IESG , ECN-Sane , IETF Discussion Mailing List , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Taht X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 13:47:16 -0000 Although this is a side issue.... > On May 10, 2019, at 2:17 AM, Dave Taht wrote: >=20 > Unlike all the other conferences we attend, speakers are not > recompensed for their costs in the IETF, either. Speakers at conferences are not compensated. They register like everyone els= e - that has been ACM, IEEE, IFiP, and OSA policy - I know because in some c= ases, I *wrote* the policy. Students are typically required to register at t= he full rate if they present. In the majority of cases, even the chairs pay t= heir own way or at best are comp=E2=80=99d registration. Speakers at trade shows are paid, as are some (but not all) keynotes and tut= orial presenters. The latter often get only honoraria and a comp=E2=80=99d r= eg, not enough for travel/lodging in most cases. The only people who get a fully free ride that I know of are the IEEE Comso= c Board.=20 Joe= From nobody Fri May 10 07:00:14 2019 Return-Path: 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 3F368120021 for ; Fri, 10 May 2019 07:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 Jil7vNpRShhQ for ; Fri, 10 May 2019 07:00:06 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 2EF2B1200A2 for ; Fri, 10 May 2019 07:00:04 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id a132so3615834qkb.13 for ; Fri, 10 May 2019 07:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=O3/sNKfNSW6hgFCXWVOtwtDhPr1/Z3eoJOg41+o7so0=; b=s333RBG6oEkDoP7inZGCJqFqDprnlb+YliB5ZEujqSkZ6R9z4GxfLyUQAkWYAULP5Z LsheJ2EzFRUDRUHRbcpH5+tfIPvO/Xbdb8y3nXGNLWhd2T8Yl3XGJXgGgsmMviyoT6mM I/qJM+8D8ZyMA9aCTsQLz3b7pytA+9Yx/QWH4cB2tXMP1vexgihcd7qxrtXgaRb0maV0 Zs3LyrHP2Hs/a84MZLRxPdvjKNLRk0B+U92+21avgSwCGExsKrYkPpjtZ+jTo3RhZF2N 6aJjWa1Xs1h0hbH3zkUnYsLQxnmZLputb2HmB4ttqXA//QUZYesyRnIROIJHTxr5zn3p iwGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=O3/sNKfNSW6hgFCXWVOtwtDhPr1/Z3eoJOg41+o7so0=; b=uVRc4eh1obIVAYbdYI4XZyHQIUBB2Ya25cZ+r+hFt+s9FhMik92d6tNOMdy7UdXOUP Zk7jCabBoUprd7vfOYUOeRGc7xQZfTyS9bU3jXFb2OHAJr3LAuLYgkcpkWriZCZH316t JIAvTU7QqXx2VJae19VPPkUAicWqJ2BeIxXZ8v5H5kW+kGlgWRLuDIygvuQuBRZiA5/L LZRWmLrSKnBTtYy94W09Dder/eXfp7iuqpunef/GLr0IGfPkR8h2+dCpmo3Y7TMNwl8K LrzVBHzua49XeI+Wp+6qa9FVupLyC+LtH2ZKHtMwlAMOE3UyWmQCQ0AArbiawvXiBORe Mevw== X-Gm-Message-State: APjAAAWWXjf7abXxo9tIbDcMQyhAW5pIlEPaRSfOejdGdLwPTis4gdhC hsGyh4cLZtmDJHgAiUBTK0r37Q== X-Google-Smtp-Source: APXvYqwMesGxdjimZiQUZRPFJV93dYUFAXGr7mDGV9wzTzrlvSaQCppcSFUvN/pXaV1LTzR6l5ZOtw== X-Received: by 2002:a37:b846:: with SMTP id i67mr8863499qkf.179.1557496803156; Fri, 10 May 2019 07:00:03 -0700 (PDT) Received: from [10.0.10.34] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id j4sm3285339qti.49.2019.05.10.07.00.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 07:00:02 -0700 (PDT) From: Ted Lemon Message-Id: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_533A965A-B804-46CC-A8A7-FCDF65F04DB1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Fri, 10 May 2019 10:00:00 -0400 In-Reply-To: Cc: Dave Taht , Magnus Westerlund , tsvwg IETF list , ECN-Sane , The IESG , IETF Discussion Mailing List To: Joe Touch References: X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 14:00:07 -0000 --Apple-Mail=_533A965A-B804-46CC-A8A7-FCDF65F04DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 10, 2019, at 9:47 AM, Joe Touch wrote: > The only people who get a fully free ride that I know of are the IEEE = Comsoc Board.=20 Hm. I=E2=80=99ve never paid to attend IETF. Granted, this is not = because IETF comped me, but because I was fortunate enough to have an = employer who could afford to send me at no cost to me. This model unfortunately doesn=E2=80=99t work for open source developers = who are not on the payroll of a company with deep pockets. --Apple-Mail=_533A965A-B804-46CC-A8A7-FCDF65F04DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 10, 2019, at 9:47 AM, Joe Touch <touch@strayalpha.com> wrote:
The only  people who get a fully free ride that I know = of are the IEEE Comsoc Board. 

Hm.  I=E2=80=99ve never paid to attend IETF. =  Granted, this is not because IETF comped me, but because I was = fortunate enough to have an employer who could afford to send me at no = cost to me.

This= model unfortunately doesn=E2=80=99t work for open source developers who = are not on the payroll of a company with deep pockets.

= --Apple-Mail=_533A965A-B804-46CC-A8A7-FCDF65F04DB1-- From nobody Fri May 10 07:12:59 2019 Return-Path: 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 A0ECD120222; Fri, 10 May 2019 07:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 G3Ecr5w9MLXa; Fri, 10 May 2019 07:12:33 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 9DDA412022E; Fri, 10 May 2019 07:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lWtg6tgldRhiQx1Ytm5GV65J/elcplZpwMPNxPZlV9I=; b=YKbXvMVUB97fFx73fvxwhyueG GpUIrEkL05LYGSn/njZL5caOtqf+kYKvPRFTFOl9qPbaC+utAVyaa7qKKdHSOO5M5V9mNciBv3/ew QBQgL/JERtiV/wGqsnjDy9pYproreTLB1e1q31/Lp6CUhiHGq4iZEzA92un1ofENTnqdc//xslzPo 2d3W325hu54WZISvsMnkSFRGFU4Nu2QxD1hPscdKw54q9P+7/xrvwJYN/Zd/N5uHq+n2fYshuEf+i WFd3M2JTNSOi1+f2pf1m9Sod3T4NClfvD8+UilDchb/XDVAaTwUzYhvxaUtovSm1C5Y4Bg/4Hkois UI3xo+ovQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57954 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hP6GA-0042Lu-7M; Fri, 10 May 2019 10:12:30 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_A22B5EAB-CD08-475D-B949-6826C4248F2A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> Date: Fri, 10 May 2019 07:12:24 -0700 Cc: Magnus Westerlund , IETF Discussion Mailing List , Dave Taht , ECN-Sane , The IESG , tsvwg IETF list Message-Id: References: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 14:12:38 -0000 --Apple-Mail=_A22B5EAB-CD08-475D-B949-6826C4248F2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 10, 2019, at 7:00 AM, Ted Lemon wrote: >=20 > On May 10, 2019, at 9:47 AM, Joe Touch > wrote: >> The only people who get a fully free ride that I know of are the = IEEE Comsoc Board.=20 >=20 > Hm. I=E2=80=99ve never paid to attend IETF. Granted, this is not = because IETF comped me, but because I was fortunate enough to have an = employer who could afford to send me at no cost to me. >=20 > This model unfortunately doesn=E2=80=99t work for open source = developers who are not on the payroll of a company with deep pockets. Nor academics. I stopped coming because I couldn=E2=80=99t find a = gov=E2=80=99t agency interested in supporting my participation either = (and my current employer doesn=E2=80=99t either). This is a problem not only for general attendance but also for the IESG = - which impacts some decisions being made as well. Joe --Apple-Mail=_A22B5EAB-CD08-475D-B949-6826C4248F2A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 10, 2019, at 7:00 AM, Ted Lemon <mellon@fugue.com> = wrote:

On May 10, 2019, at = 9:47 AM, Joe Touch <touch@strayalpha.com> wrote:
The only  people who get a fully free ride that I know = of are the IEEE Comsoc Board. 

Hm.  I=E2=80=99ve never paid to attend IETF. =  Granted, this is not because IETF comped me, but because I was = fortunate enough to have an employer who could afford to send me at no = cost to me.

This= model unfortunately doesn=E2=80=99t work for open source developers who = are not on the payroll of a company with deep = pockets.

Nor academics. I = stopped coming because I couldn=E2=80=99t find a gov=E2=80=99t agency = interested in supporting my participation either (and my current = employer doesn=E2=80=99t either).

This is a problem not only for general attendance = but also for the IESG - which impacts some decisions being made as = well.

Joe

= --Apple-Mail=_A22B5EAB-CD08-475D-B949-6826C4248F2A-- From nobody Fri May 10 07:24:35 2019 Return-Path: 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 A4713120203 for ; Fri, 10 May 2019 07:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 mzoTs4CGSnzp for ; Fri, 10 May 2019 07:24:31 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 5DF431201DD for ; Fri, 10 May 2019 07:24:31 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id z5so5247863lji.10 for ; Fri, 10 May 2019 07:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zVUCRyaRDlFaYhh48IeWO1d6I2EZgGBgmgmu1QHhgBw=; b=A1OvhC4gt37u0sB9zoAqjmrfBvPL/DAS5CqwMvoukos5U6aeFobuZZS26t8+XU7T4r nP3xAlnEa8XBfspSjV/GVmq+KD/+3x/0QLRcyqabZe5rV48WBnauzxedcjYk4LyyILiI sH6A0BQNGIEDFpt7GkJN8wCwy4Hyunq8iLCzY0NF0Y/WJerIdCv41ajSr3+GwFh4zy9v cNrHwsgl8NivwsMRrMgB3W90ZWRp8PBMMBdn7HsceWglEQVcFKCIQwO5YcRE/sQaF75R W9M8miYYa4U/MNdAkV4Eqa8xrQX5CATyJyJeaOCnWA/cOsSHWuzujod3WkEi4E/8oCys 3tHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zVUCRyaRDlFaYhh48IeWO1d6I2EZgGBgmgmu1QHhgBw=; b=Y+ZaDyimfIX/8zW1hPTA2Lu60JjKYycQpE9r19KjcVRAWD27hET+VnCoX7A1hzcRHI jgFItas1r9l2zPjvH4RLifBopZ5vISOD9Os5ZBsJr8HpmOmXIL6f6FH4eaCNGtw1xyU6 8tY641vOPSmJuxxt0O8EucY/X8pFH+jvJj2oVlY0k/bowHPTh9iEeu49b4+dbjy9Qb4i szkmQasBQjoPG6yUHUn2z4OpaBz1dueg/u48JYBbJuG2cucfnGUq0KA0pNosvY6/sNqF kWznHhlQWwoHeZ/EvAX+oYhkhexKpJVM9uNq5O9ki/Wy5wXTD2zldCG0ulxhUW/EUS4B pBBA== X-Gm-Message-State: APjAAAULvyh3jyBwO30R7w5pSUpBS6kk83TSYX3ZHDCsLP4vRH5eEOUE xfNHgGaSO+HbREc8/SQqpOcF2z7YwnO6bGTl++/UTg== X-Google-Smtp-Source: APXvYqxiV1qTSZZeOxMvec+yIniNqtiq5ek5JmZCEX6xlxKRdPZDNr9e+mdFecy74E2T/17h9rp9nSJCjZkr+GZjILM= X-Received: by 2002:a2e:1f02:: with SMTP id f2mr6066007ljf.86.1557498269642; Fri, 10 May 2019 07:24:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 10 May 2019 07:23:53 -0700 Message-ID: To: Joe Touch Cc: Dave Taht , Magnus Westerlund , tsvwg IETF list , ECN-Sane , The IESG , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="00000000000019c90c05888953aa" Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 14:24:33 -0000 --00000000000019c90c05888953aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2019 at 6:47 AM Joe Touch wrote: > Although this is a side issue.... > > > On May 10, 2019, at 2:17 AM, Dave Taht wrote: > > > > Unlike all the other conferences we attend, speakers are not > > recompensed for their costs in the IETF, either. > > Speakers at conferences are not compensated. They register like everyone > else - that has been ACM, IEEE, IFiP, and OSA policy - I know because in > some cases, I *wrote* the policy. Students are typically required to > register at the full rate if they present. In the majority of cases, even > the chairs pay their own way or at best are comp=E2=80=99d registration. > It actually varies. I have been comped where I was asked to give an Invited Talk. That said, the IETF is very different from an academic conference, and i think it would clearly be impractical for the IETF to comp registration for everyone who presented. -Ekr > > Speakers at trade shows are paid, as are some (but not all) keynotes and > tutorial presenters. The latter often get only honoraria and a comp=E2= =80=99d reg, > not enough for travel/lodging in most cases. > > The only people who get a fully free ride that I know of are the IEEE > Comsoc Board. > > Joe > --00000000000019c90c05888953aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 10, 2019 at 6:47 AM Joe T= ouch <touch@strayalpha.com&g= t; wrote:
Althou= gh this is a side issue....

> On May 10, 2019, at 2:17 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
> Unlike all the other conferences we attend, speakers are not
> recompensed for their costs in the IETF, either.

Speakers at conferences are not compensated. They register like everyone el= se - that has been ACM, IEEE, IFiP, and OSA policy - I know because in some= cases, I *wrote* the policy. Students are typically required to register a= t the full rate if they present. In the majority of cases, even the chairs = pay their own way or at best are comp=E2=80=99d registration.

It actually varies. I have been comped where I = was asked to give an Invited Talk.

That said, the = IETF is very different from an academic conference, and i think it would cl= early be impractical for the IETF to comp registration for everyone who pre= sented.

-Ekr
=C2=A0

Speakers at trade shows are paid, as are some (but not all) keynotes and tu= torial presenters.=C2=A0 The latter often get only honoraria and a comp=E2= =80=99d reg, not enough for travel/lodging in most cases.

The only=C2=A0 people who get a fully free ride that I know of are the IEEE= Comsoc Board.

Joe
--00000000000019c90c05888953aa-- From nobody Fri May 10 08:11:37 2019 Return-Path: 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 A9A411200B4 for ; Fri, 10 May 2019 08:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no 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 OK7JpbpsQF9a for ; Fri, 10 May 2019 08:11:15 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 86604120058 for ; Fri, 10 May 2019 08:11:11 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id i31so6906467qti.13 for ; Fri, 10 May 2019 08:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O0r9zmJdJ7wINBebVo7yhlBQvoFULB9bGV1CBTxNAQM=; b=vM3vw5w12bY6Ksil5eDDWwNdXjGC5hNsqJhffluUv9otOJFLArcpoTwEH/GJL6IrnG HObbFNKQvrdfFDG+mZ4RMf0+b0AUrZ1mzeviyUN80j8b/RQdr+nNAP74/2343UKizqwB 8K2mVlp7Y8WV9zFSUCDX/z49SRIRaf064CD36A3i0KUB1JExJTmGs9+MzPkydmhAkxtb D2QG3NUtOTgf0W1Uawyk1UU+dZ9g9R0x2UrICgdjz6nU59pnXLLjf+eOmchkoQo7TJDj VdDd5hY3W7InTPH43hYaRdci1rqTj1enuXYL4eKpgvaUr5zGsClQI5vbVm/NU72FCcYO KJZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O0r9zmJdJ7wINBebVo7yhlBQvoFULB9bGV1CBTxNAQM=; b=Ca+5yILll0o6xrgfqNCoKbcD1mo8LtuDj8gw5Iudh0tP2BEFI2aENTDxsdKgu8Vs9s M9SW7l+4A2CnE3upVHU6Z6f7l9G2NIZm71mFgnCEeByx+WZWR2R37zFB2DjG7ZaCF5QQ /HkRlz60DJPKRd6LMA0teohRoie02fGO6OuOjHBp6ojkiWhHo+sUzFg+DPL1PewlHtlI seaeCym1j4yyjdENM8Pvgf590NW3o5J86YeSW+fYUkA0DMiTHjk/0/sGBh4Y50geMXui v7uNVthaeeCZEFfjKpfyGu/7sq/3ygxoy1BTDQDB3mlMoMQaIB/eBiBnwfnwAj3SMj39 INGg== X-Gm-Message-State: APjAAAWHM1QsJHPkON5x5XriTNJihb5Z7e83DMjwGULYGTrw9zLhootA mlRTURt99sLsLc7QdyPb0sU4nQf+6lYTUBzMogE01w== X-Google-Smtp-Source: APXvYqwb5RudTTPwA38BoHp+Fm6pCghfJ3mXrPsLy9NTsih4ejk1ldmPrhFJ3gJUFH5yDPZzGBut1ez24XZs0ECXufY= X-Received: by 2002:aed:3e57:: with SMTP id m23mr10312089qtf.246.1557501070431; Fri, 10 May 2019 08:11:10 -0700 (PDT) MIME-Version: 1.0 References: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> In-Reply-To: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> From: Tom Herbert Date: Fri, 10 May 2019 08:10:57 -0700 Message-ID: To: Ted Lemon Cc: Joe Touch , Magnus Westerlund , IETF Discussion Mailing List , Dave Taht , ECN-Sane , The IESG , tsvwg IETF list Content-Type: multipart/alternative; boundary="0000000000000a8b64058889fab1" Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 15:11:17 -0000 --0000000000000a8b64058889fab1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2019, 7:00 AM Ted Lemon wrote: > On May 10, 2019, at 9:47 AM, Joe Touch wrote: > > The only people who get a fully free ride that I know of are the IEEE > Comsoc Board. > > > Hm. I=E2=80=99ve never paid to attend IETF. Granted, this is not becaus= e IETF > comped me, but because I was fortunate enough to have an employer who cou= ld > afford to send me at no cost to me. > Ted, I have paid to attend IETF. It is expensive. In fact, for Prague IETF registration alone plus VAT cost twice as much as the airfare to get there from US! I was only able to justify the trip only because we ran Netdev conference at the same location a week before. > > This model unfortunately doesn=E2=80=99t work for open source developers = who are > not on the payroll of a company with deep pockets. > Yes, and I hope this is considered a bad thing lest IETF becomes an elitist organization with only a handful of bigger players running the show. Maybe there should be a "non-sponsored" registration tier with a discount to help make it affordable for the little guys. Tom > --0000000000000a8b64058889fab1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 10, 2019, 7:00 AM Ted Lemon <mellon@fugue.com> wrote:
On May 10, 2019, at 9:47 AM, Joe Touch <touch@strayalpha.= com> wrote:
The only =C2=A0people who get a fu= lly free ride that I know of are the IEEE Comsoc Board.=C2=A0

Hm.=C2=A0 I=E2=80=99ve never paid= to attend IETF.=C2=A0 Granted, this is not because IETF comped me, but bec= ause I was fortunate enough to have an employer who could afford to send me= at no cost to me.
Ted,

I have paid to attend IETF. It is expensive. In fact, for Prague IET= F registration alone plus VAT cost twice as much as the airfare to get ther= e from US! I was only able to justify the trip only because we ran Netdev c= onference at the same location a week before.

This model un= fortunately doesn=E2=80=99t work for open source developers who are not on = the payroll of a company with deep pockets.
<= /div>

Yes, and I hope this is = considered a bad thing lest IETF becomes an elitist organization with only = a handful of bigger players running the show.

Maybe there should be a "non-sponsored" reg= istration tier with a discount to help make it affordable for the little gu= ys.

Tom


--0000000000000a8b64058889fab1-- From nobody Fri May 10 08:53:16 2019 Return-Path: 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 C328412016D for ; Fri, 10 May 2019 08:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 WcnnZ3vHIWKU for ; Fri, 10 May 2019 08:53:13 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 56D0712011B for ; Fri, 10 May 2019 08:53:13 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id j6so7164813qtq.1 for ; Fri, 10 May 2019 08:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F1rtuz8n8LV7lbCe2GTZsZ/78dwK92kzHrOhIIvUR5g=; b=P3PeIYW/4uKgwKt5Q80dSb5qh4LU1eTf1y0g1szLGTofzVhaQqTc0pDYGCy8HyftMO S1sh9WtqmROGp7dlF0t+azJj6hm0mY7m91P3p3cPUIp+48BGrEG0wsxzUJBSi629s94Z r2MZmuN/qG+07htVHHbZXT7XpsstlEzqu6jwcSPThIVUa4ajWzaehPXCgYwctH/04mPS VgdsPRFMU7OWzdfDnaMh6IE4xIpyMZ+CVds9D4oPWxqAiBMmGyaWMS9Ojop8h+CYEnj3 Ts6a/c43OAazXwNTXOCVv5THFQBFI6UqWLhBExU439JOk0yA+hXMMOb+AWCiPEO4IWpt WPBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F1rtuz8n8LV7lbCe2GTZsZ/78dwK92kzHrOhIIvUR5g=; b=BB6SOyAOQXHnqTMwd5ritDJI7o0j9Y4F1FauVFK1ZYqNb4zL6O1OCjeMLL1dBD+ff8 g1PXFcfxSyg4mvwyek0VTS9oUwNpJUl9NL2+hYCYstUP0ofug0MrS14gVtguvS7pbjAC g5Klg3ZIp3QxBhHqa1yC2n2jJovPnvVUeAOSZEjk2Dgj8QFIjyliy+IcugJniBLtm3Ux i+v32TZuro90D4S7gsWsKfU/0m7KGinw1S6Ow0i1UIeCwYrmm45TAwansYs5OHhPxUDp Z0MYFTGLLlyhdhKYnfiUdATcMdOo4dGPEcGixqT1ZVaHG40v1PQn60V3kGuhmUhRB+/E QsKw== X-Gm-Message-State: APjAAAWRUEKTqIaIVLb2JJYqM1Jgc6pe3k6CujbQY4hQu60PaC7bKIYf RIAJ001cncFn35f0cilzxunMjw== X-Google-Smtp-Source: APXvYqya4vWDs5suBh2u+2OV04FRZGlGwVHjndqIxcNhO5p9h1tib7wNqKzPEm/tgHfIj8NM5Cf7Vw== X-Received: by 2002:a0c:d1da:: with SMTP id k26mr9744418qvh.117.1557503592512; Fri, 10 May 2019 08:53:12 -0700 (PDT) Received: from [10.0.10.34] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id m129sm2763220qkb.55.2019.05.10.08.53.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 08:53:11 -0700 (PDT) From: Ted Lemon Message-Id: <037CE2E0-A87E-4EDE-A4BA-B21D19AD1826@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6B1CBC87-175A-49E9-BC90-EF4DAF6275A8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Fri, 10 May 2019 11:53:10 -0400 In-Reply-To: Cc: Joe Touch , Magnus Westerlund , IETF Discussion Mailing List , Dave Taht , ECN-Sane , The IESG , tsvwg IETF list To: Tom Herbert References: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 15:53:15 -0000 --Apple-Mail=_6B1CBC87-175A-49E9-BC90-EF4DAF6275A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 10, 2019, at 11:10 AM, Tom Herbert wrote: > Maybe there should be a "non-sponsored" registration tier with a = discount to help make it affordable for the little guys. The problem is figuring out a sustainability model for IETF that = doesn=E2=80=99t rely on attendance fees and hotel stays. --Apple-Mail=_6B1CBC87-175A-49E9-BC90-EF4DAF6275A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 10, 2019, at 11:10 AM, Tom Herbert <tom@herbertland.com>= wrote:
Maybe there should be a "non-sponsored" registration = tier with a discount to help make it affordable for the little = guys.

The problem is = figuring out a sustainability model for IETF that doesn=E2=80=99t rely = on attendance fees and hotel stays.


= --Apple-Mail=_6B1CBC87-175A-49E9-BC90-EF4DAF6275A8-- From nobody Fri May 10 13:34:12 2019 Return-Path: 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 0CFD91200C5; Fri, 10 May 2019 13:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MONwUCDwZFpc; Fri, 10 May 2019 13:34:01 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 79E3A1200B8; Fri, 10 May 2019 13:34:01 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id a5so3324446pls.12; Fri, 10 May 2019 13:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rM10ZzOsHGLfP2DGaJu7iyiX+uTX6YZ8JuHVJPP6KHE=; b=dgvqb0x0/xC0iJv/YGnUew6ilTaS3Q6NB0+LMvWfVPHD97ToSYs/fGhs+wfU7v+g63 MQgvherAysje7ULdU6Ghyn5xSOn37KwAgmsbc0QcyklPpLNwN6JAl3LMUSUWcg9Pzj3l u8hwyy0aKb8E14y1rCOo6LUlene1eCTHoATnUelcy0LnL0f8yLlaqUfKNBvb/cFlEDWV Wd5irgpHfqUUhRCODPWTDVPGG3Bpt//MBoHk+DVGqwkSwEegLKt/5SJrwptz7/AUdQms 73F3V+KVixWP7nJbMUkXCwr/tzAeaOZc6O99XksEdJs7N33rfFH/PTQAngZUA8qPklo5 vawQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rM10ZzOsHGLfP2DGaJu7iyiX+uTX6YZ8JuHVJPP6KHE=; b=fj0wJBdP+a6I8gO/IlzkddZJFE+G5lSf0JfbzV/B9oNPa8OgvW4uT7Rv7UlBBVoof5 zB1dBKzYZ+SkwhClXZIvWYjbEU7UuSGGnaIJ4mma/1g7pj+ppNZ4QYL4Nc+1yDym1xKY +4LVROGKftuqxmp3otupEYTf8Gb7ObMfD+kQsSsCiwZjD/UY/Hc8akIEp0PAtKzmcrq/ mz8z7X9zOAGgwR2vZUy7plKLo3/+oq368OK8Plv6Aj9RrOdueWI74v/JpJDk0g4pqx+T yphzwdd4Y2GdL3HiIKqG/U51Syoq8L8iZlCV+eeXGL15fUwXY83LLR7Wfy/KrJTQyGT9 8b2Q== X-Gm-Message-State: APjAAAXBgFHJgxePEqvsO3HNjzwNf8WJ1ELljewebJqTWFdIBn8Bh+ms HkExrdUiIBk/ivhoVu656/RwlOo+ X-Google-Smtp-Source: APXvYqxq/NgMnRJfLHI4lN+ULq5rFSKoYEXy9hMfOSFvtdSiBX0IHvOK4qPEQ8MZnjZT4YEJz5BAwQ== X-Received: by 2002:a17:902:bc4b:: with SMTP id t11mr8104489plz.255.1557520440711; Fri, 10 May 2019 13:34:00 -0700 (PDT) Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id f6sm6140409pgq.11.2019.05.10.13.33.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 13:33:59 -0700 (PDT) To: Joe Touch , Ted Lemon Cc: Magnus Westerlund , tsvwg IETF list , ECN-Sane , The IESG , IETF Discussion Mailing List References: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> From: Brian E Carpenter Message-ID: <828cc927-0407-1398-1c21-cfb5100b8628@gmail.com> Date: Sat, 11 May 2019 08:33:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 20:34:03 -0000 On 11-May-19 02:12, Joe Touch wrote: >=20 >=20 >> On May 10, 2019, at 7:00 AM, Ted Lemon > wrote: >> >> On May 10, 2019, at 9:47 AM, Joe Touch > wrote: >>> The only =C2=A0people who get a fully free ride that I know of are th= e IEEE Comsoc Board.=C2=A0 >> >> Hm. =C2=A0I=E2=80=99ve never paid to attend IETF. =C2=A0Granted, this = is not because IETF comped me, but because I was fortunate enough to have= an employer who could afford to send me at no cost to me. >> >> This model unfortunately doesn=E2=80=99t work for open source develope= rs who are not on the payroll of a company with deep pockets. >=20 > Nor academics. I stopped coming because I couldn=E2=80=99t find a gov=E2= =80=99t agency interested in supporting my participation either (and my c= urrent employer doesn=E2=80=99t either). >=20 > This is a problem not only for general attendance but also for the IESG= - which impacts some decisions being made as well. Of course. But none of this is new and the world is a hard place. I misse= d one of the vital meetings of the IPng Directorate in 1994, the meeting = that was the last chance for a major change of direction for what would b= ecome IPv6, because my then employer (CERN) had limited travel funds. I'v= e always regretted missing that meeting. Too bad for me. On 11-May-19 06:19, Keith Moore wrote: > On 5/10/19 11:53 AM, Ted Lemon wrote: >=20 >> On May 10, 2019, at 11:10 AM, Tom Herbert > wrote: >>> Maybe there should be a "non-sponsored" registration tier with a disc= ount to help make it affordable for the little guys. >> >> The problem is figuring out a sustainability model for IETF that doesn= =E2=80=99t rely on attendance fees and hotel stays. >=20 >=20 > And this has been a problem since the early 1990s when the US governmen= t stopped subsidizing the meetings (and perhaps also the secretariat?). = But I wish we'd try harder to find that sustainability model rather than= constantly punting the problem, because the Internet has been suffering = for all that time from a lack of diverse participation in IETF. I don't see how the IETF is supposed to fix the fact that independent ope= n source developers are, um, independent. There is no money tree. And if = you change the model such that funded attendees are subsidising unfunded = attendees in significant numbers, guess what? The number of funded attend= ees will rapidly decline. It seems to me that the current focus on improv= ing remote attendance facilities is really the best we can do, but again:= if remote attendance really becomes as good as on-site attendance, the n= umber of funded atttendees will rapidly decline. I think that if there was a viable answer to this problem, we'd already h= ave found it. Brian From 4bone@gndrsh.dnsmgr.net Sat May 11 10:24:36 2019 Return-Path: <4bone@gndrsh.dnsmgr.net> 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 E330112015F for ; Sat, 11 May 2019 10:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1] autolearn=no 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 lemhPWRYxxln for ; Sat, 11 May 2019 10:24:35 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2F1120158 for ; Sat, 11 May 2019 10:24:34 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x4BHOXiW032848; Sat, 11 May 2019 10:24:33 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x4BHOWeb032847; Sat, 11 May 2019 10:24:32 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201905111724.x4BHOWeb032847@gndrsh.dnsmgr.net> In-Reply-To: <828cc927-0407-1398-1c21-cfb5100b8628@gmail.com> To: Brian E Carpenter Date: Sat, 11 May 2019 10:24:32 -0700 (PDT) CC: Joe Touch , Ted Lemon , IETF Discussion Mailing List , ECN-Sane , tsvwg IETF list , The IESG X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Sun, 12 May 2019 07:52:23 -0700 Subject: Re: [tsvwg] [Ecn-sane] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 17:28:07 -0000 > On 11-May-19 02:12, Joe Touch wrote: > > > > > >> On May 10, 2019, at 7:00 AM, Ted Lemon > wrote: > >> > >> On May 10, 2019, at 9:47 AM, Joe Touch > wrote: > >>> The only ?people who get a fully free ride that I know of are the IEEE Comsoc Board.? > >> > >> Hm. ?I?ve never paid to attend IETF. ?Granted, this is not because IETF comped me, but because I was fortunate enough to have an employer who could afford to send me at no cost to me. > >> > >> This model unfortunately doesn?t work for open source developers who are not on the payroll of a company with deep pockets. > > > > Nor academics. I stopped coming because I couldn?t find a gov?t agency interested in supporting my participation either (and my current employer doesn?t either). > > > > This is a problem not only for general attendance but also for the IESG - which impacts some decisions being made as well. > > Of course. But none of this is new and the world is a hard place. I missed one of the vital meetings of the IPng Directorate in 1994, the meeting that was the last chance for a major change of direction for what would become IPv6, because my then employer (CERN) had limited travel funds. I've always regretted missing that meeting. Too bad for me. Since the ietf is in the standards business, and making good standards means making good decisions, and making good decisions requires being informed, it seems this exclusionary nature of a large critical mass of "smart people" with valid inputs is self defeating. > On 11-May-19 06:19, Keith Moore wrote: > > > On 5/10/19 11:53 AM, Ted Lemon wrote: > > > >> On May 10, 2019, at 11:10 AM, Tom Herbert > wrote: > >>> Maybe there should be a "non-sponsored" registration tier with a discount to help make it affordable for the little guys. > >> > >> The problem is figuring out a sustainability model for IETF that doesn?t rely on attendance fees and hotel stays. > > > > > > And this has been a problem since the early 1990s when the US government stopped subsidizing the meetings (and perhaps also the secretariat?). But I wish we'd try harder to find that sustainability model rather than constantly punting the problem, because the Internet has been suffering for all that time from a lack of diverse participation in IETF. I concur. This problem *must* be solved, but until it comes onto the table as an official problem it well continue to be un-resolvd. > I don't see how the IETF is supposed to fix the fact that independent open source developers are, um, independent. There is no money tree. And if you change the model such that funded attendees are subsidising unfunded attendees in significant numbers, guess what? The number of funded attendees will rapidly decline. It seems to me that the current focus on improving remote attendance facilities is really the best we can do, but again: if remote attendance really becomes as good as on-site attendance, the number of funded atttendees will rapidly decline. > One path forward is to try to lower the cost of the conference through other means. > I think that if there was a viable answer to this problem, we'd already have found it. You can only find things that you look for, from reading this thread it sounds as if there are people who would like this problem solved, but they are not empowered to solve it, and those that are empowered to solve it are not looking for a solution. This is the endless complaint, no action taken cycle. Now that I have responded to the prior comments, rather than just rant, try to offer some positive possible impacts. A) Lower cost to attend. I saw at least one person mention cost of conference exceeding the air-fair, I am going to assume that was an international flight. The Ietf by having its meetings around the globe has infact done some mitigation on this, though it is expensive to attend all meetings, some are usually within reach of many. However the Hotel choice due to size needs is often expensive. I could suggest what I have seen in smaller conferences to help offer a lower cost housign solution, team up with universities, especially over the summer months, many of them have empty dormatories that are available for very low cost. I shall be at an Ottawa, Canada conference next week and my total housing cost based on a shared 2 bd room doorm suite is $250 USD for 5 nights!. B) Create an independent travel grant program, and/or solicite entities that already have a travel grant program that would consider the IETF an appropriate to their needs use of that grant. List these programs on a "need helping attending IETF" web site. C) Continue to improve the remote attendance program, try to bring it on par with actual attendance. We are in the era of remote "work from home, work anyplace on the planet" businesses, this technology is become more and more common place, the IETF *should* commit resources to this. -- Rod Grimes rgrimes@freebsd.org From nobody Sun May 12 15:28:19 2019 Return-Path: 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 A43411201CA for ; Sun, 12 May 2019 15:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Cda1jIj8649V for ; Sun, 12 May 2019 15:28:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 77F351200B1 for ; Sun, 12 May 2019 15:28:02 -0700 (PDT) Received: from [172.19.248.59] ([104.153.224.166]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id x4CMR88V050624; Sun, 12 May 2019 22:27:42 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [104.153.224.166] claimed to be [172.19.248.59] From: Joel Jaeggli Message-Id: <617F1DC0-E891-4548-8BD0-56054ED64E6E@bogus.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B500680C-9B51-4A01-8654-A39F8DED56F6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Sun, 12 May 2019 15:27:00 -0700 In-Reply-To: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> Cc: Joe Touch , Magnus Westerlund , IETF Discussion Mailing List , ECN-Sane , The IESG , tsvwg IETF list To: Ted Lemon References: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2019 22:28:04 -0000 --Apple-Mail=_B500680C-9B51-4A01-8654-A39F8DED56F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 10, 2019, at 07:00, Ted Lemon wrote: >=20 > On May 10, 2019, at 9:47 AM, Joe Touch > wrote: >> The only people who get a fully free ride that I know of are the = IEEE Comsoc Board.=20 >=20 > Hm. I=E2=80=99ve never paid to attend IETF. Granted, this is not = because IETF comped me, but because I was fortunate enough to have an = employer who could afford to send me at no cost to me. >=20 > This model unfortunately doesn=E2=80=99t work for open source = developers who are not on the payroll of a company with deep pockets. >=20 That's an odd definition of having never paid. At the point of = registration, you either provided a credit card or requested an invoice. = The nominal cost of your involvement in the IETF borne on the part of = you or your employer(s) is no doubt considerable, especially during your = term on the IESG when the time commitment was also considerable.. =20 For most of the 4 years I spent on the IESG I paid the costs of = attending out of my own pocket. I did that, because it was what i signed = up for, because it needed to get done and because I believed there was = value in the work being done in the operations and management area. = Back as an individual contributor I come when I have something to do and = some way to pay for it otherwise I wouldn't be there. joel --Apple-Mail=_B500680C-9B51-4A01-8654-A39F8DED56F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 10, 2019, at 07:00, Ted Lemon <mellon@fugue.com> = wrote:

On May 10, 2019, at = 9:47 AM, Joe Touch <touch@strayalpha.com> wrote:
The only  people who get a fully free ride that I know = of are the IEEE Comsoc Board. 

Hm.  I=E2=80=99ve never paid to attend IETF. =  Granted, this is not because IETF comped me, but because I was = fortunate enough to have an employer who could afford to send me at no = cost to me.

This= model unfortunately doesn=E2=80=99t work for open source developers who = are not on the payroll of a company with deep pockets.


That's an odd definition of having never = paid.  At the point of registration, you either provided a credit = card or requested an invoice. The nominal cost of your involvement in = the IETF borne on the part of you or your employer(s) is no doubt = considerable, especially during your term on the IESG when the time = commitment was also considerable..  

For most  of the 4 years I spent = on the IESG I paid the costs of attending out of my own pocket. I did = that, because it was what i signed up for, because it needed to get done = and because I believed there was value in the work being done in the = operations and management area.  Back as an individual contributor = I come when I have something to do and some way to pay for it otherwise = I wouldn't be there.

joel

= --Apple-Mail=_B500680C-9B51-4A01-8654-A39F8DED56F6-- From nobody Sun May 12 16:02:22 2019 Return-Path: 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 0445312011F for ; Sun, 12 May 2019 16:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 IVWU9sxkMCTP for ; Sun, 12 May 2019 16:02:09 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 7A74312013E for ; Sun, 12 May 2019 16:02:09 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id w20so6919746qka.7 for ; Sun, 12 May 2019 16:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5LzVS5wu9T8AFVBcRVVDSYqb55nuuBCHc40PKREbb50=; b=n/Ph8Mv3kNpER4TOMrT1IKcRUSkSER8FZy0kp7D/mOuMaO/mIK8p1W9+7DGmjaAHtc N6Ky8Mm/1Py+Wrsjh4JLbT0LpCUU/iKVjqrzM6ih8w7FkNw9BQbuMA/X8Ks4p64PjWiV 4DENWrVxmnqPrLZD/npM993iuV13tO1pqkQS2dHDqFQ5HW+thsG0Y67Xb0KuykQ+GcNO J/LC+BcEVdwuzJrFpDCWojWjfYJFuny+zQWqX3hCVn3y1Dwd/cB9IW7mbh+KdYjQD/Ms dLBJBN0u0xiz+boLxGIMY7JH2MWNnUjr1pqW/BukqZZRzSouN3czWzC03beeO9B0cJfp PlCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5LzVS5wu9T8AFVBcRVVDSYqb55nuuBCHc40PKREbb50=; b=IHxMgr7Ut4JHXz50OhwYOUTq8XPcV88YFAm9zOpqOFi6rmXHkIN2JtIBzMLhky8LYv 3G0WhQIfiTUKbtvf1E5GtFd9xQ6lo0wya+AYHiNYq2kINrwBI3IIzyp+CbJnmcJ4IevR 8JIQ1HVTC71sj7WdSM8ZQPXliq1Lb5Ky1D3dR17emfXxa3C784PF3HuDYJCSSQgYyBDU zNWSHWMzymcpfGuclcjQa5vFp7P2PjIyEElmeNo5rPAwvKWZCeNyxGf3QdGdouFhB+rB jA5ye6qgR9C/z3rpHHFU/3SjiujaUuzYLWgNSlldxAc93ik1tLbddMMiNT0Zw8VVyxAs CWQw== X-Gm-Message-State: APjAAAWaKXWEbXIULnWCQUaqD0OvkUys8sGov//Ix+I30+cHE/t+X35s hlgErtJDM0xbjRw8qPDZ1fvooA== X-Google-Smtp-Source: APXvYqwrSHnTF7TEZ7Cxy+ZOFap+8Egx86QDyvYv1XCAOPH0DUCfE7xvZGxiEfDnfA7w+t/OsWhx5A== X-Received: by 2002:ae9:f117:: with SMTP id k23mr18667531qkg.344.1557702128363; Sun, 12 May 2019 16:02:08 -0700 (PDT) Received: from [10.0.100.13] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id y14sm7359561qth.48.2019.05.12.16.02.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 May 2019 16:02:06 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9DAC453E-E879-4CE8-8AF0-640141210A33 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPhone Mail (16F155) In-Reply-To: <617F1DC0-E891-4548-8BD0-56054ED64E6E@bogus.com> Date: Sun, 12 May 2019 19:02:05 -0400 Cc: Joe Touch , Magnus Westerlund , IETF Discussion Mailing List , ECN-Sane , The IESG , tsvwg IETF list Content-Transfer-Encoding: 7bit Message-Id: References: <4C8193B9-586C-4ED9-B01E-6BA37071600A@fugue.com> <617F1DC0-E891-4548-8BD0-56054ED64E6E@bogus.com> To: Joel Jaeggli Archived-At: Subject: Re: [tsvwg] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2019 23:02:13 -0000 --Apple-Mail-9DAC453E-E879-4CE8-8AF0-640141210A33 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is the precise distinction I was making. I didn=E2=80=99t pay. Someone p= aid, but not me. It=E2=80=99s amazing that you were willing to make it work o= ut of pocket, but that=E2=80=99s just not scalable.=20 Sent from my iPhone > On May 12, 2019, at 6:27 PM, Joel Jaeggli wrote: >=20 >=20 >=20 >> On May 10, 2019, at 07:00, Ted Lemon wrote: >>=20 >>> On May 10, 2019, at 9:47 AM, Joe Touch wrote: >>> The only people who get a fully free ride that I know of are the IEEE C= omsoc Board.=20 >>=20 >> Hm. I=E2=80=99ve never paid to attend IETF. Granted, this is not becaus= e IETF comped me, but because I was fortunate enough to have an employer who= could afford to send me at no cost to me. >>=20 >> This model unfortunately doesn=E2=80=99t work for open source developers w= ho are not on the payroll of a company with deep pockets. >>=20 >=20 > That's an odd definition of having never paid. At the point of registrati= on, you either provided a credit card or requested an invoice. The nominal c= ost of your involvement in the IETF borne on the part of you or your employe= r(s) is no doubt considerable, especially during your term on the IESG when t= he time commitment was also considerable.. =20 >=20 > For most of the 4 years I spent on the IESG I paid the costs of attending= out of my own pocket. I did that, because it was what i signed up for, beca= use it needed to get done and because I believed there was value in the work= being done in the operations and management area. Back as an individual co= ntributor I come when I have something to do and some way to pay for it othe= rwise I wouldn't be there. >=20 > joel >=20 --Apple-Mail-9DAC453E-E879-4CE8-8AF0-640141210A33 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is the precise distinction I was makin= g. I didn=E2=80=99t pay. Someone paid, but not me. It=E2=80=99s amazing that= you were willing to make it work out of pocket, but that=E2=80=99s just not= scalable. 

Sent from= my iPhone

On May 12, 2019, at 6:27 PM, Joel Jaegg= li <joelja@bogus.com> wrote:


On May 10, 20= 19, at 07:00, Ted Lemon <m= ellon@fugue.com> wrote:

=
On May 10, 2019, at 9:= 47 AM, Joe Touch <touc= h@strayalpha.com> wrote:
The only  people who get a fully free rid= e that I know of are the IEEE Comsoc Board. 

Hm.  I=E2=80=99ve never pai= d to attend IETF.  Granted, this is not because IETF comped me, but bec= ause I was fortunate enough to have an employer who could afford to send me a= t no cost to me.

T= his model unfortunately doesn=E2=80=99t work for open source developers who a= re not on the payroll of a company with deep pockets.
<= br class=3D"">

That's an odd definition of having never paid.  At the point of r= egistration, you either provided a credit card or requested an invoice. The n= ominal cost of your involvement in the IETF borne on the part of you or your= employer(s) is no doubt considerable, especially during your term on the IE= SG when the time commitment was also considerable..  

For most  of the 4 years I spen= t on the IESG I paid the costs of attending out of my own pocket. I did that= , because it was what i signed up for, because it needed to get done and bec= ause I believed there was value in the work being done in the operations and= management area.  Back as an individual contributor I come when I have= something to do and some way to pay for it otherwise I wouldn't be there.

joel

= --Apple-Mail-9DAC453E-E879-4CE8-8AF0-640141210A33-- From nobody Sun May 12 20:13:05 2019 Return-Path: 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 DEDF9120165; Sun, 12 May 2019 20:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0KbmPd6cyaHa; Sun, 12 May 2019 20:11:54 -0700 (PDT) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 47E24120049; Sun, 12 May 2019 20:11:54 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id w7so5716252plz.1; Sun, 12 May 2019 20:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aIfuIkrVqK9UgjzmzczLxuw3JOuIqEP9h2JWokkVdo8=; b=t4kBOyMRFAsWE+kvwGgCTr5idmQEdhRbCIpDT37jd8wf6iwM2frhAqgC1obP8CMli5 G1PZ/z9wNoF/UKjT1gp8LdbX2ZxGCtwweXwLYMoz+V6U8D88kW+/HybNKUp4joQbGM9o QNa6gf16fSYrc9APw7sJalasFDgJy7S3RI3zRIfDHFLK7YKeMD4Gh877V3oFTfONsFJ5 Hj6o51QmFokItARzcKZPUePHJ56aclkfkCMdgpzbIHDAkLH4LVPfWOLyP7eB7Yj6oV1L HaMtKYjRJhcYHH8RsrjDwv1/UKo7pBdK95clUdidXCU0Jt9enOMJfBwOCOF/tJavNY5y Ldyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aIfuIkrVqK9UgjzmzczLxuw3JOuIqEP9h2JWokkVdo8=; b=J1r4ndAxcnQG5FD/bj7XKS03FDIGQNjYCfQ9cKAy318NiT+PcGcWnBJpusIGea252N sGBAsRu6X2BNArN3FW+Nx0sJge/Dh4eSM1M/1MwaoiLRRCJ3zPS9sBrgUWNqvzoyR2Rb NtiqxRIFvV3qsNZZqGn++OT0vFVoEN/ztr7pRi68+kjhV9zS1a6JvZxB67dzQJ1XpA0s RJ0xfC47GF4bIQoQxx3PVBhiYp3fpUyt5FVghBQ9+QYdGOq9l57ajBTdETzHy6PuCGx3 9iKp4tqV1LqIwxLpi5XmfSfX1TF3KESmEacomOMiPbOciHn3ZBbpMmmiQ6nPUJCgyqYH Qbaw== X-Gm-Message-State: APjAAAUsnFPwZIIc6dnv1uoB0loN7xSF074QjXIRhV6KzmVTB4IWS3Kf p9xAxVRT2xpOvwfpLIeASm7xpgmF X-Google-Smtp-Source: APXvYqyE2jl5Q8CLifgftFg40d3HyN0xupNXIXfN4bvxc0oJpFaWzdexN0/vL9BcX3BD0yIzguy7Fg== X-Received: by 2002:a17:902:6948:: with SMTP id k8mr28315407plt.81.1557717113513; Sun, 12 May 2019 20:11:53 -0700 (PDT) Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id k14sm26920078pfj.171.2019.05.12.20.11.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 May 2019 20:11:52 -0700 (PDT) To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Cc: Joe Touch , Ted Lemon , IETF Discussion Mailing List , ECN-Sane , tsvwg IETF list , The IESG References: <201905111724.x4BHOWeb032847@gndrsh.dnsmgr.net> From: Brian E Carpenter Message-ID: <812705f6-58ff-9a7f-dc0d-cc3438a870d1@gmail.com> Date: Mon, 13 May 2019 15:11:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <201905111724.x4BHOWeb032847@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] [Ecn-sane] travel funds for ietf for the next SCE talk? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 03:11:56 -0000 On 12-May-19 05:24, Rodney W. Grimes wrote: >> On 11-May-19 02:12, Joe Touch wrote: >>> >>> >>>> On May 10, 2019, at 7:00 AM, Ted Lemon > wrote: >>>> >>>> On May 10, 2019, at 9:47 AM, Joe Touch > wrote: >>>>> The only ?people who get a fully free ride that I know of are the IEEE Comsoc Board.? >>>> >>>> Hm. ?I?ve never paid to attend IETF. ?Granted, this is not because IETF comped me, but because I was fortunate enough to have an employer who could afford to send me at no cost to me. >>>> >>>> This model unfortunately doesn?t work for open source developers who are not on the payroll of a company with deep pockets. >>> >>> Nor academics. I stopped coming because I couldn?t find a gov?t agency interested in supporting my participation either (and my current employer doesn?t either). >>> >>> This is a problem not only for general attendance but also for the IESG - which impacts some decisions being made as well. >> >> Of course. But none of this is new and the world is a hard place. I missed one of the vital meetings of the IPng Directorate in 1994, the meeting that was the last chance for a major change of direction for what would become IPv6, because my then employer (CERN) had limited travel funds. I've always regretted missing that meeting. Too bad for me. > > Since the ietf is in the standards business, and making good standards means making good decisions, and making good decisions requires being informed, it seems this exclusionary nature of a large critical mass of "smart people" with valid inputs is self defeating. We've moved forward considerably since 1994, when the remote participation facility was extremely weak (remember the MBONE?), conference calls were all over clunky POTs equipment, etc. But what we haven't done is changed the 4-monthly meeting calendar, which is our principal tool for causing work to advance. Nor have we changed the rule that consensus decisions must be based on mailing list discussion. That included the decision to charter IPv6, and the decision to charter homenet, and and every decision to advance the resulting standards track documents. I'm not suggesting that everything should stay as it is; far from it. But even if the results are not always as we'd like them, we do have an existing remote participation model where, in theory, your voice is worth exactly the same as mine. Let me give you an example. I'm co-author of a certain draft in a certain WG. At the last IETF, there was a short in-person discussion and the consensus in the room was to advance the draft to the IESG. The WG chair then sent a message to the WG list to confirm this. I can't give you an exact count of the number of subsequent messages on that thread, but it exceeds 150. I have no idea of the final outcome, but the fate of this document will be decided by remote participants. >> On 11-May-19 06:19, Keith Moore wrote: >> >>> On 5/10/19 11:53 AM, Ted Lemon wrote: >>> >>>> On May 10, 2019, at 11:10 AM, Tom Herbert > wrote: >>>>> Maybe there should be a "non-sponsored" registration tier with a discount to help make it affordable for the little guys. >>>> >>>> The problem is figuring out a sustainability model for IETF that doesn?t rely on attendance fees and hotel stays. >>> >>> >>> And this has been a problem since the early 1990s when the US government stopped subsidizing the meetings (and perhaps also the secretariat?). But I wish we'd try harder to find that sustainability model rather than constantly punting the problem, because the Internet has been suffering for all that time from a lack of diverse participation in IETF. > > I concur. This problem *must* be solved, but until it comes onto the table as an official problem it well continue to be un-resolvd. > >> I don't see how the IETF is supposed to fix the fact that independent open source developers are, um, independent. There is no money tree. And if you change the model such that funded attendees are subsidising unfunded attendees in significant numbers, guess what? The number of funded attendees will rapidly decline. It seems to me that the current focus on improving remote attendance facilities is really the best we can do, but again: if remote attendance really becomes as good as on-site attendance, the number of funded atttendees will rapidly decline. >> > > One path forward is to try to lower the cost of the conference through other means. It's a _meeting_ not a conference, and the semantics matter. Even though we have sponsors, it's a not a conference with primary marketing or educational value. As others have commented, we're also constrained to venues with large enough facilities and nearby airports. So both squeezing out cost and obtaining additional sponsorship are challenging. > >> I think that if there was a viable answer to this problem, we'd already have found it. > > You can only find things that you look for, from reading this thread > it sounds as if there are people who would like this problem solved, > but they are not empowered to solve it, and those that are empowered > to solve it are not looking for a solution. > > This is the endless complaint, no action taken cycle. Not really. We've recently reformatted our admin, with one of the goals being more professional and focused fund-raising. We've also done a lot of work on criteria for venue selection. We've done a lot to improve remote participation, which is now largely viable, with relatively rare glitches. What we haven't done is change our basic 4-monthly cycle, as noted above. Brian > > Now that I have responded to the prior comments, rather than just rant, try to offer some positive possible impacts. > > A) Lower cost to attend. I saw at least one person mention cost of conference exceeding the air-fair, I am going to assume that was an international flight. The Ietf by having its meetings around the globe has infact done some mitigation on this, though it is expensive to attend all meetings, some are usually within reach of many. However the Hotel choice due to size needs is often expensive. I could suggest what I have seen in smaller conferences to help offer a lower cost housign solution, team up with universities, especially over the summer months, many of them have empty dormatories that are available for very low cost. I shall be at an Ottawa, Canada conference next week and my total housing cost based on a shared 2 bd room doorm suite is $250 USD for 5 nights!. > > B) Create an independent travel grant program, and/or solicite entities that already have a travel grant program that would consider the IETF an appropriate to their needs use of that grant. List these programs on a "need helping attending IETF" web site. > > C) Continue to improve the remote attendance program, try to bring it on par with actual attendance. We are in the era of remote "work from home, work anyplace on the planet" businesses, this technology is become more and more common place, the IETF *should* commit resources to this. > From andrewmcgr@gmail.com Tue May 14 20:32:42 2019 Return-Path: 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 265F7120260 for ; Tue, 14 May 2019 20:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QhGz84QyhQmj for ; Tue, 14 May 2019 20:32:39 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 B3B6F1200EC for ; Tue, 14 May 2019 20:32:39 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id e9so465573uar.9 for ; Tue, 14 May 2019 20:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qNC62bgAYCWGaO5J7dTSWxbfTW1YjuKIhkCVGvoiFj0=; b=YRybHtRXWZcugZLDkgqEYjZGHu5tb3yPD2z9S39BX7Qw76KvVDN7hHjO3FPGvgEPFm mYjM7uEhx6r3JH0YjAWgGWfqG6yrogMo84k+GW7fAmr5ZrrTxnO+zwFJ3RmybKVBtM1k v/Sy4kfVHjob25bMUWw+P3JYrwPw70N5F0JnmRCrCMYbHsOx9Bpt88cT35M00jzrZPZ0 1ZzLNyiV27sYEpGR3qqXZky2m9gaSvunRnJQI4aN4psab8UbP2Gf1XYtiZ8yVwYcjiXo Pgj2mXIzSE3gfH9+qezACX4824Eiu/HBKn52e7E7bVDZGzIrQePAnh39FDVLIT+HQzSo bn2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qNC62bgAYCWGaO5J7dTSWxbfTW1YjuKIhkCVGvoiFj0=; b=fCb5E7I4f+pEB+TSTkOdSHlXvoXD3T7XHGbclr/y0zRGd3vU9G1hwuDhpWMEzarSpw 06luep+DFtnYxO5EmMt3FCXQAfpMqCmYdaXnDSDNQrnTPYKti1hht9PC4Ur7d3um0ofn S/Yyi2jSErHewbYeDCMk5lDh0oKXG1hsGM0aiz+GuomRHr6E0X6oYttwSOqhxd5jPp8K 1uLrATEemI3PKeF4c5ze5uAZCFn/+Rt5SUI1//+ISbcSAQy0dLzwWHLtpoemE9tL5bmB A6C12ZThNcpSUfNLyncCpRrGtce27XGCcGNo5C8RqxWZvjRL+6TAQbTMxxTbsjf4nvgT cy1g== X-Gm-Message-State: APjAAAX+U4WVHu4wYYqI18kZhPzQzF+Lr/vNVeUncImcP7cIqNHOujPK /sxXjKiwvt0rQzA91xqor516+asIw+4cdustB0weMene X-Google-Smtp-Source: APXvYqyucsWzX0oR0ylG23vZT0EghvRWGZhTcYYPqaZM9BbkUt3RuZzkS0ItZ/HcE4peQhy4hmH5yb0k0eRZWDvSPdc= X-Received: by 2002:ab0:2845:: with SMTP id c5mr15795564uaq.61.1557891158351; Tue, 14 May 2019 20:32:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew McGregor Date: Wed, 15 May 2019 13:32:27 +1000 Message-ID: To: tsvwg Content-Type: multipart/alternative; boundary="00000000000017a5d80588e4cd00" Archived-At: Subject: [tsvwg] Fwd: TSVWG: WGLC reviews of ECN encapsulation drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 11:09:23 -0000 --00000000000017a5d80588e4cd00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message --------- From: Andrew McGregor Date: Fri, May 10, 2019 at 10:32 AM Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts To: Black, David , < draft-ietf-tsvwg-ecn-encap-guidelines@ietf.org> Cc: gorry@erg.abdn.ac.uk , Scheffenegger, Richard < Richard.Scheffenegger@netapp.com>, Brian Trammell (trammell@tik.ee.ethz.ch) , Black, David , Wesley Eddy Hi all, I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines. I find only one issue of any substance. That is, the definition of a PDU and the discussion on reframing and congestion marking in section 4.6 seems to me to apply more to fragmenting MACs like ATM than to aggregating MACs like LTE, WiFi, and DOCSIS. Particularly, if an aggregated PDU is congestion marked in total, is it correct to mark all the contained IP frames? What if, like WiFi, the lower layer supports non-congestive drops for single PDUs within an MPDU, and could conceivably also support congestion marking separately? One could imagine defining congestion in terms of airtime rather than octets for wireless MACs, for example. Nits: "doesn't" seems to be used frequently, which doesn't seem appropriate in every case. "feed-up-an-forward" typo in the second-last paragraph of the conclusion. Hope this helps, Andrew On Thu, Dec 20, 2018 at 11:31 AM Black, David wrote: > Gentlemen (Gorry, Richard, Brian and Andrew): > > > > Once upon a time (this past summer in Montreal), I believe that each of > you volunteered to review the two ECN encapsulation drafts during a Worki= ng > Group Last Call (WGLC): > > - draft-ietf-tsvwg-ecn-encap-guidelines > > > - draft-ietf-tsvwg-rfc6040update-shim > > > I subsequently dropped the ball on this :-(. > > > > I=E2=80=99m now planning to start a combined WGLC on these two drafts som= etime in > January. Would each of you please let me know: > > - Whether you=E2=80=99re still able to and interested in = reviewing > these drafts during WGLC, and > > - Any time preferences or restrictions on when to do the > review, so that I can schedule the WGLC appropriately. > > I have no problem with a longer-than-usual WGLC time period to enable > reviews from talented folks such as you. > > > > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Senior Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA 01748 > > +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > > > --00000000000017a5d80588e4cd00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Andrew McGregor <andrewmcgr@gmail.com&g= t;
Date: Fri, May 10, 2019 at 10:32 AM
Subject: Re: TSVWG: WGL= C reviews of ECN encapsulation drafts
To: Black, David <David.Black@dell.com>, <draft-ietf-tsvwg-ecn-e= ncap-guidelines@ietf.org>
Cc: gorry@erg.abdn.ac.uk <g= orry@erg.abdn.ac.uk>, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>, = Brian Trammell (trammell@tik.ee.= ethz.ch) <trammell@tik.ee= .ethz.ch>, Black, David <= David.Black@dell.com>, Wesley Eddy <wes@mti-systems.com>


Hi all,

I have reviewed draft-ietf-tsvwg-e= cn-encap-guidelines.

I find only one issue of any = substance. That is, the definition of a PDU and the discussion on reframing= and congestion marking in section 4.6 seems to me to apply more to fragmen= ting MACs like ATM than to aggregating MACs like LTE, WiFi, and DOCSIS. Par= ticularly, if an aggregated PDU is congestion marked in total, is it correc= t to mark all the contained IP frames? What if, like WiFi, the lower layer = supports non-congestive drops for single PDUs within an MPDU, and could con= ceivably also support congestion marking separately? One could imagine defi= ning congestion in terms of airtime rather than octets for wireless MACs, f= or example.

Nits:
"doesn't"= ; seems to be used frequently, which doesn't seem appropriate in every = case.

"feed-up-an-forward" typo in the s= econd-last paragraph of the conclusion.

Hope this = helps,
Andrew

On Thu, Dec 20, 2018 at 11:31 AM Black, = David <David.B= lack@dell.com> wrote:

Gentlemen (Gorry, Richard, Brian and Andrew):=

=C2=A0

Once upon a time (this past summer in Montreal), I b= elieve that each of you volunteered to review the two ECN encapsulation dra= fts during a Working Group Last Call (WGLC):

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - draft-ietf-tsvwg-ecn-encap-guidelines

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - draft-ietf-tsvwg-rfc6040update-shim

I subsequently dropped the ball on this :-(.<= u>

=C2=A0

I=E2=80=99m now planning to start a combined WGLC on= these two drafts sometime in January.=C2=A0=C2=A0 Would each of you please= let me know:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Whether you=E2=80=99re still able= to and interested in reviewing these drafts during WGLC, and=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Any time preferences or restricti= ons on when to do the review, so that I can schedule the WGLC appropriately= .

I have no problem with a longer-than-usual WGLC time= period to enable reviews from talented folks such as you.

=C2=A0

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Senior Distinguished Engineer=

Dell EMC, 176 South St., Hopkinton, MA=C2=A0 01748

+1 (774) 350-9323 New=C2=A0=C2=A0=C2=A0 Mobil= e: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------= ------------

=C2=A0

--00000000000017a5d80588e4cd00-- From andrewmcgr@gmail.com Tue May 14 20:32:53 2019 Return-Path: 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 EC84012026B for ; Tue, 14 May 2019 20:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EZapVei5roG3 for ; Tue, 14 May 2019 20:32:52 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 D7CCC1200EC for ; Tue, 14 May 2019 20:32:51 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id z11so726409vsq.9 for ; Tue, 14 May 2019 20:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ci70yNnkQPqZcF82cMGN2IPRtxN5INm1q/hDnnaQ87c=; b=LbVYX9lER0d2ytuoNq/Qw1z+tW1CAHA7xgOxJ3f+ilLGdm1NLDbJ9JzOLwSjgmr86c o+TDa9Ez1C+APTd9iEOJ5zuYRinM9mM8C58ICdO+/3JzBuXV/NY8UbYbHYd7zFycDQXX 1jezKmf4pzu4ZDjq5LvqX+79WLEcjluWBiZxooTQ8/zo+Yph/JNOUZ0M+sa7d+S0hIyc BJJer9SZUCikr8OTHf+hYBs86UW2lTXfnyz30TdHUGtjG3V90LqPdt0HozmxYzuvAUSW 3iI1pB2GLpMZDeG7gKIZpXPLhA7ItTkoTNIalbD9rkhmCKX5ijwvvBMLN+FmTGyVwYrJ u18w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ci70yNnkQPqZcF82cMGN2IPRtxN5INm1q/hDnnaQ87c=; b=q9fMeGj42KdfM3Mv7N9zx+amzvRkh/WAXI8g3Zhv0859yPUDXEWR14QL8bg0oBSasU 5HWUJ7IKFg2AzNSMFa7HuIiqboWhjDr7h3hVDASt6bNlEYQGXnNLeg2OoScksdh/Znbv udG3f6xDNsngq7qw20uI62vaMOzj62W27t6Wpev0IA6SdtMWvfrcLyvzPyUd6wxcQyB7 j6+76xjx3dyb1wGBJg3u/kC/apAcBpmMOhGU6Ryc7MT/f3IungdiiJcXVeh9ME/haIwF HU/OhqQX8bO0l+y/HhnZ+zi0pNvDzypPyI/IvNftmr0tLzSEeA1Sw8bCUdr4HcSjNVU5 Qn0g== X-Gm-Message-State: APjAAAWXUgnkRKT5yKKEndyISIhhH4X7JBIZOZW9bd4w+xcrDwPEMRkr g7plCf3uYTn9HpasEKNRwyxsWWGMN3oC4FZjG5R4jI+L X-Google-Smtp-Source: APXvYqyP3q+dUSIEt7b+tc39RogPU+6vpgi2+9/Izusr6c3cNQuOI4sgZyyFYpvvJ6ct8E+4e/Kh9aQErw7o4+T0TLc= X-Received: by 2002:a67:f489:: with SMTP id o9mr9271246vsn.118.1557891170674; Tue, 14 May 2019 20:32:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew McGregor Date: Wed, 15 May 2019 13:32:39 +1000 Message-ID: To: tsvwg Content-Type: multipart/alternative; boundary="000000000000d3abd70588e4cde8" Archived-At: Subject: [tsvwg] Fwd: TSVWG: WGLC reviews of ECN encapsulation drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 11:09:33 -0000 --000000000000d3abd70588e4cde8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message --------- From: Andrew McGregor Date: Fri, May 10, 2019 at 2:10 PM Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts To: Black, David , < draft-ietf-tsvwg-rfc6040update-shim@ietf.org> Cc: gorry@erg.abdn.ac.uk , Scheffenegger, Richard < Richard.Scheffenegger@netapp.com>, Brian Trammell (trammell@tik.ee.ethz.ch) , Black, David , Wesley Eddy Hi all, I have reviewed draft-ietf-tsvwg-rfc6040update-shim, and in my opinion it is good to publish. I note the RFCXXX instructions to the RFC editor and corresponding parenthetical notes, it may be as well, if not already done, to ask what form the editors prefer those to be in. Hope this helps, Andrew On Thu, Dec 20, 2018 at 11:31 AM Black, David wrote: > Gentlemen (Gorry, Richard, Brian and Andrew): > > > > Once upon a time (this past summer in Montreal), I believe that each of > you volunteered to review the two ECN encapsulation drafts during a Worki= ng > Group Last Call (WGLC): > > - draft-ietf-tsvwg-ecn-encap-guidelines > > > - draft-ietf-tsvwg-rfc6040update-shim > > > I subsequently dropped the ball on this :-(. > > > > I=E2=80=99m now planning to start a combined WGLC on these two drafts som= etime in > January. Would each of you please let me know: > > - Whether you=E2=80=99re still able to and interested in = reviewing > these drafts during WGLC, and > > - Any time preferences or restrictions on when to do the > review, so that I can schedule the WGLC appropriately. > > I have no problem with a longer-than-usual WGLC time period to enable > reviews from talented folks such as you. > > > > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Senior Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA 01748 > > +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > > > --000000000000d3abd70588e4cde8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Andrew McGregor <andrewmcgr@gmail.com&g= t;
Date: Fri, May 10, 2019 at 2:10 PM
Subject: Re: TSVWG: WGLC= reviews of ECN encapsulation drafts
To: Black, David <David.Black@dell.com>, <draft-ietf-tsvwg-rfc6040u= pdate-shim@ietf.org>
Cc: = gorry@erg.abdn.ac.uk <gorry@= erg.abdn.ac.uk>, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>, Brian= Trammell (trammell@tik.ee.ethz.= ch) <trammell@tik.ee.ethz= .ch>, Black, David <David= .Black@dell.com>, Wesley Eddy <wes@mti-systems.com>


Hi all,

I have re= viewed draft-ietf-tsvwg-rfc6040update-shim, and in my opinion it is good to= publish.

I note the RFCXXX instru= ctions to the RFC editor and corresponding parenthetical notes, it may be a= s well, if not already done, to ask what form the editors prefer those to b= e in.

Hope this helps,
Andrew

On Th= u, Dec 20, 2018 at 11:31 AM Black, David <David.Black@dell.com> wrote:

Gentlemen (Gorry, Richard, Brian and Andrew):=

=C2=A0

Once upon a time (this past summer in Montreal), I b= elieve that each of you volunteered to review the two ECN encapsulation dra= fts during a Working Group Last Call (WGLC):

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - draft-ietf-tsvwg-ecn-encap-guidelines

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - draft-ietf-tsvwg-rfc6040update-shim

I subsequently dropped the ball on this :-(.<= u>

=C2=A0

I=E2=80=99m now planning to start a combined WGLC on= these two drafts sometime in January.=C2=A0=C2=A0 Would each of you please= let me know:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Whether you=E2=80=99re still able= to and interested in reviewing these drafts during WGLC, and=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Any time preferences or restricti= ons on when to do the review, so that I can schedule the WGLC appropriately= .

I have no problem with a longer-than-usual WGLC time= period to enable reviews from talented folks such as you.

=C2=A0

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Senior Distinguished Engineer=

Dell EMC, 176 South St., Hopkinton, MA=C2=A0 01748

+1 (774) 350-9323 New=C2=A0=C2=A0=C2=A0 Mobil= e: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------= ------------

=C2=A0

--000000000000d3abd70588e4cde8-- From nobody Wed May 15 11:08:34 2019 Return-Path: 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 256251204C3 for ; Wed, 15 May 2019 11:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 aDmGD4dvNJfe for ; Wed, 15 May 2019 11:08:30 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 C95F912015F for ; Wed, 15 May 2019 11:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6f+/08cIR5MeZK6fHhhGqkdhMcw3v4sq3Emip8BI6yA=; b=4FmD79oVhb6SvW9Z7A2YMMNo/ vwSey6ChsUGQB28MeJsueMEtPOrn2qnVZpU6R2/+KpDBD5+o9snAA+aoFH1P2GXCB/pWjWO/PFthN g9iuWgmjjtp66bnxgCQHm5/aufZYBBWrNm8AJL91ie6CgsPPzr2UF4wqfLjOVpZu84TImVg4ue5ED 7yPGzhiD79th0h7CHUEzY+xVRi1pkjSNAaFg1KMABkRX6bbqYOexhVNtCTWW/UidTSrnPLU84d74E JPFYMTinfOQDaSTY8WKc9vdcq/LwZKJzm6LBW6JN/kv6aeWrvXZDfmhvzNclIAGII4BABa2e8BA3j Is/U7j2Zw==; Received: from [31.185.135.221] (port=33514 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hQyKJ-0008Im-49; Wed, 15 May 2019 19:08:27 +0100 To: Andrew McGregor , tsvwg References: From: Bob Briscoe Message-ID: <84005628-9703-c6ab-d27b-b91fce2e396a@bobbriscoe.net> Date: Wed, 15 May 2019 19:08:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------745B8BA4BB81233A94577278" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] Fwd: TSVWG: WGLC reviews of ECN encapsulation drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 18:08:33 -0000 This is a multi-part message in MIME format. --------------745B8BA4BB81233A94577278 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Andrew, Thank you v much for reviewing this hefty tome. Inline... On 15/05/2019 04:32, Andrew McGregor wrote: > > > ---------- Forwarded message --------- > From: *Andrew McGregor* > > Date: Fri, May 10, 2019 at 10:32 AM > Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts > To: Black, David >, > > > Cc: gorry@erg.abdn.ac.uk > >, Scheffenegger, > Richard >, Brian Trammell > (trammell@tik.ee.ethz.ch ) > >, Black, > David >, Wesley > Eddy > > > > Hi all, > > I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines. > > I find only one issue of any substance. That is, the definition of a > PDU and the discussion on reframing and congestion marking in section > 4.6 seems to me to apply more to fragmenting MACs like ATM than to > aggregating MACs like LTE, WiFi, and DOCSIS. I don't think LTE and DOCSIS can be called aggregating MACs in the same way that WiFi is. Their link layer forwards a byte stream chopped up into segments/frames so the boundaries of packet and of segments/frames don't generally align. Whereas I believe a WiFi frame always contains an integer number of packets. > Particularly, if an aggregated PDU is congestion marked in total, is > it correct to mark all the contained IP frames? Yes. For instance, if the AQM is currently marking 0.1% of aggregated PDUs (randomly - without regard to their size), then marking all the packets within each marked MPDU will also mark 0.1% of packets on average. You might think it would be better to somehow spread out the 0.1% marking of packets. But that would necessarily involve holding back markings. The text in S.4.6 says don't do that, rightly IMO. > What if, like WiFi, the lower layer supports non-congestive drops for > single PDUs within an MPDU, and could conceivably also support > congestion marking separately? One could imagine defining congestion > in terms of airtime rather than octets for wireless MACs, for example. If the lower layer chooses to ECN-mark packets as they arrive at the queue into the layer, that's fine. Then there is no re-framing problem for the ECN markings. That's how AQM dropping and ECN marking is done in DOCSIS. I suspect a link layer would generally only need the L2 protocol to support ECN marking where there might be pure L2 nodes with no IP awareness. For instance, in LTE, an eNodeB is often not IP-aware, so if an AQM at the eNodeB was going to ECN-mark in-band, the RLC protocol would have to be modified to support ECN marks. Then, when RLC PDUs were decapsulated, the reframing rules for ECN marking in S.4.6 would come into play. I'm not sure yet whether or what I need to change in section 4.6. Given the above, can you help me understand what I've written incomprehenisbly? Thx for the nits. > > Nits: > "doesn't" seems to be used frequently, which doesn't seem appropriate > in every case. > > "feed-up-an-forward" typo in the second-last paragraph of the conclusion. > > Hope this helps, > Andrew > > On Thu, Dec 20, 2018 at 11:31 AM Black, David > wrote: > > Gentlemen (Gorry, Richard, Brian and Andrew): > > Once upon a time (this past summer in Montreal), I believe that > each of you volunteered to review the two ECN encapsulation drafts > during a Working Group Last Call (WGLC): > >                 - draft-ietf-tsvwg-ecn-encap-guidelines > > >                 - draft-ietf-tsvwg-rfc6040update-shim > > > I subsequently dropped the ball on this :-(. > > I’m now planning to start a combined WGLC on these two drafts > sometime in January.   Would each of you please let me know: > >                 - Whether you’re still able to and interested in > reviewing these drafts during WGLC, and > >                 - Any time preferences or restrictions on when to > do the review, so that I can schedule the WGLC appropriately.. > > I have no problem with a longer-than-usual WGLC time period to > enable reviews from talented folks such as you. > > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Senior Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA  01748 > > +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------745B8BA4BB81233A94577278 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Andrew,

Thank you v much for reviewing this hefty tome. Inline...

On 15/05/2019 04:32, Andrew McGregor wrote:


---------- Forwarded message ---------
From: Andrew McGregor <andrewmcgr@gmail.com>
Date: Fri, May 10, 2019 at 10:32 AM
Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts
To: Black, David <David.Black@dell.com>, <draft-ietf-tsvwg-ecn-encap-guidelines@ietf.org>
Cc: gorry@erg.abdn.ac.uk <gorry@erg.abdn.ac.uk>, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>, Brian Trammell (trammell@tik.ee.ethz.ch) <trammell@tik.ee..ethz.ch>, Black, David <David.Black@dell.com>, Wesley Eddy <wes@mti-systems.com>


Hi all,

I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines.

I find only one issue of any substance. That is, the definition of a PDU and the discussion on reframing and congestion marking in section 4.6 seems to me to apply more to fragmenting MACs like ATM than to aggregating MACs like LTE, WiFi, and DOCSIS.
I don't think LTE and DOCSIS can be called aggregating MACs in the same way that WiFi is. Their link layer forwards a byte stream chopped up into segments/frames so the boundaries of packet and of segments/frames don't generally align. Whereas I believe a WiFi frame always contains an integer number of packets.

Particularly, if an aggregated PDU is congestion marked in total, is it correct to mark all the contained IP frames?
Yes. For instance, if the AQM is currently marking 0.1% of aggregated PDUs (randomly - without regard to their size), then marking all the packets within each marked MPDU will also mark 0.1% of packets on average.

You might think it would be better to somehow spread out the 0.1% marking of packets. But that would necessarily involve holding back markings. The text in S.4.6 says don't do that, rightly IMO.

What if, like WiFi, the lower layer supports non-congestive drops for single PDUs within an MPDU, and could conceivably also support congestion marking separately? One could imagine defining congestion in terms of airtime rather than octets for wireless MACs, for example.
If the lower layer chooses to ECN-mark packets as they arrive at the queue into the layer, that's fine. Then there is no re-framing problem for the ECN markings. That's how AQM dropping and ECN marking is done in DOCSIS.

I suspect a link layer would generally only need the L2 protocol to support ECN marking where there might be pure L2 nodes with no IP awareness. For instance, in LTE, an eNodeB is often not IP-aware, so if an AQM at the eNodeB was going to ECN-mark in-band, the RLC protocol would have to be modified to support ECN marks. Then, when RLC PDUs were decapsulated, the reframing rules for ECN marking in S.4.6 would come into play.

I'm not sure yet whether or what I need to change in section 4.6. Given the above, can you help me understand what I've written incomprehenisbly?


Thx for the nits.



Nits:
"doesn't" seems to be used frequently, which doesn't seem appropriate in every case.

"feed-up-an-forward" typo in the second-last paragraph of the conclusion.

Hope this helps,
Andrew

On Thu, Dec 20, 2018 at 11:31 AM Black, David <David.Black@dell.com> wrote:

Gentlemen (Gorry, Richard, Brian and Andrew):

 

Once upon a time (this past summer in Montreal), I believe that each of you volunteered to review the two ECN encapsulation drafts during a Working Group Last Call (WGLC):

                - draft-ietf-tsvwg-ecn-encap-guidelines

                - draft-ietf-tsvwg-rfc6040update-shim

I subsequently dropped the ball on this :-(.

 

I’m now planning to start a combined WGLC on these two drafts sometime in January.   Would each of you please let me know:

                - Whether you’re still able to and interested in reviewing these drafts during WGLC, and

                - Any time preferences or restrictions on when to do the review, so that I can schedule the WGLC appropriately..

I have no problem with a longer-than-usual WGLC time period to enable reviews from talented folks such as you.

 

Thanks, --David

----------------------------------------------------------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------------------

 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------745B8BA4BB81233A94577278-- From nobody Wed May 15 14:57:21 2019 Return-Path: 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 7EC5912010C for ; Wed, 15 May 2019 14:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 j6qdnP913LX5 for ; Wed, 15 May 2019 14:57:16 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 3BCA51200FE for ; Wed, 15 May 2019 14:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:To:Subject:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YT1o/9RQ+o45RWBRtlOgEnRLitBmpA8wIbA1huoFJ68=; b=T7vaIjmQJ5APU9LmSzHhT7suN u6mAn1W0UJ9Bn+KY40VqEIgyhgeCA7XRqJUGmBZkRQxfcaJXseY93rXCWCBWFE1yldsgI6bNtOM37 M0YTVZo2qcwyoWcWXI+QG6quMg8XKDZpaFhpWuvHWZkw5EbgBKKy8gB3j3fwe/NVaPpW8FGZOSixO hf0MCW6XO6a+Wj1KGYqZYGJ1ROkGhIKTfUJcM/ctUHqvRiICHp3cIaWOshw53BbpyqcPTWKiokfzI ciVRhCtpxartiYDneHadDt2vJt+jr7DKyxIZIoEUZzXM1xLBnESS0rahSN0SDvGg1BweReqcUMxzD oydXIfrFQ==; Received: from [31.185.135.221] (port=33552 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hR1ti-0000rh-1G; Wed, 15 May 2019 22:57:14 +0100 From: Bob Briscoe To: Andrew McGregor , tsvwg References: Message-ID: <7ee360ab-0ea0-515a-3920-3047592287c6@bobbriscoe.net> Date: Wed, 15 May 2019 22:57:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------00B806BCB5E2BEF7CE2FE353" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] Fwd: TSVWG: WGLC reviews of ECN encapsulation drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 21:57:20 -0000 This is a multi-part message in MIME format. --------------00B806BCB5E2BEF7CE2FE353 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Andrew, Thank you v much for reviewing this hefty tome. I've added one more sentence inline (after "incomprehensibly"), cos I fired the last email off a bit early... On 15/05/2019 04:32, Andrew McGregor wrote: > > > ---------- Forwarded message --------- > From: *Andrew McGregor* > > Date: Fri, May 10, 2019 at 10:32 AM > Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts > To: Black, David >, > > > Cc: gorry@erg.abdn.ac.uk > >, Scheffenegger, > Richard >, Brian Trammell > (trammell@tik.ee.ethz.ch ) > >, Black, > David >, Wesley > Eddy > > > > Hi all, > > I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines. > > I find only one issue of any substance. That is, the definition of a > PDU and the discussion on reframing and congestion marking in section > 4.6 seems to me to apply more to fragmenting MACs like ATM than to > aggregating MACs like LTE, WiFi, and DOCSIS. I don't think LTE and DOCSIS can be called aggregating MACs in the same way that WiFi is. Their link layer forwards a byte stream chopped up into segments/frames so the boundaries of packet and of segments/frames don't generally align. Whereas I believe a WiFi frame always contains an integer number of packets. > Particularly, if an aggregated PDU is congestion marked in total, is > it correct to mark all the contained IP frames? Yes. For instance, if the AQM is currently marking 0.1% of aggregated PDUs (randomly - without regard to their size), then marking all the packets within each marked MPDU will also mark 0.1% of packets on average. You might think it would be better to somehow spread out the 0.1% marking of packets. But that would necessarily involve holding back markings. The text in S.4.6 says don't do that, rightly IMO. > What if, like WiFi, the lower layer supports non-congestive drops for > single PDUs within an MPDU, and could conceivably also support > congestion marking separately? One could imagine defining congestion > in terms of airtime rather than octets for wireless MACs, for example. If the lower layer chooses to ECN-mark packets as they arrive at the queue into the layer, that's fine. Then there is no re-framing problem for the ECN markings. That's how AQM dropping and ECN marking is done in DOCSIS. I suspect a link layer would generally only need the L2 protocol to support ECN marking where there might be pure L2 nodes with no IP awareness. For instance, in LTE, an eNodeB is often not IP-aware, so if an AQM at the eNodeB was going to ECN-mark in-band, the RLC protocol would have to be modified to support ECN marks. Then, when RLC PDUs were decapsulated, the reframing rules for ECN marking in S.4.6 would come into play. I'm not sure yet whether or what I need to change in section 4.6. Given the above, can you help me understand what I've written incomprehensibly? These are meant to be guildelines on how to write a detailed spec for a particular L2 technology. AFAICT, what I wrote in S.4.6. covers all the cases you mention, and I believe it is necessary and sufficient. You obviously think not, but I can't work out why yet. Thx for the nits. Bob > > Nits: > "doesn't" seems to be used frequently, which doesn't seem appropriate > in every case. > > "feed-up-an-forward" typo in the second-last paragraph of the conclusion. > > Hope this helps, > Andrew > > On Thu, Dec 20, 2018 at 11:31 AM Black, David > wrote: > > Gentlemen (Gorry, Richard, Brian and Andrew): > > Once upon a time (this past summer in Montreal), I believe that > each of you volunteered to review the two ECN encapsulation drafts > during a Working Group Last Call (WGLC): > >                 - draft-ietf-tsvwg-ecn-encap-guidelines > > >                 - draft-ietf-tsvwg-rfc6040update-shim > > > I subsequently dropped the ball on this :-(. > > I’m now planning to start a combined WGLC on these two drafts > sometime in January.   Would each of you please let me know: > >                 - Whether you’re still able to and interested in > reviewing these drafts during WGLC, and > >                 - Any time preferences or restrictions on when to > do the review, so that I can schedule the WGLC appropriately.. > > I have no problem with a longer-than-usual WGLC time period to > enable reviews from talented folks such as you. > > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Senior Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA  01748 > > +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------00B806BCB5E2BEF7CE2FE353 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Andrew,

Thank you v much for reviewing this hefty tome. I've added one more sentence inline (after "incomprehensibly"), cos I fired the last email off a bit early...

On 15/05/2019 04:32, Andrew McGregor wrote:


---------- Forwarded message ---------
From: Andrew McGregor <andrewmcgr@gmail.com>
Date: Fri, May 10, 2019 at 10:32 AM
Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts
To: Black, David <David.Black@dell.com>, <draft-ietf-tsvwg-ecn-encap-guidelines@ietf.org>
Cc: gorry@erg.abdn.ac.uk <gorry@erg.abdn.ac.uk>, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>, Brian Trammell (trammell@tik.ee.ethz.ch) <trammell@tik.ee..ethz.ch>, Black, David <David.Black@dell.com>, Wesley Eddy <wes@mti-systems.com>


Hi all,

I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines.

I find only one issue of any substance. That is, the definition of a PDU and the discussion on reframing and congestion marking in section 4.6 seems to me to apply more to fragmenting MACs like ATM than to aggregating MACs like LTE, WiFi, and DOCSIS.
I don't think LTE and DOCSIS can be called aggregating MACs in the same way that WiFi is. Their link layer forwards a byte stream chopped up into segments/frames so the boundaries of packet and of segments/frames don't generally align. Whereas I believe a WiFi frame always contains an integer number of packets.

Particularly, if an aggregated PDU is congestion marked in total, is it correct to mark all the contained IP frames?
Yes. For instance, if the AQM is currently marking 0.1% of aggregated PDUs (randomly - without regard to their size), then marking all the packets within each marked MPDU will also mark 0.1% of packets on average.

You might think it would be better to somehow spread out the 0.1% marking of packets. But that would necessarily involve holding back markings. The text in S.4.6 says don't do that, rightly IMO.

What if, like WiFi, the lower layer supports non-congestive drops for single PDUs within an MPDU, and could conceivably also support congestion marking separately? One could imagine defining congestion in terms of airtime rather than octets for wireless MACs, for example.
If the lower layer chooses to ECN-mark packets as they arrive at the queue into the layer, that's fine. Then there is no re-framing problem for the ECN markings. That's how AQM dropping and ECN marking is done in DOCSIS.

I suspect a link layer would generally only need the L2 protocol to support ECN marking where there might be pure L2 nodes with no IP awareness. For instance, in LTE, an eNodeB is often not IP-aware, so if an AQM at the eNodeB was going to ECN-mark in-band, the RLC protocol would have to be modified to support ECN marks. Then, when RLC PDUs were decapsulated, the reframing rules for ECN marking in S.4.6 would come into play.

I'm not sure yet whether or what I need to change in section 4.6. Given the above, can you help me understand what I've written incomprehensibly?

These are meant to be guildelines on how to write a detailed spec for a particular L2 technology. AFAICT, what I wrote in S.4.6. covers all the cases you mention, and I believe it is necessary and sufficient. You obviously think not, but I can't work out why yet.


Thx for the nits.



Bob


Nits:
"doesn't" seems to be used frequently, which doesn't seem appropriate in every case.

"feed-up-an-forward" typo in the second-last paragraph of the conclusion.

Hope this helps,
Andrew

On Thu, Dec 20, 2018 at 11:31 AM Black, David <David.Black@dell.com> wrote:

Gentlemen (Gorry, Richard, Brian and Andrew):

 

Once upon a time (this past summer in Montreal), I believe that each of you volunteered to review the two ECN encapsulation drafts during a Working Group Last Call (WGLC):

                - draft-ietf-tsvwg-ecn-encap-guidelines

                - draft-ietf-tsvwg-rfc6040update-shim

I subsequently dropped the ball on this :-(.

 

I’m now planning to start a combined WGLC on these two drafts sometime in January.   Would each of you please let me know:

                - Whether you’re still able to and interested in reviewing these drafts during WGLC, and

                - Any time preferences or restrictions on when to do the review, so that I can schedule the WGLC appropriately..

I have no problem with a longer-than-usual WGLC time period to enable reviews from talented folks such as you.

 

Thanks, --David

----------------------------------------------------------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------------------

 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------00B806BCB5E2BEF7CE2FE353-- From nobody Wed May 15 15:09:52 2019 Return-Path: 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 402E612010C for ; Wed, 15 May 2019 15:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fsZMeZofJwbO for ; Wed, 15 May 2019 15:09:41 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 30FDF1200DE for ; Wed, 15 May 2019 15:09:41 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id 94so506919uam.3 for ; Wed, 15 May 2019 15:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yeeI3KnNOlwPH6Zt4wcRVncdSVy8MhIxsQ8UZb1h4Jg=; b=o71NYNfKPHb5knnGJ2qvz8D/l3ZzWjlHVkfWp+bYvl22LEbOnkaoceN+zLsBpC0lWj sWXu+0oDjv186QX4vP96f21ql0owpbJTIKYnWFVVJFuBVeBdgBN1Pf5gbt6BxGh2VxUz ZfV3MkrCGfjOMD1Dta9dOYUaeJxzWFMA1uIUCNTrNrsstNxGevoP5Z6IKmyVceT0zkTJ WylyzmFnCew8TaCV3TfcO51zF8EMWvm61dJpq+rrmDqd1IBYy9K3Uosvd2vo62XeqYV+ e2ZCvKaqHA3Mjl4trcZV0LgpH7g4iP4yBiNBKldAco+q67kIWnvwwFIpJe/4qCwXOsGK CdfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yeeI3KnNOlwPH6Zt4wcRVncdSVy8MhIxsQ8UZb1h4Jg=; b=ZnKxfS8+0tF+M5RX/YK5YUWDC/XrAPpshfcP0cgt/EmOtwzZw4myIJgZHhpMRxjTHD mpG4W/BF/3+LSS8GXsgUqDuK92JJAM6KcwaZh/xNSbq2e6uzD6RtpZak6DaYwOW0uTCi qpMtbHqrTRh5eb59tl4Xu9NZfSkqAtUtYe7kIWnLqqhG4ZnpH0DFSGVCdnePDQCE3OL+ 5R7EdadKdijp301VwvoQPECqcVfzcp/zDPPVOzarKqox3l4gJP5++2VuhVM6ohmtxGLL 1L+r5L3TJvi2tDVpMakFnpLEWRGT+n6Avj5oRJwfmCZ0ZVluQjBWGEIrBT++ObMBEcsC IR6A== X-Gm-Message-State: APjAAAXXeBCuOpZfWaPlvWZrDOM/y740+thMMLwjH0f4u5tJ9WRB5QbP 9mijWzScr2f/sGB6FBZ3uEcRu6y+15qdTWUBCjoZOS/O X-Google-Smtp-Source: APXvYqwm0GIXTwrghmmMXqlsxxid/ZXs2WSp1DYgzhprU3h2VTP8/O3DjRLqZO39pI365rJ3ZV32ThSYQak5u/DewKM= X-Received: by 2002:ab0:2845:: with SMTP id c5mr18586573uaq.61.1557958180020; Wed, 15 May 2019 15:09:40 -0700 (PDT) MIME-Version: 1.0 References: <84005628-9703-c6ab-d27b-b91fce2e396a@bobbriscoe.net> In-Reply-To: <84005628-9703-c6ab-d27b-b91fce2e396a@bobbriscoe.net> From: Andrew McGregor Date: Thu, 16 May 2019 08:09:28 +1000 Message-ID: To: Bob Briscoe Cc: tsvwg Content-Type: multipart/alternative; boundary="000000000000e526500588f46729" Archived-At: Subject: Re: [tsvwg] Fwd: TSVWG: WGLC reviews of ECN encapsulation drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 22:09:49 -0000 --000000000000e526500588f46729 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Bob, That clarifies it for me, maybe we just need to add one or two sentences to avoid others tripping over the same point. Comments inline. On Thu, May 16, 2019 at 4:08 AM Bob Briscoe wrote: > Andrew, > > Thank you v much for reviewing this hefty tome. Inline... > > On 15/05/2019 04:32, Andrew McGregor wrote: > > > > ---------- Forwarded message --------- > From: Andrew McGregor > Date: Fri, May 10, 2019 at 10:32 AM > Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts > To: Black, David , < > draft-ietf-tsvwg-ecn-encap-guidelines@ietf.org> > Cc: gorry@erg.abdn.ac.uk , > Scheffenegger, Richard , Brian Trammell > (trammell@tik.ee.ethz.ch) >, Black, David , Wesley > Eddy > > > Hi all, > > I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines. > > I find only one issue of any substance. That is, the definition of a PDU > and the discussion on reframing and congestion marking in section 4.6 see= ms > to me to apply more to fragmenting MACs like ATM than to aggregating MACs > like LTE, WiFi, and DOCSIS. > > I don't think LTE and DOCSIS can be called aggregating MACs in the same > way that WiFi is. Their link layer forwards a byte stream chopped up into > segments/frames so the boundaries of packet and of segments/frames don't > generally align. Whereas I believe a WiFi frame always contains an intege= r > number of packets. > Correct, a WiFi AMPDU contains several complete packets plus perhaps some extra MAC-layer IEs. Each IP packet has an 802.11 header attached, and the AMPDU has an 802.11 header of its own which can contain extra IEs beyond just the aggregation header. By definition, if there's only one packet, it's a PDU not an AMPDU. Particularly, if an aggregated PDU is congestion marked in total, is it > correct to mark all the contained IP frames? > > Yes. For instance, if the AQM is currently marking 0.1% of aggregated PDU= s > (randomly - without regard to their size), then marking all the packets > within each marked MPDU will also mark 0.1% of packets on average. > > You might think it would be better to somehow spread out the 0.1% marking > of packets. But that would necessarily involve holding back markings. The > text in S.4.6 says don't do that, rightly IMO. > Agreed, extra delay for that reason would be counterproductive. > What if, like WiFi, the lower layer supports non-congestive drops for > single PDUs within an MPDU, and could conceivably also support congestion > marking separately? One could imagine defining congestion in terms of > airtime rather than octets for wireless MACs, for example. > > If the lower layer chooses to ECN-mark packets as they arrive at the queu= e > into the layer, that's fine. Then there is no re-framing problem for the > ECN markings. That's how AQM dropping and ECN marking is done in DOCSIS. > I think this point is what I missed. I suspect a link layer would generally only need the L2 protocol to support > ECN marking where there might be pure L2 nodes with no IP awareness. For > instance, in LTE, an eNodeB is often not IP-aware, so if an AQM at the > eNodeB was going to ECN-mark in-band, the RLC protocol would have to be > modified to support ECN marks. Then, when RLC PDUs were decapsulated, the > reframing rules for ECN marking in S.4.6 would come into play. > Ah, OK. I see how this works now. I'm not sure yet whether or what I need to change in section 4.6. Given the > above, can you help me understand what I've written incomprehenisbly? > I think the text is comprehensible and correct as it stands, if you can think of a way to make that specific point more obvious that would be good. If not, I don't object, it's subtle. Thanks, Andrew > > > Thx for the nits. > > > > Nits: > "doesn't" seems to be used frequently, which doesn't seem appropriate in > every case. > > "feed-up-an-forward" typo in the second-last paragraph of the conclusion. > > Hope this helps, > Andrew > > On Thu, Dec 20, 2018 at 11:31 AM Black, David > wrote: > >> Gentlemen (Gorry, Richard, Brian and Andrew): >> >> >> >> Once upon a time (this past summer in Montreal), I believe that each of >> you volunteered to review the two ECN encapsulation drafts during a Work= ing >> Group Last Call (WGLC): >> >> - draft-ietf-tsvwg-ecn-encap-guidelines >> >> >> - draft-ietf-tsvwg-rfc6040update-shim >> >> >> I subsequently dropped the ball on this :-(. >> >> >> >> I=E2=80=99m now planning to start a combined WGLC on these two drafts so= metime in >> January. Would each of you please let me know: >> >> - Whether you=E2=80=99re still able to and interested in >> reviewing these drafts during WGLC, and >> >> - Any time preferences or restrictions on when to do the >> review, so that I can schedule the WGLC appropriately.. >> >> I have no problem with a longer-than-usual WGLC time period to enable >> reviews from talented folks such as you. >> >> >> >> Thanks, --David >> >> ---------------------------------------------------------------- >> >> David L. Black, Senior Distinguished Engineer >> >> Dell EMC, 176 South St., Hopkinton, MA 01748 >> >> +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 >> >> David.Black@dell.com >> >> ---------------------------------------------------------------- >> >> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --000000000000e526500588f46729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Bob,
That clarifies it for me, maybe we just need to add one or two= sentences to avoid others tripping over the same point.=C2=A0 Comments inl= ine.

On Thu, May 16, 2019 at 4:08 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:
=20 =20 =20
Andrew,

Thank you v much for reviewing this hefty tome. Inline...

On 15/05/201= 9 04:32, Andrew McGregor wrote:
=20


---------- Forwarded messag= e ---------
From: Andrew McGregor <andrewmcgr@gmail.com> Date: Fri, May 10, 2019 at 10:32 AM
Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts To: Black, David <David.Black@dell.com>, <draft-ietf-tsvwg= -ecn-encap-guidelines@ietf.org>
Cc: = gorry@erg.abdn.ac.uk <gorry@erg.abdn.ac.uk>, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>, Brian Trammell (trammell@tik.ee.ethz.ch) <trammell@tik.ee..ethz.ch>, Black, David <David.Black@dell.com>, Wesley Eddy <wes@mti-systems.com>


Hi all,

I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines.

I find only one issue of any substance. That is, the definition of a PDU and the discussion on reframing and congestion marking in section 4.6 seems to me to apply more to fragmenting MACs like ATM than to aggregating MACs like LTE, WiFi, and DOCSIS.
I don't think LTE and DOCSIS can be called aggregating MACs in the same way that WiFi is. Their link layer forwards a byte stream chopped up into segments/frames so the boundaries of packet and of segments/frames don't generally align. Whereas I believe a WiFi frame always contains an integer number of packets.

Correct, a WiFi AMPDU contains several complete pack= ets plus perhaps some extra MAC-layer IEs. Each IP packet has an 802.11 hea= der attached, and the AMPDU has an 802.11 header of its own which can conta= in extra IEs beyond just the aggregation header. By definition, if there= 9;s only one packet, it's a PDU not an AMPDU.

Particularly, if an aggregated PDU is congestion marked in total, is it correct to mark all the contained IP frames?
Yes. For instance, if the AQM is currently marking 0.1% of aggregated PDUs (randomly - without regard to their size), then marking all the packets within each marked MPDU will also mark 0.1% of packets on average.

You might think it would be better to somehow spread out the 0.1% marking of packets. But that would necessarily involve holding back markings. The text in S.4.6 says don't do that, rightly IMO.

Agreed, extra delay for that reason wou= ld be counterproductive.
=C2=A0
What if, like WiFi, the lower layer supports non-congestive drops for single PDUs within an MPDU, and could conceivably also support congestion marking separately? One could imagine defining congestion in terms of airtime rather than octets for wireless MACs, for example.
If the lower layer chooses to ECN-mark packets as they arrive at the queue into the layer, that's fine. Then there is no re-framing problem for the ECN markings. That's how AQM dropping and ECN marking is done in DOCSIS.

I = think this point is what I missed.

I suspect a link layer would generally only need the L2 protocol to support ECN marking where there might be pure L2 nodes with no IP awareness. For instance, in LTE, an eNodeB is often not IP-aware, so if an AQM at the eNodeB was going to ECN-mark in-band, the RLC protocol would have to be modified to support ECN marks. Then, when RLC PDUs were decapsulated, the reframing rules for ECN marking in S.4.6 would come into play.

A= h, OK. I see how this works now.=C2=A0

I'm not sure yet whether or what I need to change in section 4.6. Given the above, can you help me understand what I've written incomprehenisbly?

I think the= text is comprehensible and correct as it stands, if you can think of a way= to make that specific point more obvious that would be good. If not, I don= 't object, it's subtle.

Thanks,
= Andrew
=C2=A0


Thx for the nits.



Nits:
"doesn't" seems to be used frequently, whi= ch doesn't seem appropriate in every case.

"feed-up-an-forward" typo in the second-last paragraph of the conclusion.

Hope this helps,
Andrew

On Thu, Dec 20, 2018 at 11:31 AM Black, David <David.Black@dell.com> wrote:

Gentlemen (Gorry, Richard, Brian and Andrew):

=C2=A0

Once upon a time (this past summer in Montreal), I believe that each of you volunteered to review the two ECN encapsulation drafts during a Working Group Last Call (WGLC):

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - draft-ietf-tsvwg-ecn-encap-guidelines

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - draft-ietf-tsvwg-rfc6040update-shim

I subsequently dropped the ball on this :-(.

=C2=A0

I=E2=80=99m now planning to start = a combined WGLC on these two drafts sometime in January.=C2=A0=C2=A0 Would each of you please let me kn= ow:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Whether you=E2= =80=99re still able to and interested in reviewing these drafts during WGLC, and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Any time preferences or restrictions on when to do the review, so that I can schedule the WGLC appropriately..

I have no problem with a longer-than-usual WGLC time period to enable reviews from talented folks such as you.

=C2=A0

Thanks, --David

----------------------------------= ------------------------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA=C2=A0 01748

+1 (774) 350-9323 New=C2=A0= =C2=A0=C2=A0 Mobile: +1 (978) 394-7754

David.Black@del= l.com

----------------------------------= ------------------------------

=C2=A0


--=
=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--000000000000e526500588f46729-- From nobody Wed May 15 16:19:14 2019 Return-Path: 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 32DDC12016B for ; Wed, 15 May 2019 16:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 NU4g52rXjPJJ for ; Wed, 15 May 2019 16:19:02 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 E340512002F for ; Wed, 15 May 2019 16:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9K4USGTu/8YHGiAVFfvNG5ypkwDQbA3VP/Te3kn94nI=; b=ldnnQhf9lLELfoOj2RdraQBR9 aul2QboBVdLkeo2L7+WkiY4CsdS3QiStx3w+6tXmMMZc4V9HvQVmIP3/YEqB/+3WbOgF6bo1Ta4nT oP5SviyIYKXKbrJYqaU0rMiwZUQFSK/lE9mUJjBa+bJOG5V6if8tH5ipNG4fYnCh0bqIBGzxKu/Df axyUIFjMlxX/o5Z2Mx8SzuGk+hnds4PP0PdrMfA7RTIDPeXKdqFV9ydK/fgWXsfQ9N946Jt+ZHdNa KemaienCjQVeTcfvncLG8H7xM6OEzMGvB82+JN5WFyUpxacAU2Z5C+74IAoxV9BSy1vlZ3jVdJxmR +4yNuk5pw==; Received: from [31.185.135.221] (port=33832 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hR3Ap-0000P1-2K; Thu, 16 May 2019 00:18:59 +0100 To: Andrew McGregor Cc: tsvwg References: <84005628-9703-c6ab-d27b-b91fce2e396a@bobbriscoe.net> From: Bob Briscoe Message-ID: <4a3958f9-0b9e-0b9c-8350-480354b9786f@bobbriscoe.net> Date: Thu, 16 May 2019 00:18:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D1720EEF97233E2E8A54C046" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] Fwd: TSVWG: WGLC reviews of ECN encapsulation drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 23:19:13 -0000 This is a multi-part message in MIME format. --------------D1720EEF97233E2E8A54C046 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Andrew, inline tagged [BB] On 15/05/2019 23:09, Andrew McGregor wrote: > Thanks Bob, > > That clarifies it for me, maybe we just need to add one or two > sentences to avoid others tripping over the same point. Comments inline. > > On Thu, May 16, 2019 at 4:08 AM Bob Briscoe > wrote: > > Andrew, > > Thank you v much for reviewing this hefty tome. Inline... > > On 15/05/2019 04:32, Andrew McGregor wrote: >> >> >> ---------- Forwarded message --------- >> From: *Andrew McGregor* > > >> Date: Fri, May 10, 2019 at 10:32 AM >> Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts >> To: Black, David > >, >> > > >> Cc: gorry@erg.abdn.ac.uk >> >, >> Scheffenegger, Richard > >, Brian Trammell >> (trammell@tik.ee.ethz.ch ) >> >, >> Black, David > >, Wesley Eddy > > >> >> >> Hi all, >> >> I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines. >> >> I find only one issue of any substance. That is, the definition >> of a PDU and the discussion on reframing and congestion marking >> in section 4.6 seems to me to apply more to fragmenting MACs like >> ATM than to aggregating MACs like LTE, WiFi, and DOCSIS. > I don't think LTE and DOCSIS can be called aggregating MACs in the > same way that WiFi is. Their link layer forwards a byte stream > chopped up into segments/frames so the boundaries of packet and of > segments/frames don't generally align. Whereas I believe a WiFi > frame always contains an integer number of packets. > > > Correct, a WiFi AMPDU contains several complete packets plus perhaps > some extra MAC-layer IEs. Each IP packet has an 802.11 header > attached, and the AMPDU has an 802.11 header of its own which can > contain extra IEs beyond just the aggregation header. By definition, > if there's only one packet, it's a PDU not an AMPDU. > >> Particularly, if an aggregated PDU is congestion marked in total, >> is it correct to mark all the contained IP frames? > Yes. For instance, if the AQM is currently marking 0.1% of > aggregated PDUs (randomly - without regard to their size), then > marking all the packets within each marked MPDU will also mark > 0.1% of packets on average. > > You might think it would be better to somehow spread out the 0.1% > marking of packets. But that would necessarily involve holding > back markings. The text in S.4.6 says don't do that, rightly IMO. > > > Agreed, extra delay for that reason would be counterproductive. > >> What if, like WiFi, the lower layer supports non-congestive drops >> for single PDUs within an MPDU, and could conceivably also >> support congestion marking separately? One could imagine defining >> congestion in terms of airtime rather than octets for wireless >> MACs, for example. > If the lower layer chooses to ECN-mark packets as they arrive at > the queue into the layer, that's fine. Then there is no re-framing > problem for the ECN markings. That's how AQM dropping and ECN > marking is done in DOCSIS. > > > I think this point is what I missed. > > I suspect a link layer would generally only need the L2 protocol > to support ECN marking where there might be pure L2 nodes with no > IP awareness. For instance, in LTE, an eNodeB is often not > IP-aware, so if an AQM at the eNodeB was going to ECN-mark > in-band, the RLC protocol would have to be modified to support ECN > marks. Then, when RLC PDUs were decapsulated, the reframing rules > for ECN marking in S.4.6 would come into play. > > > Ah, OK. I see how this works now. [BB] That was what I suspected from reading between your lines. > > I'm not sure yet whether or what I need to change in section 4.6. > Given the above, can you help me understand what I've written > incomprehenisbly? > > > I think the text is comprehensible and correct as it stands, if you > can think of a way to make that specific point more obvious that would > be good. If not, I don't object, it's subtle. [BB] I think the section is missing a statement of the problem. I've added the following para, after the first sentence about terminology: "Where an AQM marks the ECN field of IP packets as they queue into a layer-2 link, there will be no problem with framing boundaries, because the ECN markings would be applied directly to IP packets. The guidance in this section is only applicable where an ECN capability is being added to a layer-2 protocol so that layer-2 frames can be ECN-marked by an AQM at layer-2. This would only be necessary where AQM will be applied at pure layer-2 nodes (without IP-awareness). Where framing boundaries do not necessarily align with packet boundaries, the following guidance will be needed. It explains how to propagate ECN markings from layer-2 frame headers when they are stripped off and IP PDUs with different boundaries are reassembled for forwarding. " HTH Bob > > Thanks, > Andrew > > > > Thx for the nits. > > >> >> Nits: >> "doesn't" seems to be used frequently, which doesn't seem >> appropriate in every case. >> >> "feed-up-an-forward" typo in the second-last paragraph of the >> conclusion. >> >> Hope this helps, >> Andrew >> >> On Thu, Dec 20, 2018 at 11:31 AM Black, David >> > wrote: >> >> Gentlemen (Gorry, Richard, Brian and Andrew): >> >> Once upon a time (this past summer in Montreal), I believe >> that each of you volunteered to review the two ECN >> encapsulation drafts during a Working Group Last Call (WGLC): >> >>                 - draft-ietf-tsvwg-ecn-encap-guidelines >> >> >>                 - draft-ietf-tsvwg-rfc6040update-shim >> >> >> I subsequently dropped the ball on this :-(. >> >> I’m now planning to start a combined WGLC on these two drafts >> sometime in January.   Would each of you please let me know: >> >>                 - Whether you’re still able to and interested >> in reviewing these drafts during WGLC, and >> >>                 - Any time preferences or restrictions on >> when to do the review, so that I can schedule the WGLC >> appropriately.. >> >> I have no problem with a longer-than-usual WGLC time period >> to enable reviews from talented folks such as you. >> >> Thanks, --David >> >> ---------------------------------------------------------------- >> >> David L. Black, Senior Distinguished Engineer >> >> Dell EMC, 176 South St., Hopkinton, MA  01748 >> >> +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 >> >> David.Black@dell.com >> >> ---------------------------------------------------------------- >> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------D1720EEF97233E2E8A54C046 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Andrew, inline tagged [BB]

On 15/05/2019 23:09, Andrew McGregor wrote:
Thanks Bob,

That clarifies it for me, maybe we just need to add one or two sentences to avoid others tripping over the same point.  Comments inline.

On Thu, May 16, 2019 at 4:08 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:
Andrew,

Thank you v much for reviewing this hefty tome. Inline...

On 15/05/2019 04:32, Andrew McGregor wrote:


---------- Forwarded message ---------
From: Andrew McGregor <andrewmcgr@gmail.com>
Date: Fri, May 10, 2019 at 10:32 AM
Subject: Re: TSVWG: WGLC reviews of ECN encapsulation drafts
To: Black, David <David.Black@dell.com>, <draft-ietf-tsvwg-ecn-encap-guidelines@ietf.org>
Cc: gorry@erg.abdn.ac.uk <gorry@erg.abdn.ac.uk>, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>, Brian Trammell (trammell@tik.ee.ethz.ch) <trammell@tik.ee..ethz.ch>, Black, David <David.Black@dell.com>, Wesley Eddy <wes@mti-systems.com>


Hi all,

I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines.

I find only one issue of any substance. That is, the definition of a PDU and the discussion on reframing and congestion marking in section 4.6 seems to me to apply more to fragmenting MACs like ATM than to aggregating MACs like LTE, WiFi, and DOCSIS.
I don't think LTE and DOCSIS can be called aggregating MACs in the same way that WiFi is. Their link layer forwards a byte stream chopped up into segments/frames so the boundaries of packet and of segments/frames don't generally align. Whereas I believe a WiFi frame always contains an integer number of packets.

Correct, a WiFi AMPDU contains several complete packets plus perhaps some extra MAC-layer IEs. Each IP packet has an 802.11 header attached, and the AMPDU has an 802.11 header of its own which can contain extra IEs beyond just the aggregation header. By definition, if there's only one packet, it's a PDU not an AMPDU.

Particularly, if an aggregated PDU is congestion marked in total, is it correct to mark all the contained IP frames?
Yes. For instance, if the AQM is currently marking 0.1% of aggregated PDUs (randomly - without regard to their size), then marking all the packets within each marked MPDU will also mark 0.1% of packets on average.

You might think it would be better to somehow spread out the 0.1% marking of packets. But that would necessarily involve holding back markings. The text in S.4.6 says don't do that, rightly IMO.

Agreed, extra delay for that reason would be counterproductive.
 
What if, like WiFi, the lower layer supports non-congestive drops for single PDUs within an MPDU, and could conceivably also support congestion marking separately? One could imagine defining congestion in terms of airtime rather than octets for wireless MACs, for example.
If the lower layer chooses to ECN-mark packets as they arrive at the queue into the layer, that's fine. Then there is no re-framing problem for the ECN markings. That's how AQM dropping and ECN marking is done in DOCSIS.

I think this point is what I missed.

I suspect a link layer would generally only need the L2 protocol to support ECN marking where there might be pure L2 nodes with no IP awareness. For instance, in LTE, an eNodeB is often not IP-aware, so if an AQM at the eNodeB was going to ECN-mark in-band, the RLC protocol would have to be modified to support ECN marks. Then, when RLC PDUs were decapsulated, the reframing rules for ECN marking in S.4.6 would come into play.

Ah, OK. I see how this works now.
[BB] That was what I suspected from reading between your lines.

I'm not sure yet whether or what I need to change in section 4.6. Given the above, can you help me understand what I've written incomprehenisbly?

I think the text is comprehensible and correct as it stands, if you can think of a way to make that specific point more obvious that would be good. If not, I don't object, it's subtle.
[BB] I think the section is missing a statement of the problem. I've added the following para, after the first sentence about terminology:

"Where an AQM marks the ECN field of IP packets as they queue into a layer-2 link, there will be no problem with framing boundaries, because the ECN markings would be applied directly to IP packets. The guidance in this section is only applicable where an ECN capability is being added to a layer-2 protocol so that layer-2 frames can be ECN-marked by an AQM at layer-2. This would only be necessary where AQM will be applied at pure layer-2 nodes (without IP-awareness). Where framing boundaries do not necessarily align with packet boundaries, the following guidance will be needed. It explains how to propagate ECN markings from layer-2 frame headers when they are stripped off and IP PDUs with different boundaries are reassembled for forwarding. "

HTH


Bob


Thanks,
Andrew
 


Thx for the nits.



Nits:
"doesn't" seems to be used frequently, which doesn't seem appropriate in every case.

"feed-up-an-forward" typo in the second-last paragraph of the conclusion.

Hope this helps,
Andrew

On Thu, Dec 20, 2018 at 11:31 AM Black, David <David.Black@dell.com> wrote:

Gentlemen (Gorry, Richard, Brian and Andrew):

 

Once upon a time (this past summer in Montreal), I believe that each of you volunteered to review the two ECN encapsulation drafts during a Working Group Last Call (WGLC):

                - draft-ietf-tsvwg-ecn-encap-guidelines

                - draft-ietf-tsvwg-rfc6040update-shim

I subsequently dropped the ball on this :-(.

 

I’m now planning to start a combined WGLC on these two drafts sometime in January.   Would each of you please let me know:

                - Whether you’re still able to and interested in reviewing these drafts during WGLC, and

                - Any time preferences or restrictions on when to do the review, so that I can schedule the WGLC appropriately..

I have no problem with a longer-than-usual WGLC time period to enable reviews from talented folks such as you.

 

Thanks, --David

----------------------------------------------------------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------------------

 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------D1720EEF97233E2E8A54C046-- From nobody Wed May 15 16:28:34 2019 Return-Path: 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 56EC712009C for ; Wed, 15 May 2019 16:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 212GZvcgcalC for ; Wed, 15 May 2019 16:28:28 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 F2BEB12002F for ; Wed, 15 May 2019 16:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:References:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vD0Wv/FPjGo3oehQoOqKTrxgApg6cjSt7yYj7g8vKes=; b=St4DKkmNorWpESk/cW/Evpctd GD669rdS20UViTnGQTsANasDGVG/1Ab/Xhu8gCjIAk1AwtXmfgf+KQOx++AUKZQJV/CwHyFUQH0fn Dxvdb/ayrPX7MWGMP3UZjOW1JgvICVpTfyhNnUbNqNO859zGs3eoSS7HcwEkH67BWex260N+zcHLB tJ3+Dj/Vwa2uwAB8jVQQW5ilL6Ty6u1pPeJv6NukRsjTnWPN7eo50EA5Ar1nL+3FwMDHBRqh0U3kn nuMd3WaI2LhYuoTpo2t/KQTXNLbb9pUXRBCOTPH73UHsfGe4va/iLHdKc9Ehzxga1JMTW3e0U6/Fl CUnsahzvQ==; Received: from [31.185.135.221] (port=33840 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hR3Js-00017N-Rl; Thu, 16 May 2019 00:28:24 +0100 From: Bob Briscoe To: "Black, David" , "tsvwg@ietf.org" References: Message-ID: <247a9990-30c0-b0ea-5e3d-2a0b2ae57a95@bobbriscoe.net> Date: Thu, 16 May 2019 00:28:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E0339A33F339C792C7B1F9D3" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 23:28:33 -0000 This is a multi-part message in MIME format. --------------E0339A33F339C792C7B1F9D3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit David, I've addressed all your points inline (and RS's and AMcG's points in recent emails). I've edited my local copy of the draft as I describe. I'll submit it in a few hours time. I'm off to bed now, and in the morning I just want to double-check I haven't missed anyone's comments before posting it. That might also allow you, my co-author or anyone else enough time to come back on any of my responses below before I post... On 09/05/2019 01:10, Black, David wrote: > > First of all, this is a well-written and comprehensive draft on ECN > encapsulation design guidelines. > > I found no major issues, and all of the minor issues are truly minor > some border on editorial, > > and all can be dealt with via relatively minor edits.. > > --- Minor --- > > [A] Need an explicit statement of exactly what the update to RFC 3819 is, > > preferably in a section whose name uses "RFC 3819" and appears in the > > table of contents. Do this before some AD tells you to ;-). This is > > also the only thing that idnits found that needs attention. > RFC 3819 contained a paragraph of brief musings on how subnetworks might handle ECN. So ecn-encap completely replaces that para with a whole document. I hope the new text quoted below is sufficient to explain that there is no specific section that updates RFC 3819. Rather the whole document does: Copied sentence below from end of intro to abstract: "This document updates the advice to subnetwork designers about ECN in RFC 3819." Expanded sentence at the end of Intro to: "This document updates and completely replaces the brief paragraph of advice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89)." > [B] 1. Introduction, first paragraph, last sentence > > The phrase "egress at any layer" is too general, hence incorrect (e.g., > > layer 7 was not intended to be included) - "lower layer" needs to be > > used for clarity. > > OLD > > If an egress at any layer is not ECN-aware, or if the > > ultimate receiver or sender is not ECN-aware, congestion needs to be > > indicated by dropping a packet, not marking it. > > NEW > > If a lower layer header that may contain ECN congestion indications is > > removed by an egress that is not ECN-aware, or if the ultimate > receiver or > > sender is not ECN-aware, then lower layer congestion needs to be > indicated > > by dropping a packet, not marking it. > > END > Thx. Used verbatim (except s/an egress/a subnet egress/). > [C] 1.1 Scope > > Second paragraph and the two-bullet list imply that RFC 4774 states > that use > > of ECT(1) to signal alternative ECN semantics is a best current practice. > > That's not correct, as RFC 4774 covers only the first bullet on use of > DSCP, > > not the second bullet on use of ECT(1), as that second bullet is based > solely > > on RFC 8311. Some rewriting is in order to disconnect the second > bullet from > > RFC 4774. > Done: "There are two main examples for how alternative ECN semantics have been defined in practice: o RFC 4774 suggests... o RFC 8311 suggests..." > Based on this, all other places where RFC 4774 is mentioned or cited > should > > be checked to determine whether RFC 8311 also ought to be mentioned or > cited. > Done. The one other occurrence of RFC4774 says: "The guidelines are also designed to ensure compliance with the more general best current practice for the design of alternate ECN schemes given in [RFC4774]..." Added: "...and extended by [RFC8311]" > [D] Page 5, first complete paragraph > > Alternative semantics for the ECN field can be defined to depend on > > the traffic class indicated by the DSCP. Therefore correct > > propagation of congestion signals could depend on correct propagation > > of the DSCP between the layers. > > This also depends on correct propagation across diffserv boundaries - that > > and the potential damage wrought by bleaching DSCPs to zero at such > boundaries > > both deserve mention here. > Done; added: "Similarly, if the DSCP is wiped at the boundary between Diffserv domains, the special ECN semantics would also be lost." > [E] 1.1 Scope, end of section > > In the feed-backward mode, propagation of > > congestion signals for multicast and anycast packets is out-of-scope > > (because it would be so complicated that it is hoped no-one would > > attempt such an abomination). > > Much as I may agree with it :-), the parenthetical remark is inappropriate > > for an archival RFC, and hence needs to be removed. > When doing transport area reviews, I have criticised other authors for just ruling stuff out of scope without justification or explanation of the implications. So rather than delete, I've toned this down: "... (because the complexity would make it unlikely to be attempted)." BTW, for archival documents IMO light-heartedness is no less appropriate than unrelenting blandness. > [F] 2. Terminology > > ECN-PDU: A PDU that is part of a feedback loop within which all the > > nodes that need to propagate explicit congestion notifications > > back to the Load Regulator are ECN-capable. > > That first sentence is too broad as it includes both the forward and > > reverse directions of the feedback loop, whereas only the forward > direction is intended (FWIW, the definition of PDU does not suffice to > > narrow this to the forward direction only). For example, a TCP packet > > with the ECE flag set in the TCP header and Not-ECT in the ECN field in > > the IP header would be an ECN-PDU under this definition, which is not > > what was intended. The immediately following definition of Not-ECN-PDU > > has the same problem. > The point of building on the OSI term 'PDU' was because a PDU is defined by the layer that is stated as relevant. By the OSI definition, a PDU at a certain layer does not include lower layer headers that encapsulate it. So, in the example you give of a TCP packet with ECE set, that is a TCP PDU. By OSI definition, a TCP PDU does not include the IP header that encapsulates it. The IP header is only relevant when considering it as an IP PDU. And then the TCP PDU within it is just payload (the SDU that was passed to IP) and not part of the protocol of the IP PDU. > The narrowing concept that needs to be added is that if the PDU carries > > a congestion indication, then that congestion indication participates in > > such a feedback loop, > Yes, valid point. Thank you. ECN-PDU: A PDU that is part of a feedback loop within which all the nodes that need to propagate *the* explicit congestion notification *signal in the PDU* back to the Load Regulator are ECN-capable *of doing so*. > and even that is subtle when there are multiple > > possible congestion indication locations. An example of the subtlety is > > that the same PDU may be an ECN-PDU in feed-up-and-forward mode because > > the layer 3 and 4 protocols support ECN but may be a Not-ECN-PDU for > > feed-forward-and-up mode because the L2 decapsulator ignores and discards > > L2 congestion indications. > I think the bold words in the phrase "nodes that *need to* propagate" deals with that subtlety. In your example, if the subnet is propagating the PDU's ECN signal in feed-up-and-forward mode and the L2 decapsulator doesn't propagate ECN, it's not relevant because it also doesn't *need to* propagate ECN. Whereas, if the subnet propagates ECN in feed-forward-and-up mode, the decap does *need to*. I've also extended the above correction into the next definition: Not-ECN-PDU: A PDU that is part of a feedback-loop within whichsome *at least one* node necessary to propagate*the* explicit congestion notification*signal in the PDU * back to the load regulatorare *is* notECN-capable*of doing so*. > [G] 2. Terminology > > Congestion Baseline: The location of the function on the path that > > initialised the values of all congestion notification fields in a > > sequence of packets, before any are set to the congestion > > experienced (CE) codepoint if they experience congestion further > > downstream. Typically the original data source at layer-4. > > That's counter-intuitive - a baseline is a level, not a location. I've > > tagged this as a minor issue as opposed to editorial because it causes > > severe confusion in the only place that this term is used, namely item 3 > > in Section 4.3. That item 3 is about a Monitoring Baseline which is > > a level not a location. > > The Congestion Baseline term should be removed, and item 3 in Section > > 4.3 revised accordingly. The term "Congestion Baseline" is used twice > > there, but only the latter of those two uses needs to be retained and > > expanded after deletion of this definition. > You're right. I've done as you suggest. I've also nearly completely re-written the second half of the section, because I had temporarily forgotten the rationale, and even I couldn't understand what the rationale was after reading my own words. > [H] 3. Modes of Operation > > Feed-Up-and-Forward: A lower layer switch feeds-up congestion > > notification directly into the ECN field in the higher layer > > (e.g. IP) header, irrespective of whether the node is at the > > egress of a subnet. > > Remove "the ECN field in" as that's too restrictive, even though that's > > a common case, and move it into the example (e.g., ECN field in the > > IP header)" where "header" moved inside the parentheses. > Done. > [I] 3.3. Feed-Backward Mode > > Please make it clear that the critique of the ATM ABR relative rate > > control mechanism also applies to Ethernet QCN, as that's a more > > current example. This should be connected to the QCN discussion at > > the end of Section 4.2. > I didn't want to imply any criticism of QCN, which always made it clear it was only applicable to a single subnet. However, I can now see the need to have this written down, given certain companies are giving incentives to churn out Frankenpatents (any random combination of existing ideas, no matter whether useful or correct). So I've kept ATM as the example, but added at the end: QCN [IEEE802.1Qau] would suffer from similar problems if extended to multiple subnets. However, from the start QCN was clearly stated as solely applicable to a single subnet (see Section 6). > [J] 4.3 Encapsulation Guidelines > > Resolving minor issue [G] requires some edits to item 3 in this section: > > - Remove "(the Congestion Baseline)" from the third paragraph. > > - Rewrite start of fourth paragraph: > > OLD > > Most information can be extracted if the Congestion Baseline is > > standardised at the node that is regulating the load (the Load > > Regulator--typically the data source). > > NEW > > More information can be extracted if the protocol specification > > requires that congestion fields be initialized to indicate no > > congestion only by the node that is regulating the load (the > > Load Regulator--typically the data source). > > END > See minor issue [G] above - already completely rewritten this text. > [K] 12.2 Informative References > > Please check the references to 802.1Qah and 802.1Qau with IEEE. The > > correct references to use now may be the latest version of 802.1Q with > > specific functionality and/or clauses identified. > Done. 802.1Qau -> 802.1Q Sections 30--33 802.1ah -> 802.1Q (as a whole - too scattered to call out particular sections). Pat Thaler having retired, I no longer have a co-author who can advise on IEEE citation correctness. But the above is good enough. [I knew someone would point that out - I should have dealt with it but, even tho I purportedly have free access to the full rolled-up text of the current standard (IEEE802.1Q-2018), I've always had trouble viewing it. The IEEE pay-wall insists on displaying the free copy in my browser in a way that it can't be downloaded, but in Firefox the activity bar spins but nothing ever appears. After much gnashing of teeth, I discovered it works OK in Chrome.] > --- Editorial/Nits --- > > Abstract, last sentence > > Following these guidelines should assure > > interworking between new lower layer congestion notification > > mechanisms, whether specified by the IETF or other standards bodies. > > between new -> among IP layer and > Yup. > > 1. Introduction, first paragraph > > Suggest removing use of the word "buffer" - "lower layer" suffices in > > all of the places where this word is used in this paragraph. > Not as simple as that. I've guessed that the idea of a buffer doing marking jars with you, so I've addressed the two occurrences of 'buffer' as follows: 1. When a lower layer buffer drops a packet This was intended to introduce the context as congestion loss, not transmission loss. So left unchanged. 2. In contrast, when a lower layer marks a packet with ECN, the marking needs to be explicitly propagated up the layers. The same is true if a buffer marks the outer header of a packet that encapsulates inner tunnelled headers. The second sentence is about tunnels, not lower layers. So, I've introduced AQM into both sentences: In contrast, when active queue management (AQM) at a lower layer marks a packet with ECN, the marking needs to be explicitly propagated up the layers. The same is true if AQM marks the outer header of a packet that encapsulates inner tunnelled headers. > 1. Introduction, second paragraph > > The purpose of this document is to guide the addition of congestion > > notification to any subnet technology or tunnelling protocol, so that > > lower layer equipment can signal congestion explicitly and it will > > propagate consistently into encapsulated (higher layer) headers, > > otherwise the signals will not reach their ultimate destination. > > Suggest: "equipment" -> "functionality" > Sorry, the word 'functionality' gets to me like finger-nails on a blackboard. https://www.dailywritingtips.com/is-that-even-a-word/ I've used s/equipment/AQM algorithms/ > Page 5, first full paragraph: > > If a particular protocol design chooses to contradict a > > 'SHOULD (NOT)' given in the advice below, it MUST include a sound > > justification. > > chooses to contradict -> chooses not to follow > Yup > > 1.1. Scope, first paragraph > > This document only concerns wire protocol processing of explicit > > notification of congestion. > > Remove "wire" > I think that loses the intended sense in too much ambiguity. 'Protocol processing' could include the AQM algorithms, which this sentence is trying to exclude. > Section 3.1, second paragraph > > In these cases, ECN may best be supported by standardising explicit > > notification of congestion into the lower layer protocol that carries > > the data forwards. It will then also be necessary to define how the > > egress of the lower layer subnet propagates this explicit signal into > > the forwarded upper layer (IP) header. It can then continue forwards > > until it finally reaches the destination transport (at L4). Then > > typically the destination will feed this congestion notification back > > to the source transport using an end-to-end protocol (e.g. TCP). > > This is the arrangement that has already been used to add ECN to IP- > > in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129]. > > The referents of "It" at the start of the second and third sentences are > > unclear and different. Suggested rephrasings: > > It will then also be necessary to define -> > > This necessitates also specifying > > It can then continue -> This signal continues > Good. > > Section 3.1, first paragraph after Figure 1 > > Cite one or more of the 3GPP references for GTP tunnels, as this is the > > first occurrence of that concept in this draft. > Yup > > Section 3.1, second paragraph after Figure 1 > > Cite a Frame Relay reference for the FECN bit.. Moving the [Buck00] > > citation up to immediately follow "Frame Relay" in the first line > suffices. > Good. > > Section 3.2 first paragraph > > These are Ethernet switches that bury into the Ethernet payload ... > > bury -> burrow > > [Spelling checker is missing read users mind feature :-)] > I've used dig. Hard to read user's mind. Easier to tell user what to think ;) > Section 3.4 > > The second paragraph could be improved by citing references for fat-tree > > and Clos network topologies. > Done. > Section 4.1, second paragraph > > Therefore section 4 of > > [I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to > > configure the ingress of a non-ECN tunnel so that it zeros the ECN > > field in the outer IP header. > > non-ECN tunnel -> tunnel that does not support ECN > OK > > Section 4.1, third paragraph > > Even > > if the shim(s) encapsulate a L2 header, it is often possible to find > > an inner IP header within the L2 header > > Latter instance of "L2 header" should be "L2 PDU" > Good. > > Section 4.1, last paragraph > > Instead a companion specification > > [I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has > > sufficient standards track status to update standards track > > protocols. > > sufficient -> the appropriate > Done. > > Authors Addresses > > Please check these - Pat Thaler's contact info probably needs to be > updated. > In progress. Bob > > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Senior Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA 01748 > > +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------E0339A33F339C792C7B1F9D3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit David,

I've addressed all your points inline (and RS's and AMcG's points in recent emails).

I've edited my local copy of the draft as I describe. I'll submit it in a few hours time. I'm off to bed now, and in the morning I just want to double-check I haven't missed anyone's comments before posting it. That might also allow you, my co-author or anyone else enough time to come back on any of my responses below before I post...


On 09/05/2019 01:10, Black, David wrote:

First of all, this is a well-written and comprehensive draft on ECN encapsulation design guidelines.

I found no major issues, and all of the minor issues are truly minor some border on editorial,

and all can be dealt with via relatively minor edits..

--- Minor ---

[A] Need an explicit statement of exactly what the update to RFC 3819 is,

preferably in a section whose name uses "RFC 3819" and appears in the

table of contents. Do this before some AD tells you to ;-). This is

also the only thing that idnits found that needs attention.


RFC 3819 contained a paragraph of brief musings on how subnetworks might handle ECN. So ecn-encap completely replaces that para with a whole document. I hope the new text quoted below is sufficient to explain that there is no specific section that updates RFC 3819. Rather the whole document does:

Copied sentence below from end of intro to abstract:
"This document updates the advice to subnetwork designers about ECN in RFC 3819."

Expanded sentence at the end of Intro to:
"This document updates and completely replaces the brief paragraph of advice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89)."

[B] 1. Introduction, first paragraph, last sentence

The phrase "egress at any layer" is too general, hence incorrect (e.g.,

layer 7 was not intended to be included) - "lower layer" needs to be

used for clarity.

OLD

If an egress at any layer is not ECN-aware, or if the

ultimate receiver or sender is not ECN-aware, congestion needs to be

indicated by dropping a packet, not marking it.

NEW

If a lower layer header that may contain ECN congestion indications is

removed by an egress that is not ECN-aware, or if the ultimate receiver or

sender is not ECN-aware, then lower layer congestion needs to be indicated

by dropping a packet, not marking it.

END

Thx. Used verbatim (except s/an egress/a subnet egress/).

[C] 1.1 Scope

Second paragraph and the two-bullet list imply that RFC 4774 states that use

of ECT(1) to signal alternative ECN semantics is a best current practice.

That's not correct, as RFC 4774 covers only the first bullet on use of DSCP,

not the second bullet on use of ECT(1), as that second bullet is based solely

on RFC 8311. Some rewriting is in order to disconnect the second bullet from

RFC 4774.

Done:
"There are two main examples for how alternative ECN semantics have been defined in practice:
o RFC 4774 suggests...
o RFC 8311 suggests..."

Based on this, all other places where RFC 4774 is mentioned or cited should

be checked to determine whether RFC 8311 also ought to be mentioned or cited.

Done.

The one other occurrence of RFC4774 says:
"The guidelines are also designed to ensure compliance with the more general best current practice for the design of alternate ECN schemes given in [RFC4774]..."

Added: "...and extended by [RFC8311]"


[D] Page 5, first complete paragraph

Alternative semantics for the ECN field can be defined to depend on

the traffic class indicated by the DSCP. Therefore correct

propagation of congestion signals could depend on correct propagation

of the DSCP between the layers.

This also depends on correct propagation across diffserv boundaries - that

and the potential damage wrought by bleaching DSCPs to zero at such boundaries

both deserve mention here.

Done; added:
"Similarly, if the DSCP is wiped at the boundary between Diffserv domains, the special ECN semantics would also be lost."


[E] 1.1 Scope, end of section

In the feed-backward mode, propagation of

congestion signals for multicast and anycast packets is out-of-scope

(because it would be so complicated that it is hoped no-one would

attempt such an abomination).

Much as I may agree with it :-), the parenthetical remark is inappropriate

for an archival RFC, and hence needs to be removed.

When doing transport area reviews, I have criticised other authors for just ruling stuff out of scope without justification or explanation of the implications. So rather than delete, I've toned this down:

"... (because the complexity would make it unlikely to be attempted)."

BTW, for archival documents IMO light-heartedness is no less appropriate than unrelenting blandness.

[F] 2. Terminology


ECN-PDU: A PDU that is part of a feedback loop within which all the

nodes that need to propagate explicit congestion notifications

back to the Load Regulator are ECN-capable.

That first sentence is too broad as it includes both the forward and

reverse directions of the feedback loop, whereas only the forward
direction is intended (FWIW, the definition of PDU does not suffice to

narrow this to the forward direction only). For example, a TCP packet

with the ECE flag set in the TCP header and Not-ECT in the ECN field in

the IP header would be an ECN-PDU under this definition, which is not

what was intended. The immediately following definition of Not-ECN-PDU

has the same problem.

The point of building on the OSI term 'PDU' was because a PDU is defined by the layer that is stated as relevant. By the OSI definition, a PDU at a certain layer does not include lower layer headers that encapsulate it.

So, in the example you give of a TCP packet with ECE set, that is a TCP PDU. By OSI definition, a TCP PDU does not include the IP header that encapsulates it. The IP header is only relevant when considering it as an IP PDU. And then the TCP PDU within it is just payload (the SDU that was passed to IP) and not part of the protocol of the IP PDU.

The narrowing concept that needs to be added is that if the PDU carries

a congestion indication, then that congestion indication participates in

such a feedback loop,

Yes, valid point. Thank you.

ECN-PDU: A PDU that is part of a feedback loop within which all the

nodes that need to propagate the explicit congestion notification

signal in the PDU back to the Load Regulator are ECN-capable of doing so.


and even that is subtle when there are multiple

possible congestion indication locations. An example of the subtlety is

that the same PDU may be an ECN-PDU in feed-up-and-forward mode because

the layer 3 and 4 protocols support ECN but may be a Not-ECN-PDU for

feed-forward-and-up mode because the L2 decapsulator ignores and discards

L2 congestion indications.

I think the bold words in the phrase "nodes that need to propagate" deals with that subtlety.

In your example, if the subnet is propagating the PDU's ECN signal in feed-up-and-forward mode and the L2 decapsulator doesn't propagate ECN, it's not relevant because it also doesn't need to propagate ECN. Whereas, if the subnet propagates ECN in feed-forward-and-up mode, the decap does need to.

I've also extended the above correction into the next definition:
   Not-ECN-PDU:  A PDU that is part of a feedback-loop within which some at least one
      node necessary to propagate the explicit congestion notification signal in the PDU  
      back to the load regulator are is not ECN-capable of doing so.

[G] 2. Terminology

Congestion Baseline: The location of the function on the path that

initialised the values of all congestion notification fields in a

sequence of packets, before any are set to the congestion

experienced (CE) codepoint if they experience congestion further

downstream. Typically the original data source at layer-4.

That's counter-intuitive - a baseline is a level, not a location. I've

tagged this as a minor issue as opposed to editorial because it causes

severe confusion in the only place that this term is used, namely item 3

in Section 4.3. That item 3 is about a Monitoring Baseline which is

a level not a location.

The Congestion Baseline term should be removed, and item 3 in Section

4.3 revised accordingly. The term "Congestion Baseline" is used twice

there, but only the latter of those two uses needs to be retained and

expanded after deletion of this definition.

You're right. I've done as you suggest.

I've also nearly completely re-written the second half of the section, because I had temporarily forgotten the rationale, and even I couldn't understand what the rationale was after reading my own words.

[H] 3. Modes of Operation

Feed-Up-and-Forward: A lower layer switch feeds-up congestion

notification directly into the ECN field in the higher layer

(e.g. IP) header, irrespective of whether the node is at the

egress of a subnet.

Remove "the ECN field in" as that's too restrictive, even though that's

a common case, and move it into the example (e.g., ECN field in the

IP header)" where "header" moved inside the parentheses.

Done.


[I] 3.3. Feed-Backward Mode

Please make it clear that the critique of the ATM ABR relative rate

control mechanism also applies to Ethernet QCN, as that's a more

current example. This should be connected to the QCN discussion at

the end of Section 4.2.

I didn't want to imply any criticism of QCN, which always made it clear it was only applicable to a single subnet.

However, I can now see the need to have this written down, given certain companies are giving incentives to churn out Frankenpatents (any random combination of existing ideas, no matter whether useful or correct). So I've kept ATM as the example, but added at the end:

   QCN [IEEE802.1Qau] would suffer from similar problems if extended to
   multiple subnets.  However, from the start QCN was clearly stated as
   solely applicable to a single subnet (see Section 6).

[J] 4.3 Encapsulation Guidelines

Resolving minor issue [G] requires some edits to item 3 in this section:

- Remove "(the Congestion Baseline)" from the third paragraph.

- Rewrite start of fourth paragraph:

OLD

Most information can be extracted if the Congestion Baseline is

standardised at the node that is regulating the load (the Load

Regulator--typically the data source).

NEW

More information can be extracted if the protocol specification

requires that congestion fields be initialized to indicate no

congestion only by the node that is regulating the load (the

Load Regulator--typically the data source).

END

See minor issue [G] above - already completely rewritten this text.


[K] 12.2 Informative References

Please check the references to 802.1Qah and 802.1Qau with IEEE. The

correct references to use now may be the latest version of 802.1Q with

specific functionality and/or clauses identified.

Done.
802.1Qau -> 802.1Q Sections 30--33
802.1ah -> 802.1Q (as a whole - too scattered to call out particular sections).

Pat Thaler having retired, I no longer have a co-author who can advise on IEEE citation correctness.
But the above is good enough.

[I knew someone would point that out - I should have dealt with it but, even tho I purportedly have free access to the full rolled-up text of the current standard (IEEE802.1Q-2018), I've always had trouble viewing it. The IEEE pay-wall insists on displaying the free copy in my browser in a way that it can't be downloaded, but in Firefox the activity bar spins but nothing ever appears. After much gnashing of teeth, I discovered it works OK in Chrome.]

--- Editorial/Nits ---

Abstract, last sentence

Following these guidelines should assure

interworking between new lower layer congestion notification

mechanisms, whether specified by the IETF or other standards bodies.

between new -> among IP layer and

Yup.

1. Introduction, first paragraph

Suggest removing use of the word "buffer" - "lower layer" suffices in

all of the places where this word is used in this paragraph.

Not as simple as that. I've guessed that the idea of a buffer doing marking jars with you, so I've addressed the two occurrences of 'buffer' as follows:
1.   When a lower layer buffer drops a packet
This was intended to introduce the context as congestion loss, not transmission loss. So left unchanged.

2. In
   contrast, when a lower layer marks a packet with ECN, the marking
   needs to be explicitly propagated up the layers.  The same is true if
   a buffer marks the outer header of a packet that encapsulates inner
   tunnelled headers.
The second sentence is about tunnels, not lower layers.
So, I've introduced AQM into both sentences:
   In
   contrast, when active queue management (AQM) at a lower layer marks a
   packet with ECN, the marking needs to be explicitly propagated up the
   layers.  The same is true if AQM marks the outer header of a packet
   that encapsulates inner tunnelled headers.

1. Introduction, second paragraph

The purpose of this document is to guide the addition of congestion

notification to any subnet technology or tunnelling protocol, so that

lower layer equipment can signal congestion explicitly and it will

propagate consistently into encapsulated (higher layer) headers,

otherwise the signals will not reach their ultimate destination.

Suggest: "equipment" -> "functionality"

Sorry, the word 'functionality' gets to me like finger-nails on a blackboard.
https://www.dailywritingtips.com/is-that-even-a-word/

I've used s/equipment/AQM algorithms/


Page 5, first full paragraph:

If a particular protocol design chooses to contradict a

'SHOULD (NOT)' given in the advice below, it MUST include a sound

justification.

chooses to contradict -> chooses not to follow

Yup

1.1. Scope, first paragraph

This document only concerns wire protocol processing of explicit

notification of congestion.

Remove "wire"

I think that loses the intended sense in too much ambiguity.
'Protocol processing' could include the AQM algorithms, which this sentence is trying to exclude.

Section 3.1, second paragraph

In these cases, ECN may best be supported by standardising explicit

notification of congestion into the lower layer protocol that carries

the data forwards. It will then also be necessary to define how the

egress of the lower layer subnet propagates this explicit signal into

the forwarded upper layer (IP) header. It can then continue forwards

until it finally reaches the destination transport (at L4). Then

typically the destination will feed this congestion notification back

to the source transport using an end-to-end protocol (e.g. TCP).

This is the arrangement that has already been used to add ECN to IP-

in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129].

The referents of "It" at the start of the second and third sentences are

unclear and different. Suggested rephrasings:

It will then also be necessary to define ->

This necessitates also specifying

It can then continue -> This signal continues

Good.

Section 3.1, first paragraph after Figure 1

Cite one or more of the 3GPP references for GTP tunnels, as this is the

first occurrence of that concept in this draft.

Yup

Section 3.1, second paragraph after Figure 1

Cite a Frame Relay reference for the FECN bit.. Moving the [Buck00]

citation up to immediately follow "Frame Relay" in the first line
suffices.

Good.

Section 3.2 first paragraph

These are Ethernet switches that bury into the Ethernet payload ...

bury -> burrow

[Spelling checker is missing read users mind feature :-)]

I've used dig.

Hard to read user's mind. Easier to tell user what to think ;)

Section 3.4

The second paragraph could be improved by citing references for fat-tree

and Clos network topologies.

Done.

Section 4.1, second paragraph

Therefore section 4 of

[I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to

configure the ingress of a non-ECN tunnel so that it zeros the ECN

field in the outer IP header.

non-ECN tunnel -> tunnel that does not support ECN

OK

Section 4.1, third paragraph

Even

if the shim(s) encapsulate a L2 header, it is often possible to find

an inner IP header within the L2 header

Latter instance of "L2 header" should be "L2 PDU"

Good.

Section 4.1, last paragraph

Instead a companion specification

[I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has

sufficient standards track status to update standards track

protocols.

sufficient -> the appropriate

Done.

Authors Addresses

Please check these - Pat Thaler's contact info probably needs to be updated.

In progress.



Bob

Thanks, --David

----------------------------------------------------------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA 01748

+1 (774) 350-9323 New Mobile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------------------


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E0339A33F339C792C7B1F9D3-- From nobody Thu May 16 09:03:48 2019 Return-Path: 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 5652A1200EF; Thu, 16 May 2019 09:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 BAziXtD2d0-9; Thu, 16 May 2019 09:03:41 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 52C72120074; Thu, 16 May 2019 09:03:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,477,1549926000"; d="scan'208,217";a="306293232" Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2019 18:03:31 +0200 From: Vincent Roca Message-Id: <08DF989D-17BE-47AE-9E8F-A087BC7F607E@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_36C06F64-50DA-4FD3-8FAA-6E0339CC1E5C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 16 May 2019 18:03:30 +0200 In-Reply-To: <155731992421.22706.18402243276597862967@ietfa.amsl.com> Cc: Vincent Roca , gen-art@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-tinymt32.all@ietf.org, tsvwg@ietf.org To: Stewart Bryant References: <155731992421.22706.18402243276597862967@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-tinymt32-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 16:03:46 -0000 --Apple-Mail=_36C06F64-50DA-4FD3-8FAA-6E0339CC1E5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Stewart, Thanks a lot for your review. We have submitted a new I-D to reflect = these changes. More precisely: > Reviewer: Stewart Bryant > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-tsvwg-tinymt32-01 > Reviewer: Stewart Bryant > Review Date: 2019-05-08 > IETF LC End Date: 2019-05-13 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: A well written document. There are a few review comments = below that > the authors should consider. >=20 > Major issues: None >=20 > Minor issues: >=20 > According to statistical tests (BigCrush in TestU01 > and AdaptiveCrush > ) the > quality of the outputs of TinyMT seems pretty good, >=20 > SB> It would be useful to the reader to specify "pretty good =C2=BB [VR] Good point. This is a claim that comes from the TinyMT32 authors=20 (also co-author of this I-D): = http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/TINYMT/index.html A few things have been changed (mention to uniformity, addition of the = above URL to know where the claim comes from, mention of the limitations of=20 Park-Miller PRNG. But as explained, we can do better with Mersenne = Twister PRNG (for instance), but it has a cost. None of them are considered = cryptographically secure, which we now mention. NEW: The purpose of TinyMT is not to replace Mersenne Twister: TinyMT has a far shorter period (2^^127 - 1) than MT. The merit of TinyMT is in its small size of the internal state of 127 bits, far smaller than 19937 bits of MT. According to statistical tests (BigCrush in TestU01 [3] and AdaptiveCrush [4]) the quality of the outputs of TinyMT seems pretty good in terms of randomnes (in particular the uniformity of generated numbers), taking the small size of the internal state into consideration (see [5]). =46rom this point of view, TinyMT32 represents a major improvement with respect to the Park-Miler Linear Congruential PRNG (e.g., as specified in [RFC5170]) that suffers several known limitations. However, neither TinyMT nor MT are meant to be used for cryptographic applications. > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The TinyMT32 PRNG initialization depends, among other things, on a > parameter set -- namely (mat1, mat2, tmat) -- >=20 > SB> These probably need a few words of explanation on introduction. [VR] Agreed. We have extended this paragraph to be more clear. NEW: The TinyMT32 PRNG initialization depends, among other things, on a parameter set -- namely (mat1, mat2, tmat) -- that needs to be well chosen (pre-calculated values are available in the official web site). In order to facilitate the use of this PRNG and make the sequence of pseudo-random numbers depend only on the seed value, this specification requires the use of a specific parameter set (see Section 3.1). This is a first difference with respect to the implementation version 1.1 (2015/04/24) by Mutsuo Saito and Makoto Matsumoto that leaves this parameter set unspecified. A second difference is the removal of the tinymt32_init_by_array() alternative initialization function, to only keep the simple initialisation through a seed value (see Section 3.2). > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > static void tinymt32_next_state (tinymt32_t * s); > SB> I assume that this notation is good C, but > SB> type space star space name does not seem common. > SB> This may confuse some readers. One more often > SB> sees one of the spaces omitted. [VR] Yes, let=E2=80=99s do that in the usual way. I=E2=80=99ve removed = the extra space before the =C2=AB * =C2=BB (the opposite is possible too, with a subtil = difference when several variables are defined together, which we avoid here). > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Nits/editorial comments: >=20 > This specialisation aims at having a simple-to-use and deterministic > PRNG, as explained below. >=20 > SB> I assume that "deterministic PRNG" is a term of the art, but the > SB> it sounds like an oxymoron to the uninitiated. Perhaps a word > SB> or two would clarify. >=20 [VR] Agreed. We have extended this paragraph as follows: NEW: Finally, the determinism of this PRNG, for a given seed, has been carefully checked (see Section 3.3). It means that the same sequence of pseudo-random numbers should be generated, no matter the target execution platform and compiler, for a given initial seed value. This determinism can be a key requirement as it the case with [RLC-ID] that normatively depends on this specification. > =3D=3D=3D=3D=3D=3D=3D Cheers, Vincent --Apple-Mail=_36C06F64-50DA-4FD3-8FAA-6E0339CC1E5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Stewart,

Thanks a lot for your = review. We have submitted a new I-D to reflect these changes.
More precisely:

Reviewer: Stewart = Bryant
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The = General Area
Review Team (Gen-ART) reviews all IETF = documents being processed
by the IESG for the IETF Chair. =  Please treat these comments just
like any other last = call comments.

For more information, please = see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-tsvwg-tinymt32-01
Reviewer: Stewart Bryant
Review Date: = 2019-05-08
IETF LC End Date: 2019-05-13
IESG = Telechat date: Not scheduled for a telechat

Summary: A well written document. There are a few review = comments below that
the authors should consider.

Major issues: None

Minor issues:

According to = statistical tests (BigCrush in TestU01
<http://simul.iro.umontreal.ca/testu01/tu01.html> and = AdaptiveCrush
<http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ADAPTIVE/&g= t;) the
quality of the outputs of TinyMT seems pretty = good,

SB> It would be useful to the = reader to specify  "pretty good =C2=BB

[VR] Good point. This is a claim that comes from = the TinyMT32 authors 
(also co-author of this = I-D):
A few things have been changed (mention to uniformity, = addition of the above
URL to know where the claim comes from, = mention of the limitations of 
Park-Miller PRNG. But as = explained, we can do better with Mersenne Twister
PRNG (for = instance), but it has a cost. None of them are considered = cryptographically
secure, which we now mention.

NEW:
   The purpose of = TinyMT is not to replace Mersenne Twister: TinyMT has
  =  a far shorter period (2^^127 - 1) than = MT.  The merit of TinyMT is in
   its small = size of the internal state of 127 bits, far smaller = than
   19937 bits of MT.  According to = statistical tests (BigCrush in
   TestU01 [3] and = AdaptiveCrush [4]) the quality of the outputs of
  =  TinyMT seems pretty good in terms of randomnes (in particular the
  =  uniformity of generated numbers), taking the small size of = the
   internal state into = consideration (see [5]).  =46rom this point = of
   view, TinyMT32 represents a major improvement = with respect to the
   Park-Miler Linear = Congruential PRNG (e.g., as specified in = [RFC5170])
   that suffers = several known limitations.  However, neither TinyMT = nor
   MT are meant to be used for = cryptographic applications.


=3D=3D=3D=3D=3D=3D=3D=3D=3D

  The TinyMT32 PRNG initialization depends, among = other things, on a
  parameter set -- namely = (mat1, mat2, tmat) --

SB> These probably = need a few words  of explanation on introduction.

[VR] Agreed. We = have extended this paragraph to be more clear.

NEW:
   The TinyMT32 PRNG = initialization depends, among other things, on a
  =  parameter set -- namely (mat1, mat2, tmat) -- that needs to be = well
   chosen (pre-calculated values are available = in the official web
   site).  In order to facilitate the use of this PRNG and make = the
   sequence of pseudo-random = numbers depend only on the seed value, this
   specification requires the use of a specific = parameter set (see
   Section = 3.1).  This is a first difference with respect to = the
   implementation version 1.1 = (2015/04/24) by Mutsuo Saito and Makoto
 =  Matsumoto that leaves this parameter set unspecified.  A = second
   difference is the removal of the = tinymt32_init_by_array()
  =  alternative initialization function, to only keep the = simple
   initialisation through a = seed value (see Section 3.2).

=3D=3D=3D=3D=3D=3D=3D=3D<= br class=3D"">
  static void tinymt32_next_state = (tinymt32_t * s);
SB> I assume that this notation is = good C, but
SB> type space star space name does not = seem common.
SB> This may confuse some readers. One = more often
SB> sees one of the spaces omitted.

[VR] Yes, let=E2=80= =99s do that in the usual way. I=E2=80=99ve removed the extra = space
before the =C2=AB * =C2=BB  (the opposite = is possible too, with a subtil difference
when several = variables are defined together, which we avoid here).


=3D=3D=3D=3D=3D=3D=3D=3D=3D

Nits/editorial comments:

  This specialisation aims at having a = simple-to-use and deterministic
  PRNG, as = explained below.

SB> I assume that = "deterministic PRNG" is a term of the art, but the
SB> = it sounds like an oxymoron to the uninitiated. Perhaps a word
SB> or two would clarify.


[VR] Agreed. = We have extended this paragraph as follows:

NEW:
   Finally, the = determinism of this PRNG, for a given seed, has been
  =  carefully checked (see Section 3.3).  It means = that the same sequence
   of = pseudo-random numbers should be generated, no matter the = target
   execution platform and = compiler, for a given initial seed value.
  =  This determinism can be a key requirement as it the case = with
   [RLC-ID] that normatively depends on this = specification.


=3D=3D=3D=3D=3D=3D=3D

Cheers,

   Vincent


= --Apple-Mail=_36C06F64-50DA-4FD3-8FAA-6E0339CC1E5C-- From nobody Thu May 16 09:06:32 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1255120133; Thu, 16 May 2019 09:06:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <155802279086.19810.5950959068569731773@ietfa.amsl.com> Date: Thu, 16 May 2019 09:06:30 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-tinymt32-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 16:06:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : TinyMT32 Pseudo Random Number Generator (PRNG) Authors : Mutsuo Saito Makoto Matsumoto Vincent Roca Emmanuel Baccelli Filename : draft-ietf-tsvwg-tinymt32-02.txt Pages : 11 Date : 2019-05-16 Abstract: This document describes the TinyMT32 Pseudo Random Number Generator (PRNG) that produces 32-bit pseudo-random unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of Mersenne Twister (MT) PRNG, also designed by M. Saito and M. Matsumoto. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms including embedded devices, while keeping a reasonably good randomness. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-tinymt32/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-tinymt32-02 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-tinymt32-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-tinymt32-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 16 10:15:12 2019 Return-Path: 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 2572B120025 for ; Thu, 16 May 2019 10:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=GhagON24; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=oGyqYXHn 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 0gOjNfhJqQhh for ; Thu, 16 May 2019 10:15:04 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 0CB7A120117 for ; Thu, 16 May 2019 10:14:50 -0700 (PDT) Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4GH9s1k018129; Thu, 16 May 2019 13:14:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=Of/W2NfESjmzLN8mm+GZIGP7seE0ENXwtRFXD2VDpBQ=; b=GhagON24cS9SfRvZcqhwcuqlfZLbUsOSiBEhrv8vKRU9k8rQpSX5hC4zBatcavKb4UXs dmMQPwBiirN4O0l0wrLv/QERQtSt2JdP7mvEPnPuBaBHVdMW9YYWk3oFrJ+xsCuasQcq xxxc2+9ROOrk+9YZrbwGkIsqcyccOof4Zy0BwfSEpLYJrX6aI8EyLj2+KXuoVaFK4kQA rQwPHk3wPeOf7S8jeM8U3AKs99SClJmjNdn654+Sog7dfJZLy29PQF4uTxOwneO1hrzS iiDIwAD8seqc3gUHFWQjr4QnXVj1kQW4HU3RNFfU3/8FdZoK7IT2QKzr/6dPJ8df+Yht QA== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2sgeujwyw7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 May 2019 13:14:06 -0400 Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4GHD3we008589; Thu, 16 May 2019 13:14:05 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-00154901.pphosted.com with ESMTP id 2sh8kv4c9h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 May 2019 13:14:05 -0400 Received: from m0142699.ppops.net (m0142699.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.27/8.16.0.27) with SMTP id x4GHDSNb009582; Thu, 16 May 2019 13:14:04 -0400 Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0a-00154901.pphosted.com with ESMTP id 2sh8kv4c93-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 May 2019 13:14:04 -0400 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4GHDw0J003373 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 May 2019 13:14:02 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x4GHDw0J003373 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1558026843; bh=nacA0ElQK1wkklZuhsJ76OZYblI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=oGyqYXHnmfQkOi8hds9iQk19tmKB2I5g1DwVHb1mbVmhiUqLWnfRA8VUaLG9eJDcp Qw6JScj5/e4Atpej/CeBeILw98UngcA8oLpnZeOCpVupNkxJAi97QVrLA7NLs66Lal RvFK/CLRDm6qKzAykcGueRWlmLcLGqrpMNPB1KKU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x4GHDw0J003373 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 16 May 2019 13:13:26 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4GHDdtc027184 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 16 May 2019 13:13:40 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0439.000; Thu, 16 May 2019 13:13:39 -0400 From: "Black, David" To: Bob Briscoe , "tsvwg@ietf.org" Thread-Topic: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12 Thread-Index: AdUF+PJKfYny0XdBSEe2JZXBy1PR5AFnnW2AABxCnBA= Date: Thu, 16 May 2019 17:13:38 +0000 Message-ID: References: <247a9990-30c0-b0ea-5e3d-2a0b2ae57a95@bobbriscoe.net> In-Reply-To: <247a9990-30c0-b0ea-5e3d-2a0b2ae57a95@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.130] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363056B1F5MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160109 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160109 Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 17:15:11 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363056B1F5MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, Thanks for the comprehensive response, most of which I agree with. Please= also take note of Joe Touch's comments on fragmentation and the relationsh= ip to draft-intarea-tunnels. I have a few more comments - anything that isn't mentioned here is fine wit= h me. i) > Expanded sentence at the end of Intro to: > "This document updates and completely replaces the brief paragraph of adv= ice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89)." That'll suffice for now - I still expect to get dinged on this by an AD dur= ing IESG evaluation, but we can wait until then to determine what else is r= equired. ii) > [D] Page 5, first complete paragraph [... snip ...] > Done; added: > "Similarly, if the DSCP is wiped at the boundary between Diffserv domains= , the special ECN semantics would also be lost." wiped -> changed (e.g., zeroed) iii) > ECN-PDU: A PDU that is part of a feedback loop within which all the > nodes that need to propagate the explicit congestion notification > signal in the PDU back to the Load Regulator are ECN-capable of doing = so. I think this improved definition needs an additional hair-splitting clarifi= cation: A PDU that is -> A PDU whose congestion indication (if any) is The rationale for this clarification is to exclude signals back to the Load= Regulator, e.g., TCP ECE. > I've also extended the above correction into the next definition: > Not-ECN-PDU: A PDU that is part of a feedback-loop within which some at = least one > node necessary to propagate the explicit congestion notification signa= l in the PDU > back to the load regulator are is not ECN-capable of doing so. And apply the same change to this definition also. Thanks, --David From: Bob Briscoe Sent: Wednesday, May 15, 2019 7:28 PM To: Black, David; tsvwg@ietf.org Cc: John Kaippallimalil Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-enca= p-guidelines-12 [EXTERNAL EMAIL] David, I've addressed all your points inline (and RS's and AMcG's points in recent= emails). I've edited my local copy of the draft as I describe. I'll submit it in a f= ew hours time. I'm off to bed now, and in the morning I just want to double= -check I haven't missed anyone's comments before posting it. That might als= o allow you, my co-author or anyone else enough time to come back on any of= my responses below before I post... On 09/05/2019 01:10, Black, David wrote: First of all, this is a well-written and comprehensive draft on ECN encapsu= lation design guidelines. I found no major issues, and all of the minor issues are truly minor - some= border on editorial, and all can be dealt with via relatively minor edits.. --- Minor --- [A] Need an explicit statement of exactly what the update to RFC 3819 is, preferably in a section whose name uses "RFC 3819" and appears in the table of contents. Do this before some AD tells you to ;-). This is also the only thing that idnits found that needs attention. RFC 3819 contained a paragraph of brief musings on how subnetworks might ha= ndle ECN. So ecn-encap completely replaces that para with a whole document.= I hope the new text quoted below is sufficient to explain that there is no= specific section that updates RFC 3819. Rather the whole document does: Copied sentence below from end of intro to abstract: "This document updates the advice to subnetwork designers about ECN in RFC = 3819." Expanded sentence at the end of Intro to: "This document updates and completely replaces the brief paragraph of advic= e to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89)." [B] 1. Introduction, first paragraph, last sentence The phrase "egress at any layer" is too general, hence incorrect (e.g., layer 7 was not intended to be included) - "lower layer" needs to be used for clarity. OLD If an egress at any layer is not ECN-aware, or if the ultimate receiver or sender is not ECN-aware, congestion needs to be indicated by dropping a packet, not marking it. NEW If a lower layer header that may contain ECN congestion indications is removed by an egress that is not ECN-aware, or if the ultimate receiver = or sender is not ECN-aware, then lower layer congestion needs to be indicat= ed by dropping a packet, not marking it. END Thx. Used verbatim (except s/an egress/a subnet egress/). [C] 1.1 Scope Second paragraph and the two-bullet list imply that RFC 4774 states that us= e of ECT(1) to signal alternative ECN semantics is a best current practice. That's not correct, as RFC 4774 covers only the first bullet on use of DSCP= , not the second bullet on use of ECT(1), as that second bullet is based sole= ly on RFC 8311. Some rewriting is in order to disconnect the second bullet fro= m RFC 4774. Done: "There are two main examples for how alternative ECN semantics have been de= fined in practice: o RFC 4774 suggests... o RFC 8311 suggests..." Based on this, all other places where RFC 4774 is mentioned or cited should be checked to determine whether RFC 8311 also ought to be mentioned or cite= d. Done. The one other occurrence of RFC4774 says: "The guidelines are also designed to ensure compliance with the more ge= neral best current practice for the design of alternate ECN schemes given i= n [RFC4774]..." Added: "...and extended by [RFC8311]" [D] Page 5, first complete paragraph Alternative semantics for the ECN field can be defined to depend on the traffic class indicated by the DSCP. Therefore correct propagation of congestion signals could depend on correct propagation of the DSCP between the layers. This also depends on correct propagation across diffserv boundaries - that and the potential damage wrought by bleaching DSCPs to zero at such boundar= ies both deserve mention here. Done; added: "Similarly, if the DSCP is wiped at the boundary between Diffserv domains, = the special ECN semantics would also be lost." [E] 1.1 Scope, end of section In the feed-backward mode, propagation of congestion signals for multicast and anycast packets is out-of-scope (because it would be so complicated that it is hoped no-one would attempt such an abomination). Much as I may agree with it :-), the parenthetical remark is inappropriate for an archival RFC, and hence needs to be removed. When doing transport area reviews, I have criticised other authors for just= ruling stuff out of scope without justification or explanation of the impl= ications. So rather than delete, I've toned this down: "... (because the complexity would make it unlikely to be attempted)." BTW, for archival documents IMO light-heartedness is no less appropriate th= an unrelenting blandness. [F] 2. Terminology ECN-PDU: A PDU that is part of a feedback loop within which all the nodes that need to propagate explicit congestion notifications back to the Load Regulator are ECN-capable. That first sentence is too broad as it includes both the forward and reverse directions of the feedback loop, whereas only the forward direction is intended (FWIW, the definition of PDU does not suffice to narrow this to the forward direction only). For example, a TCP packet with the ECE flag set in the TCP header and Not-ECT in the ECN field in the IP header would be an ECN-PDU under this definition, which is not what was intended. The immediately following definition of Not-ECN-PDU has the same problem. The point of building on the OSI term 'PDU' was because a PDU is defined by= the layer that is stated as relevant. By the OSI definition, a PDU at a ce= rtain layer does not include lower layer headers that encapsulate it. So, in the example you give of a TCP packet with ECE set, that is a TCP PDU= . By OSI definition, a TCP PDU does not include the IP header that encapsul= ates it. The IP header is only relevant when considering it as an IP PDU. A= nd then the TCP PDU within it is just payload (the SDU that was passed to I= P) and not part of the protocol of the IP PDU. The narrowing concept that needs to be added is that if the PDU carries a congestion indication, then that congestion indication participates in such a feedback loop, Yes, valid point. Thank you. ECN-PDU: A PDU that is part of a feedback loop within which all the nodes that need to propagate the explicit congestion notification signal in the PDU back to the Load Regulator are ECN-capable of doing= so. and even that is subtle when there are multiple possible congestion indication locations. An example of the subtlety is that the same PDU may be an ECN-PDU in feed-up-and-forward mode because the layer 3 and 4 protocols support ECN but may be a Not-ECN-PDU for feed-forward-and-up mode because the L2 decapsulator ignores and discards L2 congestion indications. I think the bold words in the phrase "nodes that need to propagate" deals w= ith that subtlety. In your example, if the subnet is propagating the PDU's ECN signal in feed-= up-and-forward mode and the L2 decapsulator doesn't propagate ECN, it's not= relevant because it also doesn't need to propagate ECN. Whereas, if the su= bnet propagates ECN in feed-forward-and-up mode, the decap does need to. I've also extended the above correction into the next definition: Not-ECN-PDU: A PDU that is part of a feedback-loop within which some at= least one node necessary to propagate the explicit congestion notification sign= al in the PDU back to the load regulator are is not ECN-capable of doing so. [G] 2. Terminology Congestion Baseline: The location of the function on the path that initialised the values of all congestion notification fields in a sequence of packets, before any are set to the congestion experienced (CE) codepoint if they experience congestion further downstream. Typically the original data source at layer-4. That's counter-intuitive - a baseline is a level, not a location. I've tagged this as a minor issue as opposed to editorial because it causes severe confusion in the only place that this term is used, namely item 3 in Section 4.3. That item 3 is about a Monitoring Baseline which is a level not a location. The Congestion Baseline term should be removed, and item 3 in Section 4.3 revised accordingly. The term "Congestion Baseline" is used twice there, but only the latter of those two uses needs to be retained and expanded after deletion of this definition. You're right. I've done as you suggest. I've also nearly completely re-written the second half of the section, beca= use I had temporarily forgotten the rationale, and even I couldn't understa= nd what the rationale was after reading my own words. [H] 3. Modes of Operation Feed-Up-and-Forward: A lower layer switch feeds-up congestion notification directly into the ECN field in the higher layer (e.g. IP) header, irrespective of whether the node is at the egress of a subnet. Remove "the ECN field in" as that's too restrictive, even though that's a common case, and move it into the example - "(e.g., ECN field in the IP header)" where "header" moved inside the parentheses. Done. [I] 3.3. Feed-Backward Mode Please make it clear that the critique of the ATM ABR relative rate control mechanism also applies to Ethernet QCN, as that's a more current example. This should be connected to the QCN discussion at the end of Section 4.2. I didn't want to imply any criticism of QCN, which always made it clear it = was only applicable to a single subnet. However, I can now see the need to have this written down, given certain co= mpanies are giving incentives to churn out Frankenpatents (any random combi= nation of existing ideas, no matter whether useful or correct). So I've kep= t ATM as the example, but added at the end: QCN [IEEE802.1Qau] would suffer from similar problems if extended to multiple subnets. However, from the start QCN was clearly stated as solely applicable to a single subnet (see Section 6). [J] 4.3 Encapsulation Guidelines Resolving minor issue [G] requires some edits to item 3 in this section: - Remove "(the Congestion Baseline)" from the third paragraph. - Rewrite start of fourth paragraph: OLD Most information can be extracted if the Congestion Baseline is standardised at the node that is regulating the load (the Load Regulator--typically the data source). NEW More information can be extracted if the protocol specification requires that congestion fields be initialized to indicate no congestion only by the node that is regulating the load (the Load Regulator--typically the data source). END See minor issue [G] above - already completely rewritten this text. [K] 12.2 Informative References Please check the references to 802.1Qah and 802.1Qau with IEEE. The correct references to use now may be the latest version of 802.1Q with specific functionality and/or clauses identified. Done. 802.1Qau -> 802.1Q Sections 30--33 802.1ah -> 802.1Q (as a whole - too scattered to call out particular sectio= ns). Pat Thaler having retired, I no longer have a co-author who can advise on I= EEE citation correctness. But the above is good enough. [I knew someone would point that out - I should have dealt with it but, eve= n tho I purportedly have free access to the full rolled-up text of the curr= ent standard (IEEE802.1Q-2018), I've always had trouble viewing it. The IEE= E pay-wall insists on displaying the free copy in my browser in a way that = it can't be downloaded, but in Firefox the activity bar spins but nothing e= ver appears. After much gnashing of teeth, I discovered it works OK in Chro= me.] --- Editorial/Nits --- Abstract, last sentence Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. between new -> among IP layer and Yup. 1. Introduction, first paragraph Suggest removing use of the word "buffer" - "lower layer" suffices in all of the places where this word is used in this paragraph. Not as simple as that. I've guessed that the idea of a buffer doing marking= jars with you, so I've addressed the two occurrences of 'buffer' as follow= s: 1. When a lower layer buffer drops a packet This was intended to introduce the context as congestion loss, not transmis= sion loss. So left unchanged. 2. In contrast, when a lower layer marks a packet with ECN, the marking needs to be explicitly propagated up the layers. The same is true if a buffer marks the outer header of a packet that encapsulates inner tunnelled headers. The second sentence is about tunnels, not lower layers. So, I've introduced AQM into both sentences: In contrast, when active queue management (AQM) at a lower layer marks a packet with ECN, the marking needs to be explicitly propagated up the layers. The same is true if AQM marks the outer header of a packet that encapsulates inner tunnelled headers. 1. Introduction, second paragraph The purpose of this document is to guide the addition of congestion notification to any subnet technology or tunnelling protocol, so that lower layer equipment can signal congestion explicitly and it will propagate consistently into encapsulated (higher layer) headers, otherwise the signals will not reach their ultimate destination. Suggest: "equipment" -> "functionality" Sorry, the word 'functionality' gets to me like finger-nails on a blackboar= d. https://www.dailywritingtips.com/is-that-even-a-word/ I've used s/equipment/AQM algorithms/ Page 5, first full paragraph: If a particular protocol design chooses to contradict a 'SHOULD (NOT)' given in the advice below, it MUST include a sound justification. chooses to contradict -> chooses not to follow Yup 1.1. Scope, first paragraph This document only concerns wire protocol processing of explicit notification of congestion. Remove "wire" I think that loses the intended sense in too much ambiguity. 'Protocol processing' could include the AQM algorithms, which this sentence= is trying to exclude. Section 3.1, second paragraph In these cases, ECN may best be supported by standardising explicit notification of congestion into the lower layer protocol that carries the data forwards. It will then also be necessary to define how the egress of the lower layer subnet propagates this explicit signal into the forwarded upper layer (IP) header. It can then continue forwards until it finally reaches the destination transport (at L4). Then typically the destination will feed this congestion notification back to the source transport using an end-to-end protocol (e.g. TCP). This is the arrangement that has already been used to add ECN to IP- in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129]. The referents of "It" at the start of the second and third sentences are unclear and different. Suggested rephrasings: It will then also be necessary to define -> This necessitates also specifying It can then continue -> This signal continues Good. Section 3.1, first paragraph after Figure 1 Cite one or more of the 3GPP references for GTP tunnels, as this is the first occurrence of that concept in this draft. Yup Section 3.1, second paragraph after Figure 1 Cite a Frame Relay reference for the FECN bit.. Moving the [Buck00] citation up to immediately follow "Frame Relay" in the first line suffices. Good. Section 3.2 first paragraph These are Ethernet switches that bury into the Ethernet payload ... bury -> burrow [Spelling checker is missing "read user's mind" feature :-)] I've used dig. Hard to read user's mind. Easier to tell user what to think ;) Section 3.4 The second paragraph could be improved by citing references for fat-tree and Clos network topologies. Done. Section 4.1, second paragraph Therefore section 4 of [I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to configure the ingress of a non-ECN tunnel so that it zeros the ECN field in the outer IP header. non-ECN tunnel -> tunnel that does not support ECN OK Section 4.1, third paragraph Even if the shim(s) encapsulate a L2 header, it is often possible to find an inner IP header within the L2 header Latter instance of "L2 header" should be "L2 PDU" Good. Section 4.1, last paragraph Instead a companion specification [I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has sufficient standards track status to update standards track protocols. sufficient -> the appropriate Done. Authors Addresses Please check these - Pat Thaler's contact info probably needs to be updated= . In progress. Bob Thanks, --David ---------------------------------------------------------------- David L. Black, Senior Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (774) 350-9323 New Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_CE03DB3D7B45C245BCA0D243277949363056B1F5MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,=

 

Thanks for the compreh= ensive response, most of which I agree with.   Please also take n= ote of Joe Touch’s comments on fragmentation and the relationship to = draft-intarea-tunnels.

 

I have a few more comm= ents – anything that isn’t mentioned here is fine with me.=

 

i)

> Expanded sentence at the end of Intro to:
> "This document updates and completely replaces the brief paragrap= h of advice to subnetwork designers about ECN in Section 13 of [RFC3819] (B= CP 89)."

 

That’ll suffice = for now – I still expect to get dinged on this by an AD during IESG e= valuation, but we can wait until then to determine what else is required.

 

ii)<= /p>

= > [D] Page 5, first complete paragraph

[… snip …]=

 

> Done; added:
> "Similarly, if the DSCP is wiped at the boundary between Diffserv= domains, the special ECN semantics would also be lost."

 

wiped -> changed (e= .g., zeroed)

 

iii)

> ECN-PDU:  A PDU that is part of a f= eedback loop within which all the

>    nodes that need to pro= pagate the explici= t congestion notification

>    signal in the PDU back to the Load Regulator are ECN-capable of doing so= .

 

I think this improved = definition needs an additional hair-splitting clarification:

 

= A PDU that is -> A PDU whose congestion indication (if any) is

=  

The rationale for this= clarification is to exclude signals back to the Load Regulator, e.g., TCP = ECE.

 

> I've also extended the above correction into th= e next definition:

> Not-ECN-PDU:  A PDU that is part of a feedback-loop within w=
hich some at least one
>    node necessary to propagate the explicit congestion notification signal in the PDU  
>    back to the load regulator are is =
not ECN-capable of doing so.

 

And apply the same cha= nge to this definition also.

 

Thanks, --David

 

From:= Bob Briscoe <ietf@bobbriscoe.net>
Sent: Wednesday, May 15, 2019 7:28 PM
To: Black, David; tsvwg@ietf.org
Cc: John Kaippallimalil
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-e= cn-encap-guidelines-12

 

[EXTERNAL EMAIL]

David,

I've addressed all your points inline (and RS's and AMcG's points in recent= emails).

I've edited my local copy of the draft as I describe. I'll submit it in a f= ew hours time. I'm off to bed now, and in the morning I just want to double= -check I haven't missed anyone's comments before posting it. That might als= o allow you, my co-author or anyone else enough time to come back on any of my responses below before I post..= .

On 09/05/2019 01:10, Black, David wrote:<= /p>

First of all, this is a well-written and comprehensi= ve draft on ECN encapsulation design guidelines.

 

I found no major issues, and all of the minor issues= are truly minor – some border on editorial,

and all can be dealt with via relatively minor edits= ..

 

--- Minor ---

 

[A] Need an explicit statement of exactly wha= t the update to RFC 3819 is,

preferably in a section whose name uses "= ;RFC 3819" and appears in the

table of contents.  Do this before some = AD tells you to ;-).  This is

also the only thing that idnits found that ne= eds attention.


RFC 3819 contained a paragraph of brief musings on how subnetworks might ha= ndle ECN. So ecn-encap completely replaces that para with a whole document.= I hope the new text quoted below is sufficient to explain that there is no= specific section that updates RFC 3819. Rather the whole document does:

Copied sentence below from end of intro to abstract:
"This document updates the advice to subnetwork designers about ECN in= RFC 3819."

Expanded sentence at the end of Intro to:
"This document updates and completely replaces the brief paragraph of = advice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89= )."


 

[B] 1. Introduction, first paragraph, last se= ntence

 

The phrase "egress at any layer" is= too general, hence incorrect (e.g.,

layer 7 was not intended to be included) - &q= uot;lower layer" needs to be

used for clarity.

 

OLD

   If an egress at any layer is not= ECN-aware, or if the

   ultimate receiver or sender is n= ot ECN-aware, congestion needs to be

   indicated by dropping a packet, = not marking it.

NEW

   If a lower layer header that may= contain ECN congestion indications is

   removed by an egress that is not= ECN-aware, or if the ultimate receiver or

   sender is not ECN-aware, then lo= wer layer congestion needs to be indicated

   by dropping a packet, not markin= g it.

END

Thx. Used verbatim (except s/an egress/a subnet egre= ss/).


 

[C] 1.1 Scope

 

Second paragraph and the two-bullet list impl= y that RFC 4774 states that use

of ECT(1) to signal alternative ECN semantics= is a best current practice.

That's not correct, as RFC 4774 covers only t= he first bullet on use of DSCP,

not the second bullet on use of ECT(1), as th= at second bullet is based solely

on RFC 8311. Some rewriting is in order to di= sconnect the second bullet from

RFC 4774.

Done:
"There are two main examples for how alternative ECN semantics have be= en defined in practice:
    o RFC 4774 suggests...
    o RFC 8311 suggests..."


 

Based on this, all other places where RFC 477= 4 is mentioned or cited should

be checked to determine whether RFC 8311 also= ought to be mentioned or cited.

Done.

The one other occurrence of RFC4774 says:
    "The guidelines are also designed to ensure complia= nce with the more general best current practice for the design of alternate= ECN schemes given in [RFC4774]..."

Added: "...and extended by [RFC8311]"



 

[D] Page 5, first complete paragraph

 

   Alternative semantics for the EC= N field can be defined to depend on

   the traffic class indicated by t= he DSCP.  Therefore correct

   propagation of congestion signal= s could depend on correct propagation

   of the DSCP between the layers.<= /span>

 

This also depends on correct propagation acro= ss diffserv boundaries - that

and the potential damage wrought by bleaching= DSCPs to zero at such boundaries

both deserve mention here.<= /p>

Done; added:
"Similarly, if the DSCP is wiped at the boundary between Diffserv doma= ins, the special ECN semantics would also be lost."



 

[E] 1.1 Scope, end of section

 

   In the feed-backward mode, propa= gation of

   congestion signals for multicast= and anycast packets is out-of-scope

   (because it would be so complica= ted that it is hoped no-one would

   attempt such an abomination).

 

Much as I may agree with it :-), the parenthe= tical remark is inappropriate

for an archival RFC, and hence needs to be re= moved.

When doing transport area reviews, I have criticised= other authors for just ruling stuff out of scope without justification or = explanation of the implications. So rather than delete, I've toned this dow= n:

"... (because the complexity would make it unlikely to be attempted).&= quot;

BTW, for archival documents IMO light-heartedness is no less appropriate th= an unrelenting blandness.


 

[F] 2. Terminology



 

   ECN-PDU:  A PDU that is par= t of a feedback loop within which all the

      nodes that nee= d to propagate explicit congestion notifications

      back to the Lo= ad Regulator are ECN-capable.

 

That first sentence is too broad as it includ= es both the forward and

reverse directions of the feedback loop, wher= eas only the forward
direction is intended (FWIW, the definition of PDU does not suffice to

narrow this to the forward direction only).&n= bsp; For example, a TCP packet

with the ECE flag set in the TCP header and N= ot-ECT in the ECN field in

the IP header would be an ECN-PDU under this = definition, which is not

what was intended.  The immediately foll= owing definition of Not-ECN-PDU

has the same problem.

The point of building on the OSI term 'PDU' was beca= use a PDU is defined by the layer that is stated as relevant. By the OSI de= finition, a PDU at a certain layer does not include lower layer headers tha= t encapsulate it.

So, in the example you give of a TCP packet with ECE set, that is a TCP PDU= . By OSI definition, a TCP PDU does not include the IP header that encapsul= ates it. The IP header is only relevant when considering it as an IP PDU. A= nd then the TCP PDU within it is just payload (the SDU that was passed to IP) and not part of the protocol = of the IP PDU.


 

The narrowing concept that needs to be added = is that if the PDU carries

a congestion indication, then that congestion= indication participates in

such a feedback loop,

Yes, valid point. Tha= nk you.

   ECN-PDU:  A PDU that is par= t of a feedback loop within which all the

      nodes that nee= d to propagate the explici= t congestion notification

      signal in the PDU back to the Load Regulator are ECN-capable of doing so= .



and even that is subtle when there are multip= le

possible congestion indication locations.&nbs= p; An example of the subtlety is

that the same PDU may be an ECN-PDU in feed-u= p-and-forward mode because

the layer 3 and 4 protocols support ECN but m= ay be a Not-ECN-PDU for

feed-forward-and-up mode because the L2 decap= sulator ignores and discards

L2 congestion indications.<= /p>

I think the bold words in the phrase "nodes tha= t need to propagate" deals with that subtlety.

In your example, if the subnet is propagating the PDU's ECN signal in feed-= up-and-forward mode and the L2 decapsulator doesn't propagate ECN, it's not= relevant because it also doesn't need to propagate ECN. Whereas, if the subnet propagates ECN in feed= -forward-and-up mode, the decap does need to.

I've also extended the above correction into the next definition:

   Not-ECN-PDU:  A PDU that is part of a feedback-loop =
within which some at least one
      node necessary to propagate the explicit congestion notification signal in the PDU  <=
/pre>
      back to the load regulator are i=
s not ECN-capable=
 of doing so.



 

[G] 2. Terminology

 

   Congestion Baseline:  The l= ocation of the function on the path that

      initialised th= e values of all congestion notification fields in a

      sequence of pa= ckets, before any are set to the congestion

      experienced (C= E) codepoint if they experience congestion further

      downstream.&nb= sp; Typically the original data source at layer-4.


That's counter-intuitive - a baseline is a le= vel, not a location. I've

tagged this as a minor issue as opposed to ed= itorial because it causes

severe confusion in the only place that this = term is used, namely item 3

in Section 4.3.  That item 3 is about a = Monitoring Baseline which is

a level not a location.

 

The Congestion Baseline term should be remove= d, and item 3 in Section

4.3 revised accordingly.  The term "= ;Congestion Baseline" is used twice

there, but only the latter of those two uses = needs to be retained and

expanded after deletion of this definition.

You're right. I've done as you suggest.

I've also nearly completely re-written the second half of the section, beca= use I had temporarily forgotten the rationale, and even I couldn't understa= nd what the rationale was after reading my own words.


 

[H] 3. Modes of Operation

 

      Feed-Up-and-Fo= rward:  A lower layer switch feeds-up congestion

       &nb= sp; notification directly into the ECN field in the higher layer

       &nb= sp; (e.g.  IP) header, irrespective of whether the node is at the

       &nb= sp; egress of a subnet.

 

Remove "the ECN field in" as that's= too restrictive, even though that's

a common case, and move it into the example &= #8211; “(e.g., ECN field in the

IP header)" where "header" mov= ed inside the parentheses.

Done.



 

[I] 3.3.  Feed-Backward Mode=

 

Please make it clear that the critique of the= ATM ABR relative rate

control mechanism also applies to Ethernet QC= N, as that's a more

current example.  This should be connect= ed to the QCN discussion at

the end of Section 4.2.

I didn't want to impl= y any criticism of QCN, which always made it clear it was only applicable t= o a single subnet.

However, I can now see the need to have this written down, given certain co= mpanies are giving incentives to churn out Frankenpatents (any random combi= nation of existing ideas, no matter whether useful or correct). So I've kep= t ATM as the example, but added at the end:

   QCN [IEEE802.1Qau] would suffer from similar problems if =
extended to
   multiple subnets.  However, from the start QCN was c=
learly stated as
   solely applicable to a single subnet (see Section 6).



 

[J] 4.3 Encapsulation Guidelines<= /o:p>

 

Resolving minor issue [G] requires some edits= to item 3 in this section:

- Remove "(the Congestion Baseline)"= ; from the third paragraph.

- Rewrite start of fourth paragraph:

 

OLD

       Most inf= ormation can be extracted if the Congestion Baseline is

       standard= ised at the node that is regulating the load (the Load

       Regulato= r--typically the data source).

NEW

       More inf= ormation can be extracted if the protocol specification

       requires= that congestion fields be initialized to indicate no

       congesti= on only by the node that is regulating the load (the

       Load Reg= ulator--typically the data source).

END

See minor issue [G] above - already completely rewri= tten this text.



 

[K] 12.2 Informative References

 

Please check the references to 802.1Qah and 8= 02.1Qau with IEEE.  The

correct references to use now may be the late= st version of 802.1Q with

specific functionality and/or clauses identif= ied.

Done.
802.1Qau -> 802.1Q Sections 30--33
802.1ah -> 802.1Q (as a whole - too scattered to call out particular sec= tions).

Pat Thaler having retired, I no longer have a co-author who can advise on I= EEE citation correctness.
But the above is good enough.

[I knew someone would point that out - I should have dealt with it but, eve= n tho I purportedly have free access to the full rolled-up text of the curr= ent standard (IEEE802.1Q-2018), I've always had trouble viewing it. The IEE= E pay-wall insists on displaying the free copy in my browser in a way that it can't be downloaded, but in F= irefox the activity bar spins but nothing ever appears. After much gnashing= of teeth, I discovered it works OK in Chrome.]


 

 

--- Editorial/Nits ---

 

Abstract, last sentence

 

   Following these guidelines shoul= d assure

   interworking between new lower l= ayer congestion notification

   mechanisms, whether specified by= the IETF or other standards bodies.

 

between new -> among IP layer and

Yup.

 

1. Introduction, first paragraph<= /o:p>

 

Suggest removing use of the word "buffer= " - "lower layer" suffices in

all of the places where this word is used in = this paragraph.

Not as simple as that. I've guessed that the idea of= a buffer doing marking jars with you, so I've addressed the two occurrence= s of 'buffer' as follows:

1.   When a lower layer buffer drops a packet

This was intended to = introduce the context as congestion loss, not transmission loss. So left un= changed.

2. In
   contrast, when a lower layer marks a packet with ECN, the=
 marking
   needs to be explicitly propagated up the layers.  Th=
e same is true if
   a buffer marks the outer header of a packet that encapsul=
ates inner
   tunnelled headers.

The second sentence is about tunnels, not lower laye= rs.
So, I've introduced AQM into both sentences:

   In
   contrast, when active queue management (AQM) at a lower l=
ayer marks a
   packet with ECN, the marking needs to be explicitly propa=
gated up the
   layers.  The same is true if AQM marks the outer hea=
der of a packet
   that encapsulates inner tunnelled headers.



 

1. Introduction, second paragraph=

 

   The purpose of this document is = to guide the addition of congestion

   notification to any subnet techn= ology or tunnelling protocol, so that

   lower layer equipment can signal= congestion explicitly and it will

   propagate consistently into enca= psulated (higher layer) headers,

   otherwise the signals will not r= each their ultimate destination.

 

Suggest: "equipment" -> "fu= nctionality"

Sorry, the word 'functionality' gets to me like fing= er-nails on a blackboard.
    https://www.dailywritingtips.com/is-that-even-a-word/

I've used s/equipment/AQM algorithms/



 

Page 5, first full paragraph:

 

   If a particular protocol design = chooses to contradict a

   'SHOULD (NOT)' given in the advi= ce below, it MUST include a sound

   justification.=

 

chooses to contradict -> chooses not to fo= llow

Yup

 

1.1. Scope, first paragraph=

 

   This document only concerns wire= protocol processing of explicit

   notification of congestion.

 

Remove "wire"

I think that loses the intended sense in too much am= biguity.
'Protocol processing' could include the AQM algorithms, which this sentence= is trying to exclude.


 

Section 3.1, second paragraph

 

   In these cases, ECN may best be = supported by standardising explicit

   notification of congestion into = the lower layer protocol that carries

   the data forwards.  It will= then also be necessary to define how the

   egress of the lower layer subnet= propagates this explicit signal into

   the forwarded upper layer (IP) h= eader.  It can then continue forwards

   until it finally reaches the des= tination transport (at L4).  Then

   typically the destination will f= eed this congestion notification back

   to the source transport using an= end-to-end protocol (e.g.  TCP).

   This is the arrangement that has= already been used to add ECN to IP-

   in-IP tunnels [RFC6040], IP-in-M= PLS and MPLS-in-MPLS [RFC5129].

 

The referents of "It" at the start = of the second and third sentences are

unclear and different.  Suggested rephra= sings:

 

It will then also be necessary to define ->= ;

     This necessitates al= so specifying

 

It can then continue -> This signal contin= ues

Good.

 

Section 3.1, first paragraph after Figure 1

 

Cite one or more of the 3GPP references for G= TP tunnels, as this is the

first occurrence of that concept in this draf= t.

Yup

 

Section 3.1, second paragraph after Figure 1<= /span>

 

Cite a Frame Relay reference for the FECN bit= ..  Moving the [Buck00]

citation up to immediately follow "Frame= Relay" in the first line
suffices.

Good.

 

Section 3.2 first paragraph=

 

   These are Ethernet switches that= bury into the Ethernet payload ...

 

bury -> burrow

[Spelling checker is missing “read user= ’s mind” feature :-)]

I've used dig.

Hard to read user's mind. Easier to tell user what to think ;)


 

Section 3.4

 

The second paragraph could be improved by cit= ing references for fat-tree

and Clos network topologies.

Done.


 

Section 4.1, second paragraph

 

   Therefore section 4 of

   [I-D.ietf-tsvwg-rfc6040update-sh= im] requires network operators to

   configure the ingress of a non-E= CN tunnel so that it zeros the ECN

   field in the outer IP header.

 

non-ECN tunnel -> tunnel that does not sup= port ECN

OK

 

Section 4.1, third paragraph

 

   Even

   if the shim(s) encapsulate a L2 = header, it is often possible to find

   an inner IP header within the L2= header

 

Latter instance of "L2 header" shou= ld be "L2 PDU"

Good.

 

Section 4.1, last paragraph=

 

   Instead a companion specificatio= n

   [I-D.ietf-tsvwg-rfc6040update-sh= im] has been prepared that has

   sufficient standards track statu= s to update standards track

   protocols.


sufficient -> the appropriate<= /o:p>

Done.

 

Authors Addresses

 

Please check these - Pat Thaler's contact inf= o probably needs to be updated.

In progress.



Bob

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (774) 350-9323 New    M= obile: +1 (978) 394-7754

David.Black@= dell.com

----------------------------------------------------= ------------

 



-- 
________________________________________________________________<=
/o:p>
Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/
--_000_CE03DB3D7B45C245BCA0D243277949363056B1F5MX307CL04corpem_-- From nobody Thu May 16 10:18:57 2019 Return-Path: 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 F3A4A12008F for ; Thu, 16 May 2019 10:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=gCYLxvh1; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=duPxUi/J 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 R0sMUOtpoFHV for ; Thu, 16 May 2019 10:18:53 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 CCFE6120043 for ; Thu, 16 May 2019 10:18:52 -0700 (PDT) Received: from pps.filterd (m0170398.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4GH9uJ0029564 for ; Thu, 16 May 2019 13:18:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=96sOrVVnLwLufMnNc6fhbdheEB7ebS/OK/DWGikOXII=; b=gCYLxvh1DSWpYVWEdZgD9gb9nL4RY0nF49Cyq9IkkwZpqPP2yp+EULvJJ1XGs+NVyybD vW0bcPrLjy1h4T/N9MH28+nE71VIinULg3dz2DyuhVgrycrpBb3RFIXPyahOqsayhWA/ 95p9+zncoG1YG+mTJRM3LJ/Za6Bqzr74jjGG5Tzvj0sW5jMBv5aJ66iYHRlEw84yvPGg s7YfHXb8CE1zJIKBDj+j2kMADw3wzoo3b+/SDTMhyfn7UDmmOayGM660vg/+zED2vPxV MY+6N4uwpyvP/xHbK0NxkYIWYNQmQYNKmCbsFPo3RT6xIClc+RgKEy4Xcjn5+igrov0M NQ== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2sgr4ubt8d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 May 2019 13:18:48 -0400 Received: from pps.filterd (m0134746.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4GHD07s040996 for ; Thu, 16 May 2019 13:18:47 -0400 Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by mx0a-00154901.pphosted.com with ESMTP id 2sh9apkhcy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 16 May 2019 13:18:47 -0400 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4GHIj2o011883 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 May 2019 13:18:45 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com x4GHIj2o011883 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1558027126; bh=MN2cCXnTIiaY/JplV4rU7zpTWbw=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=duPxUi/JuhQiUiLq1CPYw3xYU0qfymFwSentSm8FBiC3EUwtkqsQNMv9ch6Wu9LR8 gKsRzhehj94UnKvHE9uqfwH0DpTtDjF/8Hz5dFa2soT/YwG796O3SEhSMpjS1cMjTl 0HzzTVnRJSoncJS1wkuLJ4hyZxR95pvlZfKwAk3E= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com x4GHIj2o011883 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Thu, 16 May 2019 13:18:33 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4GHHhe3030897 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Thu, 16 May 2019 13:18:34 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0439.000; Thu, 16 May 2019 13:18:22 -0400 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: 2nd WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts - Concluded Thread-Index: AdUMC1xbtNHynAkRQMKgzY9qqMQbaw== Date: Thu, 16 May 2019 17:18:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.130] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363056B221MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=401 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160109 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=461 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160109 Archived-At: Subject: [tsvwg] 2nd WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts - Concluded X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 17:18:55 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363056B221MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The 2nd WGLC on these drafts has concluded, and we did get enough reviews t= his time, so there should be no need for a 3rd WGLC. Many thanks to those who took the time to review and comment. Bob (primary= author) is working on addressing the comments. Thanks, --David From: tsvwg On Behalf Of Black, David Sent: Wednesday, April 17, 2019 2:51 PM To: tsvwg@ietf.org Subject: [tsvwg] 2nd WGLC on ecn-encap-guidelines and rfc6040-update-shim d= rafts, closes 6 May 2019 [EXTERNAL EMAIL] This email announces a 2nd TSVWG Working Group Last Call (WGLC) on two draf= ts: [1] Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP draft-ietf-tsvwg-ecn-encap-guidelines-12 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ This draft is intended to become a Best Current Practice RFC [2] Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim draft-ietf-tsvwg-rfc6040update-shim-08 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ This draft is intended to become a Proposed Standard RFC. This WGLC will run through the end of the day on Monday, May 6, 2019. Comments should be sent to the tsvwg@ietf.org list, = although purely editorial comments may be sent directly to the author. Please cc: the WG chairs at tsvwg-chairs@ietf.org if you wo= uld like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on either draft Thanks, David, Gorry and Wes (TSVWG Co-Chairs) --_000_CE03DB3D7B45C245BCA0D243277949363056B221MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 2nd WGL= C on these drafts has concluded, and we did get enough reviews this time, s= o there should be no need for a 3rd WGLC.

 

Many thanks to those w= ho took the time to review and comment.  Bob (primary author) is worki= ng on addressing the comments.

 

Thanks, --David

 

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Black, David
Sent: Wednesday, April 17, 2019 2:51 PM
To: tsvwg@ietf.org
Subject: [tsvwg] 2nd WGLC on ecn-encap-guidelines and rfc6040-update= -shim drafts, closes 6 May 2019

 

[EXTERNAL EMAIL]

This email announces a 2nd TSVWG Working Group La= st Call (WGLC) on two drafts:

 

[1] Guidelines for Adding Congestion Notification= to Protocols that

        &= nbsp;           &nbs= p;        Encapsulate IP

        &= nbsp;       draft-ietf-tsvwg-ecn-encap-guidel= ines-12

https://datatracker.ietf.org/doc/draft-i= etf-tsvwg-ecn-encap-guidelines/

This draft is intended to become a Best Current P= ractice RFC

 

[2] Propagating Explicit Congestion Notification = Across IP Tunnel Headers

        &= nbsp;           &nbs= p;     Separated by a Shim

        &= nbsp;        draft-ietf-tsvwg-rfc6040upd= ate-shim-08

https://datatracker.ietf.org/doc/draft-iet= f-tsvwg-rfc6040update-shim/

This draft is intended to become a Proposed Stand= ard RFC.

 

This WGLC will run through the end of the day on = Monday, May 6, 2019.

 

Comments should be sent to the tsvwg@ietf.org list, although purely

editorial comments may be sent directly to the au= thor. Please cc: the

WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to

track such editorial comments as part of the WGLC= process.

 

No IPR disclosures have been submitted directly o= n either draft

 

Thanks,

David, Gorry and Wes

(TSVWG Co-Chairs)

 

--_000_CE03DB3D7B45C245BCA0D243277949363056B221MX307CL04corpem_-- From nobody Thu May 16 14:14:37 2019 Return-Path: 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 42247120307; Thu, 16 May 2019 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 kvpqs71ccDTP; Thu, 16 May 2019 14:14:33 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 A60031200E9; Thu, 16 May 2019 14:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XCYOy9myuV6Dx0jaIvVeo8bx4r0PtA8pL82OC/6aTm8=; b=xR/AFY0nxXJSv5tH/sby7pLmE GICw0ga2LQhVAs8Uo/qg++TNMxDXvpv+JI8fDX3B5lVb3H9v0+TrRNmT2bXWfhJ7s7gmg+jmTJVC3 BIqHgxiDJ5qROL3iVSDzLAlmN/twrESf7XaGQ3CJNLRe+kgsOLKwVPrzNByInGMaEMSf/erowt+d1 NpGZTTtAsMOtoK8o77t6MfRWZpxSbb0QjPGB/LOobKxB07E6RKL1jPIbU34HnZ+KRyV6rcXmxXeKN jVhjaq6060s2PEyv3dIL7RVekMrjc3AiygvzT9hK6NFv4l3Nkq2OFLGwStNYNIizOiAtep+oeWQ1X lLyESXWng==; Received: from [31.185.135.221] (port=46460 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hRNhs-0004C7-SE; Thu, 16 May 2019 22:14:29 +0100 To: Joe Touch , "Black, David" Cc: "int-area@ietf.org" , tsvwg References: <598B8434-3B6D-434A-B963-7FEE04D9770B@strayalpha.com> From: Bob Briscoe Message-ID: <70abde72-0091-66e3-b819-ad839e1fd028@bobbriscoe.net> Date: Thu, 16 May 2019 22:14:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <598B8434-3B6D-434A-B963-7FEE04D9770B@strayalpha.com> Content-Type: multipart/alternative; boundary="------------F00B54A6BBF21732F4DDBF97" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 21:14:36 -0000 This is a multi-part message in MIME format. --------------F00B54A6BBF21732F4DDBF97 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Joe, Sorry I missed this posting at the time (my mail filters moved both cross-postings into my int-area box which I check only rarely). On 27/04/2019 18:13, Joe Touch wrote: > Cross-posting to let both communities know: > > - it would be useful for these documents to address how fragmentation > and reassembly affects these signals > (esp. if reassembling fragments with different ECN values) > [BB] This is addressed by the re-framing section in ecn-encap-guidelines, altho it doesn't give examples of what might have caused frame boundary misalignment, so fragmentation is not specifically mentioned. I think I will add an explicit mention of fragmentation (if only so a search finds that section). Actually I've realized that this highlights an inconsistency between the advice on ECN and fragment reassembly in RFC3168 and in ecn-encap-guidelines.: * RFC3168 requires that the ECN marking of a reassembled packet is the logical OR of the ECN marks on the fragments, * whereas ecn-encap-guidelines recommends marking the same number of outgoing as incoming octets when reassembling L2 frames or tunnelled packets with different boundaries - using a simple counter to track the balance. In fact, it was the review of RFC3168 by me and Jon Crowcroft back in 2001 that originally raised the question of how to handle reassembly of ECN-marked fragments . I'll quote a passage from the review, which I think justifies the recommendation in ecn-encap-guidelines to count marked bytes, rather than use the logical OR of RFC3168: To use the logical OR of the marking of all fragments might be a pragmatic solution, particularly for congestion control protocols like TCP where one loss per round trip is treated identically to many. However, it is becoming more common to see large numbers of packets per round trip time as data rates increase while packet sizes and the speed of light haven't increased for many years. Therefore it is to be expected that newer congestion control protocols might take more accurate account of the number of packets marked in a round trip. Hence, the inaccuracy of a logical OR during re-assembly at the IP layer is best avoided. I'm not too worried about the inaccuracy of using a logical OR, but I think it best to recommend more accurate and no less costly counting. The only justification for the logical OR was that TCP only reacted to one ECN mark per RTT. But that is changing now, and the behaviour of one transport should not be embedded in lower layers anyway. > - it would be useful for these documents to consider > draft-ietf-intarea-tunnels (which relates to the above) and its > discussion on many of the protocols cited I can't find anything in draft-ietf-intarea-tunnels that ought to be cited from ecn-encap-guidelines or rfc6040-update-shim. Did you have something specific in mind? I do want to raise a question about the following sentence, which precedes the mention of ECN: There are exceptions to this rule that are explicitly intended to relay signals from inside the tunnel to the network outside the tunnel, typically relevant only when the tunnel network N and the outer network M use the same network. Was that last word meant to say "network protocol"? Then, if that is what you meant, I would disagree. Many different network protocols include concepts similar to Diffserv and/or ECN (e.g. IEEE802.1p, MPLS and TRILL support both, etc), and there's rarely a reason /not/ to propagate the concept between different network protocols when they encapsulate each other, even tho it's not always straightforward to do so. Bob Bob > > Joe > >> On Apr 26, 2019, at 1:50 PM, Black, David > > wrote: >> >> This may be of interest to INT folks who are interested in tunnels >> and encapsulations. >> Comments by the WGLC deadline are encouraged, but comments after the >> deadline are ok, as they’d have to be dealt with anyway at IETF Last >> Call. >> Thanks, --David >> *From:*tsvwg > >*On Behalf Of*Black, David >> *Sent:*Wednesday, April 17, 2019 2:51 PM >> *To:*tsvwg@ietf.org >> *Subject:*[tsvwg] 2nd WGLC on ecn-encap-guidelines and >> rfc6040-update-shim drafts, closes 6 May 2019 >> >> [EXTERNAL EMAIL] >> >> This email announces a 2nd TSVWG Working Group Last Call (WGLC) on >> two drafts: >> [1] Guidelines for Adding Congestion Notification to Protocols that >> Encapsulate IP >> draft-ietf-tsvwg-ecn-encap-guidelines-12 >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ >> This draft is intended to become a Best Current Practice RFC >> [2] Propagating Explicit Congestion Notification Across IP Tunnel Headers >> Separated by a Shim >> draft-ietf-tsvwg-rfc6040update-shim-08 >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ >> This draft is intended to become a Proposed Standard RFC. >> This WGLC will run through the end of the day on Monday, May 6, 2019. >> Comments should be sent to thetsvwg@ietf.org >> list, although purely >> editorial comments may be sent directly to the author. Please cc: the >> WG chairs attsvwg-chairs@ietf.org if >> you would like the chairs to >> track such editorial comments as part of the WGLC process. >> No IPR disclosures have been submitted directly on either draft >> Thanks, >> David, Gorry and Wes >> (TSVWG Co-Chairs) >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------F00B54A6BBF21732F4DDBF97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Joe,

Sorry I missed this posting at the time (my mail filters moved both cross-postings into my int-area box which I check only rarely).


On 27/04/2019 18:13, Joe Touch wrote:
Cross-posting to let both communities know:

- it would be useful for these documents to address how fragmentation and reassembly affects these signals
(esp. if reassembling fragments with different ECN values)

[BB] This is addressed by the re-framing section in ecn-encap-guidelines, altho it doesn't give examples of what might have caused frame boundary misalignment, so fragmentation is not specifically mentioned. I think I will add an explicit mention of fragmentation (if only so a search finds that section).

Actually I've realized that this highlights an inconsistency between the advice on ECN and fragment reassembly in RFC3168 and in ecn-encap-guidelines.:
  • RFC3168 requires that the ECN marking of a reassembled packet is the logical OR of the ECN marks on the fragments,
  • whereas ecn-encap-guidelines recommends marking the same number of outgoing as incoming octets when reassembling L2 frames or tunnelled packets with different boundaries - using a simple counter to track the balance.
In fact, it was the review of RFC3168 by me and Jon Crowcroft back in 2001 that originally raised the question of how to handle reassembly of ECN-marked fragments. I'll quote a passage from the review, which I think justifies the recommendation in ecn-encap-guidelines to count marked bytes, rather than use the logical OR of RFC3168:

To use the logical OR of the marking of all fragments might be a pragmatic
solution, particularly for congestion control protocols like TCP where one
loss per round trip is treated identically to many. However, it is becoming
more common to see large numbers of packets per round trip time as data
rates increase while packet sizes and the speed of light haven't increased
for many years. Therefore it is to be expected that newer congestion
control protocols might take more accurate account of the number of packets
marked in a round trip. Hence, the inaccuracy of a logical OR during
re-assembly at the IP layer is best avoided.
I'm not too worried about the inaccuracy of using a logical OR, but I think it best to recommend more accurate and no less costly counting. The only justification for the logical OR was that TCP only reacted to one ECN mark per RTT. But that is changing now, and the behaviour of one transport should not be embedded in lower layers anyway.

- it would be useful for these documents to consider draft-ietf-intarea-tunnels (which relates to the above) and its discussion on many of the protocols cited
I can't find anything in draft-ietf-intarea-tunnels that ought to be cited from ecn-encap-guidelines or rfc6040-update-shim. Did you have something specific in mind?

I do want to raise a question about the following sentence, which precedes the mention of ECN:
   There are exceptions to this rule that are explicitly intended to
   relay signals from inside the tunnel to the network outside the
   tunnel, typically relevant only when the tunnel network N and the
   outer network M use the same network.
Was that last word meant to say "network protocol"?

Then, if that is what you meant, I would disagree. Many different network protocols include concepts similar to Diffserv and/or ECN (e.g. IEEE802.1p, MPLS and TRILL support both, etc), and there's rarely a reason /not/ to propagate the concept between different network protocols when they encapsulate each other, even tho it's not always straightforward to do so.



Bob


Bob

Joe

On Apr 26, 2019, at 1:50 PM, Black, David <David.Black@dell.com> wrote:

This may be of interest to INT folks who are interested in tunnels and encapsulations.
 
Comments by the WGLC deadline are encouraged, but comments after the deadline are ok, as they’d have to be dealt with anyway at IETF Last Call.
 
Thanks, --David
 
From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Black, David
Sent: Wednesday, April 17, 2019 2:51 PM
To: tsvwg@ietf.org
Subject: [tsvwg] 2nd WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019
 

[EXTERNAL EMAIL] 

This email announces a 2nd TSVWG Working Group Last Call (WGLC) on two drafts:
 
[1] Guidelines for Adding Congestion Notification to Protocols that
                             Encapsulate IP
                draft-ietf-tsvwg-ecn-encap-guidelines-12
This draft is intended to become a Best Current Practice RFC
 
[2] Propagating Explicit Congestion Notification Across IP Tunnel Headers
                          Separated by a Shim
                 draft-ietf-tsvwg-rfc6040update-shim-08
This draft is intended to become a Proposed Standard RFC.
 
This WGLC will run through the end of the day on Monday, May 6, 2019.
 
Comments should be sent to the tsvwg@ietf.org list, although purely
editorial comments may be sent directly to the author. Please cc: the
WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to
track such editorial comments as part of the WGLC process.
 
No IPR disclosures have been submitted directly on either draft
 
Thanks,
David, Gorry and Wes
(TSVWG Co-Chairs)
 
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------F00B54A6BBF21732F4DDBF97-- From nobody Thu May 16 15:18:11 2019 Return-Path: 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 200D0120106 for ; Thu, 16 May 2019 15:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 IfYv3qraiK3l for ; Thu, 16 May 2019 15:18:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 DA9D5120324 for ; Thu, 16 May 2019 15:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pQo9QV4rCG/+Vw6ntgP+dz/XSYmvkoAQZKWrVZbCDSE=; b=eSyWTIiOf4NwyOYn7IHEKaX71 NqeOWS7uLRNqQws6OVJjo/TRsDNCnAryzuWZczqcQd2xl5300JCTvAsmk6g28SkZc3ojuwv6XIr3+ OKhySdOETddGdQyCQCg43Fi+R1mQG6zCQ7Tr3zCowFVIL1ae85Rzih+dc/od7I20yoY4TUYVG5/Id v/8u53r34C4UOKgfeD3JqcPfYPeuTaBEyVfXe8o4iCnslYWXJQ2nFIddc6hes9SO+osX4aLtebTHe wsD2NPtY3B8o7fjMy3AV3ZgfjA/11XG2wEAHMC/dZqLS3SR6Uzs4KnxMsK6IEybW8mcctJ5mT4UPE cjqSQldkQ==; Received: from [31.185.135.221] (port=46492 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hROhL-0001uE-Vy; Thu, 16 May 2019 23:18:01 +0100 To: "Black, David" , "tsvwg@ietf.org" References: <247a9990-30c0-b0ea-5e3d-2a0b2ae57a95@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Thu, 16 May 2019 23:17:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5744AE65074B51DCA0155339" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 22:18:10 -0000 This is a multi-part message in MIME format. --------------5744AE65074B51DCA0155339 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit David, See inline. No response means accepted... On 16/05/2019 18:13, Black, David wrote: > > Bob, > > Thanks for the comprehensive response, most of which I agree with. > Please also take note of Joe Touchs comments on fragmentation and the > relationship to draft-intarea-tunnels. > > I have a few more comments anything that isnt mentioned here is > fine with me. > > i) > > > Expanded sentence at the end of Intro to: > > "This document updates and completely replaces the brief paragraph > of advice to subnetwork designers about ECN in Section 13 of [RFC3819] > (BCP 89)." > > Thatll suffice for now I still expect to get dinged on this by an > AD during IESG evaluation, but we can wait until then to determine > what else is required. > > ii) > > > [D] Page 5, first complete paragraph > > [ snip ] > > > Done; added: > > "Similarly, if the DSCP is wiped at the boundary between Diffserv > domains, the special ECN semantics would also be lost." > > wiped -> changed (e.g., zeroed) > > iii) > > > ECN-PDU: A PDU that is part of a feedback loop within which all the > > > nodes that need to propagate *the*explicit congestion notification > > > *signal in the PDU*back to the Load Regulator are ECN-capable *of > doing so*. > > I think this improved definition needs an additional hair-splitting > clarification: > > A PDU that is -> A PDU whose congestion indication (if any) is > > The rationale for this clarification is to exclude signals back to the > Load Regulator, e.g., TCP ECE. > [BB] OK. Actually, rather than trying to be subtle, I'm going to just say this much more straightforwardly: ECN-PDU: A PDU at the IP layer or below carrying an explicit congestion notification signal that is part of a feedback loop within which all the nodes that need to propagate the signal back to the Load Regulator are capable of doing so. I've also used 'signal' rather than 'indication' so that '(if any)' is not needed (because indication implies the positive aspect of the signal, whereas signal implies both congestion indication and non-indication). > > I've also extended the above correction into the next definition: > > > Not-ECN-PDU: A PDU that is part of a feedback-loop within which some *at least one* > > node necessary to propagate *the* explicit congestion notification*signal in the PDU * > > back to the load regulator are *is* notECN-capable*of doing so*. > > And apply the same change to this definition also. > [BB] That's not possible 'cos, by definition, an ECN-PDU doesn't have a congestion indication, so we can't use that trick to exclude feedback packets. I'll just resort to adding "...at the IP layer or below..." here too: Not-ECN-PDU: A PDU at the IP layer or below that is part of a feedback-loop within which at least one node necessary to propagate any explicit congestion notification signals back to the Load Regulator is not capable of doing so. Bob > Thanks, --David > > *From:*Bob Briscoe > *Sent:* Wednesday, May 15, 2019 7:28 PM > *To:* Black, David; tsvwg@ietf.org > *Cc:* John Kaippallimalil > *Subject:* Re: [tsvwg] David Black's WGLC review of > draft-ietf-tsvwg-ecn-encap-guidelines-12 > > [EXTERNAL EMAIL] > > David, > > I've addressed all your points inline (and RS's and AMcG's points in > recent emails). > > I've edited my local copy of the draft as I describe. I'll submit it > in a few hours time. I'm off to bed now, and in the morning I just > want to double-check I haven't missed anyone's comments before posting > it. That might also allow you, my co-author or anyone else enough time > to come back on any of my responses below before I post... > > On 09/05/2019 01:10, Black, David wrote: > > First of all, this is a well-written and comprehensive draft on > ECN encapsulation design guidelines. > > I found no major issues, and all of the minor issues are truly > minor some border on editorial, > > and all can be dealt with via relatively minor edits.. > > --- Minor --- > > [A] Need an explicit statement of exactly what the update to RFC > 3819 is, > > preferably in a section whose name uses "RFC 3819" and appears in the > > table of contents. Do this before some AD tells you to ;-). This is > > also the only thing that idnits found that needs attention. > > > RFC 3819 contained a paragraph of brief musings on how subnetworks > might handle ECN. So ecn-encap completely replaces that para with a > whole document. I hope the new text quoted below is sufficient to > explain that there is no specific section that updates RFC 3819. > Rather the whole document does: > > Copied sentence below from end of intro to abstract: > "This document updates the advice to subnetwork designers about ECN in > RFC 3819." > > Expanded sentence at the end of Intro to: > "This document updates and completely replaces the brief paragraph of > advice to subnetwork designers about ECN in Section 13 of [RFC3819] > (BCP 89)." > > > [B] 1. Introduction, first paragraph, last sentence > > The phrase "egress at any layer" is too general, hence incorrect > (e.g., > > layer 7 was not intended to be included) - "lower layer" needs to be > > used for clarity. > > OLD > > If an egress at any layer is not ECN-aware, or if the > > ultimate receiver or sender is not ECN-aware, congestion needs > to be > > indicated by dropping a packet, not marking it. > > NEW > > If a lower layer header that may contain ECN congestion > indications is > > removed by an egress that is not ECN-aware, or if the ultimate > receiver or > > sender is not ECN-aware, then lower layer congestion needs to > be indicated > > by dropping a packet, not marking it. > > END > > Thx. Used verbatim (except s/an egress/a subnet egress/). > > > [C] 1.1 Scope > > Second paragraph and the two-bullet list imply that RFC 4774 > states that use > > of ECT(1) to signal alternative ECN semantics is a best current > practice. > > That's not correct, as RFC 4774 covers only the first bullet on > use of DSCP, > > not the second bullet on use of ECT(1), as that second bullet is > based solely > > on RFC 8311. Some rewriting is in order to disconnect the second > bullet from > > RFC 4774. > > Done: > "There are two main examples for how alternative ECN semantics have > been defined in practice: > o RFC 4774 suggests... > o RFC 8311 suggests..." > > > Based on this, all other places where RFC 4774 is mentioned or > cited should > > be checked to determine whether RFC 8311 also ought to be > mentioned or cited. > > Done. > > The one other occurrence of RFC4774 says: > "The guidelines are also designed to ensure compliance with the > more general best current practice for the design of alternate ECN > schemes given in [RFC4774]..." > > Added: "...and extended by [RFC8311]" > > > > [D] Page 5, first complete paragraph > > Alternative semantics for the ECN field can be defined to depend on > > the traffic class indicated by the DSCP. Therefore correct > > propagation of congestion signals could depend on correct propagation > > of the DSCP between the layers. > > This also depends on correct propagation across diffserv > boundaries - that > > and the potential damage wrought by bleaching DSCPs to zero at > such boundaries > > both deserve mention here. > > Done; added: > "Similarly, if the DSCP is wiped at the boundary between Diffserv > domains, the special ECN semantics would also be lost." > > > > [E] 1.1 Scope, end of section > > In the feed-backward mode, propagation of > > congestion signals for multicast and anycast packets is out-of-scope > > (because it would be so complicated that it is hoped no-one would > > attempt such an abomination). > > Much as I may agree with it :-), the parenthetical remark is > inappropriate > > for an archival RFC, and hence needs to be removed. > > When doing transport area reviews, I have criticised other authors for > just ruling stuff out of scope without justification or explanation of > the implications. So rather than delete, I've toned this down: > > "... (because the complexity would make it unlikely to be attempted)." > > BTW, for archival documents IMO light-heartedness is no less > appropriate than unrelenting blandness. > > > [F] 2. Terminology > > > > ECN-PDU: A PDU that is part of a feedback loop within which all the > > nodes that need to propagate explicit congestion notifications > > back to the Load Regulator are ECN-capable. > > That first sentence is too broad as it includes both the forward and > > reverse directions of the feedback loop, whereas only the forward > direction is intended (FWIW, the definition of PDU does not suffice to > > narrow this to the forward direction only). For example, a TCP packet > > with the ECE flag set in the TCP header and Not-ECT in the ECN > field in > > the IP header would be an ECN-PDU under this definition, which is not > > what was intended. The immediately following definition of > Not-ECN-PDU > > has the same problem. > > The point of building on the OSI term 'PDU' was because a PDU is > defined by the layer that is stated as relevant. By the OSI > definition, a PDU at a certain layer does not include lower layer > headers that encapsulate it. > > So, in the example you give of a TCP packet with ECE set, that is a > TCP PDU. By OSI definition, a TCP PDU does not include the IP header > that encapsulates it. The IP header is only relevant when considering > it as an IP PDU. And then the TCP PDU within it is just payload (the > SDU that was passed to IP) and not part of the protocol of the IP PDU. > > > The narrowing concept that needs to be added is that if the PDU > carries > > a congestion indication, then that congestion indication > participates in > > such a feedback loop, > > Yes, valid point. Thank you. > > ECN-PDU: A PDU that is part of a feedback loop within which all the > > nodes that need to propagate *the*explicit congestion notification > > *signal in the PDU*back to the Load Regulator are ECN-capable *of > doing so*. > > > > and even that is subtle when there are multiple > > possible congestion indication locations. An example of the > subtlety is > > that the same PDU may be an ECN-PDU in feed-up-and-forward mode > because > > the layer 3 and 4 protocols support ECN but may be a Not-ECN-PDU for > > feed-forward-and-up mode because the L2 decapsulator ignores and > discards > > L2 congestion indications. > > I think the bold words in the phrase "nodes that *need to* propagate" > deals with that subtlety. > > In your example, if the subnet is propagating the PDU's ECN signal in > feed-up-and-forward mode and the L2 decapsulator doesn't propagate > ECN, it's not relevant because it also doesn't *need to* propagate > ECN. Whereas, if the subnet propagates ECN in feed-forward-and-up > mode, the decap does *need to*. > > I've also extended the above correction into the next definition: > > Not-ECN-PDU: A PDU that is part of a feedback-loop within whichsome *at least one* > node necessary to propagate*the* explicit congestion notification*signal in the PDU * > back to the load regulatorare *is* notECN-capable*of doing so*. > > > > [G] 2. Terminology > > Congestion Baseline: The location of the function on the path that > > initialised the values of all congestion notification fields in a > > sequence of packets, before any are set to the congestion > > experienced (CE) codepoint if they experience congestion further > > downstream. Typically the original data source at layer-4. > > > That's counter-intuitive - a baseline is a level, not a location. I've > > tagged this as a minor issue as opposed to editorial because it causes > > severe confusion in the only place that this term is used, namely > item 3 > > in Section 4.3. That item 3 is about a Monitoring Baseline which is > > a level not a location. > > The Congestion Baseline term should be removed, and item 3 in Section > > 4.3 revised accordingly. The term "Congestion Baseline" is used twice > > there, but only the latter of those two uses needs to be retained and > > expanded after deletion of this definition. > > You're right. I've done as you suggest. > > I've also nearly completely re-written the second half of the section, > because I had temporarily forgotten the rationale, and even I couldn't > understand what the rationale was after reading my own words. > > > [H] 3. Modes of Operation > > Feed-Up-and-Forward: A lower layer switch feeds-up congestion > > notification directly into the ECN field in the higher layer > > (e.g. IP) header, irrespective of whether the node is at the > > egress of a subnet. > > Remove "the ECN field in" as that's too restrictive, even though > that's > > a common case, and move it into the example (e.g., ECN field in the > > IP header)" where "header" moved inside the parentheses. > > Done. > > > > [I] 3.3. Feed-Backward Mode > > Please make it clear that the critique of the ATM ABR relative rate > > control mechanism also applies to Ethernet QCN, as that's a more > > current example. This should be connected to the QCN discussion at > > the end of Section 4.2. > > I didn't want to imply any criticism of QCN, which always made it > clear it was only applicable to a single subnet. > > However, I can now see the need to have this written down, given > certain companies are giving incentives to churn out Frankenpatents > (any random combination of existing ideas, no matter whether useful or > correct). So I've kept ATM as the example, but added at the end: > > QCN [IEEE802.1Qau] would suffer from similar problems if extended to > multiple subnets. However, from the start QCN was clearly stated as > solely applicable to a single subnet (see Section 6). > > > > [J] 4.3 Encapsulation Guidelines > > Resolving minor issue [G] requires some edits to item 3 in this > section: > > - Remove "(the Congestion Baseline)" from the third paragraph. > > - Rewrite start of fourth paragraph: > > OLD > > Most information can be extracted if the Congestion Baseline is > > standardised at the node that is regulating the load (the Load > > Regulator--typically the data source). > > NEW > > More information can be extracted if the protocol specification > > requires that congestion fields be initialized to indicate no > > congestion only by the node that is regulating the load (the > > Load Regulator--typically the data source). > > END > > See minor issue [G] above - already completely rewritten this text. > > > > [K] 12.2 Informative References > > Please check the references to 802.1Qah and 802.1Qau with IEEE. The > > correct references to use now may be the latest version of 802.1Q with > > specific functionality and/or clauses identified. > > Done. > 802.1Qau -> 802.1Q Sections 30--33 > 802.1ah -> 802.1Q (as a whole - too scattered to call out particular > sections). > > Pat Thaler having retired, I no longer have a co-author who can advise > on IEEE citation correctness. > But the above is good enough. > > [I knew someone would point that out - I should have dealt with it > but, even tho I purportedly have free access to the full rolled-up > text of the current standard (IEEE802.1Q-2018), I've always had > trouble viewing it. The IEEE pay-wall insists on displaying the free > copy in my browser in a way that it can't be downloaded, but in > Firefox the activity bar spins but nothing ever appears. After much > gnashing of teeth, I discovered it works OK in Chrome.] > > > --- Editorial/Nits --- > > Abstract, last sentence > > Following these guidelines should assure > > interworking between new lower layer congestion notification > > mechanisms, whether specified by the IETF or other standards bodies. > > between new -> among IP layer and > > Yup. > > 1. Introduction, first paragraph > > Suggest removing use of the word "buffer" - "lower layer" suffices in > > all of the places where this word is used in this paragraph. > > Not as simple as that. I've guessed that the idea of a buffer doing > marking jars with you, so I've addressed the two occurrences of > 'buffer' as follows: > > 1. When a lower layer buffer drops a packet > > This was intended to introduce the context as congestion loss, not > transmission loss. So left unchanged. > > 2. In > contrast, when a lower layer marks a packet with ECN, the marking > needs to be explicitly propagated up the layers. The same is true if > a buffer marks the outer header of a packet that encapsulates inner > tunnelled headers. > > The second sentence is about tunnels, not lower layers. > So, I've introduced AQM into both sentences: > > In > contrast, when active queue management (AQM) at a lower layer marks a > packet with ECN, the marking needs to be explicitly propagated up the > layers. The same is true if AQM marks the outer header of a packet > that encapsulates inner tunnelled headers. > > > > 1. Introduction, second paragraph > > The purpose of this document is to guide the addition of congestion > > notification to any subnet technology or tunnelling protocol, so that > > lower layer equipment can signal congestion explicitly and it will > > propagate consistently into encapsulated (higher layer) headers, > > otherwise the signals will not reach their ultimate destination. > > Suggest: "equipment" -> "functionality" > > Sorry, the word 'functionality' gets to me like finger-nails on a > blackboard. > https://www.dailywritingtips.com/is-that-even-a-word/ > > I've used s/equipment/AQM algorithms/ > > > > Page 5, first full paragraph: > > If a particular protocol design chooses to contradict a > > 'SHOULD (NOT)' given in the advice below, it MUST include a sound > > justification. > > chooses to contradict -> chooses not to follow > > Yup > > 1.1. Scope, first paragraph > > This document only concerns wire protocol processing of explicit > > notification of congestion. > > Remove "wire" > > I think that loses the intended sense in too much ambiguity. > 'Protocol processing' could include the AQM algorithms, which this > sentence is trying to exclude. > > > Section 3.1, second paragraph > > In these cases, ECN may best be supported by standardising explicit > > notification of congestion into the lower layer protocol that carries > > the data forwards. It will then also be necessary to define > how the > > egress of the lower layer subnet propagates this explicit > signal into > > the forwarded upper layer (IP) header. It can then continue > forwards > > until it finally reaches the destination transport (at L4). Then > > typically the destination will feed this congestion > notification back > > to the source transport using an end-to-end protocol (e.g. TCP). > > This is the arrangement that has already been used to add ECN > to IP- > > in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129]. > > The referents of "It" at the start of the second and third > sentences are > > unclear and different. Suggested rephrasings: > > It will then also be necessary to define -> > > This necessitates also specifying > > It can then continue -> This signal continues > > Good. > > Section 3.1, first paragraph after Figure 1 > > Cite one or more of the 3GPP references for GTP tunnels, as this > is the > > first occurrence of that concept in this draft. > > Yup > > Section 3.1, second paragraph after Figure 1 > > Cite a Frame Relay reference for the FECN bit.. Moving the [Buck00] > > citation up to immediately follow "Frame Relay" in the first line > suffices. > > Good. > > Section 3.2 first paragraph > > These are Ethernet switches that bury into the Ethernet payload ... > > bury -> burrow > > [Spelling checker is missing read users mind feature :-)] > > I've used dig. > > Hard to read user's mind. Easier to tell user what to think ;) > > > Section 3.4 > > The second paragraph could be improved by citing references for > fat-tree > > and Clos network topologies. > > Done. > > > Section 4.1, second paragraph > > Therefore section 4 of > > [I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to > > configure the ingress of a non-ECN tunnel so that it zeros the ECN > > field in the outer IP header. > > non-ECN tunnel -> tunnel that does not support ECN > > OK > > Section 4.1, third paragraph > > Even > > if the shim(s) encapsulate a L2 header, it is often possible to > find > > an inner IP header within the L2 header > > Latter instance of "L2 header" should be "L2 PDU" > > Good. > > Section 4.1, last paragraph > > Instead a companion specification > > [I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has > > sufficient standards track status to update standards track > > protocols. > > > sufficient -> the appropriate > > Done. > > Authors Addresses > > Please check these - Pat Thaler's contact info probably needs to > be updated. > > In progress. > > > > Bob > > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Senior Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA 01748 > > +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------5744AE65074B51DCA0155339 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit David,

See inline. No response means accepted...

On 16/05/2019 18:13, Black, David wrote:

Bob,

Thanks for the comprehensive response, most of which I agree with. Please also take note of Joe Touchs comments on fragmentation and the relationship to draft-intarea-tunnels.

I have a few more comments anything that isnt mentioned here is fine with me.

i)

> Expanded sentence at the end of Intro to:
> "This document updates and completely replaces the brief paragraph of advice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89)."

Thatll suffice for now I still expect to get dinged on this by an AD during IESG evaluation, but we can wait until then to determine what else is required.

ii)

> [D] Page 5, first complete paragraph

[ snip ]

> Done; added:
> "Similarly, if the DSCP is wiped at the boundary between Diffserv domains, the special ECN semantics would also be lost."

wiped -> changed (e.g., zeroed)

iii)

> ECN-PDU: A PDU that is part of a feedback loop within which all the

> nodes that need to propagate the explicit congestion notification

> signal in the PDU back to the Load Regulator are ECN-capable of doing so.

I think this improved definition needs an additional hair-splitting clarification:

A PDU that is -> A PDU whose congestion indication (if any) is

The rationale for this clarification is to exclude signals back to the Load Regulator, e.g., TCP ECE.

[BB] OK. Actually, rather than trying to be subtle, I'm going to just say this much more straightforwardly:

ECN-PDU: A PDU at the IP layer or below carrying an explicit congestion notification signal that is part of a feedback loop within which all the nodes that need to propagate the signal back to the Load Regulator are capable of doing so.

I've also used 'signal' rather than 'indication' so that '(if any)' is not needed (because indication implies the positive aspect of the signal, whereas signal implies both congestion indication and non-indication).

> I've also extended the above correction into the next definition:

> Not-ECN-PDU: A PDU that is part of a feedback-loop within which some at least one
> node necessary to propagate the explicit congestion notification signal in the PDU 
> back to the load regulator are is not ECN-capable of doing so.

And apply the same change to this definition also.

[BB] That's not possible 'cos, by definition, an ECN-PDU doesn't have a congestion indication, so we can't use that trick to exclude feedback packets. I'll just resort to adding "...at the IP layer or below..." here too:

Not-ECN-PDU: A PDU at the IP layer or below that is part of a feedback-loop within which at least one node necessary to propagate any explicit congestion notification signals back to the Load Regulator is not capable of doing so.


Bob

Thanks, --David

From: Bob Briscoe <ietf@bobbriscoe.net>
Sent: Wednesday, May 15, 2019 7:28 PM
To: Black, David; tsvwg@ietf.org
Cc: John Kaippallimalil
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12

[EXTERNAL EMAIL]

David,

I've addressed all your points inline (and RS's and AMcG's points in recent emails).

I've edited my local copy of the draft as I describe. I'll submit it in a few hours time. I'm off to bed now, and in the morning I just want to double-check I haven't missed anyone's comments before posting it. That might also allow you, my co-author or anyone else enough time to come back on any of my responses below before I post...

On 09/05/2019 01:10, Black, David wrote:

First of all, this is a well-written and comprehensive draft on ECN encapsulation design guidelines.

I found no major issues, and all of the minor issues are truly minor some border on editorial,

and all can be dealt with via relatively minor edits..

--- Minor ---

[A] Need an explicit statement of exactly what the update to RFC 3819 is,

preferably in a section whose name uses "RFC 3819" and appears in the

table of contents. Do this before some AD tells you to ;-). This is

also the only thing that idnits found that needs attention.


RFC 3819 contained a paragraph of brief musings on how subnetworks might handle ECN. So ecn-encap completely replaces that para with a whole document. I hope the new text quoted below is sufficient to explain that there is no specific section that updates RFC 3819. Rather the whole document does:

Copied sentence below from end of intro to abstract:
"This document updates the advice to subnetwork designers about ECN in RFC 3819."

Expanded sentence at the end of Intro to:
"This document updates and completely replaces the brief paragraph of advice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89)."


[B] 1. Introduction, first paragraph, last sentence

The phrase "egress at any layer" is too general, hence incorrect (e.g.,

layer 7 was not intended to be included) - "lower layer" needs to be

used for clarity.

OLD

If an egress at any layer is not ECN-aware, or if the

ultimate receiver or sender is not ECN-aware, congestion needs to be

indicated by dropping a packet, not marking it.

NEW

If a lower layer header that may contain ECN congestion indications is

removed by an egress that is not ECN-aware, or if the ultimate receiver or

sender is not ECN-aware, then lower layer congestion needs to be indicated

by dropping a packet, not marking it.

END

Thx. Used verbatim (except s/an egress/a subnet egress/).


[C] 1.1 Scope

Second paragraph and the two-bullet list imply that RFC 4774 states that use

of ECT(1) to signal alternative ECN semantics is a best current practice.

That's not correct, as RFC 4774 covers only the first bullet on use of DSCP,

not the second bullet on use of ECT(1), as that second bullet is based solely

on RFC 8311. Some rewriting is in order to disconnect the second bullet from

RFC 4774.

Done:
"There are two main examples for how alternative ECN semantics have been defined in practice:
o RFC 4774 suggests...
o RFC 8311 suggests..."


Based on this, all other places where RFC 4774 is mentioned or cited should

be checked to determine whether RFC 8311 also ought to be mentioned or cited.

Done.

The one other occurrence of RFC4774 says:
"The guidelines are also designed to ensure compliance with the more general best current practice for the design of alternate ECN schemes given in [RFC4774]..."

Added: "...and extended by [RFC8311]"



[D] Page 5, first complete paragraph

Alternative semantics for the ECN field can be defined to depend on

the traffic class indicated by the DSCP. Therefore correct

propagation of congestion signals could depend on correct propagation

of the DSCP between the layers.

This also depends on correct propagation across diffserv boundaries - that

and the potential damage wrought by bleaching DSCPs to zero at such boundaries

both deserve mention here.

Done; added:
"Similarly, if the DSCP is wiped at the boundary between Diffserv domains, the special ECN semantics would also be lost."



[E] 1.1 Scope, end of section

In the feed-backward mode, propagation of

congestion signals for multicast and anycast packets is out-of-scope

(because it would be so complicated that it is hoped no-one would

attempt such an abomination).

Much as I may agree with it :-), the parenthetical remark is inappropriate

for an archival RFC, and hence needs to be removed.

When doing transport area reviews, I have criticised other authors for just ruling stuff out of scope without justification or explanation of the implications. So rather than delete, I've toned this down:

"... (because the complexity would make it unlikely to be attempted)."

BTW, for archival documents IMO light-heartedness is no less appropriate than unrelenting blandness.


[F] 2. Terminology



ECN-PDU: A PDU that is part of a feedback loop within which all the

nodes that need to propagate explicit congestion notifications

back to the Load Regulator are ECN-capable.

That first sentence is too broad as it includes both the forward and

reverse directions of the feedback loop, whereas only the forward
direction is intended (FWIW, the definition of PDU does not suffice to

narrow this to the forward direction only). For example, a TCP packet

with the ECE flag set in the TCP header and Not-ECT in the ECN field in

the IP header would be an ECN-PDU under this definition, which is not

what was intended. The immediately following definition of Not-ECN-PDU

has the same problem.

The point of building on the OSI term 'PDU' was because a PDU is defined by the layer that is stated as relevant. By the OSI definition, a PDU at a certain layer does not include lower layer headers that encapsulate it.

So, in the example you give of a TCP packet with ECE set, that is a TCP PDU. By OSI definition, a TCP PDU does not include the IP header that encapsulates it. The IP header is only relevant when considering it as an IP PDU. And then the TCP PDU within it is just payload (the SDU that was passed to IP) and not part of the protocol of the IP PDU.


The narrowing concept that needs to be added is that if the PDU carries

a congestion indication, then that congestion indication participates in

such a feedback loop,

Yes, valid point. Thank you.

ECN-PDU: A PDU that is part of a feedback loop within which all the

nodes that need to propagate the explicit congestion notification

signal in the PDU back to the Load Regulator are ECN-capable of doing so.



and even that is subtle when there are multiple

possible congestion indication locations. An example of the subtlety is

that the same PDU may be an ECN-PDU in feed-up-and-forward mode because

the layer 3 and 4 protocols support ECN but may be a Not-ECN-PDU for

feed-forward-and-up mode because the L2 decapsulator ignores and discards

L2 congestion indications.

I think the bold words in the phrase "nodes that need to propagate" deals with that subtlety.

In your example, if the subnet is propagating the PDU's ECN signal in feed-up-and-forward mode and the L2 decapsulator doesn't propagate ECN, it's not relevant because it also doesn't need to propagate ECN. Whereas, if the subnet propagates ECN in feed-forward-and-up mode, the decap does need to.

I've also extended the above correction into the next definition:

 Not-ECN-PDU: A PDU that is part of a feedback-loop within which some at least one
 node necessary to propagate the explicit congestion notification signal in the PDU 
back to the load regulator are is not ECN-capable of doing so.



[G] 2. Terminology

Congestion Baseline: The location of the function on the path that

initialised the values of all congestion notification fields in a

sequence of packets, before any are set to the congestion

experienced (CE) codepoint if they experience congestion further

downstream. Typically the original data source at layer-4.


That's counter-intuitive - a baseline is a level, not a location. I've

tagged this as a minor issue as opposed to editorial because it causes

severe confusion in the only place that this term is used, namely item 3

in Section 4.3. That item 3 is about a Monitoring Baseline which is

a level not a location.

The Congestion Baseline term should be removed, and item 3 in Section

4.3 revised accordingly. The term "Congestion Baseline" is used twice

there, but only the latter of those two uses needs to be retained and

expanded after deletion of this definition.

You're right. I've done as you suggest.

I've also nearly completely re-written the second half of the section, because I had temporarily forgotten the rationale, and even I couldn't understand what the rationale was after reading my own words.


[H] 3. Modes of Operation

Feed-Up-and-Forward: A lower layer switch feeds-up congestion

notification directly into the ECN field in the higher layer

(e.g. IP) header, irrespective of whether the node is at the

egress of a subnet.

Remove "the ECN field in" as that's too restrictive, even though that's

a common case, and move it into the example (e.g., ECN field in the

IP header)" where "header" moved inside the parentheses.

Done.



[I] 3.3. Feed-Backward Mode

Please make it clear that the critique of the ATM ABR relative rate

control mechanism also applies to Ethernet QCN, as that's a more

current example. This should be connected to the QCN discussion at

the end of Section 4.2.

I didn't want to imply any criticism of QCN, which always made it clear it was only applicable to a single subnet.

However, I can now see the need to have this written down, given certain companies are giving incentives to churn out Frankenpatents (any random combination of existing ideas, no matter whether useful or correct). So I've kept ATM as the example, but added at the end:

 QCN [IEEE802.1Qau] would suffer from similar problems if extended to
 multiple subnets. However, from the start QCN was clearly stated as
 solely applicable to a single subnet (see Section 6).



[J] 4.3 Encapsulation Guidelines

Resolving minor issue [G] requires some edits to item 3 in this section:

- Remove "(the Congestion Baseline)" from the third paragraph.

- Rewrite start of fourth paragraph:

OLD

Most information can be extracted if the Congestion Baseline is

standardised at the node that is regulating the load (the Load

Regulator--typically the data source).

NEW

More information can be extracted if the protocol specification

requires that congestion fields be initialized to indicate no

congestion only by the node that is regulating the load (the

Load Regulator--typically the data source).

END

See minor issue [G] above - already completely rewritten this text.



[K] 12.2 Informative References

Please check the references to 802.1Qah and 802.1Qau with IEEE. The

correct references to use now may be the latest version of 802.1Q with

specific functionality and/or clauses identified.

Done.
802.1Qau -> 802.1Q Sections 30--33
802.1ah -> 802.1Q (as a whole - too scattered to call out particular sections).

Pat Thaler having retired, I no longer have a co-author who can advise on IEEE citation correctness.
But the above is good enough.

[I knew someone would point that out - I should have dealt with it but, even tho I purportedly have free access to the full rolled-up text of the current standard (IEEE802.1Q-2018), I've always had trouble viewing it. The IEEE pay-wall insists on displaying the free copy in my browser in a way that it can't be downloaded, but in Firefox the activity bar spins but nothing ever appears. After much gnashing of teeth, I discovered it works OK in Chrome.]


--- Editorial/Nits ---

Abstract, last sentence

Following these guidelines should assure

interworking between new lower layer congestion notification

mechanisms, whether specified by the IETF or other standards bodies.

between new -> among IP layer and

Yup.

1. Introduction, first paragraph

Suggest removing use of the word "buffer" - "lower layer" suffices in

all of the places where this word is used in this paragraph.

Not as simple as that. I've guessed that the idea of a buffer doing marking jars with you, so I've addressed the two occurrences of 'buffer' as follows:

1. When a lower layer buffer drops a packet

This was intended to introduce the context as congestion loss, not transmission loss. So left unchanged.

2. In
 contrast, when a lower layer marks a packet with ECN, the marking
 needs to be explicitly propagated up the layers. The same is true if
 a buffer marks the outer header of a packet that encapsulates inner
 tunnelled headers.

The second sentence is about tunnels, not lower layers.
So, I've introduced AQM into both sentences:

 In
 contrast, when active queue management (AQM) at a lower layer marks a
 packet with ECN, the marking needs to be explicitly propagated up the
 layers. The same is true if AQM marks the outer header of a packet
 that encapsulates inner tunnelled headers.



1. Introduction, second paragraph

The purpose of this document is to guide the addition of congestion

notification to any subnet technology or tunnelling protocol, so that

lower layer equipment can signal congestion explicitly and it will

propagate consistently into encapsulated (higher layer) headers,

otherwise the signals will not reach their ultimate destination.

Suggest: "equipment" -> "functionality"

Sorry, the word 'functionality' gets to me like finger-nails on a blackboard.
https://www.dailywritingtips.com/is-that-even-a-word/

I've used s/equipment/AQM algorithms/



Page 5, first full paragraph:

If a particular protocol design chooses to contradict a

'SHOULD (NOT)' given in the advice below, it MUST include a sound

justification.

chooses to contradict -> chooses not to follow

Yup

1.1. Scope, first paragraph

This document only concerns wire protocol processing of explicit

notification of congestion.

Remove "wire"

I think that loses the intended sense in too much ambiguity.
'Protocol processing' could include the AQM algorithms, which this sentence is trying to exclude.


Section 3.1, second paragraph

In these cases, ECN may best be supported by standardising explicit

notification of congestion into the lower layer protocol that carries

the data forwards. It will then also be necessary to define how the

egress of the lower layer subnet propagates this explicit signal into

the forwarded upper layer (IP) header. It can then continue forwards

until it finally reaches the destination transport (at L4). Then

typically the destination will feed this congestion notification back

to the source transport using an end-to-end protocol (e.g. TCP).

This is the arrangement that has already been used to add ECN to IP-

in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129].

The referents of "It" at the start of the second and third sentences are

unclear and different. Suggested rephrasings:

It will then also be necessary to define ->

This necessitates also specifying

It can then continue -> This signal continues

Good.

Section 3.1, first paragraph after Figure 1

Cite one or more of the 3GPP references for GTP tunnels, as this is the

first occurrence of that concept in this draft.

Yup

Section 3.1, second paragraph after Figure 1

Cite a Frame Relay reference for the FECN bit.. Moving the [Buck00]

citation up to immediately follow "Frame Relay" in the first line
suffices.

Good.

Section 3.2 first paragraph

These are Ethernet switches that bury into the Ethernet payload ...

bury -> burrow

[Spelling checker is missing read users mind feature :-)]

I've used dig.

Hard to read user's mind. Easier to tell user what to think ;)


Section 3.4

The second paragraph could be improved by citing references for fat-tree

and Clos network topologies.

Done.


Section 4.1, second paragraph

Therefore section 4 of

[I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to

configure the ingress of a non-ECN tunnel so that it zeros the ECN

field in the outer IP header.

non-ECN tunnel -> tunnel that does not support ECN

OK

Section 4.1, third paragraph

Even

if the shim(s) encapsulate a L2 header, it is often possible to find

an inner IP header within the L2 header

Latter instance of "L2 header" should be "L2 PDU"

Good.

Section 4.1, last paragraph

Instead a companion specification

[I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has

sufficient standards track status to update standards track

protocols.


sufficient -> the appropriate

Done.

Authors Addresses

Please check these - Pat Thaler's contact info probably needs to be updated.

In progress.



Bob

Thanks, --David

----------------------------------------------------------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA 01748

+1 (774) 350-9323 New Mobile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------------------



-- 
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------5744AE65074B51DCA0155339-- From nobody Thu May 16 16:44:04 2019 Return-Path: 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 A4133120106 for ; Thu, 16 May 2019 16:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 WJyaw-BYAZfy for ; Thu, 16 May 2019 16:43:59 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 D388A1200C4 for ; Thu, 16 May 2019 16:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7mkQDKLGcacQLsnsypfa1y6evdsbqPtwjtdt5/WOmE8=; b=WvUWBu0ZE8A95g18vC29Fx1iu KVOpPpTPD8x4rpv8FXhhajQKlOamL4xgGOJb8HwrRfIPIPTguyJ1H2kYo99n+gjH/EX/w1zzNfezT yZKzqnVK+w7v3wBH+lvQdUt2CRBV9jlWdr3AV3q8VGyFoC/YkYuAoKNjHHj7xyUyvz76VXKMqC5PD N11lLRCJnSu7JFLH5RTUWN4KDWYXPWfNAn8D+borbV9/NLH/qz3IPDsl0qSJwkS9Yojv2RdnXE53w bis8OQ8djqse6bbXtaQnvvhyqQvUS9IIqjk1Zt3/8qaX+R9j7z2uaCSMfj/8quPHin6Ni9Wd16hUR Y0x1Xuc7A==; Received: from [31.185.135.221] (port=46654 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hRQ2T-0001PN-Gm; Fri, 17 May 2019 00:43:54 +0100 To: "Black, David" , "tsvwg@ietf.org" References: From: Bob Briscoe Message-ID: <89e67cfc-9574-c7a7-b837-c909c2180595@bobbriscoe.net> Date: Fri, 17 May 2019 00:43:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------430F99A79ED230BCC1FC6DC3" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 23:44:03 -0000 This is a multi-part message in MIME format. --------------430F99A79ED230BCC1FC6DC3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit David, I'll split your email in two and solely deal with the major issue first. See inline. On 09/05/2019 02:08, Black, David wrote: > > idnits found a couple of minor things: > > * Current reference for IKEv2 is RFC 7296 instead of RFC 5996 > * If any text was copied from pre-5378 RFCs, an additional > boilerplate disclaimer is required. > > Thanks, --David > > *From:* Black, David > *Sent:* Wednesday, May 8, 2019 8:50 PM > *To:* tsvwg@ietf.org > *Subject:* David Black's WGLC review of > draft-ietf-tsvwg-rfc6040update-shim-08 > > This is a solidly written draft on updating tunnel protocols that use > shim headers to propagate ECN according to RFC 6040. > > Unfortunately, I found a major issue with the updates [1] along with a > few minor issues (easily dealt with) and a bunch of editorial items. > > The major issue [1] on updates creating non-compliant implementations > looks like it will need WG discussion on what should be done, as the > right thing to do appears to be in potential conflict with deployed > running code. > > --- Major --- > > [1] Compliance with RFC 6040 update > > Section 3.1 says: > > However, an RFC has no jurisdiction over implementations that choose > > not to comply with it or cannot comply with it, including all those > > implementations that pre-dated the RFC. Therefore it would have been > > unreasonable to add such a requirement to RFC 6040. > > But then Section 4 goes on to do exactly that by updating RFC 6040 to > > add this text: > > In order that the network operator can comply with the above > > safety rules, even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > * it SHOULD be able to be configured to zero the outer ECN field. > > followed by this attempt to excuse the result: > > There might be concern that the above "MUST" makes compliant > > equipment non-compliant at a stroke. However, any equipment that is > > still treating the former ToS octet (IPv4) or the former Traffic > > Class octet (IPv6) as a single 8-bit field is already non-compliant, > > and has been since 1998 when the upper 6 bits were separated off for > > the Diffserv field [RFC2474], [RFC3260]. For instance, copying the > > ECN field as a side-effect of copying the DSCP is a seriously unsafe > > bug that risks breaking the feedback loops that regulate load on a > > tunnel. > > These three chunks of text need to be aligned.. I'm not sure what should > > be done here, as the concern about updating RFC 6040 to cause > non-compliance > > is an important concern. > [BB] This draft proposes to update RFC6040, which in turn updated RFC3168, which in turn updated RFC2474 (there were other RFCs in the tree of updates ending at RFC6040, but those updates were not with respect to the Diffserv/ECN fields). I fully agree that we have to be careful not to make any equipment that already complies with any of these RFCs non-compliant. And we don't... If any equipment does not satisfy the proposed 'MUST' statement above, it will not be treating the DSCP and the ECN fields independently. Such equipment would not have complied with RFC2474, which separated out the last 2 bits of the ToS byte, which made it possible to specify ECN in the first place. So the proposed 'MUST' statement does not make any equipment that complied with any of these RFCs non-compliant, unless it was already non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. So the equipment would already be non-compliant with all these RFCs. Now, check the detailed wording: even if an implementation of a tunnel ingress does not claim to support RFC 6040, RFC 4301 or the full functionality mode of RFC 3168: * it MUST make propagation of the ECN field between inner and outer IP headers independent of any configuration of Diffserv codepoint propagation; You'll notice RFC2474 is not in the list of RFCs that an implementation might even not claim to support. That's because the MUST is about Diffserv configuration. If equipment offers any Diffserv configuration, it already has to comply with RFC2474. However, if it doesn't already comply with this MUST, it already doesn't comply with RFC2474. So again, this MUST does not make any equipment that complied with any of the chain of RFCs non-compliant, unless they were already non-compliant with RFC2474, and therefore non-compliant with all the RFCs in the chain of updates up to RFC6040, because RFC2474 grandfathered the chain. > Analogous non-compliance concerns apply to the updates to other RFCs in > > Section 5 to varying degrees. > > If you accept my arguments above, but can still find other non-compliance concerns, please do point them out. Nonetheless, I'm pretty sure I've been similarly careful to avoid introducing any non-compliance surprises. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------430F99A79ED230BCC1FC6DC3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit David,

I'll split your email in two and solely deal with the major issue first. See inline.

On 09/05/2019 02:08, Black, David wrote:

idnits found a couple of minor things:

  • Current reference for IKEv2 is RFC 7296 instead of RFC 5996
  • If any text was copied from pre-5378 RFCs, an additional boilerplate disclaimer is required.

Thanks, --David

From: Black, David
Sent: Wednesday, May 8, 2019 8:50 PM
To: tsvwg@ietf.org
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

This is a solidly written draft on updating tunnel protocols that use shim headers to propagate ECN according to RFC 6040.

Unfortunately, I found a major issue with the updates [1] along with a few minor issues (easily dealt with) and a bunch of editorial items.

The major issue [1] on updates creating non-compliant implementations looks like it will need WG discussion on what should be done, as the right thing to do appears to be in potential conflict with deployed running code.

--- Major ---

[1] Compliance with RFC 6040 update

Section 3.1 says:

However, an RFC has no jurisdiction over implementations that choose

not to comply with it or cannot comply with it, including all those

implementations that pre-dated the RFC. Therefore it would have been

unreasonable to add such a requirement to RFC 6040.

But then Section 4 goes on to do exactly that by updating RFC 6040 to

add this text:

In order that the network operator can comply with the above

safety rules, even if an implementation of a tunnel ingress does

not claim to support RFC 6040, RFC 4301 or the full functionality

mode of RFC 3168:

* it MUST make propagation of the ECN field between inner and

outer IP headers independent of any configuration of Diffserv

codepoint propagation;

* it SHOULD be able to be configured to zero the outer ECN field.

followed by this attempt to excuse the result:

There might be concern that the above "MUST" makes compliant

equipment non-compliant at a stroke. However, any equipment that is

still treating the former ToS octet (IPv4) or the former Traffic

Class octet (IPv6) as a single 8-bit field is already non-compliant,

and has been since 1998 when the upper 6 bits were separated off for

the Diffserv field [RFC2474], [RFC3260]. For instance, copying the

ECN field as a side-effect of copying the DSCP is a seriously unsafe

bug that risks breaking the feedback loops that regulate load on a

tunnel.

These three chunks of text need to be aligned.. I'm not sure what should

be done here, as the concern about updating RFC 6040 to cause non-compliance

is an important concern.

[BB] This draft proposes to update RFC6040, which in turn updated RFC3168, which in turn updated RFC2474 (there were other RFCs in the tree of updates ending at RFC6040, but those updates were not with respect to the Diffserv/ECN fields).

I fully agree that we have to be careful not to make any equipment that already complies with any of these RFCs non-compliant. And we don't...

If any equipment does not satisfy the proposed 'MUST' statement above, it will not be treating the DSCP and the ECN fields independently. Such equipment would not have complied with RFC2474, which separated out the last 2 bits of the ToS byte, which made it possible to specify ECN in the first place.

So the proposed 'MUST' statement does not make any equipment that complied with any of these RFCs non-compliant, unless it was already non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. So the equipment would already be non-compliant with all these RFCs.

Now, check the detailed wording:

even if an implementation of a tunnel ingress does

not claim to support RFC 6040, RFC 4301 or the full functionality

mode of RFC 3168:


* it MUST make propagation of the ECN field between inner and

outer IP headers independent of any configuration of Diffserv

codepoint propagation;


You'll notice RFC2474 is not in the list of RFCs that an implementation might even not claim to support. That's because the MUST is about Diffserv configuration. If equipment offers any Diffserv configuration, it already has to comply with RFC2474. However, if it doesn't already comply with this MUST, it already doesn't comply with RFC2474.

So again, this MUST does not make any equipment that complied with any of the chain of RFCs non-compliant, unless they were already non-compliant with RFC2474, and therefore non-compliant with all the RFCs in the chain of updates up to RFC6040, because RFC2474 grandfathered the chain.


Analogous non-compliance concerns apply to the updates to other RFCs in

Section 5 to varying degrees.


If you accept my arguments above, but can still find other non-compliance concerns, please do point them out.

Nonetheless, I'm pretty sure I've been similarly careful to avoid introducing any non-compliance surprises.



Bob



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------430F99A79ED230BCC1FC6DC3-- From nobody Fri May 17 08:36:33 2019 Return-Path: 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 7ECD0120110 for ; Fri, 17 May 2019 08:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=X6PjD6Y7; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=swf2NSzU 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 gKc2L_J1u9MA for ; Fri, 17 May 2019 08:36:28 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 0D735120359 for ; Fri, 17 May 2019 08:36:28 -0700 (PDT) Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4HFTtN3017104; Fri, 17 May 2019 11:35:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=BjbDdSToeAl7ek9hkfOo4H5NjQf2pwKEtSfN9Hhn2ZQ=; b=X6PjD6Y7lhjx6RJuk0KuICUZCS62TvA838lLSl0LMvNulNGl7mfrJ/j1IiIv2/uArpbv kAWfrZ5x3jTfyvHfkuyuy6vQvayMIPBxZktu1HlHBLb7rspmVatQ6HbQghKa6hUz90pO gVSlFGWdSJugqMrwyUBkFLanr8+l7oX1sQ+OOmIsPnkEm0QdcQtcDPmFVLs4YwPkbl/n xjx4uyjtCsGh37amPwLBtkkJ9nskOaAN5iyU0/6PFgKkJXCvyQ2CNCqg0WA2T9k5JYHu Dc0aG+OmTJbhUCZZAB35428j3zuQh82bsyGKjvrsWARf+VwloNSAPeBe20OGsNwa4Ul5 Vg== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2shs7x1g99-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 May 2019 11:35:43 -0400 Received: from pps.filterd (m0142693.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4HFRuIB019185; Fri, 17 May 2019 11:35:43 -0400 Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by mx0a-00154901.pphosted.com with ESMTP id 2shubwccp3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 May 2019 11:35:42 -0400 Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4HFZWLv006210 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 May 2019 11:35:41 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com x4HFZWLv006210 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1558107341; bh=2UHlg2ZxhdeTW+WyiPnpUHqsOn8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=swf2NSzUHW3jHuuxeMh0Eo4g2CYaJRIwLcFa9+fPC0BsqPQrdyBYIMKQoi5jUe6rU jjxns9R0y+9Ot9BuTpZKTQoOMbsSG2c6DXy0EELyi1gZfsn5wGb59DksklUtp/wKGG adp9/BXIJ2TaI1s5XUnp8bNKd8d03mOoKHhH+Qiw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com x4HFZWLv006210 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd53.lss.emc.com (RSA Interceptor); Fri, 17 May 2019 11:34:02 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4HFYcMr017835 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 17 May 2019 11:34:38 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0439.000; Fri, 17 May 2019 11:34:38 -0400 From: "Black, David" To: Bob Briscoe , "tsvwg@ietf.org" Thread-Topic: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 Thread-Index: AdUGAGT4Th8zbG5rQXClmZ/2hSiF0gAAs+7gAZfidQAAGJaicA== Date: Fri, 17 May 2019 15:34:37 +0000 Message-ID: References: <89e67cfc-9574-c7a7-b837-c909c2180595@bobbriscoe.net> In-Reply-To: <89e67cfc-9574-c7a7-b837-c909c2180595@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.130] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363056D070MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-17_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905170094 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905170094 Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 15:36:32 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363056D070MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Before going further down the compliance rathole, let me suggest an alterna= tive that might resolve this quickly. The crucial text (whose technical correctness is not in question) is: In order that the network operator can comply with the above safety rules, even if an implementation of a tunnel ingress does not claim to support RFC 6040, RFC 4301 or the full functionality mode of RFC 3168: * it MUST make propagation of the ECN field between inner and outer IP headers independent of any configuration of Diffserv codepoint propagation; * it SHOULD be able to be configured to zero the outer ECN field. The headaches are being caused by treating that text as an update to RFC 60= 40, but looking at it now, it reads like a best current practice recommendation, so ... Would it be reasonable to move that text into the ecn-encapsulation draft (= which is intended to become a BCP)? Doing that would sidestep the entire discussion of consequences of= the consequences of updating RFC 6040 with that text. If that sounds plausible, we should take a look at whether any of the other= RFC 6040 update text in section 4 should likewise be moved to the ECN encapsulation draft. Thanks, --David From: Bob Briscoe Sent: Thursday, May 16, 2019 7:44 PM To: Black, David; tsvwg@ietf.org Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040u= pdate-shim-08 [EXTERNAL EMAIL] David, I'll split your email in two and solely deal with the major issue first. Se= e inline. On 09/05/2019 02:08, Black, David wrote: idnits found a couple of minor things: * Current reference for IKEv2 is RFC 7296 instead of RFC 5996 * If any text was copied from pre-5378 RFCs, an additional boilerplate = disclaimer is required. Thanks, --David From: Black, David Sent: Wednesday, May 8, 2019 8:50 PM To: tsvwg@ietf.org Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-0= 8 This is a solidly written draft on updating tunnel protocols that use shim = headers to propagate ECN according to RFC 6040. Unfortunately, I found a major issue with the updates [1] along with a few = minor issues (easily dealt with) and a bunch of editorial items. The major issue [1] on updates creating non-compliant implementations looks= like it will need WG discussion on what should be done, as the "right thin= g to do" appears to be in potential conflict with deployed "running code". --- Major --- [1] Compliance with RFC 6040 update Section 3.1 says: However, an RFC has no jurisdiction over implementations that choose not to comply with it or cannot comply with it, including all those implementations that pre-dated the RFC. Therefore it would have been unreasonable to add such a requirement to RFC 6040. But then Section 4 goes on to do exactly that by updating RFC 6040 to add this text: In order that the network operator can comply with the above safety rules, even if an implementation of a tunnel ingress does not claim to support RFC 6040, RFC 4301 or the full functionality mode of RFC 3168: * it MUST make propagation of the ECN field between inner and outer IP headers independent of any configuration of Diffserv codepoint propagation; * it SHOULD be able to be configured to zero the outer ECN field. followed by this attempt to excuse the result: There might be concern that the above "MUST" makes compliant equipment non-compliant at a stroke. However, any equipment that is still treating the former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field is already non-compliant, and has been since 1998 when the upper 6 bits were separated off for the Diffserv field [RFC2474], [RFC3260]. For instance, copying the ECN field as a side-effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel. These three chunks of text need to be aligned.. I'm not sure what should be done here, as the concern about updating RFC 6040 to cause non-complianc= e is an important concern. [BB] This draft proposes to update RFC6040, which in turn updated RFC3168, = which in turn updated RFC2474 (there were other RFCs in the tree of updates= ending at RFC6040, but those updates were not with respect to the Diffserv= /ECN fields). I fully agree that we have to be careful not to make any equipment that alr= eady complies with any of these RFCs non-compliant. And we don't... If any equipment does not satisfy the proposed 'MUST' statement above, it w= ill not be treating the DSCP and the ECN fields independently. Such equipme= nt would not have complied with RFC2474, which separated out the last 2 bit= s of the ToS byte, which made it possible to specify ECN in the first place= . So the proposed 'MUST' statement does not make any equipment that complied = with any of these RFCs non-compliant, unless it was already non-compliant w= ith RFC2474. And RFC2474 grandfathered all these RFCs. So the equipment wou= ld already be non-compliant with all these RFCs. Now, check the detailed wording: even if an implementation of a tunnel ingress does not claim to support RFC 6040, RFC 4301 or the full functionality mode of RFC 3168: * it MUST make propagation of the ECN field between inner and outer IP headers independent of any configuration of Diffserv codepoint propagation; You'll notice RFC2474 is not in the list of RFCs that an implementation mig= ht even not claim to support. That's because the MUST is about Diffserv con= figuration. If equipment offers any Diffserv configuration, it already has = to comply with RFC2474. However, if it doesn't already comply with this MUS= T, it already doesn't comply with RFC2474. So again, this MUST does not make any equipment that complied with any of t= he chain of RFCs non-compliant, unless they were already non-compliant with= RFC2474, and therefore non-compliant with all the RFCs in the chain of upd= ates up to RFC6040, because RFC2474 grandfathered the chain. Analogous non-compliance concerns apply to the updates to other RFCs in Section 5 to varying degrees. If you accept my arguments above, but can still find other non-compliance c= oncerns, please do point them out. Nonetheless, I'm pretty sure I've been similarly careful to avoid introduci= ng any non-compliance surprises. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_CE03DB3D7B45C245BCA0D243277949363056D070MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Before going further d= own the compliance rathole, let me suggest an alternative that might resolv= e this quickly.

 

The crucial text (whos= e technical correctness is not in question) is:

 

      In order= that the network operator can comply with the above

      safety r= ules, even if an implementation of a tunnel ingress does<= /p>

      not clai= m to support RFC 6040, RFC 4301 or the full functionality=

      mode of = RFC 3168:

 

      *  = it MUST make propagation of the ECN field between inner and

      &nb= sp;  outer IP headers independent of any configuration of Diffserv

      &nb= sp;  codepoint propagation;

 

      *  = it SHOULD be able to be configured to zero the outer ECN field.=

 

The headaches are bein= g caused by treating that text as an update to RFC 6040, but looking at it = now,

it reads like a best c= urrent practice recommendation, so …

 

Would it be reasonable= to move that text into the ecn-encapsulation draft (which is intended to b= ecome

a BCP)?  Doing th= at would sidestep the entire discussion of consequences of the consequences= of

updating RFC 6040 with= that text.

 

If that sounds plausib= le, we should take a look at whether any of the other RFC 6040 update text = in section

4 should likewise be m= oved to the ECN encapsulation draft.

 

Thanks, --David

 

From:= Bob Briscoe <ietf@bobbriscoe.net>
Sent: Thursday, May 16, 2019 7:44 PM
To: Black, David; tsvwg@ietf.org
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-r= fc6040update-shim-08

 

[EXTERNAL EMAIL]

David,

I'll split your email in two and solely deal with the major issue first. Se= e inline.

On 09/05/2019 02:08, Black, David wrote:<= /p>

idnits found a couple = of minor things:

  • Cur= rent reference for IKEv2 is RFC 7296 instead of RFC 5996
  • If any= text was copied from pre-5378 RFCs, an additional boilerplate disclaimer i= s required.

 

Thanks, --David=

 

From: Black, David
Sent: Wednesday, May 8, 2019 8:50 PM
To: tsvwg@ietf.org
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update= -shim-08

 

This is a solidly written draft on updating tunnel p= rotocols that use shim headers to propagate ECN according to RFC 6040.=

 

Unfortunately, I found a major issue with the update= s [1] along with a few minor issues (easily dealt with) and a bunch of edit= orial items.

 

The major issue [1] on updates creating non-complian= t implementations looks like it will need WG discussion on what should be d= one, as the “right thing to do” appears to be in potential conf= lict with deployed “running code”.

 

--- Major ---

 

[1] Compliance with RFC 6040 update

 

Section 3.1 says:

 

   However, an RFC has no jur= isdiction over implementations that choose

   not to comply with it or c= annot comply with it, including all those

   implementations that pre-d= ated the RFC.  Therefore it would have been

   unreasonable to add such a= requirement to RFC 6040.

 

But then Section 4 goes on to do exactl= y that by updating RFC 6040 to

add this text:

 

      In order= that the network operator can comply with the above

      safety r= ules, even if an implementation of a tunnel ingress does<= /p>

      not clai= m to support RFC 6040, RFC 4301 or the full functionality=

      mode of = RFC 3168:

 

      *  = it MUST make propagation of the ECN field between inner and

      &nb= sp;  outer IP headers independent of any configuration of Diffserv

      &nb= sp;  codepoint propagation;

 

      *  = it SHOULD be able to be configured to zero the outer ECN field.=

 

followed by this attempt to excuse the = result:

 

   There might be concern tha= t the above "MUST" makes compliant

   equipment non-compliant at= a stroke.  However, any equipment that is

   still treating the former = ToS octet (IPv4) or the former Traffic

   Class octet (IPv6) as a si= ngle 8-bit field is already non-compliant,

   and has been since 1998 wh= en the upper 6 bits were separated off for

   the Diffserv field [RFC247= 4], [RFC3260].  For instance, copying the

   ECN field as a side-effect= of copying the DSCP is a seriously unsafe

   bug that risks breaking th= e feedback loops that regulate load on a

   tunnel.<= /p>

 

These three chunks of text need to be a= ligned..  I'm not sure what should

be done here, as the concern about upda= ting RFC 6040 to cause non-compliance

is an important concern.

[BB] This draft propo= ses to update RFC6040, which in turn updated RFC3168, which in turn updated= RFC2474 (there were other RFCs in the tree of updates ending at RFC6040, b= ut those updates were not with respect to the Diffserv/ECN fields).

I fully agree that we have to be careful not to make any equipment that alr= eady complies with any of these RFCs non-compliant. And we don't...

If any equipment does not satisfy the proposed 'MUST' statement above, it w= ill not be treating the DSCP and the ECN fields independently. Such equipme= nt would not have complied with RFC2474, which separated out the last 2 bit= s of the ToS byte, which made it possible to specify ECN in the first place.

So the proposed 'MUST' statement does not make any equipment that complied = with any of these RFCs non-compliant, unless it was already non-compliant w= ith RFC2474. And RFC2474 grandfathered all these RFCs. So the equipment wou= ld already be non-compliant with all these RFCs.

Now, check the detailed wording:

      even if = an implementation of a tunnel ingress does

      not clai= m to support RFC 6040, RFC 4301 or the full functionality=

      mode of = RFC 3168:

 

      *  = it MUST make propagation of the ECN field between inner and

      &nb= sp;  outer IP headers independent of any configuration of Diffserv

      &nb= sp;  codepoint propagation;


You'll notice RFC2474 is not in the list of RFCs that an implementation mig= ht even not claim to support. That's because the MUST is about Diffserv con= figuration. If equipment offers any Diffserv configuration, it already has = to comply with RFC2474. However, if it doesn't already comply with this MUST, it already doesn't comply wit= h RFC2474.

So again, this MUST does not make any equipment that complied with any of t= he chain of RFCs non-compliant, unless they were already non-compliant with= RFC2474, and therefore non-compliant with all the RFCs in the chain of upd= ates up to RFC6040, because RFC2474 grandfathered the chain.



 

Analogous non-compliance concerns apply= to the updates to other RFCs in

Section 5 to varying degrees.

 

If you accept my arguments above, but can still find= other non-compliance concerns, please do point them out.

Nonetheless, I'm pretty sure I've been similarly careful to avoid introduci= ng any non-compliance surprises.



Bob




-- 
________________________________________________________________<=
/o:p>
Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/
--_000_CE03DB3D7B45C245BCA0D243277949363056D070MX307CL04corpem_-- From nobody Fri May 17 15:54:48 2019 Return-Path: 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 38A5B1201A2 for ; Fri, 17 May 2019 15:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 N3eD-AxlxQqc for ; Fri, 17 May 2019 15:54:43 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 70F89120152 for ; Fri, 17 May 2019 15:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IV5H2K22J1Rf3RNkplq2TbZZbzrrbr1MVx0F+zJsZJs=; b=hc77TnsBhsZVusQlr0i0h23NA IAkTk/8YvO7wlHxO/WOvjUEhs3uyHZBRzyw6nlqhxCT9HOg5jmSM35ek8L3b2P6XV57ulRb3nRbjF 9t8SBXw47u4GGrSw2qCjQQkp9V61WMPpctWNBBDaxlJ5mOKmToupp2r6/DVeyvHnmafWULf9TAtbD KtqRWCMOavIAOoxYsLfrs70+ZYYMHfYEAsUBF+aIYjJ1hvUNaAcafTs1AbO+pFxgbs4657SPGQiOa W9DOBKnnpSGW+Ah0mOoh3oQWxs6swI2ZmSaprBtqsve1A/4Ovi8NAYeHvcuAKd9JMdGABPJ10TxSL asGgnA0EA==; Received: from [31.185.135.221] (port=60482 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hRlkN-0005WI-KS; Fri, 17 May 2019 23:54:40 +0100 To: "Black, David" , "tsvwg@ietf.org" References: From: Bob Briscoe Message-ID: <8ddc9156-7da9-8cb0-3d1c-1122cd7fbb34@bobbriscoe.net> Date: Fri, 17 May 2019 23:54:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D04FE78677A6E502211841DE" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 22:54:46 -0000 This is a multi-part message in MIME format. --------------D04FE78677A6E502211841DE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit David, As promised, here's my response to the 'Minor' half of your review... On 09/05/2019 02:08, Black, David wrote: > > idnits found a couple of minor things: > > * Current reference for IKEv2 is RFC 7296 instead of RFC 5996 > * If any text was copied from pre-5378 RFCs, an additional > boilerplate disclaimer is required. > > Thanks, --David > > *From:* Black, David > *Sent:* Wednesday, May 8, 2019 8:50 PM > *To:* tsvwg@ietf.org > *Subject:* David Black's WGLC review of > draft-ietf-tsvwg-rfc6040update-shim-08 > > This is a solidly written draft on updating tunnel protocols that use > shim headers to propagate ECN according to RFC 6040. > > Unfortunately, I found a major issue with the updates [1] along with a > few minor issues (easily dealt with) and a bunch of editorial items. > > The major issue [1] on updates creating non-compliant implementations > looks like it will need WG discussion on what should be done, as the > right thing to do appears to be in potential conflict with deployed > running code. > > --- Major --- > > [snip] > > --- Minor --- > > [A] Updated RFCs. > > Need to be explicit about what the updates are to each of the updated > RFCs. > Each update to each RFC within S.5.1 says exactly what text in the original RFC is updated and exactly what it becomes. Surely it couldn't be more explicit? > The updates are scattered throughout the draft - a possible approach is to > > add a section that summarizes the update(s) to each RFC and provides > pointers > > to the section(s) that contain the update(s). > The normative updates for each RFC are all in section 5.1. under the subsection for each protocol. That's the only place those interested in that RFC will look. So that's where it is safest to put each update. All updates are extremely explicit, and all concentrated in one subsection, so I'm not sure how these criticisms have arisen. > [B] Section 4 > > * if it is known that the tunnel egress does not support > > propagation of the ECN field (RFC 6040, RFC 4301 or the full > > functionality mode of RFC 3168) > > The parenthetical listing of RFCs is unclear - I think these all do > support > > ECN field propagation, so edits are needed to make this clear. > Sry, I've changed it to read: * if it is known that the tunnel egress does not support any of the RFCs that define propagation of the ECN field (RFC 6040, RFC 4301 or the full functionality mode of RFC 3168) > [C] Section 4 > > For instance, copying the > > ECN field as a side-effect of copying the DSCP is a seriously unsafe > > bug that risks breaking the feedback loops that regulate load on a > > tunnel. > > This text comes immediately after the text in issue [1]. The problem with > > this text is that it's implicitly assuming that the tunnel egress discards > > the outer header including any congestion indication that it may contain. > > That needs to be stated/explained. > You're right. Without context this text is dangerous. Thx. I've changed it to: If a tunnel ingress does not have any ECN logic, copying the ECN field as a side-effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel. Note, it didn't say it /will/ break; it just says it /risks/ breaking. The point is, if it doesn't have ECN logic, it cannot have checked the egress ECN capability. Indeed, if the ingress doesn't have ECN logic it's quite likely the egress doesn't either, assuming both ends of many tunnels are deployed at the same time. > [D] Section 5 > > Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains > > that a tunnel that encapsulates an IP header directly within a UDP/IP > > datagram needs to follow RFC 6040 when propagating the ECN field > > between inner and outer IP headers. The requirements in Section 4 > > update RFC 6040 so, by reference, they automatically update RFC 8085 > > to add the important but previously unstated requirement that, if the > > UDP tunnel egress does not, or might not, support ECN propagation, a > > legacy UDP tunnel ingress has to clear the outer IP ECN field to > > 0b00, e.g. by configuration. > > That's too clever/subtle - this draft should explicitly update RFC 8085. > Not happy about this. Followed to its logical conclusion, as well as updating RFC6040, this draft would then need to update every RFC that already normatively references RFC6040 (e.g. GUE, Geneve, etc). Wouldn't such an update get kicked out during IESG review, as a duplicate update? Certainly it might make the ID nits checker issue a high-pitched scream as it runs round a tight loop of "Updates" headers. So, instead, how about stating the above para in the opposite order as follows: This document indirectly updates the UDP usage guidelines [RFC8085] to add the important but previously unstated requirement that, if the UDP tunnel egress does not, or might not, support ECN propagation, a legacy UDP tunnel ingress has to clear the outer IP ECN field to 0b00, e.g. by configuration. Section 3.1.11 of RFC 8085 already explains that a tunnel that encapsulates an IP header directly within a UDP/IP datagram needs to follow RFC 6040 when propagating the ECN field between inner and outer IP headers. And the requirements in Section 4 update RFC 6040 so, by reference, they indirectly update RFC 8085. > [E] Have the L2TP changes been reviewed by L2TP experts? > Of course. Each protocol modification was done in collaboration with an expert on that protocol. I wouldn't have felt confident to modify all these protocols otherwise. * L2TP update: Carlos was particularly helpful, but also Ignacio, and it was all properly discussed on the L2TPEXT list * Similarly, CAPWAP in OPSAWG with Margaret Wasserman/Cullen, Benoit, Warren Kumari, Mahalingam Mani, Dorothy Gellert, Dorothy Stanley, Michael Montemurro. But once I dug into CAPWAP, it turned out not to require any changes. * GRE was covered by INT-AREA, particularly Mohamed Boucadair. Early on INT-AREA and Alia Atlas did significant reviewing to find which protocols it should cover as well. * See the ACKs section for the names of all the significant helpers. > [F] Have the AMT changes been reviewed by AMT experts? > Yup - text suggested by Jake Holland (also ACK'd). Herding all these cats has involved a fair amount of work and cajoling, particularly 'cos it's unfamiliar territory for many people, and it's rarely their priority. > --- Editorial --- > > Abstract > > It surveys widely deployed IP tunnelling > > protocols separated by such shim header(s) > > separated by -> that use > > Section 4 > > Permanently zeroing the outer ECN field is safe, but it is not > > sufficient to claim compliance with RFC 6040 because it does not meet > > the aim of introducing ECN support to tunnels (see Section 4.3 of > > [RFC6040]). > > "Permanently" is not the right word.. Suggest rephrasing start of > paragraph to > > Zeroing the ECN field in the outer header of all packets is safe, ... > I've taken all the above verbatim. > > IANA Considerations > > The "[TO BE REMOVED: ..." text is not the "right thing to do" - do > this instead: > > OLD > IANA is requested to assign the following L2TP Control Message > > Attribute Value Pair: > > NEW > > IANA is requested to assign the following L2TP Control Message > > Attribute Value Pair in the Layer Two Tunneling Protocol "L2TP" > > registry (https://www.iana.org/assignments/l2tp-parameters/l2tp- > > > parameters.xhtml): > > END > > IANA will edit this text after performing the assignment and can > > remove the link if appropriate. > I followed RFC5226 "Guidelines for Writing an IANA Considerations Section in RFCs" verbatim: When referring to an already existing registry, providing a URL to precisely identify the registry is helpful. All such URLs, however, will be removed from the RFC prior to final publication. For example, documents could contain: [TO BE REMOVED: This registration should take place at the following location:http://www.iana.org/assignments/foobar-registry] Bob > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Senior Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA 01748 > > +1 (774) 350-9323 *New * Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------D04FE78677A6E502211841DE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit David,

As promised, here's my response to the 'Minor' half of your review...

On 09/05/2019 02:08, Black, David wrote:

idnits found a couple of minor things:

  • Current reference for IKEv2 is RFC 7296 instead of RFC 5996
  • If any text was copied from pre-5378 RFCs, an additional boilerplate disclaimer is required.

Thanks, --David

From: Black, David
Sent: Wednesday, May 8, 2019 8:50 PM
To: tsvwg@ietf.org
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

This is a solidly written draft on updating tunnel protocols that use shim headers to propagate ECN according to RFC 6040.

Unfortunately, I found a major issue with the updates [1] along with a few minor issues (easily dealt with) and a bunch of editorial items.

The major issue [1] on updates creating non-compliant implementations looks like it will need WG discussion on what should be done, as the right thing to do appears to be in potential conflict with deployed running code.

--- Major ---

[snip]

--- Minor ---

[A] Updated RFCs.

Need to be explicit about what the updates are to each of the updated RFCs.

Each update to each RFC within S.5.1 says exactly what text in the original RFC is updated and exactly what it becomes. Surely it couldn't be more explicit?

The updates are scattered throughout the draft - a possible approach is to

add a section that summarizes the update(s) to each RFC and provides pointers

to the section(s) that contain the update(s).

The normative updates for each RFC are all in section 5.1. under the subsection for each protocol. That's the only place those interested in that RFC will look. So that's where it is safest to put each update.

All updates are extremely explicit, and all concentrated in one subsection, so I'm not sure how these criticisms have arisen.

[B] Section 4

* if it is known that the tunnel egress does not support

propagation of the ECN field (RFC 6040, RFC 4301 or the full

functionality mode of RFC 3168)

The parenthetical listing of RFCs is unclear - I think these all do support

ECN field propagation, so edits are needed to make this clear.

Sry, I've changed it to read:

* if it is known that the tunnel egress does not support any

of the RFCs that define propagation of the ECN field (RFC 6040,

RFC 4301 or the full functionality mode of RFC 3168)



[C] Section 4

For instance, copying the

ECN field as a side-effect of copying the DSCP is a seriously unsafe

bug that risks breaking the feedback loops that regulate load on a

tunnel.

This text comes immediately after the text in issue [1]. The problem with

this text is that it's implicitly assuming that the tunnel egress discards

the outer header including any congestion indication that it may contain.

That needs to be stated/explained.

You're right. Without context this text is dangerous. Thx. I've changed it to:

If a tunnel ingress does not have any ECN logic, copying the ECN field as a side-effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel.

Note, it didn't say it /will/ break; it just says it /risks/ breaking. The point is, if it doesn't have ECN logic, it cannot have checked the egress ECN capability. Indeed, if the ingress doesn't have ECN logic it's quite likely the egress doesn't either, assuming both ends of many tunnels are deployed at the same time.

[D] Section 5

Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains

that a tunnel that encapsulates an IP header directly within a UDP/IP

datagram needs to follow RFC 6040 when propagating the ECN field

between inner and outer IP headers. The requirements in Section 4

update RFC 6040 so, by reference, they automatically update RFC 8085

to add the important but previously unstated requirement that, if the

UDP tunnel egress does not, or might not, support ECN propagation, a

legacy UDP tunnel ingress has to clear the outer IP ECN field to

0b00, e.g. by configuration.

That's too clever/subtle - this draft should explicitly update RFC 8085.

Not happy about this. Followed to its logical conclusion, as well as updating RFC6040, this draft would then need to update every RFC that already normatively references RFC6040 (e.g. GUE, Geneve, etc).

Wouldn't such an update get kicked out during IESG review, as a duplicate update? Certainly it might make the ID nits checker issue a high-pitched scream as it runs round a tight loop of "Updates" headers.

So, instead, how about stating the above para in the opposite order as follows:

This document indirectly updates the UDP usage guidelines [RFC8085]

to add the important but previously unstated requirement that, if the

UDP tunnel egress does not, or might not, support ECN propagation, a

legacy UDP tunnel ingress has to clear the outer IP ECN field to

0b00, e.g. by configuration. Section 3.1.11 of RFC 8085 already explains

that a tunnel that encapsulates an IP header directly within a UDP/IP

datagram needs to follow RFC 6040 when propagating the ECN field

between inner and outer IP headers. And the requirements in Section 4

update RFC 6040 so, by reference, they indirectly update RFC 8085.



[E] Have the L2TP changes been reviewed by L2TP experts?

Of course. Each protocol modification was done in collaboration with an expert on that protocol. I wouldn't have felt confident to modify all these protocols otherwise.
  • L2TP update: Carlos was particularly helpful, but also Ignacio, and it was all properly discussed on the L2TPEXT list
  • Similarly, CAPWAP in OPSAWG with Margaret Wasserman/Cullen, Benoit, Warren Kumari, Mahalingam Mani, Dorothy Gellert, Dorothy Stanley, Michael Montemurro. But once I dug into CAPWAP, it turned out not to require any changes.
  • GRE was covered by INT-AREA, particularly Mohamed Boucadair. Early on INT-AREA and Alia Atlas did significant reviewing to find which protocols it should cover as well.
  • See the ACKs section for the names of all the significant helpers.

[F] Have the AMT changes been reviewed by AMT experts?

Yup - text suggested by Jake Holland (also ACK'd).

Herding all these cats has involved a fair amount of work and cajoling, particularly 'cos it's unfamiliar territory for many people, and it's rarely their priority.

--- Editorial ---

Abstract

It surveys widely deployed IP tunnelling

protocols separated by such shim header(s)

separated by -> that use

Section 4

Permanently zeroing the outer ECN field is safe, but it is not

sufficient to claim compliance with RFC 6040 because it does not meet

the aim of introducing ECN support to tunnels (see Section 4.3 of

[RFC6040]).

"Permanently" is not the right word.. Suggest rephrasing start of paragraph to

Zeroing the ECN field in the outer header of all packets is safe, ...

I've taken all the above verbatim.

IANA Considerations

The "[TO BE REMOVED: ..." text is not the "right thing to do" - do this instead:

OLD
IANA is requested to assign the following L2TP Control Message

Attribute Value Pair:

NEW

IANA is requested to assign the following L2TP Control Message

Attribute Value Pair in the Layer Two Tunneling Protocol "L2TP"

registry (https://www.iana.org/assignments/l2tp-parameters/l2tp-

parameters.xhtml):

END

IANA will edit this text after performing the assignment and can

remove the link if appropriate.

I followed RFC5226 "Guidelines for Writing an IANA Considerations Section in RFCs" verbatim:
         When
         referring to an already existing registry, providing a URL to
         precisely identify the registry is helpful.  All such URLs,
         however, will be removed from the RFC prior to final
         publication.  For example, documents could contain: [TO BE
         REMOVED: This registration should take place at the following
         location:  http://www.iana.org/assignments/foobar-registry]



Bob

Thanks, --David

----------------------------------------------------------------

David L. Black, Senior Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA 01748

+1 (774) 350-9323 New Mobile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------------------


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------D04FE78677A6E502211841DE-- From nobody Fri May 17 16:27:19 2019 Return-Path: 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 55E3C1201F3 for ; Fri, 17 May 2019 16:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 RM_E-UhdmEwh for ; Fri, 17 May 2019 16:27:14 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 D7F5A1200B7 for ; Fri, 17 May 2019 16:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eR13bVDaFYNkXVSfgkhxG/QQ3XlIfWXgQAtdObaV+r0=; b=OLfMCfblBzKIyUxHtxn4aXuiy fjZQAJuz0tLunp5G3HUbmhaiVqtMnN4CIRJqja4fr+g5VgvuU33JZaUXvJ/D7rLTaXbsaI0cCSnjO uVZ5HUUe0OezoW22SiopKAPm+wDbG6cy8e3YJqqPzbXp+3LcOffCjcW0KzVtUKibOi0jixkD14YBr QnU/udJA6yMOQwG6KBBvO2rTwF6EKag+U6QLGlGgg7cKhMn9RqxrqdM1Or1XE58t4z4DW3TzfkAd/ vdy19SmJHzb8Ns1G251mzuvQwa21/tAlBHOgdPNE1Xh9BE+6lgxkZ9OUk/4K15/58bv1IR7eheRyV IVC3UfHsQ==; Received: from [31.185.135.221] (port=60502 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hRmFn-000054-Uv; Sat, 18 May 2019 00:27:10 +0100 To: "Black, David" , "tsvwg@ietf.org" References: <89e67cfc-9574-c7a7-b837-c909c2180595@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Sat, 18 May 2019 00:27:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2824BC9A2E92E9DBFF6D9FBE" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 23:27:17 -0000 This is a multi-part message in MIME format. --------------2824BC9A2E92E9DBFF6D9FBE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit David, Three push backs and a question: a) The MUST and SHOULD you quote below are surely not BCP, they are straight protocol implementation spec. b) I believe it is important that this safety update to RFC6040 is formally flagged as an update, so it gets noticed and hopefully acted upon. c) Also, all the updates to specific protocols in the shim draft start with a section like the following example: 5.1.4.1 . Safe Configuration of a 'Non-ECN' Ingress AMT Relay The following text is appended toSection4.2.2 of [RFC7450] as an update to the AMT specification: The operator of an AMT relay that does not supportRFC 6040 or one of its compatible predecessors (RFC 4301 or the full functionality mode ofRFC 3168 ) MUST follow the configuration requirements in Section 4 of RFCXXXX to ensure it clears the outer IP ECN field to zero. {RFCXXXX refers to the present document so it will need to be inserted by the RFC Editor} For implementers updating a particular protocol (e.g. AMT) it would be gratuitously weird to have moved Section 4 into a different RFC (especially one that did not have PS status). d) Do you agree with my assessment that the MUST you quote below doesn't make anything non-compliant that wasn't already non-compliant with 2474. And anything that wants to claim support for anything to do with ECN has to comply with the aspect of 2474 that split off the last 2 bits from the ToS byte? If so, there's no longer a problem to solve. Let's move on. This has dragged on long enough. Bob PS. Thx for other response on ecn-encap - maana. On 17/05/2019 16:34, Black, David wrote: > > Before going further down the compliance rathole, let me suggest an > alternative that might resolve this quickly. > > The crucial text (whose technical correctness is not in question) is: > > In order that the network operator can comply with the above > > safety rules, even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > * it SHOULD be able to be configured to zero the outer ECN field. > > The headaches are being caused by treating that text as an update to > RFC 6040, but looking at it now, > > it reads like a best current practice recommendation, so > > Would it be reasonable to move that text into the ecn-encapsulation > draft (which is intended to become > > a BCP)? Doing that would sidestep the entire discussion of > consequences of the consequences of > > updating RFC 6040 with that text. > > If that sounds plausible, we should take a look at whether any of the > other RFC 6040 update text in section > > 4 should likewise be moved to the ECN encapsulation draft. > > Thanks, --David > > *From:*Bob Briscoe > *Sent:* Thursday, May 16, 2019 7:44 PM > *To:* Black, David; tsvwg@ietf.org > *Subject:* Re: [tsvwg] David Black's WGLC review of > draft-ietf-tsvwg-rfc6040update-shim-08 > > [EXTERNAL EMAIL] > > David, > > I'll split your email in two and solely deal with the major issue > first. See inline. > > On 09/05/2019 02:08, Black, David wrote: > > idnits found a couple of minor things: > > * Current reference for IKEv2 is RFC 7296 instead of RFC 5996 > * If any text was copied from pre-5378 RFCs, an additional > boilerplate disclaimer is required. > > Thanks, --David > > *From:* Black, David > *Sent:* Wednesday, May 8, 2019 8:50 PM > *To:* tsvwg@ietf.org > *Subject:* David Black's WGLC review of > draft-ietf-tsvwg-rfc6040update-shim-08 > > This is a solidly written draft on updating tunnel protocols that > use shim headers to propagate ECN according to RFC 6040. > > Unfortunately, I found a major issue with the updates [1] along > with a few minor issues (easily dealt with) and a bunch of > editorial items. > > The major issue [1] on updates creating non-compliant > implementations looks like it will need WG discussion on what > should be done, as the right thing to do appears to be in > potential conflict with deployed running code. > > --- Major --- > > [1] Compliance with RFC 6040 update > > Section 3.1 says: > > However, an RFC has no jurisdiction over implementations that choose > > not to comply with it or cannot comply with it, including all those > > implementations that pre-dated the RFC. Therefore it would have been > > unreasonable to add such a requirement to RFC 6040. > > But then Section 4 goes on to do exactly that by updating RFC 6040 to > > add this text: > > In order that the network operator can comply with the above > > safety rules, even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > * it SHOULD be able to be configured to zero the outer ECN field. > > followed by this attempt to excuse the result: > > There might be concern that the above "MUST" makes compliant > > equipment non-compliant at a stroke. However, any equipment that is > > still treating the former ToS octet (IPv4) or the former Traffic > > Class octet (IPv6) as a single 8-bit field is already non-compliant, > > and has been since 1998 when the upper 6 bits were separated off for > > the Diffserv field [RFC2474], [RFC3260]. For instance, copying the > > ECN field as a side-effect of copying the DSCP is a seriously unsafe > > bug that risks breaking the feedback loops that regulate load on a > > tunnel. > > These three chunks of text need to be aligned.. I'm not sure what > should > > be done here, as the concern about updating RFC 6040 to cause > non-compliance > > is an important concern. > > [BB] This draft proposes to update RFC6040, which in turn updated > RFC3168, which in turn updated RFC2474 (there were other RFCs in the > tree of updates ending at RFC6040, but those updates were not with > respect to the Diffserv/ECN fields). > > I fully agree that we have to be careful not to make any equipment > that already complies with any of these RFCs non-compliant. And we > don't... > > If any equipment does not satisfy the proposed 'MUST' statement above, > it will not be treating the DSCP and the ECN fields independently. > Such equipment would not have complied with RFC2474, which separated > out the last 2 bits of the ToS byte, which made it possible to specify > ECN in the first place. > > So the proposed 'MUST' statement does not make any equipment that > complied with any of these RFCs non-compliant, unless it was already > non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. > So the equipment would already be non-compliant with all these RFCs. > > Now, check the detailed wording: > > even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > > You'll notice RFC2474 is not in the list of RFCs that an > implementation might even not claim to support. That's because the > MUST is about Diffserv configuration. If equipment offers any Diffserv > configuration, it already has to comply with RFC2474. However, if it > doesn't already comply with this MUST, it already doesn't comply with > RFC2474. > > So again, this MUST does not make any equipment that complied with any > of the chain of RFCs non-compliant, unless they were already > non-compliant with RFC2474, and therefore non-compliant with all the > RFCs in the chain of updates up to RFC6040, because RFC2474 > grandfathered the chain. > > > > Analogous non-compliance concerns apply to the updates to other > RFCs in > > Section 5 to varying degrees. > > If you accept my arguments above, but can still find other > non-compliance concerns, please do point them out. > > Nonetheless, I'm pretty sure I've been similarly careful to avoid > introducing any non-compliance surprises. > > > > Bob > > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------2824BC9A2E92E9DBFF6D9FBE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit David,

Three push backs and a question:
a) The MUST and SHOULD you quote below are surely not BCP, they are straight protocol implementation spec.

b) I believe it is important that this safety update to RFC6040 is formally flagged as an update, so it gets noticed and hopefully acted upon.

c) Also, all the updates to specific protocols in the shim draft start with a section like the following example:
5.1.4.1. Safe Configuration of a 'Non-ECN' Ingress AMT Relay
The following text is appended to Section4.2.2 of [RFC7450] as an update to the AMT specification: The operator of an AMT relay that does not support RFC 6040 or one of its compatible predecessors (RFC 4301 or the full functionality mode of RFC 3168) MUST follow the configuration requirements in Section 4 of RFCXXXX to ensure it clears the outer IP ECN field to zero. {RFCXXXX refers to the present document so it will need to be inserted by the RFC Editor}

For implementers updating a particular protocol (e.g. AMT) it would be gratuitously weird to have moved Section 4 into a different RFC (especially one that did not have PS status).

d) Do you agree with my assessment that the MUST you quote below doesn't make anything non-compliant that wasn't already non-compliant with 2474. And anything that wants to claim support for anything to do with ECN has to comply with the aspect of 2474 that split off the last 2 bits from the ToS byte?

If so, there's no longer a problem to solve. Let's move on. This has dragged on long enough.


Bob

PS. Thx for other response on ecn-encap - maana.


On 17/05/2019 16:34, Black, David wrote:

Before going further down the compliance rathole, let me suggest an alternative that might resolve this quickly.

The crucial text (whose technical correctness is not in question) is:

In order that the network operator can comply with the above

safety rules, even if an implementation of a tunnel ingress does

not claim to support RFC 6040, RFC 4301 or the full functionality

mode of RFC 3168:

* it MUST make propagation of the ECN field between inner and

outer IP headers independent of any configuration of Diffserv

codepoint propagation;

* it SHOULD be able to be configured to zero the outer ECN field.

The headaches are being caused by treating that text as an update to RFC 6040, but looking at it now,

it reads like a best current practice recommendation, so

Would it be reasonable to move that text into the ecn-encapsulation draft (which is intended to become

a BCP)? Doing that would sidestep the entire discussion of consequences of the consequences of

updating RFC 6040 with that text.

If that sounds plausible, we should take a look at whether any of the other RFC 6040 update text in section

4 should likewise be moved to the ECN encapsulation draft.

Thanks, --David

From: Bob Briscoe <ietf@bobbriscoe.net>
Sent: Thursday, May 16, 2019 7:44 PM
To: Black, David; tsvwg@ietf.org
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

[EXTERNAL EMAIL]

David,

I'll split your email in two and solely deal with the major issue first. See inline.

On 09/05/2019 02:08, Black, David wrote:

idnits found a couple of minor things:

  • Current reference for IKEv2 is RFC 7296 instead of RFC 5996
  • If any text was copied from pre-5378 RFCs, an additional boilerplate disclaimer is required.

Thanks, --David

From: Black, David
Sent: Wednesday, May 8, 2019 8:50 PM
To: tsvwg@ietf.org
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

This is a solidly written draft on updating tunnel protocols that use shim headers to propagate ECN according to RFC 6040.

Unfortunately, I found a major issue with the updates [1] along with a few minor issues (easily dealt with) and a bunch of editorial items.

The major issue [1] on updates creating non-compliant implementations looks like it will need WG discussion on what should be done, as the right thing to do appears to be in potential conflict with deployed running code.

--- Major ---

[1] Compliance with RFC 6040 update

Section 3.1 says:

However, an RFC has no jurisdiction over implementations that choose

not to comply with it or cannot comply with it, including all those

implementations that pre-dated the RFC. Therefore it would have been

unreasonable to add such a requirement to RFC 6040.

But then Section 4 goes on to do exactly that by updating RFC 6040 to

add this text:

In order that the network operator can comply with the above

safety rules, even if an implementation of a tunnel ingress does

not claim to support RFC 6040, RFC 4301 or the full functionality

mode of RFC 3168:

* it MUST make propagation of the ECN field between inner and

outer IP headers independent of any configuration of Diffserv

codepoint propagation;

* it SHOULD be able to be configured to zero the outer ECN field.

followed by this attempt to excuse the result:

There might be concern that the above "MUST" makes compliant

equipment non-compliant at a stroke. However, any equipment that is

still treating the former ToS octet (IPv4) or the former Traffic

Class octet (IPv6) as a single 8-bit field is already non-compliant,

and has been since 1998 when the upper 6 bits were separated off for

the Diffserv field [RFC2474], [RFC3260]. For instance, copying the

ECN field as a side-effect of copying the DSCP is a seriously unsafe

bug that risks breaking the feedback loops that regulate load on a

tunnel.

These three chunks of text need to be aligned.. I'm not sure what should

be done here, as the concern about updating RFC 6040 to cause non-compliance

is an important concern.

[BB] This draft proposes to update RFC6040, which in turn updated RFC3168, which in turn updated RFC2474 (there were other RFCs in the tree of updates ending at RFC6040, but those updates were not with respect to the Diffserv/ECN fields).

I fully agree that we have to be careful not to make any equipment that already complies with any of these RFCs non-compliant. And we don't...

If any equipment does not satisfy the proposed 'MUST' statement above, it will not be treating the DSCP and the ECN fields independently. Such equipment would not have complied with RFC2474, which separated out the last 2 bits of the ToS byte, which made it possible to specify ECN in the first place.

So the proposed 'MUST' statement does not make any equipment that complied with any of these RFCs non-compliant, unless it was already non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. So the equipment would already be non-compliant with all these RFCs.

Now, check the detailed wording:

even if an implementation of a tunnel ingress does

not claim to support RFC 6040, RFC 4301 or the full functionality

mode of RFC 3168:

* it MUST make propagation of the ECN field between inner and

outer IP headers independent of any configuration of Diffserv

codepoint propagation;


You'll notice RFC2474 is not in the list of RFCs that an implementation might even not claim to support. That's because the MUST is about Diffserv configuration. If equipment offers any Diffserv configuration, it already has to comply with RFC2474. However, if it doesn't already comply with this MUST, it already doesn't comply with RFC2474.

So again, this MUST does not make any equipment that complied with any of the chain of RFCs non-compliant, unless they were already non-compliant with RFC2474, and therefore non-compliant with all the RFCs in the chain of updates up to RFC6040, because RFC2474 grandfathered the chain.



Analogous non-compliance concerns apply to the updates to other RFCs in

Section 5 to varying degrees.

If you accept my arguments above, but can still find other non-compliance concerns, please do point them out.

Nonetheless, I'm pretty sure I've been similarly careful to avoid introducing any non-compliance surprises.



Bob




-- 
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------2824BC9A2E92E9DBFF6D9FBE-- From nobody Sat May 18 00:57:50 2019 Return-Path: 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 AD9EA12014E for ; Sat, 18 May 2019 00:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 3fA8y1jXkdeR for ; Sat, 18 May 2019 00:57:44 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 68E8A1200FB for ; Sat, 18 May 2019 00:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:To:From:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=w99SKBvZRfl6uh7GtvB+AzrCmNOexslK/cU0P6vBybw=; b=BauIV58Ruv4frrzHJh9LCKBRS dG0DoiP5bf3+WjsyDvLxS+TtxSlOOs80jf8qoG1xUjH3meRjMraw5Zv6zwr+0BFOV9ogc1czHkQ0F D8PE/jcQoCmzjX8SyEmqFr9wqGUdfjaniLyvT6ngQ/LqED0o+LRsFaUtnjYk8PYuXC5E+oui2SXRr K/eVI64zKGOfqBPxXMyzQG00qS877VPe4Bi221515DNEL2iY/krai5+stfsaaaeUTIBTpxMVzujGv 9TBu4A9ePGyaQQBqzUBfq7RByBL/+J/hqQHYxygbo5+Sizhqg3tHKFisUYhdKdd/Rf+MClx6M8rIS DsMfcLq9Q==; Received: from [31.185.135.221] (port=33102 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hRuDr-0004lo-TJ; Sat, 18 May 2019 08:57:41 +0100 From: Bob Briscoe To: "Black, David" , "tsvwg@ietf.org" References: <89e67cfc-9574-c7a7-b837-c909c2180595@bobbriscoe.net> Message-ID: <63cb3350-7abe-7ec1-cd49-a983105111f6@bobbriscoe.net> Date: Sat, 18 May 2019 08:57:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7204D8BC908785051D02F0DD" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2019 07:57:48 -0000 This is a multi-part message in MIME format. --------------7204D8BC908785051D02F0DD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit David, An extra thought added to (d) below... On 18/05/2019 00:27, Bob Briscoe wrote: > David, > > Three push backs and a question: > a) The MUST and SHOULD you quote below are surely not BCP, they are > straight protocol implementation spec. > > b) I believe it is important that this safety update to RFC6040 is > formally flagged as an update, so it gets noticed and hopefully acted > upon. > > c) Also, all the updates to specific protocols in the shim draft start > with a section like the following example: > > > 5.1.4.1 > . > Safe Configuration of a 'Non-ECN' Ingress AMT Relay > > The following text is appended toSection4.2.2 of [RFC7450] as an > update to the AMT specification: > > The operator of an AMT relay that does not supportRFC 6040 or one > of its compatible predecessors (RFC 4301 or the full functionality > mode ofRFC 3168 ) MUST follow the configuration requirements in > Section 4 of RFCXXXX to ensure it clears the outer IP ECN field to > zero. {RFCXXXX refers to the present document so it will need to > be inserted by the RFC Editor} > > For implementers updating a particular protocol (e.g. AMT) it would be > gratuitously weird to have moved Section 4 into a different RFC > (especially one that did not have PS status). > > d) Do you agree with my assessment that the MUST you quote below > doesn't make anything non-compliant that wasn't already non-compliant > with 2474. And anything that wants to claim support for anything to do > with ECN has to comply with the aspect of 2474 that split off the last > 2 bits from the ToS byte? > > If so, there's no longer a problem to solve. Let's move on. This has > dragged on long enough. [BB] Would the following text change to S.4 of the shim draft also help? CURRENT: There might be concern that the above "MUST" makes compliant equipment non-compliant at a stroke. However, any equipment that is still treating the former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field is already non-compliant, and has been since 1998 when the upper 6 bits were separated off for the Diffserv field [RFC2474 ], [RFC3260 ]. SUGGESTED: There might be concern that the above "MUST" makes compliant equipment non-compliant at a stroke. However, by definition it solely applies to equipment that provides Diffserv configuration. Any such Diffserv equipment that is configuring treatment of the former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field must have always been non-compliant with the definition of the 6-bit Diffserv codepoint in [RFC2474 ]. Bob > > > Bob > > PS. Thx for other response on ecn-encap - maana. > > > On 17/05/2019 16:34, Black, David wrote: >> >> Before going further down the compliance rathole, let me suggest an >> alternative that might resolve this quickly. >> >> The crucial text (whose technical correctness is not in question) is: >> >> In order that the network operator can comply with the above >> >> safety rules, even if an implementation of a tunnel ingress does >> >> not claim to support RFC 6040, RFC 4301 or the full functionality >> >> mode of RFC 3168: >> >> * it MUST make propagation of the ECN field between inner and >> >> outer IP headers independent of any configuration of Diffserv >> >> codepoint propagation; >> >> * it SHOULD be able to be configured to zero the outer ECN field. >> >> The headaches are being caused by treating that text as an update to >> RFC 6040, but looking at it now, >> >> it reads like a best current practice recommendation, so >> >> Would it be reasonable to move that text into the ecn-encapsulation >> draft (which is intended to become >> >> a BCP)? Doing that would sidestep the entire discussion of >> consequences of the consequences of >> >> updating RFC 6040 with that text. >> >> If that sounds plausible, we should take a look at whether any of the >> other RFC 6040 update text in section >> >> 4 should likewise be moved to the ECN encapsulation draft. >> >> Thanks, --David >> >> *From:*Bob Briscoe >> *Sent:* Thursday, May 16, 2019 7:44 PM >> *To:* Black, David; tsvwg@ietf.org >> *Subject:* Re: [tsvwg] David Black's WGLC review of >> draft-ietf-tsvwg-rfc6040update-shim-08 >> >> [EXTERNAL EMAIL] >> >> David, >> >> I'll split your email in two and solely deal with the major issue >> first. See inline. >> >> On 09/05/2019 02:08, Black, David wrote: >> >> idnits found a couple of minor things: >> >> * Current reference for IKEv2 is RFC 7296 instead of RFC 5996 >> * If any text was copied from pre-5378 RFCs, an additional >> boilerplate disclaimer is required. >> >> Thanks, --David >> >> *From:* Black, David >> *Sent:* Wednesday, May 8, 2019 8:50 PM >> *To:* tsvwg@ietf.org >> *Subject:* David Black's WGLC review of >> draft-ietf-tsvwg-rfc6040update-shim-08 >> >> This is a solidly written draft on updating tunnel protocols that >> use shim headers to propagate ECN according to RFC 6040. >> >> Unfortunately, I found a major issue with the updates [1] along >> with a few minor issues (easily dealt with) and a bunch of >> editorial items. >> >> The major issue [1] on updates creating non-compliant >> implementations looks like it will need WG discussion on what >> should be done, as the right thing to do appears to be in >> potential conflict with deployed running code. >> >> --- Major --- >> >> [1] Compliance with RFC 6040 update >> >> Section 3.1 says: >> >> However, an RFC has no jurisdiction over implementations that choose >> >> not to comply with it or cannot comply with it, including all those >> >> implementations that pre-dated the RFC. Therefore it would have been >> >> unreasonable to add such a requirement to RFC 6040. >> >> But then Section 4 goes on to do exactly that by updating RFC 6040 to >> >> add this text: >> >> In order that the network operator can comply with the above >> >> safety rules, even if an implementation of a tunnel ingress does >> >> not claim to support RFC 6040, RFC 4301 or the full functionality >> >> mode of RFC 3168: >> >> * it MUST make propagation of the ECN field between inner and >> >> outer IP headers independent of any configuration of Diffserv >> >> codepoint propagation; >> >> * it SHOULD be able to be configured to zero the outer ECN field. >> >> followed by this attempt to excuse the result: >> >> There might be concern that the above "MUST" makes compliant >> >> equipment non-compliant at a stroke. However, any equipment that is >> >> still treating the former ToS octet (IPv4) or the former Traffic >> >> Class octet (IPv6) as a single 8-bit field is already non-compliant, >> >> and has been since 1998 when the upper 6 bits were separated off for >> >> the Diffserv field [RFC2474], [RFC3260]. For instance, copying the >> >> ECN field as a side-effect of copying the DSCP is a seriously unsafe >> >> bug that risks breaking the feedback loops that regulate load on a >> >> tunnel. >> >> These three chunks of text need to be aligned.. I'm not sure >> what should >> >> be done here, as the concern about updating RFC 6040 to cause >> non-compliance >> >> is an important concern. >> >> [BB] This draft proposes to update RFC6040, which in turn updated >> RFC3168, which in turn updated RFC2474 (there were other RFCs in the >> tree of updates ending at RFC6040, but those updates were not with >> respect to the Diffserv/ECN fields). >> >> I fully agree that we have to be careful not to make any equipment >> that already complies with any of these RFCs non-compliant. And we >> don't... >> >> If any equipment does not satisfy the proposed 'MUST' statement >> above, it will not be treating the DSCP and the ECN fields >> independently. Such equipment would not have complied with RFC2474, >> which separated out the last 2 bits of the ToS byte, which made it >> possible to specify ECN in the first place. >> >> So the proposed 'MUST' statement does not make any equipment that >> complied with any of these RFCs non-compliant, unless it was already >> non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. >> So the equipment would already be non-compliant with all these RFCs. >> >> Now, check the detailed wording: >> >> even if an implementation of a tunnel ingress does >> >> not claim to support RFC 6040, RFC 4301 or the full functionality >> >> mode of RFC 3168: >> >> * it MUST make propagation of the ECN field between inner and >> >> outer IP headers independent of any configuration of Diffserv >> >> codepoint propagation; >> >> >> You'll notice RFC2474 is not in the list of RFCs that an >> implementation might even not claim to support. That's because the >> MUST is about Diffserv configuration. If equipment offers any >> Diffserv configuration, it already has to comply with RFC2474. >> However, if it doesn't already comply with this MUST, it already >> doesn't comply with RFC2474. >> >> So again, this MUST does not make any equipment that complied with >> any of the chain of RFCs non-compliant, unless they were already >> non-compliant with RFC2474, and therefore non-compliant with all the >> RFCs in the chain of updates up to RFC6040, because RFC2474 >> grandfathered the chain. >> >> >> >> Analogous non-compliance concerns apply to the updates to other >> RFCs in >> >> Section 5 to varying degrees. >> >> If you accept my arguments above, but can still find other >> non-compliance concerns, please do point them out. >> >> Nonetheless, I'm pretty sure I've been similarly careful to avoid >> introducing any non-compliance surprises. >> >> >> >> Bob >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------7204D8BC908785051D02F0DD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit David, An extra thought added to (d) below...

On 18/05/2019 00:27, Bob Briscoe wrote:
David,

Three push backs and a question:
a) The MUST and SHOULD you quote below are surely not BCP, they are straight protocol implementation spec.

b) I believe it is important that this safety update to RFC6040 is formally flagged as an update, so it gets noticed and hopefully acted upon.

c) Also, all the updates to specific protocols in the shim draft start with a section like the following example:
5.1.4.1. Safe Configuration of a 'Non-ECN' Ingress AMT Relay
The following text is appended to Section4.2.2 of [RFC7450] as an update to the AMT specification: The operator of an AMT relay that does not support RFC 6040 or one of its compatible predecessors (RFC 4301 or the full functionality mode of RFC 3168) MUST follow the configuration requirements in Section 4 of RFCXXXX to ensure it clears the outer IP ECN field to zero. {RFCXXXX refers to the present document so it will need to be inserted by the RFC Editor}

For implementers updating a particular protocol (e.g. AMT) it would be gratuitously weird to have moved Section 4 into a different RFC (especially one that did not have PS status).

d) Do you agree with my assessment that the MUST you quote below doesn't make anything non-compliant that wasn't already non-compliant with 2474. And anything that wants to claim support for anything to do with ECN has to comply with the aspect of 2474 that split off the last 2 bits from the ToS byte?

If so, there's no longer a problem to solve. Let's move on. This has dragged on long enough.

[BB] Would the following text change to S.4 of the shim draft also help?

CURRENT:
   There might be concern that the above "MUST" makes compliant
   equipment non-compliant at a stroke.  However, any equipment that is
   still treating the former ToS octet (IPv4) or the former Traffic
   Class octet (IPv6) as a single 8-bit field is already non-compliant,
   and has been since 1998 when the upper 6 bits were separated off for
   the Diffserv field [RFC2474], [RFC3260].  
SUGGESTED:
   There might be concern that the above "MUST" makes compliant
   equipment non-compliant at a stroke.  However, by definition it solely applies to
  equipment that provides Diffserv configuration. Any such Diffserv equipment that is 
   configuring treatment of the former ToS octet (IPv4) or the former Traffic
   Class octet (IPv6) as a single 8-bit field must have always been non-compliant 
   with the definition of the 6-bit Diffserv codepoint in [RFC2474].



Bob



Bob

PS. Thx for other response on ecn-encap - maana.


On 17/05/2019 16:34, Black, David wrote:

Before going further down the compliance rathole, let me suggest an alternative that might resolve this quickly.

The crucial text (whose technical correctness is not in question) is:

In order that the network operator can comply with the above

safety rules, even if an implementation of a tunnel ingress does

not claim to support RFC 6040, RFC 4301 or the full functionality

mode of RFC 3168:

* it MUST make propagation of the ECN field between inner and

outer IP headers independent of any configuration of Diffserv

codepoint propagation;

* it SHOULD be able to be configured to zero the outer ECN field.

The headaches are being caused by treating that text as an update to RFC 6040, but looking at it now,

it reads like a best current practice recommendation, so

Would it be reasonable to move that text into the ecn-encapsulation draft (which is intended to become

a BCP)? Doing that would sidestep the entire discussion of consequences of the consequences of

updating RFC 6040 with that text.

If that sounds plausible, we should take a look at whether any of the other RFC 6040 update text in section

4 should likewise be moved to the ECN encapsulation draft.

Thanks, --David

From: Bob Briscoe <ietf@bobbriscoe.net>
Sent: Thursday, May 16, 2019 7:44 PM
To: Black, David; tsvwg@ietf.org
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

[EXTERNAL EMAIL]

David,

I'll split your email in two and solely deal with the major issue first. See inline.

On 09/05/2019 02:08, Black, David wrote:

idnits found a couple of minor things:

  • Current reference for IKEv2 is RFC 7296 instead of RFC 5996
  • If any text was copied from pre-5378 RFCs, an additional boilerplate disclaimer is required.

Thanks, --David

From: Black, David
Sent: Wednesday, May 8, 2019 8:50 PM
To: tsvwg@ietf.org
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

This is a solidly written draft on updating tunnel protocols that use shim headers to propagate ECN according to RFC 6040.

Unfortunately, I found a major issue with the updates [1] along with a few minor issues (easily dealt with) and a bunch of editorial items.

The major issue [1] on updates creating non-compliant implementations looks like it will need WG discussion on what should be done, as the right thing to do appears to be in potential conflict with deployed running code.

--- Major ---

[1] Compliance with RFC 6040 update

Section 3.1 says:

However, an RFC has no jurisdiction over implementations that choose

not to comply with it or cannot comply with it, including all those

implementations that pre-dated the RFC. Therefore it would have been

unreasonable to add such a requirement to RFC 6040.

But then Section 4 goes on to do exactly that by updating RFC 6040 to

add this text:

In order that the network operator can comply with the above

safety rules, even if an implementation of a tunnel ingress does

not claim to support RFC 6040, RFC 4301 or the full functionality

mode of RFC 3168:

* it MUST make propagation of the ECN field between inner and

outer IP headers independent of any configuration of Diffserv

codepoint propagation;

* it SHOULD be able to be configured to zero the outer ECN field.

followed by this attempt to excuse the result:

There might be concern that the above "MUST" makes compliant

equipment non-compliant at a stroke. However, any equipment that is

still treating the former ToS octet (IPv4) or the former Traffic

Class octet (IPv6) as a single 8-bit field is already non-compliant,

and has been since 1998 when the upper 6 bits were separated off for

the Diffserv field [RFC2474], [RFC3260]. For instance, copying the

ECN field as a side-effect of copying the DSCP is a seriously unsafe

bug that risks breaking the feedback loops that regulate load on a

tunnel.

These three chunks of text need to be aligned.. I'm not sure what should

be done here, as the concern about updating RFC 6040 to cause non-compliance

is an important concern.

[BB] This draft proposes to update RFC6040, which in turn updated RFC3168, which in turn updated RFC2474 (there were other RFCs in the tree of updates ending at RFC6040, but those updates were not with respect to the Diffserv/ECN fields).

I fully agree that we have to be careful not to make any equipment that already complies with any of these RFCs non-compliant. And we don't...

If any equipment does not satisfy the proposed 'MUST' statement above, it will not be treating the DSCP and the ECN fields independently. Such equipment would not have complied with RFC2474, which separated out the last 2 bits of the ToS byte, which made it possible to specify ECN in the first place.

So the proposed 'MUST' statement does not make any equipment that complied with any of these RFCs non-compliant, unless it was already non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. So the equipment would already be non-compliant with all these RFCs.

Now, check the detailed wording:

even if an implementation of a tunnel ingress does

not claim to support RFC 6040, RFC 4301 or the full functionality

mode of RFC 3168:

* it MUST make propagation of the ECN field between inner and

outer IP headers independent of any configuration of Diffserv

codepoint propagation;


You'll notice RFC2474 is not in the list of RFCs that an implementation might even not claim to support. That's because the MUST is about Diffserv configuration. If equipment offers any Diffserv configuration, it already has to comply with RFC2474. However, if it doesn't already comply with this MUST, it already doesn't comply with RFC2474.

So again, this MUST does not make any equipment that complied with any of the chain of RFCs non-compliant, unless they were already non-compliant with RFC2474, and therefore non-compliant with all the RFCs in the chain of updates up to RFC6040, because RFC2474 grandfathered the chain.



Analogous non-compliance concerns apply to the updates to other RFCs in

Section 5 to varying degrees.

If you accept my arguments above, but can still find other non-compliance concerns, please do point them out.

Nonetheless, I'm pretty sure I've been similarly careful to avoid introducing any non-compliance surprises.



Bob




-- 
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------7204D8BC908785051D02F0DD-- From nobody Sat May 18 01:14:21 2019 Return-Path: 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 D7F8B1200B7 for ; Sat, 18 May 2019 01:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 Tjqo2j2uk88T for ; Sat, 18 May 2019 01:14:17 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4E120089 for ; Sat, 18 May 2019 01:14:16 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 449811B00082; Sat, 18 May 2019 09:14:12 +0100 (BST) Message-ID: <5CDFBED3.7070207@erg.abdn.ac.uk> Date: Sat, 18 May 2019 09:14:11 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Black, David" CC: Bob Briscoe , "tsvwg@ietf.org" References: <89e67cfc-9574-c7a7-b837-c909c2180595@bobbriscoe.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2019 08:14:20 -0000 Just one check below: On 17/05/2019, 16:34, Black, David wrote: > > Before going further down the compliance rathole, let me suggest an > alternative that might resolve this quickly. > > The crucial text (whose technical correctness is not in question) is: > > In order that the network operator can comply with the above > > safety rules, even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > * it SHOULD be able to be configured to zero the outer ECN field. > > The headaches are being caused by treating that text as an update to > RFC 6040, but looking at it now, > > it reads like a best current practice recommendation, so > > Would it be reasonable to move that text into the ecn-encapsulation > draft (which is intended to become > > a BCP)? Doing that would sidestep the entire discussion of > consequences of the consequences of > > updating RFC 6040 with that text. > > If that sounds plausible, we should take a look at whether any of the > other RFC 6040 update text in section > > 4 should likewise be moved to the ECN encapsulation draft. > I had to read this several times, and wasn't quite sure: * it SHOULD be able to be configured to zero the outer ECN field. Was the intention that: * the configuration SHOULD allow a sender to zero the ECN field in the outer header. Gorry > Thanks, --David > > *From:*Bob Briscoe > *Sent:* Thursday, May 16, 2019 7:44 PM > *To:* Black, David; tsvwg@ietf.org > *Subject:* Re: [tsvwg] David Black's WGLC review of > draft-ietf-tsvwg-rfc6040update-shim-08 > > [EXTERNAL EMAIL] > > David, > > I'll split your email in two and solely deal with the major issue > first. See inline. > > On 09/05/2019 02:08, Black, David wrote: > > idnits found a couple of minor things: > > * Current reference for IKEv2 is RFC 7296 instead of RFC 5996 > * If any text was copied from pre-5378 RFCs, an additional > boilerplate disclaimer is required. > > Thanks, --David > > *From:* Black, David > *Sent:* Wednesday, May 8, 2019 8:50 PM > *To:* tsvwg@ietf.org > *Subject:* David Black's WGLC review of > draft-ietf-tsvwg-rfc6040update-shim-08 > > This is a solidly written draft on updating tunnel protocols that > use shim headers to propagate ECN according to RFC 6040. > > Unfortunately, I found a major issue with the updates [1] along > with a few minor issues (easily dealt with) and a bunch of > editorial items. > > The major issue [1] on updates creating non-compliant > implementations looks like it will need WG discussion on what > should be done, as the right thing to do appears to be in > potential conflict with deployed running code. > > --- Major --- > > [1] Compliance with RFC 6040 update > > Section 3.1 says: > > However, an RFC has no jurisdiction over implementations that choose > > not to comply with it or cannot comply with it, including all those > > implementations that pre-dated the RFC. Therefore it would have been > > unreasonable to add such a requirement to RFC 6040. > > But then Section 4 goes on to do exactly that by updating RFC 6040 to > > add this text: > > In order that the network operator can comply with the above > > safety rules, even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > * it SHOULD be able to be configured to zero the outer ECN field. > > followed by this attempt to excuse the result: > > There might be concern that the above "MUST" makes compliant > > equipment non-compliant at a stroke. However, any equipment that is > > still treating the former ToS octet (IPv4) or the former Traffic > > Class octet (IPv6) as a single 8-bit field is already non-compliant, > > and has been since 1998 when the upper 6 bits were separated off for > > the Diffserv field [RFC2474], [RFC3260]. For instance, copying the > > ECN field as a side-effect of copying the DSCP is a seriously unsafe > > bug that risks breaking the feedback loops that regulate load on a > > tunnel. > > These three chunks of text need to be aligned.. I'm not sure what > should > > be done here, as the concern about updating RFC 6040 to cause > non-compliance > > is an important concern. > > [BB] This draft proposes to update RFC6040, which in turn updated > RFC3168, which in turn updated RFC2474 (there were other RFCs in the > tree of updates ending at RFC6040, but those updates were not with > respect to the Diffserv/ECN fields). > > I fully agree that we have to be careful not to make any equipment > that already complies with any of these RFCs non-compliant. And we > don't... > > If any equipment does not satisfy the proposed 'MUST' statement above, > it will not be treating the DSCP and the ECN fields independently. > Such equipment would not have complied with RFC2474, which separated > out the last 2 bits of the ToS byte, which made it possible to specify > ECN in the first place. > > So the proposed 'MUST' statement does not make any equipment that > complied with any of these RFCs non-compliant, unless it was already > non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. > So the equipment would already be non-compliant with all these RFCs. > > Now, check the detailed wording: > > even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > > You'll notice RFC2474 is not in the list of RFCs that an > implementation might even not claim to support. That's because the > MUST is about Diffserv configuration. If equipment offers any Diffserv > configuration, it already has to comply with RFC2474. However, if it > doesn't already comply with this MUST, it already doesn't comply with > RFC2474. > > So again, this MUST does not make any equipment that complied with any > of the chain of RFCs non-compliant, unless they were already > non-compliant with RFC2474, and therefore non-compliant with all the > RFCs in the chain of updates up to RFC6040, because RFC2474 > grandfathered the chain. > > > > Analogous non-compliance concerns apply to the updates to other > RFCs in > > Section 5 to varying degrees. > > If you accept my arguments above, but can still find other > non-compliance concerns, please do point them out. > > Nonetheless, I'm pretty sure I've been similarly careful to avoid > introducing any non-compliance surprises. > > > > Bob > > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ From nobody Sat May 18 09:42:02 2019 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B3612006F; Sat, 18 May 2019 09:41:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-tsvwg-tinymt32@ietf.org, Wesley Eddy , tsvwg-chairs@ietf.org, wes@mti-systems.com, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155819771284.30983.4110220898246275651.idtracker@ietfa.amsl.com> Date: Sat, 18 May 2019 09:41:52 -0700 Archived-At: Subject: [tsvwg] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-tsvwg-tinymt32-02=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2019 16:41:53 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-tsvwg-tinymt32-02: No Objection When responding, please keep the subject line