From nobody Mon Dec 2 03:15:27 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C69A120047 for ; Mon, 2 Dec 2019 03:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 rbT586GfRs1M for ; Mon, 2 Dec 2019 03:15:21 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 06FBC120020 for ; Mon, 2 Dec 2019 03:15:21 -0800 (PST) Received: from 200116b82c262800d41b4bca626cdd5e.dip.versatel-1u1.de ([2001:16b8:2c26:2800:d41b:4bca:626c:dd5e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ibjfj-00066r-2p; Mon, 02 Dec 2019 12:15:19 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> Date: Mon, 2 Dec 2019 12:15:18 +0100 Cc: Jonathan Morton , tcpm IETF list , Richard Scheffenegger Content-Transfer-Encoding: quoted-printable Message-Id: References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1575285321;0f1961c5; X-HE-SMSGID: 1ibjfj-00066r-2p Archived-At: Subject: Re: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 11:15:23 -0000 Hi Bob, Regarding the sentence: "I just proposed respectively SHOULD and MAY, but I can now see there is = no need to make that judgement call. However, it is still important to = say an AccECN-enabled server MUST respond with either (0,0,1) or = (0,0,0).=E2=80=9D This is a normative statement that is defined in RFC3168 and we should = not state it here again but refer to RFC3168 instead. Mirja > On 25. Nov 2019, at 22:41, Bob Briscoe wrote: >=20 > Mirja, >=20 >=20 > On 26/11/2019 01:02, Mirja Kuehlewind wrote: >> Hi Jonathan, >>=20 >> Sorry I wasn=E2=80=99t clear. I think we should not have these = normative requirement in the draft and change the text to make it = non-normative. This section was meant to explain which modes you end up = in and the current use of normative language doesn=E2=80=99t seem to be = right to me. >>=20 >> Likewise the table was also not meant to say whenever you implement = AccECN, you MUST negotiate it in the handshake. And likewise the table = does not show any classic ECN only transitions. > In the spec of AccECN, it's necessary and reasonable to state = normative requirements for a node "that is AccECN-enabled". That doesn't = mean that an AccECN implementation has to always support AccECN - it can = always disable AccECN. But we do have to say what it is expected to do = if it is following the AccECN protocol. >=20 > This draft has included that normative language for the negotiation = phase in all 16 revisions since the first individual draft (that you = wrote!). >=20 > The table shows only cases where one end or the other is = AccECN-capable, and the text preceding and following the table gives = normative requirements solely for the AccECN node(s) in those cases. It = doesn't give any normative requirements for non-AccECN nodes. >=20 > In block 3, the server is AccECN capable, so in the AccECN spec. it's = perfectly reasonable to say what it ought to do in response to various = types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=3D0,0,0 = the AccECN-enabled server MUST respond with AE,CWR,ECE=3D0,0,0. >=20 > The only case that is in question, AFAIC, is whether we have to say = what an AccECN-capable server does in response to a SYN from an RFC3168 = client (AE,CWR,ECE=3D0,1,1). We need to somehow say an AccECN server can = respond with a SYN-ACK that is either RFC3168 or non-ECN. >=20 > I just proposed respectively SHOULD and MAY, but I can now see there = is no need to make that judgement call. However, it is still important = to say an AccECN-enabled server MUST respond with either (0,0,1) or = (0,0,0). >=20 > It's also important that the spec defines all three bits in the = SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the = combinations with AE=3D1 are ruled out and therefore remain available = for future use. >=20 >=20 >=20 > Bob >>=20 >> Mirja >>=20 >>=20 >>> On 25. Nov 2019, at 17:48, Jonathan Morton = wrote: >>>=20 >>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind = wrote: >>>>=20 >>>> I don=E2=80=99t think we can or should derive a normative = requirement from this table. The table rather explains which mode you = are in depending on the handshake that has happened. So it says: when = client A is ECN capable and requests classic ECN support in the = handshake and server B is AccECN capable and negotiated classic ECN = support in the handshake then you are in classic ECN mode. >>> I will merely re-quote the final sentence from my quoted text, which = transforms that table into a normative requirement: >>>=20 >>>> Therefore, as soon as an >>>> AccECN-enabled TCP server (B) receives the SYN shown, it MUST = set >>>> both its half connections into the feedback mode shown in the >>>> rightmost column. >>> - Jonathan Morton >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 >=20 From nobody Mon Dec 2 06:28:54 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 687AB12000F; Mon, 2 Dec 2019 06:28:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <157529693336.4311.2154215186520097572@ietfa.amsl.com> Date: Mon, 02 Dec 2019 06:28:53 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 14:28:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : Retransmission Timeout Requirements Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-09.txt Pages : 10 Date : 2019-12-02 Abstract: Ensuring reliable communication often manifests in a timeout and retry mechanism. Each implementation of a retransmission timeout mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for retransmission timeout schemes appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-09 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-09 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 Mon Dec 2 13:48:27 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAA9120018; Mon, 2 Dec 2019 13:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 BN_wX68NBWSg; Mon, 2 Dec 2019 13:48:23 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD8112008C; Mon, 2 Dec 2019 13:48:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 9908325A25; Mon, 2 Dec 2019 22:48:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1575323301; bh=en6n8+U39QeQZOa9VXuhScmpZgA+T3YsqnCflillWns=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ahL/TEm+UOr4xBj2+XgYzUrPriyTt5sm6W9dHL+cXDzwTo1FtRjEmqeNNKnZq8AWm COXnUupDIokla0ZOidCu4yJdEmf4SZz+dhr5k2caMI8U76LDNC5CkuZI85FLB1a649 2RW5y6K/mg6vRO/wVmboQks+WsHrg06oc7X1ETcU= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2T_36rCTIV9; Mon, 2 Dec 2019 22:48:19 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 2 Dec 2019 22:48:19 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.242]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 2 Dec 2019 22:48:18 +0100 From: "Scharf, Michael" To: Joe Touch CC: tcpm IETF list , "draft-scharf-tcpm-yang-tcp@ietf.org" Thread-Topic: [tcpm] Open questions in draft-scharf-tcpm-yang-tcp-03 Thread-Index: AdWmGolxZReXGVxfT16zv56GRPhU5AAtLhiAAKHpWHA= Date: Mon, 2 Dec 2019 21:48:17 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D56A3CF@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D54D9D2@rznt8114.rznt.rzdir.fht-esslingen.de> <5491D316-6F86-4DD1-A92C-E64D41986823@strayalpha.com> In-Reply-To: <5491D316-6F86-4DD1-A92C-E64D41986823@strayalpha.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Open questions in draft-scharf-tcpm-yang-tcp-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 21:48:26 -0000 SGkgSm9lLA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSBmZWVkYmFjay4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2UgVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29t Pg0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDI5LCAyMDE5IDY6MDkgUE0NCj4gVG86IFNjaGFy ZiwgTWljaGFlbCA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPg0KPiBDYzogdGNwbSBJ RVRGIGxpc3QgPHRjcG1AaWV0Zi5vcmc+OyBkcmFmdC1zY2hhcmYtdGNwbS15YW5nLXRjcEBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3RjcG1dIE9wZW4gcXVlc3Rpb25zIGluIGRyYWZ0LXNjaGFy Zi10Y3BtLXlhbmctdGNwLTAzDQo+IA0KPiBIaSwgTWljaGFlbCwNCj4gDQo+ID4gT24gTm92IDI4 LCAyMDE5LCBhdCAxMDozNyBBTSwgU2NoYXJmLCBNaWNoYWVsIDxNaWNoYWVsLlNjaGFyZkBocy0N Cj4gZXNzbGluZ2VuLmRlPiB3cm90ZToNCj4gPg0KPiA+IFtjaGFpciBoYXQgb2ZmXQ0KPiA+DQo+ ID4gQXQgSUVURiAxMDYgdGhlcmUgd2FzIG5vdCBlbm91Z2ggdGltZSBsZWZ0IGZvciBNYWhlc2gg dG8gcHJlc2VudCB0aGUgbGF0ZXN0DQo+IHVwZGF0ZSBvZiB0aGUgZG9jdW1lbnQgIllBTkcgTW9k ZWwgZm9yIFRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sIChUQ1ApDQo+IENvbmZpZ3VyYXRp b24iLg0KPiA+DQo+ID4gTWFoZXNoLCBWaXNoYWwgYW5kIG1lIGhhdmUgc2lnbmlmaWNhbnRseSB1 cGRhdGVkIGRyYWZ0LXNjaGFyZi10Y3BtLXlhbmctDQo+IHRjcC0wMyBzaW5jZSB0aGUgbGFzdCBt ZWV0aW5nLiBUaGUgY2hhbmdlcyBhcmUgc3VtbWFyaXplZCBpbiB0aGUgc2xpZGVzIHRoYXQNCj4g Y2FuIGJlIGZvdW5kIGF0Og0KPiA+DQo+ID4gICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTA2L21hdGVyaWFscy9zbGlkZXMtMTA2LXRjcG0teWFuZy0NCj4gbW9kZWwtZm9y LXRyYW5zbWlzc2lvbi1jb250cm9sLXByb3RvY29sLXRjcC1jb25maWd1cmF0aW9uLTAxDQo+ID4N Cj4gPiBPdXIgcHJvcG9zYWwgdG8gcmVmaW5lIHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQuIFRo aXMgcmVzdWx0cyBpbiBhdCBsZWFzdCA0DQo+IHF1ZXN0aW9uczoNCj4gPg0KPiA+IDEuIFNob3Vs ZCB0aGUgbW9kZWwgc3VwcG9ydCBzdGF0aXN0aWNzPw0KPiANCj4gSU1PLCBubyAtIHRoYXQgc2hv dWxkIGJlIGEgZGlmZmVyZW50LCBvcHRpb25hbCBtb2RlbCAoVENQLXN0YXRzIG9yIHNvbWV0aGlu ZykuDQoNCkkgZ3Vlc3MgdXNpbmcgYSBzZXBhcmF0ZSBtb2R1bGUgd291bGQgYmUgcG9zc2libGUu IFdlIGNhbiB0cnkgdG8gY29tZSB1cCB3aXRoIGEgcHJvcG9zYWwgdGhhdCBrZWVwcyB0aGUgc3Rh dHMgc2VwYXJhdGUuDQoNCj4gPiAyLiBTaG91bGQgaXQgbW9kZWwgYWxsIFRDUCBjb25uZWN0aW9u cz8NCj4gDQo+IEkgZG9u4oCZdCBrbm93IHdoYXQgdGhhdCBtZWFucywgZXZlbiBnaXZlbiB0aGUg c2xpZGVzLiBJIHdvdWxkIGV4cGVjdCB0aGVyZSB0byBiZQ0KPiBzb21lIGNvbW1vbiBwcmFjdGlj ZSBmb3IgdGhpcyBpbiBZQU5HIG1vZGVscywgaS5lLiwgdG8gZGVzY3JpYmUgaG93IHN0YXRlIGlz DQo+IGdyb3VwZWQgYnkgYWRkcmVzcy4NCg0KVGhlIFRDUC1NSUIgaGFkIGEgVENQIGNvbm5lY3Rp b24gbGlzdCwgYXMgZXhwbGFpbmVkIGluIGRyYWZ0IHZlcnNpb24gLTAwLiBJbiBZQU5HLCB0aGUg b3JpZ2luYWwgVENQLU1JQiBlbnRyaWVzIHdvdWxkIGxvb2sgYXMgZm9sbG93cyAoanVzdCBsaXN0 ZWQgaGVyZSBhcyBpbGx1c3RyYXRpb24pOg0KDQogICAgICstLXJ3IHRjcENvbm5lY3Rpb25FbnRy eSogW3RjcENvbm5lY3Rpb25Mb2NhbEFkZHJlc3NUeXBlIHRjcENvbm5lY3Rpb25Mb2NhbEFkZHJl c3MgdGNwQ29ubmVjdGlvbkxvY2FsUG9ydCB0Y3BDb25uZWN0aW9uUmVtQWRkcmVzc1R5cGUgdGNw Q29ubmVjdGlvblJlbUFkZHJlc3MgdGNwQ29ubmVjdGlvblJlbVBvcnRdDQogICAgICAgfCAgKy0t cm8gdGNwQ29ubmVjdGlvbkxvY2FsQWRkcmVzc1R5cGUgICAgaW5ldC1hZGRyZXNzOkluZXRBZGRy ZXNzVHlwZQ0KICAgICAgIHwgICstLXJvIHRjcENvbm5lY3Rpb25Mb2NhbEFkZHJlc3MgICAgICAg IGluZXQtYWRkcmVzczpJbmV0QWRkcmVzcw0KICAgICAgIHwgICstLXJvIHRjcENvbm5lY3Rpb25M b2NhbFBvcnQgICAgICAgICAgIGluZXQtYWRkcmVzczpJbmV0UG9ydE51bWJlcg0KICAgICAgIHwg ICstLXJvIHRjcENvbm5lY3Rpb25SZW1BZGRyZXNzVHlwZSAgICAgIGluZXQtYWRkcmVzczpJbmV0 QWRkcmVzc1R5cGUNCiAgICAgICB8ICArLS1ybyB0Y3BDb25uZWN0aW9uUmVtQWRkcmVzcyAgICAg ICAgICBpbmV0LWFkZHJlc3M6SW5ldEFkZHJlc3MNCiAgICAgICB8ICArLS1ybyB0Y3BDb25uZWN0 aW9uUmVtUG9ydCAgICAgICAgICAgICBpbmV0LWFkZHJlc3M6SW5ldFBvcnROdW1iZXINCiAgICAg ICB8ICArLS1ydyB0Y3BDb25uZWN0aW9uU3RhdGU/ICAgICAgICAgICAgICBlbnVtZXJhdGlvbg0K ICAgICAgIHwgICstLXJvIHRjcENvbm5lY3Rpb25Qcm9jZXNzPyAgICAgICAgICAgIHVpbnQzMg0K DQpUaGVyZSBzZWVtIHRvIGJlIHVzZSBjYXNlcyBpbiB3aGljaCBhIFRDUCBjb25uZWN0aW9uIGxp c3QgY291bGQgYmUgdXNlZnVsLCBtb3N0IG5vdGFibHkgc2luY2Ugc3VjaCBhIGxpc3QgbWF0dGVy cyBmb3IgYSBudW1iZXIgb2YgYXBwbGljYXRpb24gcHJvdG9jb2xzLiBBIGJlbmVmaXQgb2YgaGF2 aW5nIHRoaXMgaW4gYSBtb2RlbCBwdWJsaXNoZWQgYnkgVENQTSB3b3VsZCBiZSBjb25zaXN0ZW5j eTsgdGhlbiBvdGhlciB3b3JraW5nIGdyb3VwcyB3b3VsZCBub3QgaGF2ZSB0byByZWludmVudCB0 aGUgd2hlZWwgd2hlbiBoYXZpbmcgdG8gYWNjZXNzIGEgbGlzdCBvZiBUQ1AgY29ubmVjdGlvbnMu DQoNClRodXMsIGl0IGNvdWxkIG1ha2Ugc2Vuc2UgdG8gYWRkIHRoaXMgdG8gdGhlIFlBTkcgbW9k ZWwuIFRoZSBleGFjdCBtb2RlbGluZyBpcyBUQkQuIEl0IHdvdWxkIGJlIGEgbGlzdCwgYnV0IG5v dCBpZGVudGljYWwgdG8gd2hhdCBpcyBwcmVzZW50ZWQgYWJvdmUuDQoNCj4gPiAzLiBBZGQgc3Vw cG9ydCBmb3IgVENQLUFPPw0KPiANCj4gSXQgc2hvdWxkIGluY2x1ZGUgYWxsIGN1cnJlbnQgc3Rh bmRhcmRzLXRyYWNrIG9wdGlvbnMgSU1PLg0KDQpZZXAsIEkgYW0gd29ya2luZyBvbiB0aGF0LiBO b25ldGhlbGVzcywgVENQLUFPIGlzIHBhcnRpY3VsYXJseSByZWxldmFudCBmb3IgVENQIHN0YWNr cyB0aGF0IGNhbiBiZSBjb25maWd1cmVkIGJ5IE5FVENPTkYvWUFORy4gVGhpcyBpcyB3aHkgd2Ug YXNrIGZvciBmZWVkYmFjayBmcm9tIHRoZSBjb21tdW5pdHkuDQoNCj4gPiA0LiBBZGQgc3VwcG9y dCBmb3IgVENQLU1ENT8NCj4gDQo+IEZvciB0aGUgcmVhc29uIGFib3ZlLCB0aGlzIHNob3VsZCBu b3QgYmUgaW5jbHVkZWQgLSBpdCBpcyBkZXByZWNhdGVkIGJ5IFRDUC1BTy4NCj4gSWYgc3VwcG9y dGVkLCBpdCBzaG91bGQgYmUgY2xlYXJseSBpZGVudGlmaWVkIGFzIGRlcHJlY2F0ZWQuDQoNClRo ZSBxdWVzdGlvbiBjb21lcyBmcm9tIGltcGxlbWVudGVyczsgYXBwYXJlbnRseSB0aGVyZSBpcyBz dGlsbCBzb21lIHVzZSBvZiBUQ1AtTUQ1IGluIGxlZ2FjeSBkZXBsb3ltZW50cy4gV2Ugd291bGQg aGF2ZSB0byBjbGVhcmx5IGZsYWcgdGhpcyBhcyBkZXByZWNhdGVkIGFuZCBhZGQgYSBiaWcgd2Fy bmluZyBzaWduIGluIHRoZSBZQU5HIG1vZGVsIGluIG9yZGVyIHRvIGVuY291cmFnZSBUQ1AtQU8g aW5zdGVhZC4gVGhhdCBzZWVtcyBkb2FibGUgdG8gbWUuIEFuZCBJIGNhbiBoYXJkbHkgaW1hZ2lu ZSBob3cgdG8gcGFzcyBhIFNFQy1ESVIgcmV2aWV3IHdpdGhvdXQgYmlnIHdhcm5pbmcgc2lnbnMg Oy0pDQoNClRoYW5rcw0KDQpNaWNoYWVsDQoNCg0KPiANCj4gSm9lDQo= From nobody Tue Dec 3 09:18:17 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75B112081C for ; Tue, 3 Dec 2019 09:18:16 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_NONE=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 WrIv4XYMHwlc for ; Tue, 3 Dec 2019 09:18:14 -0800 (PST) Received: from mail-out-1.itc.rwth-aachen.de (mail-out-1.itc.rwth-aachen.de [IPv6:2a00:8a60:1:e501::5:46]) (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 DF96512022A for ; Tue, 3 Dec 2019 09:18:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DUBwCpl+Zd/xUN4ollHAEBAQEBBwEBE?= =?us-ascii?q?QEEBAEBgX6BS1VZay8qhCuQeZtSCQEBAQEBAQEBAQgtAgEBhEACF4F2JDgTAhA?= =?us-ascii?q?BAQUBAQEBAQUEbYVDhVMGIzAmEAIBCD8DAgICMBQRAgQBDQWDIoF6fgGxRoEyh?= =?us-ascii?q?U+DJoFIgTaMFg+BTD+BEScMAxGBTn4+gQSGVTKCLASQGoVMmF0HgURtcpRnG4J?= =?us-ascii?q?Bh26EE4tijkqaRYEyNyIqgS4zGiR5AYJBUBEUjH6OLnSBKJBRAQE?= X-IPAS-Result: =?us-ascii?q?A2DUBwCpl+Zd/xUN4ollHAEBAQEBBwEBEQEEBAEBgX6BS1V?= =?us-ascii?q?Zay8qhCuQeZtSCQEBAQEBAQEBAQgtAgEBhEACF4F2JDgTAhABAQUBAQEBAQUEb?= =?us-ascii?q?YVDhVMGIzAmEAIBCD8DAgICMBQRAgQBDQWDIoF6fgGxRoEyhU+DJoFIgTaMFg+?= =?us-ascii?q?BTD+BEScMAxGBTn4+gQSGVTKCLASQGoVMmF0HgURtcpRnG4JBh26EE4tijkqaR?= =?us-ascii?q?YEyNyIqgS4zGiR5AYJBUBEUjH6OLnSBKJBRAQE?= X-IronPort-AV: E=Sophos; i="5.69,273,1571695200"; d="scan'208,217"; a="96351315" Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-1.itc.rwth-aachen.de with ESMTP; 03 Dec 2019 18:18:10 +0100 Received: from messenger-mbx.win.comsys.rwth-aachen.de (messenger-mbx.win.comsys.rwth-aachen.de [137.226.13.43]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id EDD7B425D1; Tue, 3 Dec 2019 18:18:09 +0100 (CET) Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:c109:b55e:3715:5c2c) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:c109:b55e:3715:5c2c) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 3 Dec 2019 18:18:09 +0100 Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c]) by messenger-mbx.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c%12]) with mapi id 15.00.1130.005; Tue, 3 Dec 2019 18:18:09 +0100 From: Mike Kosek To: Joe Touch , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> CC: "tcpm@ietf.org" Thread-Topic: [tcpm] RFC793bis draft 14 Reserved Bits Thread-Index: AQHVpUhJ+yGPLZAplkKvEj5tj27Qsaef0DOAgAATF4CACLylAA== Date: Tue, 3 Dec 2019 17:18:09 +0000 Message-ID: <1D733CAD-E295-4234-B882-1AE6EBB4BDF6@comsys.rwth-aachen.de> References: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net> <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com> In-Reply-To: <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2a00:8a60:1014:10:819:2158:9b59:dbab] Content-Type: multipart/alternative; boundary="_000_1D733CADE2954234B8821AE6EBB4BDF6comsysrwthaachende_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] RFC793bis draft 14 Reserved Bits X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 17:18:17 -0000 --_000_1D733CADE2954234B8821AE6EBB4BDF6comsysrwthaachende_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd291bGQgc2Vjb25kIHRoZSBwcm9wb3NhbCB0byBiZSBtb3JlIGV4cGxpY2l0LiBJ ZiB3ZSB3b3VsZCBhZGQgYSBNVVNUIG9mIHVuYWx0ZXJlZCB0cmF2ZXJzYWwgaW4gdGhpcyBzcGVj aWZpYyBjYXNlLCBJIGFtIHdvbmRlcmluZyBpZiB0aGlzIHNob3VsZCBiZSBhZGRyZXNzZWQgaW4g b3RoZXIgZmllbGRzIGFzIHdlbGwuIE9idmlvdXNseSB0aGVyZSBhcmUgbGltaXRhdGlvbnMgZm9y IGNlcnRhaW4gb3B0aW9uIHR5cGVzLCBvciBzcmMvZHN0IHBvcnQsIGJ1dCBGbGFncyBhbmQgV2lu ZG93IFNpemUgc2VlbSBsaWtlIHBlcmZlY3QgZml0cy4gRmxhZ3Mgd291bGQgYWxzbyBiZSB0aGUg c3Vic2VxdWVudCBzdGVwIG9mIFJvZG5leSdzIGFuZCBKb2UncyBwcm9wb3NhbCwgYXMgYml0cyB3 b3VsZCBub3QgYmUgY292ZXJlZCBhbnkgbG9uZ2VyIGlmIHRoZXkgYXJlIGFzc2lnbmVkLg0KDQpC ZXN0LA0KTWlrZQ0KDQoNCk9uIDI4LiBOb3YgMjAxOSwgYXQgMDQ6NTIsIEpvZSBUb3VjaCA8dG91 Y2hAc3RyYXlhbHBoYS5jb208bWFpbHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tPj4gd3JvdGU6DQoN Cg0KDQpPbiBOb3YgMjcsIDIwMTksIGF0IDY6NDQgUE0sIFJvZG5leSBXLiBHcmltZXMgPDRib25l QGduZHJzaC5kbnNtZ3IubmV0PG1haWx0bzo0Ym9uZUBnbmRyc2guZG5zbWdyLm5ldD4+IHdyb3Rl Og0KDQpIaSB0Y3BtLA0KDQpTb3JyeSBmb3IgYnVtcGluZyB0aGlzLCBtYXliZSBpdCBnb3Qgb3Zl cmxvb2tlZCBkdXJpbmcgMTA2Lg0KDQpDYXRjaGluZyB1cCBvbiBkcmFmdC1pZXRmLXRjcG0tcmZj NzkzYmlzLTE0LCBJIHdhcyB3b25kZXJpbmcgd2h5IHRoZSByc3J2ZCBiaXRzIGFyZSBub3QgZXhw bGljaXRseSBzdGF0ZWQgYXMgYSBmb3JtYWwgTVVTVCByZXF1aXJlbWVudDoNCg0KIk11c3QgYmUg emVybyBpbiBnZW5lcmF0ZWQgc2VnbWVudHMgYW5kIG11c3QgYmUgaWdub3JlZCBpbiByZWNlaXZl ZCBzZWdtZW50cywgaWYgY29ycmVzcG9uZGluZyBmdXR1cmUgZmVhdHVyZXMgYXJlIHVuaW1wbGVt ZW50ZWQgYnkgdGhlIHNlbmRpbmcgb3IgcmVjZWl2aW5nIGhvc3QuIg0KDQpUbyBteSB1bmRlcnN0 YW5kaW5nLCB0aGUgY3VycmVudCBwaHJhc2luZyBpcyB1cCB0byBpbnRlcnByZXRhdGlvbiwgaS5l Liwgc29tZW9uZSBtaWdodCBvcHQgdG8gbm90IGltcGxlbWVudCBpdCBhcyBzdGF0ZWQgZHVlIHRv IHRoZSBtaXNzaW5nIGZvcm1hbCBNVVNUIC0gUGxlYXNlIHByb3ZlIG1lIHdyb25nIGlmIEkgYW0g bWlzc2luZyBzb21ldGhpbmcuDQoNCkkgd291bGQgZXZlbiBsaWtlIHRvIHNlZSBpdCBnbyBmdXJ0 aGVyIGFuZCBhZGQgInRoZXkgTVVTVCBiZSBpZ25vcmVkIGJ5IHRoZSBuZXR3b3JrLCBhbmQgdHJh dmVyc2UgdGhlIG5ldHdvcmsgdW5jaGFuZ2VkLuKAnQ0KDQpQZXJoYXBzIGZ1cnRoZXIgZXhwbGlj aXRseToNCg0KdGhleSBNVVNUIGJlIGlnbm9yZWQgYnkgdGhlIG5ldHdvcmsgYW5kIE1VU1QgdHJh dmVyc2UgdGhlIG5ldHdvcmsgdW5jaGFuZ2VkDQoNCg== --_000_1D733CADE2954234B8821AE6EBB4BDF6comsysrwthaachende_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsiPg0KPGRpdj48Zm9udCBjb2xvcj0i IzAwMDAwMCIgZmFjZT0iVmVyZGFuYSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IiBjbGFzcz0iIj5IaSw8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iVmVyZGFuYSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3Nw YW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iVmVyZGFu YSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IiBjbGFz cz0iIj5JIHdvdWxkIHNlY29uZCB0aGUgcHJvcG9zYWwgdG8gYmUgbW9yZSBleHBsaWNpdC4gSWYg d2Ugd291bGQgYWRkIGEgTVVTVCBvZiB1bmFsdGVyZWQgdHJhdmVyc2FsIGluIHRoaXMgc3BlY2lm aWMgY2FzZSwgSSBhbSB3b25kZXJpbmcgaWYgdGhpcyBzaG91bGQgYmUgYWRkcmVzc2VkDQogaW4g b3RoZXIgZmllbGRzIGFzIHdlbGwuIE9idmlvdXNseSB0aGVyZSBhcmUgbGltaXRhdGlvbnMgZm9y IGNlcnRhaW4gb3B0aW9uIHR5cGVzLCBvciBzcmMvZHN0IHBvcnQsIGJ1dCBGbGFncyBhbmQgV2lu ZG93IFNpemUgc2VlbSBsaWtlIHBlcmZlY3QgZml0cy4gRmxhZ3Mgd291bGQgYWxzbyBiZSB0aGUg c3Vic2VxdWVudCBzdGVwIG9mIFJvZG5leSdzIGFuZCBKb2UncyBwcm9wb3NhbCwgYXMgYml0cyB3 b3VsZCBub3QgYmUgY292ZXJlZCBhbnkgbG9uZ2VyDQogaWYgdGhleSBhcmUgYXNzaWduZWQuPC9z cGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwMDAiIGZhY2U9IlZlcmRh bmEiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyIgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29s b3I9IiMwMDAwMDAiIGZhY2U9IlZlcmRhbmEiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyIgY2xhc3M9IiI+QmVzdCw8L3NwYW4+PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iVmVyZGFuYSIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IiBjbGFzcz0iIj5NaWtlPC9zcGFuPjwv Zm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0id2Vi a2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMjguIE5vdiAy MDE5LCBhdCAwNDo1MiwgSm9lIFRvdWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hAc3RyYXlh bHBoYS5jb20iIGNsYXNzPSIiPnRvdWNoQHN0cmF5YWxwaGEuY29tPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gTm92IDI3LCAyMDE5LCBhdCA2OjQ0IFBNLCBSb2Ru ZXkgVy4gR3JpbWVzICZsdDs8YSBocmVmPSJtYWlsdG86NGJvbmVAZ25kcnNoLmRuc21nci5uZXQi IGNsYXNzPSIiPjRib25lQGduZHJzaC5kbnNtZ3IubmV0PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SGkg dGNwbSw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTb3JyeSBmb3IgYnVtcGluZyB0aGlz LCBtYXliZSBpdCBnb3Qgb3Zlcmxvb2tlZCBkdXJpbmcgMTA2LjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkNhdGNoaW5nIHVwIG9uIGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQsIEkg d2FzIHdvbmRlcmluZyB3aHkgdGhlIHJzcnZkIGJpdHMgYXJlIG5vdCBleHBsaWNpdGx5IHN0YXRl ZCBhcyBhIGZvcm1hbCBNVVNUIHJlcXVpcmVtZW50Og0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KJnF1b3Q7TXVzdCBiZSB6ZXJvIGluIGdlbmVyYXRlZCBzZWdtZW50cyBhbmQgbXVzdCBi ZSBpZ25vcmVkIGluIHJlY2VpdmVkIHNlZ21lbnRzLCBpZiBjb3JyZXNwb25kaW5nIGZ1dHVyZSBm ZWF0dXJlcyBhcmUgdW5pbXBsZW1lbnRlZCBieSB0aGUgc2VuZGluZyBvciByZWNlaXZpbmcgaG9z dC4mcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUbyBteSB1bmRlcnN0YW5kaW5n LCB0aGUgY3VycmVudCBwaHJhc2luZyBpcyB1cCB0byBpbnRlcnByZXRhdGlvbiwgaS5lLiwgc29t ZW9uZSBtaWdodCBvcHQgdG8gbm90IGltcGxlbWVudCBpdCBhcyBzdGF0ZWQgZHVlIHRvIHRoZSBt aXNzaW5nIGZvcm1hbCBNVVNUIC0gUGxlYXNlIHByb3ZlIG1lIHdyb25nIGlmIEkgYW0gbWlzc2lu ZyBzb21ldGhpbmcuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0K SSB3b3VsZCBldmVuIGxpa2UgdG8gc2VlIGl0IGdvIGZ1cnRoZXIgYW5kIGFkZCAmcXVvdDt0aGV5 IE1VU1QgYmUgaWdub3JlZCBieSB0aGUgbmV0d29yaywgYW5kIHRyYXZlcnNlIHRoZSBuZXR3b3Jr IHVuY2hhbmdlZC7igJ08YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+ DQpQZXJoYXBzIGZ1cnRoZXIgZXhwbGljaXRseTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQp0aGV5IE1VU1QgYmUgaWdub3JlZCBieSB0aGUgbmV0d29yayBhbmQgTVVTVCB0cmF2ZXJzZSB0 aGUgbmV0d29yayB1bmNoYW5nZWQ8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1D733CADE2954234B8821AE6EBB4BDF6comsysrwthaachende_-- From nobody Wed Dec 4 00:48:17 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA05D12013A for ; Wed, 4 Dec 2019 00:48:15 -0800 (PST) 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, SPF_NONE=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 Y-uVnJRbBBa5 for ; Wed, 4 Dec 2019 00:48:15 -0800 (PST) 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 DE35612012C for ; Wed, 4 Dec 2019 00:48:14 -0800 (PST) Received: from [10.0.1.118] (unknown [212.201.121.94]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id A276A72106C37 for ; Wed, 4 Dec 2019 09:48:12 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: <3FCB5108-7188-4A8C-B79D-3ABD7A141C3C@lurchi.franken.de> Date: Wed, 4 Dec 2019 09:47:46 +0100 To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [tcpm] Intended status of draft-ietf-tcpm-rack X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 08:48:16 -0000 Dear all, based on the feedback on the mailing list and during the TCP session at the last IETF, there is consensus that the intended status of draft-ietf-tcpm-rack should be Proposed Standard instead of Experimental. Therefore I changed the proposed status. Best regards Michael From nobody Wed Dec 4 06:18:56 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C61120817 for ; Wed, 4 Dec 2019 06:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 4qyn3UB8thgs for ; Wed, 4 Dec 2019 06:18:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 7C78B120816 for ; Wed, 4 Dec 2019 06:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575469120; bh=hp6FcM+Cit5MnBWnP0eGgbgKonWsD7QF2UxlHBER498=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=UY/xLOBFCynaYyqsQWh8vt9uIle5wyD0rUqC8QjzWbpS6lQnZT/MGcxL6hZRYT/Hf GZgoqGBUG+Y2Yccgq1BHpTvcB/wn2yMwcxKzzxXSlhzkUg4dMVYVSKqUpELZS+k6Fq SK3n/83beweiKbgyF3lw6IfIUzxvaC40pu4duqbs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.67.131.61] ([217.70.210.46]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MA7KU-1iVP1W1Tqc-00BfFG; Wed, 04 Dec 2019 15:18:40 +0100 To: Jon Crowcroft , Carles Gomez Montenegro Cc: tcpm IETF list References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> From: "Scheffenegger, Richard" Message-ID: <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> Date: Wed, 4 Dec 2019 15:18:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+EfqsH3w1h9JhOdA3RkA8FcHqmNt75lSryLSK2O5NBhgzf0w9VA Uq8Ow6Rli8uESl0l8X7WNnu+klzqtDbIs2lGM74Pjn7ARCeN7dermJ0fEB2+T96+IxXfT2Q z4PEqsQ9X5uKEcBjWZQpn5V/MnKiM3y/XN97MZ6mTUvgj8KOFD7s2CzWBFe96373umFN+Sp GHyQ+97+0rj9iYJHS15JQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:q7U6CNQ7zI4=:bgKh8MOJz6VYZmw8vnFwry r8s3uOTrd3eEiVsPRoT+JjPbfDtn41KDudlz21peWNKqq3tjyHecRjIlgHQA9ui/lqXyu13WZ LGaTfjKiDMUI5vofxwTqOxvx2FwvZ6A564cF2fxjAmXL4XWKbKM/Il/vz0omx7fV01GI1HNIl be1jBspMxu2vKKbLoY3IyQeN+YwLknk17G9OLdFOWig7D6hMohn43U8gZEMIfX5hdNsWYR0HC b2umtfSr88sJCd/R1g+0VK9lmBjO/LqYHaYpD3exub0AbaBGcIoHBr8gutSq7rWzK33VdWDm6 s71pAAnPJRCFGZFcxhezSuyn7wqfjC1NS6MMG8kH+FhPV8dr4mCe0AT7U+1AuqgBr1dcoBVYC 2lhucBozm27HuqqLWYViPKpTKKCrsbS6xDojJ94P++qPnrv6DMGesPkKFAzxChiqBXrYCkr85 ax2i5ibP+/guZVbIaygI/yHDi1rgpQ+v3ZTf0lVD8VZDXr6b9vh3W8XicOEeMMtJhKa1jd/gB Y/EA5QJJvIZHofxitnlXL7n5h2Nc0KNRPQ81zg6LDO05e7CZ3NkeoupzlyyZM/9HRAavz5KOv 5UqlegBSJ6mcHhJE8/5WZVMo3f7Oqu1RPfqFBtAEgUhnpWckaT6CRQ245ZRRyUmsNeBb+pIcl mNIfL/M+gqxiNGNEmPtgIhsrgtiB1xBxrqQT2IKwacZpZJQJDT4KNiaQKF2E30ygyUoOLvJaa 1kE1RCnc+U5m4g8KiF40PSfDsrYDl7SXe3JR37JpT8WsN2hblEpV9sMqks6/v2JSAxui9kq+G BWM8kAIsV8AxUWc1ncIzJDnVdYcbmvgavQ0m/ctqRk07AyI+xFMJ0Q6Sbsio2g9DWpJjUQFce Tq5c2hB2HakNKkoNjXCS7rm/zNfhYllx8vRr49w5YeGT+S0zNaddlvpWBVyFWO0XXzrYNaBC0 ovS4K4qr66zxCU5vaF1kHOLETLmY3xX2ofzO7ZL3sGDXvxx404TZPeSvUmsdkkME64EVio4dr gu8AjTfXebNbUr8i1A4C8agZ2lL9ADvB+gDl97wfgpZqhGFrlkIqog4unnSbR9oeLI349MlK4 wFtAqcRe3ZlTDWGwkzp4HkGQyMRwUpuW7ZPqBR594Hb3crAboPYaqy2n6zrZE7OFNxs+5/Ubq aHFcEMxwoT1o0iVCqfOXuaROD0+GQQNvCPZsujasSe3dTQO6KbvDpkbal4brSXhwYIDZFB//3 aJSsKzoGK2LbvWFovh02NK9jjhrR7S/bjaVkgmw== Archived-At: Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 14:18:54 -0000 Carles, I just found, that as a performance improvement measure, linux has recently added a patch to trigger immediate ACKs when a packet with CWR is received... While the underlying issue was found in the dctcp context, the patch appears to be against the generic rfc3168 ECN handling code. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?id=3Dfd2123a3d7527d4c7092633d55e877c0cc1d84a3 While that performance improvement has obvious benefits, RFC3168 is silent on this particular issue. But there are use cases where it is certainly valuable for the sender to be able to elicit an immediate ACK from the receiver. I don't know if it warrants a dedicated bit though - or if, for example, the combination of CWR/PSH could perhaps obtain the ACK PULL semantics as an overload of of their normal semantics... Best regards, Richard Am 18.11.2019 um 08:21 schrieb Jon Crowcroft: > Mark Handley said a lot of the middlebox corner case avoidance stuff is > in the tcpmp RFC...have got time to look just yet... > > On Mon, 18 Nov 2019, 04:46 Carles Gomez Montenegro, > > wrote: > > Hi Bob, > > Once again, thanks a lot for all the very useful feedback! > > Please find below some inline responses. > > > Carles, Jon, (re-sending, this time without accidentally omitting > tcpm, > > also see couple of addenda tagged [Bob adds:]) > > > > I'm generally supportive of a mechanism to suppress delayed ACKs = from > > the receiver (in any transport protocol including TCP). So thank = you. > > > > You might want to borrow at least some of the text for additional > > motivating scenarios for such a facility from the first two posts > on a > > thread for a similar facility in QuiC: > > https://github.com/quicwg/base-drafts/issues/1978 > > > > Also pasted at the end. > > > > Some is not relevant to your specific ack-pull scheme, 'cos it's > > proposing a more general facility in QUIC for the sender to the > receiver > > alters its ACK ratio. (theoretically there are more bits availabl= e in > > QUIC, but this particular request has been put on hold while some= one > > goes and finds them ;) > > Thanks a lot. This is indeed very useful! > > As you explain, the more general facility for QUIC allows to suppres= s > Delayed ACKs and also allows to modify the ACK ratio in a more gener= al > way. > > Regarding the Delayed ACK suppression discussion, the additional > motivation is definitely important. > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Another motivating example (rather nich= e) > > > > Coincidentally, Just this morning I published a tech report that > had to > > use the hack of overlapping a byte from the previous segment to > force a > > quick ack: > > TCP Prague Fall-back on Detection of a Classic ECN AQM > > (the link takes you > to Fig > > 2, which illustrates the hack) > > I'd rather not have to do these sorts of hacks - it really messes > with > > the segmentation code. > > This is very useful feedback as well, and a nice coincidence! > > Regarding the hack, sending an old byte may be even worse when there= is > not a next data segment readily available for sending, which would > lead to > sending a whole packet just to carry an old byte. > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Middlebox traversal of bit 6 > > > > I recall that someone did a study of traversal of each of the > reserved > > flags (Marcelo Bagnulo maybe?). I don't think it was that good [B= ob > > adds: I mean traversal - not the study!]. > > A good search engine might find it ;) > > I wasn't able to find the study, but this is an important > consideration.. > > One might think that if new functionality is defined and standardize= d, > related middlebox traversal of it should improve over time. Perhaps = that > might be optimistic... > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0More alternative approaches: > > > > 1/ At one stage, we tried to include a bit for Delayed Ack contro= l in > > another protocol called Accurate ECN. We were persuaded to take > it out, > > because it was mission creep (outside the scope of the protocol > we were > > working on): > > > https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#ap= pendix-B.4 > > I was unaware of this, thanks! > > This is actually very aligned with what we are proposing... > > > 2/ Have you considered using the Urgent Pointer in a novel way? > I.e. a > > non-zero Urgent Pointer field, even tho the URG flag is zero. > > [Bob adds:] From memory, traversal was pretty good - much better = than > > bits 4-6. But I think Windows treated it as a potential attack. I > > believe Fernando Gont did a study on how 'invalid' TCP header > fields are > > handled. > > > > You could assign, say, 3 bits of the urgent pointer for a variabl= e > > ack_exp that is log base 2 of the ack ratio the sender would > like. Then > > the sender can request the receiver uses ack_ratio` =3D 2^ack_exp= , > as in > > the QUIC proposal below, > > With ack_exp =3D 0, you get ack_ratio =3D 2^0 =3D 1, which has th= e same > effect > > as ack-pull. But you also have a more general facility for high s= peed > > machines to widen out the ack ratio. > > > > If this works, you could open up a registry for the other 13 bits= . So > > instead of using up a precious bit, you generate 13 more ;) > > Nice! :) > > Actually, we had not considered such an idea. > > In your proposal above, if a segment has the URG flag set to 1, > would then > the 3 ack_exp bits still be used as ack_exp bits, thus reducing the = size > of the urgent pointer in practice to 13 bits? > > > See: > > https://tools.ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#pag= e=3D5 > > > > I think there were problems with some implementations and middleb= oxes > > (bound to be). I've checked the minutes of the IETF meeting where > that > > slide was presented > > , bu= t > > there's no push-back in there. I suggest you delve back into the > > archives of the tcpm mailing list around the time of that meeting= to > > find out if there were any show-stoppers. > > Thanks for the pointers! > > Sure, we'll check the tcpm mailing list archive. > > Cheers, > > Carles > > > > Cheers > > > > > > > > Bob > > > > > > Paste from QUIC thread: > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\= /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Problem/goals: > > > >=C2=A0 1. Getting up to speed fast without inducing much queue is = one > of the > >=C2=A0 =C2=A0 =C2=A0main areas where latency reductions are needed= (for short and > long > >=C2=A0 =C2=A0 =C2=A0flows). The sender needs frequent ACKing durin= g this phase in > many > >=C2=A0 =C2=A0 =C2=A0approaches (hystart, etc). A Linux TCP receive= r starts with > >=C2=A0 =C2=A0 =C2=A0ack_ratio 1 and uses heuristics to identify th= e end of the > sender's > >=C2=A0 =C2=A0 =C2=A0slow-start (or a re-start after idle). This ha= s ossified a > certain > >=C2=A0 =C2=A0 =C2=A0slow-start behaviour into all TCP senders (whe= ther Linux or > not). We > >=C2=A0 =C2=A0 =C2=A0are trying to new sender behaviours (paced chi= rping being an > >=C2=A0 =C2=A0 =C2=A0example), but we need a way for the sender to = suppress > delayed ACKs. > >=C2=A0 2. At the other end of the scale, for long-running flows, m= any > current > >=C2=A0 =C2=A0 =C2=A0CC approaches (e.g. BBR) use pacing not ACK-cl= ocking so they > can use > >=C2=A0 =C2=A0 =C2=A0very few ACKs per RTT. And fewer means less ca= che ejections > for GRO. > >=C2=A0 =C2=A0 =C2=A0But the receiver doesn't know what CC the send= er is using, so it > >=C2=A0 =C2=A0 =C2=A0doesn't know how many or few is too many or to= o few. > >=C2=A0 3. Some middleboxes and the majority of link technologies (= e.g. > DOCSIS, > >=C2=A0 =C2=A0 =C2=A0LTE, Satellite) thin TCP ACKs when they detect= the upstream is > >=C2=A0 =C2=A0 =C2=A0filled with TCP ACK stream(s), which are unres= ponsive. > Otherwise the > >=C2=A0 =C2=A0 =C2=A0ACKs constrain downstream throughput (and any = upstream data > either > >=C2=A0 =C2=A0 =C2=A0in the flow itself, or in others). We don't wa= nt these links to > >=C2=A0 =C2=A0 =C2=A0attempt to guess which are the QUIC ACKs and t= ry to thin > them. QUIC > >=C2=A0 =C2=A0 =C2=A0can and should do this itself. QUIC has all th= e machinery for the > >=C2=A0 =C2=A0 =C2=A0sender CC to detect ACK congestion, but not th= e protocol to > tell the > >=C2=A0 =C2=A0 =C2=A0receiver to do the thinning. This protocol add= ition would > provide a > >=C2=A0 =C2=A0 =C2=A0sufficient hook for hosts to unilaterally add = this to their CC > >=C2=A0 =C2=A0 =C2=A0behaviour. > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Some scenarios where the sender's prefe= rred ack_ratio changes > >=C2=A0 =C2=A0 =C2=A0 =C2=A0through the connection: > > > >=C2=A0 1. > > > >=C2=A0 =C2=A0 =C2=A0A sender CC that wants the receiver to turn of= f DelAcks during > >=C2=A0 =C2=A0 =C2=A0flow-start (e.g. it's using hybrid slow-start = as in Cubic and > wants > >=C2=A0 =C2=A0 =C2=A0to get delay measurements more frequently) set= s ack_exp=3D0 during > >=C2=A0 =C2=A0 =C2=A0flow-start (ack_ratio=3D1), then increases ack= _exp during > congestion > >=C2=A0 =C2=A0 =C2=A0avoidance. If it goes idle, then re-starts, it= would set > ack_exp=3D0 > >=C2=A0 =C2=A0 =C2=A0again. > > > >=C2=A0 =C2=A0 =C2=A0Note on heuristics: A Linux TCP receiver curre= ntly uses a > heuristic > >=C2=A0 =C2=A0 =C2=A0to determine when the sender has exited slow-s= tart. However, > >=C2=A0 =C2=A0 =C2=A0heuristics -> ossification. A Linux receiver's= heuristic only > works > >=C2=A0 =C2=A0 =C2=A0with the current pattern of slow-start. In TCP= , when we tried to > >=C2=A0 =C2=A0 =C2=A0improve the pattern on the sender (paced chirp= ing), the > heuristic on > >=C2=A0 =C2=A0 =C2=A0the receiver killed us. > > > >=C2=A0 2. > > > >=C2=A0 =C2=A0 =C2=A0Imagine a paced sender has hardware generic re= ceive offload > (GRO), > >=C2=A0 =C2=A0 =C2=A0so for a long-running flow it doesn't want a h= igh rate of > QUIC ACKs > >=C2=A0 =C2=A0 =C2=A0that are opaque to GRO. Let's say it would pre= fer at least 8 ACKs > >=C2=A0 =C2=A0 =C2=A0per RTT. Again, it starts with ack_exp=3D0, bu= t in congestion > >=C2=A0 =C2=A0 =C2=A0avoidance it would use: > > > >=C2=A0 =C2=A0 =C2=A0ack_ratio <=3D cwnd_in_packets/8 > > > > Upshot: By remote controlling the receiver, the server offloads > nearly > > all the ACKs from large downloads, but still focuses its > ACK-receiving > > resources on getting each client up to speed. > > > > Note that calculation of ack_ratio lends itself to fast integer > > arithmetic. > > > > > > > > > > > > > > > > Bob > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Dec 4 06:59:39 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A3212081D for ; Wed, 4 Dec 2019 06:59:38 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=mti-systems-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 m0dcz1nG0CpP for ; Wed, 4 Dec 2019 06:59:36 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 4E3AE12008C for ; Wed, 4 Dec 2019 06:59:36 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id z22so3078qto.7 for ; Wed, 04 Dec 2019 06:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Cz5tW1NDcsIc5W4T+0nKFEol4hWwgj2o+gDR+HyVvX8=; b=1kmtSeIMz8L20e8q2NDymfAGK78Cd9xZEsmkgizSxiJkgNzo8EiPYg10Qw5vB/a65N pFVLJ/CGvUyHgIHhHP2YFbl2+rYFDM8dV83oAazt1VNPDhGBmChcgeEJVwLjX/jy3F+V wHPWHKBQjPl9SjlRI3yJUsaFxRB+yBDEUj1VtEXFh7lmiPgUbc9aeTACGqOQPAygnGJT gAh/Ntzpiit156o9sJTGLo1DveyWm5OqNSTLxQAw6Jh2VVtj5KQx+IFzh2JQB94LNHvm XCZxJP1eKCeAme2F3JRvwZayxuwNLdzC5u37vPeCoQg4nBfI2RUkq13vMruRYRCFw1cu K8TA== 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-transfer-encoding :content-language; bh=Cz5tW1NDcsIc5W4T+0nKFEol4hWwgj2o+gDR+HyVvX8=; b=eszSb0V0INhRxX0yscZWJN12fDgp7Q8T7ZI6lPzdG9BiJ2ZBMTTF2jIAsZmX+3azxR ITsUxprVASzMFKYMc96KwbpLApnBf4nkTyQQn6G6Lzfi7PARKqDNNsnXGTtbCLDzbwjT FS5B+uaFQEeouwTZ8a0K8x8iiyKF/QQdHzapIxC79mxLmWybewQmf59OldJASPFCOwvT G/QyLUSy+Z582SUsXKpp67A6J7RGUrqZVKcmxRQoAzPoDJnHhpV1V0HyD2RexSlRuwF7 ZALy0SglsXH9XtjutDF9OieSM8SSxUoRJmMMDCzb74eEgPKmhcsmJnsVYTjKX6bRtTcV 2+mw== X-Gm-Message-State: APjAAAWCitv63bYPCe3tcP3RooC64H8T3qVqndZITRY2vaX4nofjnovf 6XDvcHyPqWhOxrTPgUvOraLvhX/xauM= X-Google-Smtp-Source: APXvYqyLmMu81J0n+3KPh+ezTv/fMlfWIb0AO9efwir8FUM1P5EZY1Uq0ZtKpgqMiQjVz1NbCuSLQw== X-Received: by 2002:ac8:4513:: with SMTP id q19mr2860899qtn.334.1575471575181; Wed, 04 Dec 2019 06:59:35 -0800 (PST) Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id 63sm3721424qkd.61.2019.12.04.06.59.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Dec 2019 06:59:34 -0800 (PST) To: Joe Touch , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Cc: "tcpm@ietf.org" References: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net> <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com> From: Wesley Eddy Message-ID: <77bade9d-f090-9ec7-cc7a-29e4118321ad@mti-systems.com> Date: Wed, 4 Dec 2019 09:59:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] RFC793bis draft 14 Reserved Bits X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 14:59:38 -0000 On 11/27/2019 10:52 PM, Joe Touch wrote: > >> On Nov 27, 2019, at 6:44 PM, Rodney W. Grimes <4bone@gndrsh.dnsmgr.net> wrote: >> >>> Hi tcpm, >>> >>> Sorry for bumping this, maybe it got overlooked during 106. >>> >>> Catching up on draft-ietf-tcpm-rfc793bis-14, I was wondering why the rsrvd bits are not explicitly stated as a formal MUST requirement: >>> >>> "Must be zero in generated segments and must be ignored in received segments, if corresponding future features are unimplemented by the sending or receiving host." >>> >>> To my understanding, the current phrasing is up to interpretation, i.e., someone might opt to not implement it as stated due to the missing formal MUST - Please prove me wrong if I am missing something. >> I would even like to see it go further and add "they MUST be ignored by the network, and traverse the network unchanged.” > Perhaps further explicitly: > > they MUST be ignored by the network and MUST traverse the network unchanged This clarification seems good to me, and it looks like everyone who's chimed in so far agrees, so I can put it into the upcoming revision. From nobody Wed Dec 4 07:12:22 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52870120820 for ; Wed, 4 Dec 2019 07:12:20 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 vBiK6lsrQ-0w for ; Wed, 4 Dec 2019 07:12:19 -0800 (PST) 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 04DC112008C for ; Wed, 4 Dec 2019 07:12:18 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id d124so182214qke.6 for ; Wed, 04 Dec 2019 07:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Y0xnLp1IN6cKy8cdU8L5izveUYaTHnT05WNAfaQhjrY=; b=OJpZNOj/s1mSMl1p6fO/4wlRJoUiig5CTpEm1rzNXOzRMndG+Ti7XHTxmWpPac+EDR doB96vTp/dT2W13J2SowLcE5nUEdDRKFLlLhHUgEAj3A8xjJXrlrsN5mgWoLBSAp8ldm eqEYX6HhLLkWX23B+MRrTktQ1jx2oHLL5UMrXHygFp0+ia+T63XMmlelwrGKefE8nSN9 xVThfazj3eo3KEMiXynUo+GuCwjrJnxcyk8Ypw71+79MEYXOkoUUGAH+6gnCfqEzhXCn 6HqdQby+Fc/9CrImzKf86qELEM34lnDAxCv/BAArFxhqDTlPsSs+xRd0eijeDIWkZiSW MbuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Y0xnLp1IN6cKy8cdU8L5izveUYaTHnT05WNAfaQhjrY=; b=ory0AdYhGUpeSm/Djpmji1FdXplMeCmtPjR2xqFoLfDM/cBu5wzs4YQhBJX5z2ktrp Kx+53iyck1clz+YYWcJ2keiAEUzQ1CU6rbSngDSLMPPh7G4n24wkqcco3siikjYRhDj6 lgCd85w479X28vt6HTMi0iU6nW6oXHlTcz6Ib1L88EVHjPhCMYRD7MOrJwhs7Qs4hAig ymImDfUeUt9mbRMIdlHPgrBImH5MrFBCN+ECnL8pF102pzvSLFqUP12JwHpjejM5D21t 9qLCP5a+gIRWBIeWI2Goaz+lcyJisEvoMJWKkKfrf8Up+MjN7GvcCKzqDMOzz1vcs/5o +REQ== X-Gm-Message-State: APjAAAVS5IIEfU7myP8rRtorUs0aPED5BtNy4EKEqK77hXEWKIISjzHf Qluk3eWNFnj3ynzkFNFtZ26qysx48XI= X-Google-Smtp-Source: APXvYqynISz/BVHAEaUg2UGCafpPd/Ql77NzMm161QJ9OaeWUZYpLMNpz4XQWIrBvkq4dz7ad3+gTg== X-Received: by 2002:a05:620a:981:: with SMTP id x1mr3319369qkx.323.1575472336837; Wed, 04 Dec 2019 07:12:16 -0800 (PST) Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id v45sm3969911qtb.32.2019.12.04.07.12.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Dec 2019 07:12:16 -0800 (PST) To: tcpm@ietf.org References: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net> <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com> <1D733CAD-E295-4234-B882-1AE6EBB4BDF6@comsys.rwth-aachen.de> From: Wesley Eddy Message-ID: <2157455f-13d6-8d93-c0fb-dbe874c01bc7@mti-systems.com> Date: Wed, 4 Dec 2019 10:12:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1D733CAD-E295-4234-B882-1AE6EBB4BDF6@comsys.rwth-aachen.de> Content-Type: multipart/alternative; boundary="------------2F4BD6584478C27F89CE6A39" Content-Language: en-US Archived-At: Subject: Re: [tcpm] RFC793bis draft 14 Reserved Bits X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 15:12:20 -0000 This is a multi-part message in MIME format. --------------2F4BD6584478C27F89CE6A39 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/3/2019 12:18 PM, Mike Kosek wrote: > > I would second the proposal to be more explicit. If we would add a > MUST of unaltered traversal in this specific case, I am wondering if > this should be addressed in other fields as well. Obviously there are > limitations for certain option types, or src/dst port, but Flags and > Window Size seem like perfect fits. Flags would also be the subsequent > step of Rodney's and Joe's proposal, as bits would not be covered any > longer if they are assigned. In the case of reserved bits, I believe the reason we're trying to be so clear is that we want any new feature that might use them to work.  At least, in the past when this came up, that was why the current 793bis text on the reserved bits differs a little from the original 793 text (which is just "Reserved for future use. Must be zero."). I think it would be a mistake and fruitless to try to say for the other individual fields which ones MUST be unaltered by the network.  Generally, this is the expectation for the entire segment, even though that expectation doesn't typically hold anymore (due to NAT, etc).  I wouldn't say much more than that, because it's inviting misunderstanding that it's okay to twiddle with any bits and violate laying whenever the doc doesn't explicitly indicate not to. --------------2F4BD6584478C27F89CE6A39 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/3/2019 12:18 PM, Mike Kosek wrote:

I would second the proposal to be more explicit. If we would add a MUST of unaltered traversal in this specific case, I am wondering if this should be addressed in other fields as well. Obviously there are limitations for certain option types, or src/dst port, but Flags and Window Size seem like perfect fits. Flags would also be the subsequent step of Rodney's and Joe's proposal, as bits would not be covered any longer if they are assigned.


In the case of reserved bits, I believe the reason we're trying to be so clear is that we want any new feature that might use them to work.  At least, in the past when this came up, that was why the current 793bis text on the reserved bits differs a little from the original 793 text (which is just "Reserved for future use.  Must be zero.").

I think it would be a mistake and fruitless to try to say for the other individual fields which ones MUST be unaltered by the network.  Generally, this is the expectation for the entire segment, even though that expectation doesn't typically hold anymore (due to NAT, etc).  I wouldn't say much more than that, because it's inviting misunderstanding that it's okay to twiddle with any bits and violate laying whenever the doc doesn't explicitly indicate not to.



--------------2F4BD6584478C27F89CE6A39-- From nobody Wed Dec 4 14:15:17 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA84120046 for ; Wed, 4 Dec 2019 14:15:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157549771556.11183.7908403150908109962.idtracker@ietfa.amsl.com> Date: Wed, 04 Dec 2019 14:15:15 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 22:15:15 -0000 Changed milestone "Submit document on a time-based fast loss detection algorithm for TCP to the IESG for publication as an Experimental RFC", set due date to March 2020 from September 2017. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Dec 4 22:08:13 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1E11200B6 for ; Wed, 4 Dec 2019 22:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 Eq8ZTD0fLNl8 for ; Wed, 4 Dec 2019 22:08:11 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 071A7120047 for ; Wed, 4 Dec 2019 22:08:11 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id b11so2247180wmj.4 for ; Wed, 04 Dec 2019 22:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=boe6swujSL0eyotJ18CMxPQBosrf08ySVnwDULS0pCo=; b=pofeN75yyzKrs8Grg/bMfXT9gCbBss18W92xiz7X7KLEkxUlZiFu6N/zXvITtLwWJs eSEgEUtq+XOJe7M0R0FG8vQiMT0BA1rsv/cJsm7rwXnymNT7xGbDrWVjE9JBFvz3ZzrZ O/Zlpz27jSWyGh0++bK3ZLEukWIyBvY3TPBN077uakGP0HJvsOj2+sE+w/XVqeyXxOE5 dEcm1VXvyfmp+PIj5uFrc/ikaQu8D1NRsLkxB0GN3SpIkiAmufzRgSFPoFPRr78k2Eh/ wSXqTLYMnOBFKWbCq9wBGY2lh2U2ZSV4WOCtBdRPA3vmm9n2wpZviuswA0zSl30yy3Al qsdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=boe6swujSL0eyotJ18CMxPQBosrf08ySVnwDULS0pCo=; b=g8rJu2veAVfyA9PpbZgmi0VTeaJIXZu5Wbmpbao1pA/YKHE5ekyvTMzbvp4hc6VR3y QDiad1+hCARDOSjPmbBomPxzMtfSF0fj7JHheLC5IxejEohXkASLNSvpS0BKiea09gKo Z1azPX6jRNVJ/Lx28fBbPS07AIztsp2COy/+SMvtlWCqJNtCiUKjNLZLBRjJIqYbIgIW 2pzFQpr7WugeuYx7HEfTFBiNi0Z4v2a2hcWoYEzDw7RorEXu9V0xDYPl96Tkm51cE3m+ +9SlM5vDL+QqaWl4bKKhkWO+zyAol/sM/O4AD4G4dwFMOKqBkLp1N3FHbho76eMJlsAx hy3Q== X-Gm-Message-State: APjAAAUY8zqtrDds2xDd+mgQV9QYrg2SwYI4y9dZoGrnG97IVnUxytQn KrOfFFTYMEExFcd3jEdIs98gkMxFERLg7FJblTdGYLVz X-Google-Smtp-Source: APXvYqwnU3gyaA7CZGpBeg6vT3rpSjTLEFrtunHfPARaUTeI+xRqvaz42HpiqBA0zlRKM9ZjYqH7pXsu9qEAzlYfmhU= X-Received: by 2002:a7b:c935:: with SMTP id h21mr3074340wml.173.1575526089505; Wed, 04 Dec 2019 22:08:09 -0800 (PST) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Wed, 4 Dec 2019 22:07:58 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000e641a30598eec06c" Archived-At: Subject: [tcpm] minutes for Singapore meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 06:08:12 -0000 --000000000000e641a30598eec06c Content-Type: text/plain; charset="UTF-8" Hi, Hi, A draft minutes for Singapore meeting has been uploaded at the following url. Please let the chairs know if you have corrections, suggestions or questions. https://datatracker.ietf.org/meeting/106/materials/minutes-106-tcpm-00.txt Thanks, -- tcpm co-chairs --000000000000e641a30598eec06c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Hi,
A=C2=A0draft minu= tes for Singapore meeting has been uploaded at the following url.
Please let the chairs know if you have corrections, suggestions or = questions.


Thanks,
--
tc= pm co-chairs
--000000000000e641a30598eec06c-- From nobody Sat Dec 7 03:30:51 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4353B1201A3 for ; Sat, 7 Dec 2019 03:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 NqPOUNwlEunH for ; Sat, 7 Dec 2019 03:30:47 -0800 (PST) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 76F081200F1 for ; Sat, 7 Dec 2019 03:30:47 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id xB7BUd0L010763; Sat, 7 Dec 2019 12:30:40 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id A41B91D53C1; Sat, 7 Dec 2019 12:30:38 +0100 (CET) Received: from 83.37.3.185 by webmail.entel.upc.edu with HTTP; Sat, 7 Dec 2019 12:30:39 +0100 Message-ID: In-Reply-To: <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> Date: Sat, 7 Dec 2019 12:30:39 +0100 From: "Carles Gomez Montenegro" To: "Scheffenegger, Richard" Cc: "Jon Crowcroft" , "tcpm IETF list" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at dash X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Sat, 07 Dec 2019 12:30:40 +0100 (CET) Archived-At: Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 11:30:50 -0000 Hi Richard, Thanks a lot for your message! It is very interesting to witness how the patch you mention offers a way to trigger immediate ACKs, and the related context and benefits. Perhaps a combination or (re)use of existing TCP header fields (e.g. CWR/PSH as per your suggestion below, or the Urgent pointer as suggested earlier by Bob) could be a way to enable triggering immediate ACKs. A concern with these techniques is that they are limited to some extent. For example, some applications produce small segments with the PSH flag set and benefit from Delayed ACKs (e.g. to piggyback ACKs and replies). In those cases, even regardless of the CWR flag, triggering immediate ACKs will avoid achieving performance benefits of Delayed ACKs. In contrast, a dedicated resource (e.g. a TCP header reserved bit, as we propose in the draft) will not suffer such limitations. However, that resource needs to be allocated. Summarizing, there may be two approaches to enable ACK Pull: 1.- Overloading semantics of existing TCP header fields. 2.- Dedicating a resource. Then the question is, considering pros and cons of both approaches: which one do we prefer? It would be great to hear the WG feedback on the above question! Thanks, Carles > Carles, > > I just found, that as a performance improvement measure, linux has > recently added a patch to trigger immediate ACKs when a packet with CWR > is received... > > While the underlying issue was found in the dctcp context, the patch > appears to be against the generic rfc3168 ECN handling code. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd2123a3d7527d4c7092633d55e877c0cc1d84a3 > > While that performance improvement has obvious benefits, RFC3168 is > silent on this particular issue. > > But there are use cases where it is certainly valuable for the sender to > be able to elicit an immediate ACK from the receiver. > > > I don't know if it warrants a dedicated bit though - or if, for example, > the combination of CWR/PSH could perhaps obtain the ACK PULL semantics > as an overload of of their normal semantics... > > > Best regards, > Richard > > > Am 18.11.2019 um 08:21 schrieb Jon Crowcroft: >> Mark Handley said a lot of the middlebox corner case avoidance stuff is >> in the tcpmp RFC...have got time to look just yet... >> >> On Mon, 18 Nov 2019, 04:46 Carles Gomez Montenegro, >> > wrote: >> >> Hi Bob, >> >> Once again, thanks a lot for all the very useful feedback! >> >> Please find below some inline responses. >> >> > Carles, Jon, (re-sending, this time without accidentally omitting >> tcpm, >> > also see couple of addenda tagged [Bob adds:]) >> > >> > I'm generally supportive of a mechanism to suppress delayed ACKs >> from >> > the receiver (in any transport protocol including TCP). So thank >> you. >> > >> > You might want to borrow at least some of the text for additional >> > motivating scenarios for such a facility from the first two posts >> on a >> > thread for a similar facility in QuiC: >> > https://github.com/quicwg/base-drafts/issues/1978 >> > >> > Also pasted at the end. >> > >> > Some is not relevant to your specific ack-pull scheme, 'cos it's >> > proposing a more general facility in QUIC for the sender to the >> receiver >> > alters its ACK ratio. (theoretically there are more bits >> available in >> > QUIC, but this particular request has been put on hold while >> someone >> > goes and finds them ;) >> >> Thanks a lot. This is indeed very useful! >> >> As you explain, the more general facility for QUIC allows to >> suppress >> Delayed ACKs and also allows to modify the ACK ratio in a more >> general >> way. >> >> Regarding the Delayed ACK suppression discussion, the additional >> motivation is definitely important. >> >> >       Another motivating example (rather niche) >> > >> > Coincidentally, Just this morning I published a tech report that >> had to >> > use the hack of overlapping a byte from the previous segment to >> force a >> > quick ack: >> > TCP Prague Fall-back on Detection of a Classic ECN AQM >> > (the link takes you >> to Fig >> > 2, which illustrates the hack) >> > I'd rather not have to do these sorts of hacks - it really messes >> with >> > the segmentation code. >> >> This is very useful feedback as well, and a nice coincidence! >> >> Regarding the hack, sending an old byte may be even worse when there >> is >> not a next data segment readily available for sending, which would >> lead to >> sending a whole packet just to carry an old byte. >> >> >       Middlebox traversal of bit 6 >> > >> > I recall that someone did a study of traversal of each of the >> reserved >> > flags (Marcelo Bagnulo maybe?). I don't think it was that good >> [Bob >> > adds: I mean traversal - not the study!]. >> > A good search engine might find it ;) >> >> I wasn't able to find the study, but this is an important >> consideration.. >> >> One might think that if new functionality is defined and >> standardized, >> related middlebox traversal of it should improve over time. Perhaps >> that >> might be optimistic... >> >> >       More alternative approaches: >> > >> > 1/ At one stage, we tried to include a bit for Delayed Ack >> control in >> > another protocol called Accurate ECN. We were persuaded to take >> it out, >> > because it was mission creep (outside the scope of the protocol >> we were >> > working on): >> > >> https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#appendix-B.4 >> >> I was unaware of this, thanks! >> >> This is actually very aligned with what we are proposing... >> >> > 2/ Have you considered using the Urgent Pointer in a novel way? >> I.e. a >> > non-zero Urgent Pointer field, even tho the URG flag is zero. >> > [Bob adds:] From memory, traversal was pretty good - much better >> than >> > bits 4-6. But I think Windows treated it as a potential attack. I >> > believe Fernando Gont did a study on how 'invalid' TCP header >> fields are >> > handled. >> > >> > You could assign, say, 3 bits of the urgent pointer for a >> variable >> > ack_exp that is log base 2 of the ack ratio the sender would >> like. Then >> > the sender can request the receiver uses ack_ratio` = 2^ack_exp, >> as in >> > the QUIC proposal below, >> > With ack_exp = 0, you get ack_ratio = 2^0 = 1, which has the same >> effect >> > as ack-pull. But you also have a more general facility for high >> speed >> > machines to widen out the ack ratio. >> > >> > If this works, you could open up a registry for the other 13 >> bits. So >> > instead of using up a precious bit, you generate 13 more ;) >> >> Nice! :) >> >> Actually, we had not considered such an idea. >> >> In your proposal above, if a segment has the URG flag set to 1, >> would then >> the 3 ack_exp bits still be used as ack_exp bits, thus reducing the >> size >> of the urgent pointer in practice to 13 bits? >> >> > See: >> > https://tools.ietf.org/agenda/90/slides/slides-90-tcpm-10.pdf#page=5 >> > >> > I think there were problems with some implementations and >> middleboxes >> > (bound to be). I've checked the minutes of the IETF meeting where >> that >> > slide was presented >> > , >> but >> > there's no push-back in there. I suggest you delve back into the >> > archives of the tcpm mailing list around the time of that meeting >> to >> > find out if there were any show-stoppers. >> >> Thanks for the pointers! >> >> Sure, we'll check the tcpm mailing list archive. >> >> Cheers, >> >> Carles >> >> >> > Cheers >> > >> > >> > >> > Bob >> > >> > >> > Paste from QUIC thread: >> > >> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> > >> > >> > >> >       Problem/goals: >> > >> >  1. Getting up to speed fast without inducing much queue is one >> of the >> >     main areas where latency reductions are needed (for short >> and >> long >> >     flows). The sender needs frequent ACKing during this phase >> in >> many >> >     approaches (hystart, etc). A Linux TCP receiver starts >> with >> >     ack_ratio 1 and uses heuristics to identify the end of the >> sender's >> >     slow-start (or a re-start after idle). This has ossified a >> certain >> >     slow-start behaviour into all TCP senders (whether Linux >> or >> not). We >> >     are trying to new sender behaviours (paced chirping being >> an >> >     example), but we need a way for the sender to suppress >> delayed ACKs. >> >  2. At the other end of the scale, for long-running flows, many >> current >> >     CC approaches (e.g. BBR) use pacing not ACK-clocking so >> they >> can use >> >     very few ACKs per RTT. And fewer means less cache >> ejections >> for GRO. >> >     But the receiver doesn't know what CC the sender is using, >> so it >> >     doesn't know how many or few is too many or too few. >> >  3. Some middleboxes and the majority of link technologies (e.g. >> DOCSIS, >> >     LTE, Satellite) thin TCP ACKs when they detect the >> upstream is >> >     filled with TCP ACK stream(s), which are unresponsive. >> Otherwise the >> >     ACKs constrain downstream throughput (and any upstream >> data >> either >> >     in the flow itself, or in others). We don't want these >> links to >> >     attempt to guess which are the QUIC ACKs and try to thin >> them. QUIC >> >     can and should do this itself. QUIC has all the machinery >> for the >> >     sender CC to detect ACK congestion, but not the protocol >> to >> tell the >> >     receiver to do the thinning. This protocol addition would >> provide a >> >     sufficient hook for hosts to unilaterally add this to >> their CC >> >     behaviour. >> > >> > >> >       Some scenarios where the sender's preferred ack_ratio >> changes >> >       through the connection: >> > >> >  1. >> > >> >     A sender CC that wants the receiver to turn off DelAcks >> during >> >     flow-start (e.g. it's using hybrid slow-start as in Cubic >> and >> wants >> >     to get delay measurements more frequently) sets ack_exp=0 >> during >> >     flow-start (ack_ratio=1), then increases ack_exp during >> congestion >> >     avoidance. If it goes idle, then re-starts, it would set >> ack_exp=0 >> >     again. >> > >> >     Note on heuristics: A Linux TCP receiver currently uses a >> heuristic >> >     to determine when the sender has exited slow-start. >> However, >> >     heuristics -> ossification. A Linux receiver's heuristic >> only >> works >> >     with the current pattern of slow-start. In TCP, when we >> tried to >> >     improve the pattern on the sender (paced chirping), the >> heuristic on >> >     the receiver killed us. >> > >> >  2. >> > >> >     Imagine a paced sender has hardware generic receive >> offload >> (GRO), >> >     so for a long-running flow it doesn't want a high rate of >> QUIC ACKs >> >     that are opaque to GRO. Let's say it would prefer at least >> 8 ACKs >> >     per RTT. Again, it starts with ack_exp=0, but in >> congestion >> >     avoidance it would use: >> > >> >     ack_ratio <= cwnd_in_packets/8 >> > >> > Upshot: By remote controlling the receiver, the server offloads >> nearly >> > all the ACKs from large downloads, but still focuses its >> ACK-receiving >> > resources on getting each client up to speed. >> > >> > Note that calculation of ack_ratio lends itself to fast integer >> > arithmetic. >> > >> > >> > >> > >> > >> > >> > >> > Bob >> > >> > >> > -- >> > ________________________________________________________________ >> > Bob Briscoehttp://bobbriscoe.net/ >> > >> > >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > From nobody Sat Dec 7 05:01:48 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DF0120026 for ; Sat, 7 Dec 2019 05:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.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 cWc7Zhrd3Vho for ; Sat, 7 Dec 2019 05:01:46 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 D7430120024 for ; Sat, 7 Dec 2019 05:01:45 -0800 (PST) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1575723705; b=femrc4ozZ4fRq1JI1szkcQPmeeZFxmCVp1wy2THnuJPh294R9+sG5ESh7VpHX6ScRtcJR02W8i Kypke6JVe4WHlmkvlIiKQkHU/DktffVa91lgLZk9XDcPvPWZG6S05xJzX6e3mqdTcAH4m5iGGJ P13n4VoFBMa28kbiP5aPZQs=; ARC-Authentication-Results: i=1; wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1575723705; bh=LQz17AOrLW5G8zqkPme5I7iHGtHBiL/hTowAz3Tqdl8=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=W5sltc1z7+O1Jiu3V57u3qnc2MuNm5WivcSY8IKg4ORn/yIU+6H5j4dg8aIg7c2DBJynlltAop 1vPNFi0FxQZjLN98ksY+Yf8i2B9/SaAMk3z4nxgYW3BAEtQDt4LDw22d+2HzHmfoI1e4xwxv1a C+fHtOej/9kuNHeQCZWtzHk=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=a9AiU3tq+G6SmRbYkhvl3vpmDuO03LGN9a4kxY/M7Ow=; b=Y ht52jX2hLJl+xbzBf9kNBLDTUh0KmK02vPHDTJkKpYO94JSik7JnVEz+KhTKlyH5m5lnAF823l0pn WjV579eVcjXcm1IHx6RJakgoGWZAVVbkI3bwus2Gtm6zwKe1iluTgf9wHqGbEp86FW6CFxCYBoVzs n4n/I92nIZa45QJ0=; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) by wizmail.org (Exim 4.92.134) (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with esmtpsa id 1idZiR-00074G-4f for tcpm@ietf.org (return-path ); Sat, 07 Dec 2019 13:01:43 +0000 To: tcpm@ietf.org References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <56fe444b-87a2-8004-a178-98e8da1e28ea@wizmail.org> Date: Sat, 7 Dec 2019 13:01:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 13:01:48 -0000 On 07/12/2019 11:30, Carles Gomez Montenegro wrote: > Summarizing, there may be two approaches to enable ACK Pull: > > 1.- Overloading semantics of existing TCP header fields. > 2.- Dedicating a resource. Dedicating a resource, specifically a new TCP option type, if enabling this feature produces performance benefits, would have the useful effect of inducing the removal of middleboxes that filter unknown options. -- Cheers, Jeremy From nobody Sat Dec 7 05:08:50 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711DF1200EC for ; Sat, 7 Dec 2019 05:08:48 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 dZBNL9E1DLPZ for ; Sat, 7 Dec 2019 05:08:46 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 95B93120024 for ; Sat, 7 Dec 2019 05:08:46 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 262D91B00193; Sat, 7 Dec 2019 13:08:43 +0000 (GMT) Message-ID: <5DEBA45A.2060504@erg.abdn.ac.uk> Date: Sat, 07 Dec 2019 13:08:42 +0000 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: Jeremy Harris CC: tcpm@ietf.org References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> <56fe444b-87a2-8004-a178-98e8da1e28ea@wizmail.org> In-Reply-To: <56fe444b-87a2-8004-a178-98e8da1e28ea@wizmail.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 13:08:48 -0000 On 07/12/2019, 13:01, Jeremy Harris wrote: > On 07/12/2019 11:30, Carles Gomez Montenegro wrote: >> Summarizing, there may be two approaches to enable ACK Pull: >> >> 1.- Overloading semantics of existing TCP header fields. >> 2.- Dedicating a resource. > Dedicating a resource, specifically a new TCP option type, > if enabling this feature produces performance benefits, > would have the useful effect of inducing the removal of > middleboxes that filter unknown options. Personally, I suspect, that's not going to be a likely outcome in any reasonable time frame - and we should focus on understanding whether paths that do permit this will gain useful benefit. Gorry From nobody Sat Dec 7 06:04:01 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40B11200A4 for ; Sat, 7 Dec 2019 06:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 T6JufCO6Svdl for ; Sat, 7 Dec 2019 06:03:58 -0800 (PST) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 5ADFB120047 for ; Sat, 7 Dec 2019 06:03:58 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id h23so10693278ljc.8 for ; Sat, 07 Dec 2019 06:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XXsEIaqKNMeAkf0+NROtHaeTOOrKuDnAN6NYBZfBaHo=; b=NJO5pGA3q3Pv+E7JvpOpHXeiFl+yKSTqN4OVZ+DletMJoFtkVChkHwPpXpUlkrpmxo gKL4tpuAMc7/u7RmmdByEYhMC2od/EKguSbnc+c9oyYAXvVQPRYqZLnNB3EyTE3hJz4a bkmJuKs/DqjlL7phahRWk7icvG00jwjcp8FJyKJe/xPJ7BzFD/JvHlCjQb8hfi9gvMry 2tqcC1Mwp6rZE3b4B2tJWj8XrW42l0Q1vHPSF7w+3V5z2SCQei5ruNXpLDMn9kMv1HTQ tLTuQsPagt04RcIsm/V20tknODJw7v0HC7YSClNZfYqiNr4J4/T4znbHEV73E/YzLx2F j8rw== 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=XXsEIaqKNMeAkf0+NROtHaeTOOrKuDnAN6NYBZfBaHo=; b=A0mmX6yyyKrfT8F6h+xYHNV4BwG+tUl+SO35w1/WpZ1QkgLXWJeFKezVOOLMx8d9rL nf47WqxbBqIEfltybRCx6M7dn/XF2++CNPbtivbFgSkLE7fdFYiDEdLYX9oakVDqIsUL qjuEnp0j+Nz9gLwX45aJzPm1jWNSsak6SgOPemkg6Xvo1PjSBWe6USrw/JJS2c7A7iGh jgOOBscScr1xmmVecbMRappxfC8CzGrluv/W/u4AtlXGMEueTHobC21rbzMe7miFSjta AI1BP3hQWXqrqQzODgOs/SzmsJql7UZ+R3x4IJ1S12vab1UsobvKX8qTe27sTCIAgNLi g0og== X-Gm-Message-State: APjAAAWxaZnz0QOH8t/AClzn46re03+U5YQOGC5gtHu3zZV45piHV7hT VWifU8aAP7UbO536c2OjQng= X-Google-Smtp-Source: APXvYqyL4cPx9Hzb7PtYMfgWkYaJuHxJimPbluQUhNRI8WjHIV7XXsaRTQjaX2b++Lt/OqYdX8AlAg== X-Received: by 2002:a05:651c:1139:: with SMTP id e25mr11745862ljo.200.1575727436604; Sat, 07 Dec 2019 06:03:56 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id i19sm8385557ljj.24.2019.12.07.06.03.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Dec 2019 06:03:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton X-Priority: 3 (Normal) In-Reply-To: Date: Sat, 7 Dec 2019 16:03:53 +0200 Cc: "Scheffenegger, Richard" , tcpm IETF list , Jon Crowcroft Content-Transfer-Encoding: quoted-printable Message-Id: <2BA84671-AF1A-40B0-A195-B64059B780CD@gmail.com> References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> To: Carles Gomez Montenegro X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 14:04:00 -0000 > On 7 Dec, 2019, at 1:30 pm, Carles Gomez Montenegro = wrote: >=20 > A concern with these techniques is that they are limited to some = extent. > For example, some applications produce small segments with the PSH = flag > set and benefit from Delayed ACKs (e.g. to piggyback ACKs and = replies). In > those cases, even regardless of the CWR flag, triggering immediate = ACKs > will avoid achieving performance benefits of Delayed ACKs. >=20 > In contrast, a dedicated resource (e.g. a TCP header reserved bit, as = we > propose in the draft) will not suffer such limitations. However, that > resource needs to be allocated. >=20 > Summarizing, there may be two approaches to enable ACK Pull: >=20 > 1.- Overloading semantics of existing TCP header fields. > 2.- Dedicating a resource. >=20 > Then the question is, considering pros and cons of both approaches: = which > one do we prefer? I note that the semantics of the AKP flag differ subtly from that of = PSH, in that the former says "I want an ack immediately", while the = latter says "I have temporarily run out of data to send, so the = receiving application's buffer should be flushed now". It would be just = as easy to modify existing receivers to treat PSH as an immediate ack = request as to implement handling of AKP, so this simple use doesn't seem = very compelling for allocating a scarce bit. One potentially interesting application that was suggested to me, and = which could legitimately motivate the use of a new reserved flag bit, = was to provide a hint as to the correct Delayed Ack ratio, for use as a = congestion control mechanism for acks. Presently an ack stream can be = anti-responsive, in that dropping acks from a heavily congested reverse = path can actually increase the ack arrival rate, by improving the = throughput of an uncongested forward path that was limited by = ack-clocking. AckCC exists as an RFC to address this problem - and = would tend to benefit from Generalised ECN - but its reliance on a TCP = option is less than optimal, given the traversal problems often cited. A way that such a hint could work is by spacing AKP flags at the desired = ack ratio. A receiver observing AKP flags could then infer that the = usual Delayed Ack rule requiring an ack for every two MSS received is = suspended, and thus only send acks when AKP is set, the Delayed Ack = timer expires, or some other forcing condition occurs. It might be wise to restore normal Delayed Ack rules if the AKP flags = stop indicating a reasonable ratio, for example if the Delayed Ack timer = expires twice without an AKP flag arriving. A maximum ratio could be = specified as a sanity check, eg. 1:64, at which the receiver generates = an ack even if an AKP hasn't arrived yet. The above hinting semantics would remain compatible with other use cases = mentioned, as AKP still forces an ack. However this is also a = theoretical disadvantage because the segments marked with AKP generally = won't coincide with the trailing end of bursts caused, for example, by = link-layer aggregation or IRQ "optimisation" in NICs. Those trailing = segments are where you would optimally want to trigger an ack, but as = currently specified, AKP removes the receiver's discretion to = synchronise a sparse Delayed Ack ratio with those segments. This could be addressed by pairing AKP with PSH. Both flags set = together would require an immediate ack of that particular segment, with = the implication both that an ack is expected promptly and that no more = data is immediately forthcoming. PSH by itself would continue to permit = a degree of latitude with respect to ack timing, and merely indicates = that prompt delivery to the application is required. AKP by itself then = requests a prompt ack, but one that may reflect following segments that = are already in receive buffers and will be processed immediately after = this one, as well as the hinting described above. I think that's a reasonable amount of new functionality to introduce for = the cost of one bit. The above suggestion addresses both the original = problem and another long-standing one, with minimal newly allocated = resources and relatively little risk of traversal problems. And = (importantly) TCP doesn't break if receivers ignore or fail to = understand it. - Jonathan Morton From nobody Sun Dec 8 23:44:07 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F81120108 for ; Sun, 8 Dec 2019 23:44:05 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_NONE=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 x_9N0KhzQHYh for ; Sun, 8 Dec 2019 23:44:02 -0800 (PST) Received: from mail-out-2.itc.rwth-aachen.de (mail-out-2.itc.rwth-aachen.de [IPv6:2a00:8a60:1:e501::5:47]) (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 A6F6D120103 for ; Sun, 8 Dec 2019 23:44:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2B1AgBM+u1d/xUN4ollGwEBAQEBAQEFA?= =?us-ascii?q?QEBEQEBAwMBAQGBfoFLVVkTD0kvKgqwUAkBAQEBAQEBAQEIGAEKCgIBAYRAAoI?= =?us-ascii?q?WJDgTAhABAQUBAQEBAQUEbYU3AQuFUwIBAwEBURsLEAIBCD8HJwsUEQIEDgWDI?= =?us-ascii?q?gGBeX4BAwurPx+FMIM1gUIGgTaMGA+BTD+BEScPEYFOfj6BBIFgAQGFJYIsBI0?= =?us-ascii?q?xiEKJUI8WB4FEbXKUdBuOSYtpjkqaU4EyNyKBWDMaJE8qAYJBUBEUjH6Ib4U/d?= =?us-ascii?q?IEojGEBgQ8BAQ?= X-IPAS-Result: =?us-ascii?q?A2B1AgBM+u1d/xUN4ollGwEBAQEBAQEFAQEBEQEBAwMBAQG?= =?us-ascii?q?BfoFLVVkTD0kvKgqwUAkBAQEBAQEBAQEIGAEKCgIBAYRAAoIWJDgTAhABAQUBA?= =?us-ascii?q?QEBAQUEbYU3AQuFUwIBAwEBURsLEAIBCD8HJwsUEQIEDgWDIgGBeX4BAwurPx+?= =?us-ascii?q?FMIM1gUIGgTaMGA+BTD+BEScPEYFOfj6BBIFgAQGFJYIsBI0xiEKJUI8WB4FEb?= =?us-ascii?q?XKUdBuOSYtpjkqaU4EyNyKBWDMaJE8qAYJBUBEUjH6Ib4U/dIEojGEBgQ8BAQ?= X-IronPort-AV: E=Sophos; i="5.69,294,1571695200"; d="scan'208,217"; a="96673509" Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-2.itc.rwth-aachen.de with ESMTP; 09 Dec 2019 08:43:57 +0100 Received: from messenger-mbx.win.comsys.rwth-aachen.de (messenger-mbx.win.comsys.rwth-aachen.de [137.226.13.43]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id DF18E42261; Mon, 9 Dec 2019 08:43:57 +0100 (CET) Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 9 Dec 2019 08:43:57 +0100 Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c]) by messenger-mbx.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c%12]) with mapi id 15.00.1130.005; Mon, 9 Dec 2019 08:43:57 +0100 From: Mike Kosek To: "wes@mti-systems.com" CC: "tcpm@ietf.org" Thread-Topic: [tcpm] RFC793bis draft 14 Reserved Bits Thread-Index: AQHVpUhJ+yGPLZAplkKvEj5tj27Qsaef0DOAgAATF4CACLylAIABbymAgAdeYwA= Date: Mon, 9 Dec 2019 07:43:56 +0000 Message-ID: References: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net> <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com> <1D733CAD-E295-4234-B882-1AE6EBB4BDF6@comsys.rwth-aachen.de> <2157455f-13d6-8d93-c0fb-dbe874c01bc7@mti-systems.com> In-Reply-To: <2157455f-13d6-8d93-c0fb-dbe874c01bc7@mti-systems.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2.247.241.188] Content-Type: multipart/alternative; boundary="_000_B2113A5811C943A5990B06A200BD3829comsysrwthaachende_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] RFC793bis draft 14 Reserved Bits X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 07:44:05 -0000 --_000_B2113A5811C943A5990B06A200BD3829comsysrwthaachende_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it would be a mistake and fruitless to try to say for the other ind= ividual fields which ones MUST be unaltered by the network. Generally, thi= s is the expectation for the entire segment, even though that expectation d= oesn't typically hold anymore (due to NAT, etc). I wouldn't say much more = than that, because it's inviting misunderstanding that it's okay to twiddle= with any bits and violate laying whenever the doc doesn't explicitly indic= ate not to. Fair enough. In the case of reserved bits, I believe the reason we're trying to be so cl= ear is that we want any new feature that might use them to work. At least,= in the past when this came up, that was why the current 793bis text on the= reserved bits differs a little from the original 793 text (which is just "= Reserved for future use. Must be zero."). I agree. However, future features assigning Rsrvd could extend the Control = Bits with SHOULD requirements. As ECN shows with SHLD-8 "A TCP SHOULD imple= ment ECN as described in RFC 3168", the usage is recommended, but not requi= red. If someone opts to not include RFC 3168, it is not stated how this TCP= must handle the unused bits. I think that an explicit statement of how to = handle these cases will be beneficial, i.e., as a MUST within Control Bits = of Section 3.1: "A TCP that does not implement a Control Bits optional feature MUST handle = it as a Rsrvd Bit." Best, Mike On 4. Dec 2019, at 16:12, Wesley Eddy > wrote: On 12/3/2019 12:18 PM, Mike Kosek wrote: I would second the proposal to be more explicit. If we would add a MUST of = unaltered traversal in this specific case, I am wondering if this should be= addressed in other fields as well. Obviously there are limitations for cer= tain option types, or src/dst port, but Flags and Window Size seem like per= fect fits. Flags would also be the subsequent step of Rodney's and Joe's pr= oposal, as bits would not be covered any longer if they are assigned. In the case of reserved bits, I believe the reason we're trying to be so cl= ear is that we want any new feature that might use them to work. At least,= in the past when this came up, that was why the current 793bis text on the= reserved bits differs a little from the original 793 text (which is just "= Reserved for future use. Must be zero."). I think it would be a mistake and fruitless to try to say for the other ind= ividual fields which ones MUST be unaltered by the network. Generally, thi= s is the expectation for the entire segment, even though that expectation d= oesn't typically hold anymore (due to NAT, etc). I wouldn't say much more = than that, because it's inviting misunderstanding that it's okay to twiddle= with any bits and violate laying whenever the doc doesn't explicitly indic= ate not to. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_B2113A5811C943A5990B06A200BD3829comsysrwthaachende_ Content-Type: text/html; charset="us-ascii" Content-ID: <6209A3122F0FAF46BDC5F183188351A1@comsys.rwth-aachen.de> Content-Transfer-Encoding: quoted-printable

I think it would be a mistake and fruitless to try to say for= the other individual fields which ones MUST be unaltered by the network.&n= bsp; Generally, this is the expectation for the entire segment, even though= that expectation doesn't typically hold anymore (due to NAT, etc).  I wouldn't say much more than that, becau= se it's inviting misunderstanding that it's okay to twiddle with any bits a= nd violate laying whenever the doc doesn't explicitly indicate not to.

Fair enough.

In the case of reserved bits, I believe the reason we're tryi= ng to be so clear is that we want any new feature that might use them to wo= rk.  At least, in the past when this came up, that was why the current= 793bis text on the reserved bits differs a little from the original 793 text (which is just "Reserved for futu= re use.  Must be zero.").

I agree. However, future features assigning Rsrvd could ext= end the Control Bits with SHOULD requirements. As ECN shows with SHLD-8 &qu= ot;A TCP SHOULD implement ECN as described in RFC 3168", the usag= e is recommended, but not required. If someone opts to not include RFC 3168, it is not stated how this TCP must handle the unu= sed bits. I think that an explicit statement of how to handle these ca= ses will be beneficial, i.e., as a MUST within Control Bits of Section 3.1:=
"A TCP that does not implement a Control Bits optional feature MUST ha= ndle it as a Rsrvd Bit."


Best,
Mike


On 4. Dec 2019, at 16:12, Wesley Eddy <wes@mti-systems.com> wrote:

On 12/3/2019 12:18 PM, Mike Kosek wrote:

I would second the proposal to be more explici= t. If we would add a MUST of unaltered traversal in this specific case, I a= m wondering if this should be addressed in other fields as well. Obviously there are limitations for certain option t= ypes, or src/dst port, but Flags and Window Size seem like perfect fits. Fl= ags would also be the subsequent step of Rodney's and Joe's proposal, as bi= ts would not be covered any longer if they are assigned.


In the case of reserved bits, I believe the reason we're tryi= ng to be so clear is that we want any new feature that might use them to wo= rk.  At least, in the past when this came up, that was why the current= 793bis text on the reserved bits differs a little from the original 793 text (which is just "Reserved for futu= re use.  Must be zero.").

I think it would be a mistake and fruitless to try to say for= the other individual fields which ones MUST be unaltered by the network.&n= bsp; Generally, this is the expectation for the entire segment, even though= that expectation doesn't typically hold anymore (due to NAT, etc).  I wouldn't say much more than that, becau= se it's inviting misunderstanding that it's okay to twiddle with any bits a= nd violate laying whenever the doc doesn't explicitly indicate not to.



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--_000_B2113A5811C943A5990B06A200BD3829comsysrwthaachende_-- From nobody Tue Dec 10 05:42:15 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035C0120098 for ; Tue, 10 Dec 2019 05:42:14 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 gJznOlRuFtaD for ; Tue, 10 Dec 2019 05:42:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D1807120018 for ; Tue, 10 Dec 2019 05:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575985326; bh=HzdEcQoOADw7bh5kneNRV1sA7Q6sY1wSu81950IzqSU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=j2FhKwFeIqgS5hAiXPci8Pzo6oKreAFoUnWqLxyN/CsELUQmuHlzmjG5ikEnq27E2 Y01+eCSilB+vncjvOBrP20HqgqV2CM8xnhZgUaK2+BZrt0n0G01geDWviRyKRWakhH ECwvKjneqOr/amfhsHKm2gPQ+4yMfqJ3NdYB79fI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.233.108] ([185.236.167.136]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M2wGi-1ibMJA0ybc-003JjM; Tue, 10 Dec 2019 14:36:56 +0100 To: Carles Gomez Montenegro Cc: Jon Crowcroft , tcpm IETF list References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> From: "Scheffenegger, Richard" Message-ID: Date: Tue, 10 Dec 2019 14:37:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Zv4RDjOEpc5bioOaN2DCIZCOcMjrtKw6VN8Rr4LmCSkQq89ALgV d2tzxc0OTkGPlH5pN4XuTVox1GMVl4C0je7GGVQzRvpcMOXOcPuGqrJYVuJCM4EIJ0ofvh5 nTzoRXMI4+AxM7Gy3PGyhO1Y1HqnOQ1sggwMyGLqWN0V5hRyOJb7+DshuHEHSyEBYwNsry+ 7OMww3sX4vhd/nB+IToYg== X-UI-Out-Filterresults: notjunk:1;V03:K0:a2TikAHjlHM=:52RnYzRYQ0AXhVnOrvaHfQ PdCtgO7XiRF3j0iKK5SXyPT0DlG19KWnrJ9Ts5E8uTrf+2+eOglhOR+RoV34nKVRYZA8EtZG3 F7hBmWnG73AH7C7rrdZTdmUUD24qqKKHYf1i/czLjvhQjXBiByzOSXRmydUaP9ji6JPRqhTRR 9xRiPZNeWUwThsv2QfBcB3HceHt5UpATudVhYh+nHotEOD3L8HZdi6kBeaoV1et3D9zlqHJhA EeXF00xv513L2pkTdtj3s1voX43ckTFwxiYe7Uhfom8ZZqyN6HQsVuFzS8W+QVpcj9NHJJRD6 aKzLU0yxpB8YK7ZRsyNewLPs2EBbYVUDqR2l9FfQOWgsJiD4FPrb5ZJ4FV/8LSYVhxpc+iQI1 OWsE54xxx7yDNkwAbxtOKx9L++hKLm2M/M6X/gxUWZImnfLrCFVo26g7x3zaqdWIq5xhGM+q4 dDwAh3Lh2nCgI69CSGx3DKexlgD2weoXyx/lIUmLHs6vRlbdjsKud41voQ8U3YlLnBtPdl2vT h96tceSv9Fr9AcdXBeNitJ7VuXM6d16DHZWlHw7TEphF/8SgwFNWOSirgC0FKfh3MLziOaB8Z SWpy6fLcLyUffa5cl6gneLetkPConef328QM0jUsRgiNFQSq0y+A7COWPc/QII/jUEhv3lZMf dS67WythcTY61O9PLNdvqgHjYWRXoAYEZ4M7nIioqtLd4QkpmU2897MKy2LvAEdV8E1210qJu LBmaiHWxYzmHgDQ+LwecsVeIH5mfJn0VKEpK3sWeqSPcGTDg+nTCWhQAwvd13eTGk+/EWTlc/ 6JvfYaF61LEodB1lMIJ2YPCD3crMjv4v3djhPYdil1V0VkH4QXn5R4uzvFDHJCxMzyD3DT5aE XPulqqEFqP4jUwDVk1Kr6iS3D+rEAqbOIpIm5knTpR/bR4KsbltA1vEjMrXhcEmPal3QQdk1n bWnzl0xO/6twjtnAH5HaUMcmVwD9Bb1VXvjnDRuiR3ETRFLImmL+4bo7X05C/aVwZmHPvhzc/ +Xnp2Gj/4hw6uAMYjSQS5CsOKgurzbyBnr6dnNAmAvUBlkcPfFc0Tdd5wm1EPZND1eXoawuPx XK6HpZJuLsc7HQNsE5cbJMvQ/wrmbTqhxHNuAA3xk4H0X7vM3ULGtChjs4TGHIzQWTfuLhj8A V5C9/D+k8dV342B8VN0Q2lIz7S1M3sUonSvDUddwDZe6qeOQs/mcyEbgSw9K6pBYEJoZ3vAzG 8bI+aEdjODO5F+Dj/mvfrJ98ZJ8QBkS7eQxo6Vg== Archived-At: Subject: Re: [tcpm] More motivating scenarios for tcpm-ack-pull X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 13:42:14 -0000 I believe your list here misses the AckCC option of RFC5690 (which is only informational, not even experimental). Am Ack Ratio option of 1 followed by a an Ack Ratio of n could serve the same purpose... Note that there have been multiple investigations showing good traversability of new options across middleboxes nowadays. Best regards, Richard Am 07.12.2019 um 12:30 schrieb Carles Gomez Montenegro: > ess how the patch you mention offers a way > to trigger immediate ACKs, and the related context and benefits. > > Perhaps a combination or (re)use of existing TCP header fields (e.g. > CWR/PSH as per your suggestion below, or the Urgent pointer as suggested > earlier by Bob) could be a way to enable triggering immediate ACKs. > > A concern with these techniques is that they are limited to some extent. > For example, some applications produce small segments with the PSH flag > set and benefit from Delayed ACKs (e.g. to piggyback ACKs and replies). = In > those cases, even regardless of the CWR flag, triggering immediate ACKs > will avoid achieving performance benefits of Delayed ACKs. > > In contrast, a dedicated resource (e.g. a TCP header reserved bit, as we > propose in the draft) will not suffer such limitations. However, that > resource needs to be allocated. > > Summarizing, there may be two approaches to enable ACK Pull: > > 1.- Overloading semantics of existing TCP header fields. > 2.- Dedicating a resource. > > Then the question is, considering pros and cons of both approaches: whic= h > one do we prefer? > > It would be great to hear the WG feedback on the above question! > > Thanks, From nobody Tue Dec 10 18:19:19 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791A4120B1A for ; Tue, 10 Dec 2019 18:19:15 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 JPl0hqw27KCW for ; Tue, 10 Dec 2019 18:19:13 -0800 (PST) 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 C60331208FE for ; Tue, 10 Dec 2019 18:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=Kj/C/JUTMiChpneVQ2gr4XJyaruS5OBZXZS/lQ7WhC0=; b=nKDXMTwIUt+fqxmUjHK4b8Ds3A OljgsYda4sBVW5KjgRv77nIiDA/x+LL1hMPn95I7OQWZc+NzQcwcf5QMAug7Ify6H4V3f7FJVf9S0 +kG2rOmBmMZ1zORLz1tr8CqIVg/5vvTNB90Sdb3czn2nTeUVyg9weHvygFNVK8wAlZ+1usDGKwB48 qjwpRsFolILRUcsI21q+6ImJ6FLkYZy3iBcJuv3gx3RuIQxmlHT7kVfYipubFPKaK51XcC6BkZ6qD 9GbYCLslZpwe+Kcz2iyCz9yuYETbp21lLbJs0WK6WxD6rKDBvYz5MWhjle6g2UA8uhnecuJY4hI8M JQuBAfIg==; Received: from [31.185.128.31] (port=43906 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ieran-0008PV-Bc; Wed, 11 Dec 2019 02:19:09 +0000 To: Mirja Kuehlewind Cc: Jonathan Morton , tcpm IETF list , Richard Scheffenegger References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> From: Bob Briscoe Message-ID: <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> Date: Wed, 11 Dec 2019 02:19:08 +0000 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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 02:19:18 -0000 Mirja, On 23/1119 I sent an analysis of the changes that would need to be made to the AccECN draft if it became stds track (which would imply that it then updates RFC3168) instead of expt track. For context, please read and possibly respond to that before you respond to this email. However, my email below applies whether AccECN is stds track or expt track. I've shifted the quoting back into order below, so the context is more clear, and I've then responded inline... >> On 25. Nov 2019, at 22:41, Bob Briscoe wrote: >> >> Mirja, >> >> >> On 26/11/2019 01:02, Mirja Kuehlewind wrote: >>> Hi Jonathan, >>> >>> [MK] Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me. [BB] Please be clear exactly which requirements you are talking about. When I read the above, I just gave up and threw my laptop out of the window. Having bought a new laptop, I'm now wondering... perhaps you didn't mean all of the normative requirements under table 2 when you said 'we should not have these normative requirements', altho from your earlier email I got the distinct impression you did mean that (which is why I wasted a laptop). What did you mean? Given the considerable amount of normative language in this part of the draft, and that it's all been stable for all 16 revisions since draft-kuehlewind-01, I think we deserve to see the actual text you are proposing, and some sound reasoning for why the current normative text suddenly all has to be junked. more... >>> >>> [MK] Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions. >> [BB] In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol. >> >> This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!). >> >> The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes. >> >> In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0. >> >> The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN. >> >> I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0). On 02/12/2019 11:15, Mirja Kuehlewind wrote: > Hi Bob, > > Regarding the [above] sentence: > > This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead. [BB] But an AccECN /server/ does not have to support RFC3168. It might be desirable to support 3168 as well as AccECN, but strictly it doesn't have to for interoperability - it can fall-back to non-ECN if it receives a 3168 SYN. That was my reason for starting this thread. If an AccECN server supports 3168, it replies (0,0,1). But it can just not support 3168 at all. Then it replies (0,0,0). However, it cannot do neither. Hence why I said it MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0). This cannot be said by referring to 3168. >> [MK] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use. [BB] This cannot be said by referring to RFC3168 either. Bob >> >> >> >> Bob >>> Mirja >>> >>> >>>> On 25. Nov 2019, at 17:48, Jonathan Morton wrote: >>>> >>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind wrote: >>>>> >>>>> I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode. >>>> I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement: >>>> >>>>> Therefore, as soon as an >>>>> AccECN-enabled TCP server (B) receives the SYN shown, it MUST set >>>>> both its half connections into the feedback mode shown in the >>>>> rightmost column. >>>> - Jonathan Morton >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Dec 11 00:48:29 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572FF1207FE for ; Wed, 11 Dec 2019 00:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 mQcKEHuHHfrN for ; Wed, 11 Dec 2019 00:48:24 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 68A611200A3 for ; Wed, 11 Dec 2019 00:48:24 -0800 (PST) Received: from [46.183.103.8] (helo=[172.18.209.92]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iexfQ-0003Rg-RN; Wed, 11 Dec 2019 09:48:21 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> Date: Wed, 11 Dec 2019 09:48:18 +0100 Cc: Jonathan Morton , tcpm IETF list , Richard Scheffenegger Content-Transfer-Encoding: quoted-printable Message-Id: References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576054104;043d1216; X-HE-SMSGID: 1iexfQ-0003Rg-RN Archived-At: Subject: Re: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 08:48:27 -0000 Hi Bob, Sorry about your laptop (but if I remember correctly, it was broken = anyway=E2=80=A6). I think we do agree (and did from the beginning). Yes, = I think my first statement below was overly broad and I did not meant to = remove all normative language from that section. I was only referring to = language that talked about RFC3168 negotiation. You propose below that an AccECN sender "MUST respond to a 3168 SYN with = either (0,0,1) or (0,0,0)=E2=80=9D and I'm rather saying that we should = not use normative language here but rather say something like: =E2=80=9CIf= an AccECN sender received a 3168 SYN (without AE=3D1 respectively) is = replies as specified in RFC3168 if it is configured to support classic = ECN.=E2=80=9D Or something like that. That=E2=80=99s all :-) Mirja > On 11. Dec 2019, at 03:19, Bob Briscoe wrote: >=20 > Mirja, >=20 > On 23/1119 I sent an analysis of the changes that would need to be = made to the AccECN draft if it became stds track (which would imply that = it then updates RFC3168) instead of expt track. For context, please read = and possibly respond to that before you respond to this email. >=20 > However, my email below applies whether AccECN is stds track or expt = track. >=20 > I've shifted the quoting back into order below, so the context is more = clear, and I've then responded inline... >>> On 25. Nov 2019, at 22:41, Bob Briscoe wrote: >>>=20 >>> Mirja, >>>=20 >>>=20 >>> On 26/11/2019 01:02, Mirja Kuehlewind wrote: >>>> Hi Jonathan, >>>>=20 >>>> [MK] Sorry I wasn=E2=80=99t clear. I think we should not have these = normative requirement in the draft and change the text to make it = non-normative. This section was meant to explain which modes you end up = in and the current use of normative language doesn=E2=80=99t seem to be = right to me. > [BB] Please be clear exactly which requirements you are talking about. = When I read the above, I just gave up and threw my laptop out of the = window. >=20 > Having bought a new laptop, I'm now wondering... perhaps you didn't = mean all of the normative requirements under table 2 when you said 'we = should not have these normative requirements', altho from your earlier = email I got the distinct impression you did mean that (which is why I = wasted a laptop). >=20 > What did you mean? Given the considerable amount of normative language = in this part of the draft, and that it's all been stable for all 16 = revisions since draft-kuehlewind-01, I think we deserve to see the = actual text you are proposing, and some sound reasoning for why the = current normative text suddenly all has to be junked. >=20 > more... >=20 >>>>=20 >>>> [MK] Likewise the table was also not meant to say whenever you = implement AccECN, you MUST negotiate it in the handshake. And likewise = the table does not show any classic ECN only transitions. >>> [BB] In the spec of AccECN, it's necessary and reasonable to state = normative requirements for a node "that is AccECN-enabled". That doesn't = mean that an AccECN implementation has to always support AccECN - it can = always disable AccECN. But we do have to say what it is expected to do = if it is following the AccECN protocol. >>>=20 >>> This draft has included that normative language for the negotiation = phase in all 16 revisions since the first individual draft (that you = wrote!). >>>=20 >>> The table shows only cases where one end or the other is = AccECN-capable, and the text preceding and following the table gives = normative requirements solely for the AccECN node(s) in those cases. It = doesn't give any normative requirements for non-AccECN nodes. >>>=20 >>> In block 3, the server is AccECN capable, so in the AccECN spec. = it's perfectly reasonable to say what it ought to do in response to = various types of SYN. In particular, if it receives a SYN with = AE,CWR,ECE=3D0,0,0 the AccECN-enabled server MUST respond with = AE,CWR,ECE=3D0,0,0. >>>=20 >>> The only case that is in question, AFAIC, is whether we have to say = what an AccECN-capable server does in response to a SYN from an RFC3168 = client (AE,CWR,ECE=3D0,1,1). We need to somehow say an AccECN server can = respond with a SYN-ACK that is either RFC3168 or non-ECN. >>>=20 >>> I just proposed respectively SHOULD and MAY, but I can now see there = is no need to make that judgement call. However, it is still important = to say an AccECN-enabled server MUST respond with either (0,0,1) or = (0,0,0). >=20 > On 02/12/2019 11:15, Mirja Kuehlewind wrote: >> Hi Bob, >>=20 >> Regarding the [above] sentence: >>=20 >> This is a normative statement that is defined in RFC3168 and we = should not state it here again but refer to RFC3168 instead. > [BB] But an AccECN /server/ does not have to support RFC3168. It might = be desirable to support 3168 as well as AccECN, but strictly it doesn't = have to for interoperability - it can fall-back to non-ECN if it = receives a 3168 SYN. >=20 > That was my reason for starting this thread. If an AccECN server = supports 3168, it replies (0,0,1). But it can just not support 3168 at = all. Then it replies (0,0,0). >=20 > However, it cannot do neither. Hence why I said it MUST respond to a = 3168 SYN with either (0,0,1) or (0,0,0). >=20 > This cannot be said by referring to 3168. >>> [MK] It's also important that the spec defines all three bits in the = SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the = combinations with AE=3D1 are ruled out and therefore remain available = for future use. > [BB] This cannot be said by referring to RFC3168 either. >=20 >=20 >=20 > Bob >>>=20 >>>=20 >>>=20 >>> Bob >>>> Mirja >>>>=20 >>>>=20 >>>>> On 25. Nov 2019, at 17:48, Jonathan Morton = wrote: >>>>>=20 >>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind = wrote: >>>>>>=20 >>>>>> I don=E2=80=99t think we can or should derive a normative = requirement from this table. The table rather explains which mode you = are in depending on the handshake that has happened. So it says: when = client A is ECN capable and requests classic ECN support in the = handshake and server B is AccECN capable and negotiated classic ECN = support in the handshake then you are in classic ECN mode. >>>>> I will merely re-quote the final sentence from my quoted text, = which transforms that table into a normative requirement: >>>>>=20 >>>>>> Therefore, as soon as an >>>>>> AccECN-enabled TCP server (B) receives the SYN shown, it MUST = set >>>>>> both its half connections into the feedback mode shown in the >>>>>> rightmost column. >>>>> - Jonathan Morton >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ >>>=20 >>>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 >=20 From nobody Wed Dec 11 02:13:10 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91968120130 for ; Wed, 11 Dec 2019 02:13:06 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 chMzmt4jFSH6 for ; Wed, 11 Dec 2019 02:13:04 -0800 (PST) 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 513A41200E9 for ; Wed, 11 Dec 2019 02:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=QK+riQl7ovm3QSe7oMB5QQtHV+f59x0rGYORsv5kWkE=; b=2ZaXLmW/hyof2Ha5RN1utE4X/C cOC3VrYdG7H77R8w1FZsZ79JGXzLZCUq5R0tCnG2YrBKB/aLSQ0NDcpWlzo75WR/PGu38zsbgHeGE 3cY3+VKpEy2UkvMb9sPk84m8E1ncVWTEx3YOaIrPVk16iHbw5l+YWT2lQB3mRAs80HsuKbOuRCBBh oQAC+CVjSSirEHHuQkJSqgoplGlqDyp8C2iWoBwIOTk71+MBAahcIAZS67cVI5ejR1QKqM8wGxgF2 OE/JwBsLr27rtgJbo6125rhuTm5Tm2JYso4YD1WynDbpF59CsqWFp8LgraLdRKG6CkTn6knZ8maLC vIVxhQZQ==; Received: from [31.185.128.31] (port=44906 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ieyzM-0000je-Rb; Wed, 11 Dec 2019 10:13:01 +0000 To: Mirja Kuehlewind Cc: Jonathan Morton , tcpm IETF list , Richard Scheffenegger References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> From: Bob Briscoe Message-ID: <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> Date: Wed, 11 Dec 2019 10:12:59 +0000 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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 10:13:07 -0000 Mirja, On 11/12/2019 08:48, Mirja Kuehlewind wrote: > Hi Bob, > > Sorry about your laptop (but if I remember correctly, it was broken anyway…). I think we do agree (and did from the beginning). Yes, I think my first statement below was overly broad and I did not meant to remove all normative language from that section. I was only referring to language that talked about RFC3168 negotiation. > > You propose below that an AccECN sender "MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use normative language here but rather say something like: “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.” Or something like that. That’s all :-) Pls respond to my two points (that keep getting overlooked), both starting with "This cannot be said by referring to 3168" further down the email. Bob > > Mirja > > > >> On 11. Dec 2019, at 03:19, Bob Briscoe wrote: >> >> Mirja, >> >> On 23/1119 I sent an analysis of the changes that would need to be made to the AccECN draft if it became stds track (which would imply that it then updates RFC3168) instead of expt track. For context, please read and possibly respond to that before you respond to this email. >> >> However, my email below applies whether AccECN is stds track or expt track. >> >> I've shifted the quoting back into order below, so the context is more clear, and I've then responded inline... >>>> On 25. Nov 2019, at 22:41, Bob Briscoe wrote: >>>> >>>> Mirja, >>>> >>>> >>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote: >>>>> Hi Jonathan, >>>>> >>>>> [MK] Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me. >> [BB] Please be clear exactly which requirements you are talking about. When I read the above, I just gave up and threw my laptop out of the window. >> >> Having bought a new laptop, I'm now wondering... perhaps you didn't mean all of the normative requirements under table 2 when you said 'we should not have these normative requirements', altho from your earlier email I got the distinct impression you did mean that (which is why I wasted a laptop). >> >> What did you mean? Given the considerable amount of normative language in this part of the draft, and that it's all been stable for all 16 revisions since draft-kuehlewind-01, I think we deserve to see the actual text you are proposing, and some sound reasoning for why the current normative text suddenly all has to be junked. >> >> more... >> >>>>> [MK] Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions. >>>> [BB] In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol. >>>> >>>> This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!). >>>> >>>> The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes. >>>> >>>> In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0. >>>> >>>> The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN. >>>> >>>> I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0). >> On 02/12/2019 11:15, Mirja Kuehlewind wrote: >>> Hi Bob, >>> >>> Regarding the [above] sentence: >>> >>> This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead. >> [BB] But an AccECN /server/ does not have to support RFC3168. It might be desirable to support 3168 as well as AccECN, but strictly it doesn't have to for interoperability - it can fall-back to non-ECN if it receives a 3168 SYN. >> >> That was my reason for starting this thread. If an AccECN server supports 3168, it replies (0,0,1). But it can just not support 3168 at all. Then it replies (0,0,0). >> >> However, it cannot do neither. Hence why I said it MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0). >> >> This cannot be said by referring to 3168. >>>> [BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use. >> [BB] This cannot be said by referring to RFC3168 either. >> >> >> >> Bob >>>> >>>> >>>> Bob >>>>> Mirja >>>>> >>>>> >>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton wrote: >>>>>> >>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind wrote: >>>>>>> >>>>>>> I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode. >>>>>> I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement: >>>>>> >>>>>>> Therefore, as soon as an >>>>>>> AccECN-enabled TCP server (B) receives the SYN shown, it MUST set >>>>>>> both its half connections into the feedback mode shown in the >>>>>>> rightmost column. >>>>>> - Jonathan Morton >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>>> >>>> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Dec 11 07:28:23 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025CC120863 for ; Wed, 11 Dec 2019 07:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 XsphCp215A_j for ; Wed, 11 Dec 2019 07:28:20 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 2051612081C for ; Wed, 11 Dec 2019 07:28:20 -0800 (PST) Received: from [129.192.10.3] (helo=[10.149.1.243]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1if3uU-0004Uj-9N; Wed, 11 Dec 2019 16:28:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> Date: Wed, 11 Dec 2019 16:28:17 +0100 Cc: Jonathan Morton , tcpm IETF list , Richard Scheffenegger Content-Transfer-Encoding: quoted-printable Message-Id: <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576078100;238200c2; X-HE-SMSGID: 1if3uU-0004Uj-9N Archived-At: Subject: Re: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 15:28:22 -0000 Hi Bob, Sorry I think I just got a bit lost here. So this point: >>>> [BB] It's also important that the spec defines all three bits in = the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that = the combinations with AE=3D1 are ruled out and therefore remain = available for future use. >> [BB] This cannot be said by referring to RFC3168 either. I=E2=80=99m not sure I understand what you mean, given that the = combination with AE=3D1 is/needs to be discussion in this draft. Are we = again talking past each other (but actually agree)? Mirja > On 11. Dec 2019, at 11:12, Bob Briscoe wrote: >=20 > Mirja, >=20 > On 11/12/2019 08:48, Mirja Kuehlewind wrote: >> Hi Bob, >>=20 >> Sorry about your laptop (but if I remember correctly, it was broken = anyway=E2=80=A6). I think we do agree (and did from the beginning). Yes, = I think my first statement below was overly broad and I did not meant to = remove all normative language from that section. I was only referring to = language that talked about RFC3168 negotiation. >>=20 >> You propose below that an AccECN sender "MUST respond to a 3168 SYN = with either (0,0,1) or (0,0,0)=E2=80=9D and I'm rather saying that we = should not use normative language here but rather say something like: = =E2=80=9CIf an AccECN sender received a 3168 SYN (without AE=3D1 = respectively) is replies as specified in RFC3168 if it is configured to = support classic ECN.=E2=80=9D Or something like that. That=E2=80=99s all = :-) > Pls respond to my two points (that keep getting overlooked), both = starting with "This cannot be said by referring to 3168" further down = the email. >=20 >=20 > Bob >>=20 >> Mirja >>=20 >>=20 >>=20 >>> On 11. Dec 2019, at 03:19, Bob Briscoe wrote: >>>=20 >>> Mirja, >>>=20 >>> On 23/1119 I sent an analysis of the changes that would need to be = made to the AccECN draft if it became stds track (which would imply that = it then updates RFC3168) instead of expt track. For context, please read = and possibly respond to that before you respond to this email. >>>=20 >>> However, my email below applies whether AccECN is stds track or expt = track. >>>=20 >>> I've shifted the quoting back into order below, so the context is = more clear, and I've then responded inline... >>>>> On 25. Nov 2019, at 22:41, Bob Briscoe = wrote: >>>>>=20 >>>>> Mirja, >>>>>=20 >>>>>=20 >>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote: >>>>>> Hi Jonathan, >>>>>>=20 >>>>>> [MK] Sorry I wasn=E2=80=99t clear. I think we should not have = these normative requirement in the draft and change the text to make it = non-normative. This section was meant to explain which modes you end up = in and the current use of normative language doesn=E2=80=99t seem to be = right to me. >>> [BB] Please be clear exactly which requirements you are talking = about. When I read the above, I just gave up and threw my laptop out of = the window. >>>=20 >>> Having bought a new laptop, I'm now wondering... perhaps you didn't = mean all of the normative requirements under table 2 when you said 'we = should not have these normative requirements', altho from your earlier = email I got the distinct impression you did mean that (which is why I = wasted a laptop). >>>=20 >>> What did you mean? Given the considerable amount of normative = language in this part of the draft, and that it's all been stable for = all 16 revisions since draft-kuehlewind-01, I think we deserve to see = the actual text you are proposing, and some sound reasoning for why the = current normative text suddenly all has to be junked. >>>=20 >>> more... >>>=20 >>>>>> [MK] Likewise the table was also not meant to say whenever you = implement AccECN, you MUST negotiate it in the handshake. And likewise = the table does not show any classic ECN only transitions. >>>>> [BB] In the spec of AccECN, it's necessary and reasonable to state = normative requirements for a node "that is AccECN-enabled". That doesn't = mean that an AccECN implementation has to always support AccECN - it can = always disable AccECN. But we do have to say what it is expected to do = if it is following the AccECN protocol. >>>>>=20 >>>>> This draft has included that normative language for the = negotiation phase in all 16 revisions since the first individual draft = (that you wrote!). >>>>>=20 >>>>> The table shows only cases where one end or the other is = AccECN-capable, and the text preceding and following the table gives = normative requirements solely for the AccECN node(s) in those cases. It = doesn't give any normative requirements for non-AccECN nodes. >>>>>=20 >>>>> In block 3, the server is AccECN capable, so in the AccECN spec. = it's perfectly reasonable to say what it ought to do in response to = various types of SYN. In particular, if it receives a SYN with = AE,CWR,ECE=3D0,0,0 the AccECN-enabled server MUST respond with = AE,CWR,ECE=3D0,0,0. >>>>>=20 >>>>> The only case that is in question, AFAIC, is whether we have to = say what an AccECN-capable server does in response to a SYN from an = RFC3168 client (AE,CWR,ECE=3D0,1,1). We need to somehow say an AccECN = server can respond with a SYN-ACK that is either RFC3168 or non-ECN. >>>>>=20 >>>>> I just proposed respectively SHOULD and MAY, but I can now see = there is no need to make that judgement call. However, it is still = important to say an AccECN-enabled server MUST respond with either = (0,0,1) or (0,0,0). >>> On 02/12/2019 11:15, Mirja Kuehlewind wrote: >>>> Hi Bob, >>>>=20 >>>> Regarding the [above] sentence: >>>>=20 >>>> This is a normative statement that is defined in RFC3168 and we = should not state it here again but refer to RFC3168 instead. >>> [BB] But an AccECN /server/ does not have to support RFC3168. It = might be desirable to support 3168 as well as AccECN, but strictly it = doesn't have to for interoperability - it can fall-back to non-ECN if it = receives a 3168 SYN. >>>=20 >>> That was my reason for starting this thread. If an AccECN server = supports 3168, it replies (0,0,1). But it can just not support 3168 at = all. Then it replies (0,0,0). >>>=20 >>> However, it cannot do neither. Hence why I said it MUST respond to a = 3168 SYN with either (0,0,1) or (0,0,0). >>>=20 >>> This cannot be said by referring to 3168. >>>>> [BB] It's also important that the spec defines all three bits in = the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that = the combinations with AE=3D1 are ruled out and therefore remain = available for future use. >>> [BB] This cannot be said by referring to RFC3168 either. >>>=20 >>>=20 >>>=20 >>> Bob >>>>>=20 >>>>>=20 >>>>> Bob >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton = wrote: >>>>>>>=20 >>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind = wrote: >>>>>>>>=20 >>>>>>>> I don=E2=80=99t think we can or should derive a normative = requirement from this table. The table rather explains which mode you = are in depending on the handshake that has happened. So it says: when = client A is ECN capable and requests classic ECN support in the = handshake and server B is AccECN capable and negotiated classic ECN = support in the handshake then you are in classic ECN mode. >>>>>>> I will merely re-quote the final sentence from my quoted text, = which transforms that table into a normative requirement: >>>>>>>=20 >>>>>>>> Therefore, as soon as an >>>>>>>> AccECN-enabled TCP server (B) receives the SYN shown, it = MUST set >>>>>>>> both its half connections into the feedback mode shown in = the >>>>>>>> rightmost column. >>>>>>> - Jonathan Morton >>>>> --=20 >>>>> ________________________________________________________________ >>>>> Bob Briscoe http://bobbriscoe.net/ >>>>>=20 >>>>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ >>>=20 >>>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 >=20 From nobody Wed Dec 11 07:43:39 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B3B120B56 for ; Wed, 11 Dec 2019 07:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 HqNnCpl3tyom for ; Wed, 11 Dec 2019 07:43:35 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 064C2120AF0 for ; Wed, 11 Dec 2019 07:43:35 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id u16so19811807ilg.10 for ; Wed, 11 Dec 2019 07:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jecjx/gv8C8WmHV5x0n7WxbBLFIoy4fva0i8TDw7zLM=; b=dNG8x8pNoZpN51go5rZeRZClDwb23/r2HgPn1l1YAVpMq7Ou6emox6bmiFlADfreiW Kj148FJoQfSrKOlmgSOq35DQZhnwcgxB48k++3/taxlNhsiSjEdc2KVjrY/q+8j2meTM qf+BRS1tB9GW7+isHf+errFCFFR1GAJzI3RFwOJ0WfI94Z6SpYxHow94YvE/0S0EH3HU B/JKjjjzkHkGqCCwPUcspBI/KdjuaG/WGL6PamnfZfCFy22OVOlEK6QY9wdzmAhEZgVo ZOaTUCoPk9hGOyCOt4BAVCxwtb9x9dWF4L7+oekw3TvDyzutokIhH4+zRP8IhcMXH4RH bAAw== 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=Jecjx/gv8C8WmHV5x0n7WxbBLFIoy4fva0i8TDw7zLM=; b=UcHHI4Ex8PK/JrR0DliUvIzlN+UIQWOwkx1CtieG/Cf1RxB+Yczkj+ZLrL8skeqA7x OYe8Ia2JIq2C7Z0smXB2E/MQLUjBJq3VlQiqfZZ7IRHCaksBohFcBwGU5v7rHuBBkYIZ f42pFKrO9G7QGAjUUvdc5LiKh88V5qqOQ3YgQsMW6w9cQwNZ1Z9Mrr/j/fZ7hOylPA6k Kt467A5iUM54hce0J7Q/Z5JYzr2Yg6Rh2BkNcUQyT4vB9+uzzhi3voYghZ1PTPjJ5K68 bPmWfdKHxA5E1+pQvBdckZofYfH+pcC6ilBHhpFl6DJ+aoOUKwlE91kGJZhzfaiIzcyz TURg== X-Gm-Message-State: APjAAAVuODodwlaF7puu8r2VWS5bkUUliqabcNIrCYPOpdP7g7wqqQ+Z 5uTLRsNrpBDKL/rbT+Xlp7wgm7s53Kg+PAVl3M4i+Q== X-Google-Smtp-Source: APXvYqz39Qbe860iWa1x7Ay5jqlbursyWf2tDhLij1dLZhNaZvKWpJLWRusMl7oCbwZis8fC8P3T0xm2KP7Mg08CUeo= X-Received: by 2002:a92:3b10:: with SMTP id i16mr3964045ila.170.1576079014034; Wed, 11 Dec 2019 07:43:34 -0800 (PST) MIME-Version: 1.0 References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> In-Reply-To: <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> From: Matt Mathis Date: Wed, 11 Dec 2019 09:43:23 -0600 Message-ID: To: Bob Briscoe Cc: Mirja Kuehlewind , tcpm IETF list , Richard Scheffenegger Content-Type: multipart/alternative; boundary="000000000000c5622205996f7d70" Archived-At: Subject: Re: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 15:43:38 -0000 --000000000000c5622205996f7d70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a general strategy I would strongly prefer to wrap all 3168 compatibility language in SHOULDS, perhaps with a meta comment that this language will all be obsolete at some point in the future. I haven't been paying attention to a lot of this... Is there a doc that officially adjusts the standards status of 3168? e.g. explicitly says "not recommended for deployment in unsupervised contexts" (e.g. Siri is fine, because Apple can turn it off or update it). If not, the protocol lawyers will be upset about using SHOULDS to deprecate a standard. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. On Wed, Dec 11, 2019 at 4:13 AM Bob Briscoe wrote: > Mirja, > > On 11/12/2019 08:48, Mirja Kuehlewind wrote: > > Hi Bob, > > > > Sorry about your laptop (but if I remember correctly, it was broken > anyway=E2=80=A6). I think we do agree (and did from the beginning). Yes, = I think my > first statement below was overly broad and I did not meant to remove all > normative language from that section. I was only referring to language th= at > talked about RFC3168 negotiation. > > > > You propose below that an AccECN sender "MUST respond to a 3168 SYN wit= h > either (0,0,1) or (0,0,0)=E2=80=9D and I'm rather saying that we should n= ot use > normative language here but rather say something like: =E2=80=9CIf an Acc= ECN sender > received a 3168 SYN (without AE=3D1 respectively) is replies as specified= in > RFC3168 if it is configured to support classic ECN.=E2=80=9D Or something= like > that. That=E2=80=99s all :-) > Pls respond to my two points (that keep getting overlooked), both > starting with "This cannot be said by referring to 3168" further down > the email. > > > Bob > > > > Mirja > > > > > > > >> On 11. Dec 2019, at 03:19, Bob Briscoe wrote: > >> > >> Mirja, > >> > >> On 23/1119 I sent an analysis of the changes that would need to be mad= e > to the AccECN draft if it became stds track (which would imply that it th= en > updates RFC3168) instead of expt track. For context, please read and > possibly respond to that before you respond to this email. > >> > >> However, my email below applies whether AccECN is stds track or expt > track. > >> > >> I've shifted the quoting back into order below, so the context is more > clear, and I've then responded inline... > >>>> On 25. Nov 2019, at 22:41, Bob Briscoe wrote: > >>>> > >>>> Mirja, > >>>> > >>>> > >>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote: > >>>>> Hi Jonathan, > >>>>> > >>>>> [MK] Sorry I wasn=E2=80=99t clear. I think we should not have these > normative requirement in the draft and change the text to make it > non-normative. This section was meant to explain which modes you end up i= n > and the current use of normative language doesn=E2=80=99t seem to be righ= t to me. > >> [BB] Please be clear exactly which requirements you are talking about. > When I read the above, I just gave up and threw my laptop out of the wind= ow. > >> > >> Having bought a new laptop, I'm now wondering... perhaps you didn't > mean all of the normative requirements under table 2 when you said 'we > should not have these normative requirements', altho from your earlier > email I got the distinct impression you did mean that (which is why I > wasted a laptop). > >> > >> What did you mean? Given the considerable amount of normative language > in this part of the draft, and that it's all been stable for all 16 > revisions since draft-kuehlewind-01, I think we deserve to see the actual > text you are proposing, and some sound reasoning for why the current > normative text suddenly all has to be junked. > >> > >> more... > >> > >>>>> [MK] Likewise the table was also not meant to say whenever you > implement AccECN, you MUST negotiate it in the handshake. And likewise th= e > table does not show any classic ECN only transitions. > >>>> [BB] In the spec of AccECN, it's necessary and reasonable to state > normative requirements for a node "that is AccECN-enabled". That doesn't > mean that an AccECN implementation has to always support AccECN - it can > always disable AccECN. But we do have to say what it is expected to do if > it is following the AccECN protocol. > >>>> > >>>> This draft has included that normative language for the negotiation > phase in all 16 revisions since the first individual draft (that you > wrote!). > >>>> > >>>> The table shows only cases where one end or the other is > AccECN-capable, and the text preceding and following the table gives > normative requirements solely for the AccECN node(s) in those cases. It > doesn't give any normative requirements for non-AccECN nodes. > >>>> > >>>> In block 3, the server is AccECN capable, so in the AccECN spec. it'= s > perfectly reasonable to say what it ought to do in response to various > types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=3D0,0,0= the > AccECN-enabled server MUST respond with AE,CWR,ECE=3D0,0,0. > >>>> > >>>> The only case that is in question, AFAIC, is whether we have to say > what an AccECN-capable server does in response to a SYN from an RFC3168 > client (AE,CWR,ECE=3D0,1,1). We need to somehow say an AccECN server can > respond with a SYN-ACK that is either RFC3168 or non-ECN. > >>>> > >>>> I just proposed respectively SHOULD and MAY, but I can now see there > is no need to make that judgement call. However, it is still important to > say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0). > >> On 02/12/2019 11:15, Mirja Kuehlewind wrote: > >>> Hi Bob, > >>> > >>> Regarding the [above] sentence: > >>> > >>> This is a normative statement that is defined in RFC3168 and we shoul= d > not state it here again but refer to RFC3168 instead. > >> [BB] But an AccECN /server/ does not have to support RFC3168. It might > be desirable to support 3168 as well as AccECN, but strictly it doesn't > have to for interoperability - it can fall-back to non-ECN if it receives= a > 3168 SYN. > >> > >> That was my reason for starting this thread. If an AccECN server > supports 3168, it replies (0,0,1). But it can just not support 3168 at al= l. > Then it replies (0,0,0). > >> > >> However, it cannot do neither. Hence why I said it MUST respond to a > 3168 SYN with either (0,0,1) or (0,0,0). > >> > >> This cannot be said by referring to 3168. > >>>> [BB] It's also important that the spec defines all three bits in the > SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the > combinations with AE=3D1 are ruled out and therefore remain available for > future use. > >> [BB] This cannot be said by referring to RFC3168 either. > >> > >> > >> > >> Bob > >>>> > >>>> > >>>> Bob > >>>>> Mirja > >>>>> > >>>>> > >>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton > wrote: > >>>>>> > >>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind > wrote: > >>>>>>> > >>>>>>> I don=E2=80=99t think we can or should derive a normative require= ment from > this table. The table rather explains which mode you are in depending on > the handshake that has happened. So it says: when client A is ECN capable > and requests classic ECN support in the handshake and server B is AccECN > capable and negotiated classic ECN support in the handshake then you are = in > classic ECN mode. > >>>>>> I will merely re-quote the final sentence from my quoted text, > which transforms that table into a normative requirement: > >>>>>> > >>>>>>> Therefore, as soon as an > >>>>>>> AccECN-enabled TCP server (B) receives the SYN shown, it MUS= T > set > >>>>>>> both its half connections into the feedback mode shown in th= e > >>>>>>> rightmost column. > >>>>>> - Jonathan Morton > >>>> -- > >>>> ________________________________________________________________ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> > >>>> > >> -- > >> ________________________________________________________________ > >> Bob Briscoe http://bobbriscoe.net/ > >> > >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000c5622205996f7d70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a general strategy I would strongly=C2=A0prefer to wrap= all=C2=A03168 compatibility=C2=A0language in SHOULDS, perhaps with=C2=A0a = meta comment that this language will all be obsolete at some=C2=A0point in = the future.=C2=A0 =C2=A0

I haven't been paying atten= tion to a lot of this...=C2=A0 Is there a doc that officially adjusts the s= tandards status of 3168?=C2=A0 e.g. explicitly=C2=A0says "not recommen= ded for deployment in unsupervised contexts" (e.g. Siri is fine, becau= se Apple can turn it off or update it).

If not, th= e protocol lawyers=C2=A0will be upset about=C2=A0using SHOULDS to deprecate= =C2=A0a standard.

Thanks,
--MM--
The best way to predict the futur= e is to create it. =C2=A0- Alan Kay

We must not tolerate intolerance= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response mus= t be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 too strong would be hypocritical and risks spiraling out of control= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being = mistaken for tacit approval.

<= /div>
O= n Wed, Dec 11, 2019 at 4:13 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:
Mirja,

On 11/12/2019 08:48, Mirja Kuehlewind wrote:
> Hi Bob,
>
> Sorry about your laptop (but if I remember correctly, it was broken an= yway=E2=80=A6). I think we do agree (and did from the beginning). Yes, I th= ink my first statement below was overly broad and I did not meant to remove= all normative language from that section. I was only referring to language= that talked about RFC3168 negotiation.
>
> You propose below that an AccECN sender "MUST respond to a 3168 S= YN with either (0,0,1) or (0,0,0)=E2=80=9D and I'm rather saying that w= e should not use normative language here but rather say something like: =E2= =80=9CIf an AccECN sender received a 3168 SYN (without AE=3D1 respectively)= is replies as specified in RFC3168 if it is configured to support classic = ECN.=E2=80=9D Or something like that. That=E2=80=99s all :-)
Pls respond to my two points (that keep getting overlooked), both
starting with "This cannot be said by referring to 3168" further = down
the email.


Bob
>
> Mirja
>
>
>
>> On 11. Dec 2019, at 03:19, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>
>> Mirja,
>>
>> On 23/1119 I sent an analysis of the changes that would need to be= made to the AccECN draft if it became stds track (which would imply that i= t then updates RFC3168) instead of expt track. For context, please read and= possibly respond to that before you respond to this email.
>>
>> However, my email below applies whether AccECN is stds track or ex= pt track.
>>
>> I've shifted the quoting back into order below, so the context= is more clear, and I've then responded inline...
>>>> On 25. Nov 2019, at 22:41, Bob Briscoe <ietf@bobbriscoe.net> wrote= :
>>>>
>>>> Mirja,
>>>>
>>>>
>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> [MK] Sorry I wasn=E2=80=99t clear. I think we should n= ot have these normative requirement in the draft and change the text to mak= e it non-normative. This section was meant to explain which modes you end u= p in and the current use of normative language doesn=E2=80=99t seem to be r= ight to me.
>> [BB] Please be clear exactly which requirements you are talking ab= out. When I read the above, I just gave up and threw my laptop out of the w= indow.
>>
>> Having bought a new laptop, I'm now wondering... perhaps you d= idn't mean all of the normative requirements under table 2 when you sai= d 'we should not have these normative requirements', altho from you= r earlier email I got the distinct impression you did mean that (which is w= hy I wasted a laptop).
>>
>> What did you mean? Given the considerable amount of normative lang= uage in this part of the draft, and that it's all been stable for all 1= 6 revisions since draft-kuehlewind-01, I think we deserve to see the actual= text you are proposing, and some sound reasoning for why the current norma= tive text suddenly all has to be junked.
>>
>> more...
>>
>>>>> [MK] Likewise the table was also not meant to say when= ever you implement AccECN, you MUST negotiate it in the handshake. And like= wise the table does not show any classic ECN only transitions.
>>>> [BB] In the spec of AccECN, it's necessary and reasona= ble to state normative requirements for a node "that is AccECN-enabled= ". That doesn't mean that an AccECN implementation has to always s= upport AccECN - it can always disable AccECN. But we do have to say what it= is expected to do if it is following the AccECN protocol.
>>>>
>>>> This draft has included that normative language for the ne= gotiation phase in all 16 revisions since the first individual draft (that = you wrote!).
>>>>
>>>> The table shows only cases where one end or the other is A= ccECN-capable, and the text preceding and following the table gives normati= ve requirements solely for the AccECN node(s) in those cases. It doesn'= t give any normative requirements for non-AccECN nodes.
>>>>
>>>> In block 3, the server is AccECN capable, so in the AccECN= spec. it's perfectly reasonable to say what it ought to do in response= to various types of SYN. In particular, if it receives a SYN with AE,CWR,E= CE=3D0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=3D0,0,0.<= br> >>>>
>>>> The only case that is in question, AFAIC, is whether we ha= ve to say what an AccECN-capable server does in response to a SYN from an R= FC3168 client (AE,CWR,ECE=3D0,1,1). We need to somehow say an AccECN server= can respond with a SYN-ACK that is either RFC3168 or non-ECN.
>>>>
>>>> I just proposed respectively SHOULD and MAY, but I can now= see there is no need to make that judgement call. However, it is still imp= ortant to say an AccECN-enabled server MUST respond with either (0,0,1) or = (0,0,0).
>> On 02/12/2019 11:15, Mirja Kuehlewind wrote:
>>> Hi Bob,
>>>
>>> Regarding the [above] sentence:
>>>
>>> This is a normative statement that is defined in RFC3168 and w= e should not state it here again but refer to RFC3168 instead.
>> [BB] But an AccECN /server/ does not have to support RFC3168. It m= ight be desirable to support 3168 as well as AccECN, but strictly it doesn&= #39;t have to for interoperability - it can fall-back to non-ECN if it rece= ives a 3168 SYN.
>>
>> That was my reason for starting this thread. If an AccECN server s= upports 3168, it replies (0,0,1). But it can just not support 3168 at all. = Then it replies (0,0,0).
>>
>> However, it cannot do neither. Hence why I said it MUST respond to= a 3168 SYN with either (0,0,1) or (0,0,0).
>>
>> This cannot be said by referring to 3168.
>>>> [BB] It's also important that the spec defines all thr= ee bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - = so that the combinations with AE=3D1 are ruled out and therefore remain ava= ilable for future use.
>> [BB] This cannot be said by referring to RFC3168 either.
>>
>>
>>
>> Bob
>>>>
>>>>
>>>> Bob
>>>>> Mirja
>>>>>
>>>>>
>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton <chromatix99@gmail.c= om> wrote:
>>>>>>
>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind = <ietf@kuehlewin= d.net> wrote:
>>>>>>>
>>>>>>> I don=E2=80=99t think we can or should derive = a normative requirement from this table. The table rather explains which mo= de you are in depending on the handshake that has happened. So it says: whe= n client A is ECN capable and requests classic ECN support in the handshake= and server B is AccECN capable and negotiated classic ECN support in the h= andshake then you are in classic ECN mode.
>>>>>> I will merely re-quote the final sentence from my = quoted text, which transforms that table into a normative requirement:
>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 Therefore, as soon as an >>>>>>>=C2=A0 =C2=A0 =C2=A0 AccECN-enabled TCP server = (B) receives the SYN shown, it MUST set
>>>>>>>=C2=A0 =C2=A0 =C2=A0 both its half connections = into the feedback mode shown in the
>>>>>>>=C2=A0 =C2=A0 =C2=A0 rightmost column.
>>>>>> - Jonathan Morton
>>>> --
>>>> __________________________________________________________= ______
>>>> Bob Briscoe=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 =C2=A0http://bob= briscoe.net/
>>>>
>>>>
>> --
>> ________________________________________________________________ >> Bob Briscoe=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 =C2=A0http://bobbriscoe.net/=
>>
>>

--
________________________________________________________________
Bob Briscoe=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 =C2=A0http://bobbriscoe.net/

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000c5622205996f7d70-- From nobody Wed Dec 11 08:14:29 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734A112082F for ; Wed, 11 Dec 2019 08:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 k5OM95t3J1Sz for ; Wed, 11 Dec 2019 08:14:27 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 C674B1200B9 for ; Wed, 11 Dec 2019 08:14:26 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id m6so24738864ljc.1 for ; Wed, 11 Dec 2019 08:14:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lG4/6m1juzlgcPAZScs8X4IkcswDTjx8kpWwDma5HIE=; b=LkxokCYT2DCRj8g5LhoMNV8mxK37oyk2Wqt5XR+LOClFcK9kM8MrUHhSfkFNWggxB1 +y6d4Lm49s2EcOkiH58jpfgWG7WZp43DQysHjMN1XZDnzkbi1ITDEClva5zCpMG/cTUu wMkiHeq7WtvNRfRFgasRVU5yZSf3bTQjJ9Eo5zxj8Ov7SNBfWpz5xBBpJmiueCMZI5aR r/WBFi+Jg+Dx53k7OmZXoyJRTzbnVEbi3+eVvJeXiNxUIOH/oOT0iSPR+rox6Ic/qe9U xB2hbH+ErIeeFazJNFSnqp6YukDqQUjvRWhPEpUsUMswbK6DfNjfsf1hSTBQlZTayJ5S ooBg== 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=lG4/6m1juzlgcPAZScs8X4IkcswDTjx8kpWwDma5HIE=; b=L6T73qnIBEQjofMZSatCLMK8WYevNAX+fGu8MHUTN3hxTDDwwmbeXdHAXs2EvMbxOV OFe9Z6reozUFD4A7JAvQYxa6vrw92chwhQZcafvxiUpHHHCxpNhSacRBU2JOEo2UpLRi 6m1bnieK03r0ARxOcLADXRFafwQK+c6Ff6S4OxzZmBbNMRXMiNayXTx4n7wWbzxA1X5c rITc/cOHvKJisetLR8wLZjpZ4Xp/5lbhU7y1eluTGIvWTYDHemED2U8ozPhzxZkyeszM Dv9SpVl8nWSgswfG+VqXVRKF9EhCLgKT2z2p6o+xJLpj0C9HgaDsWpJZnkvof3K3dkTB /Svg== X-Gm-Message-State: APjAAAWwE48YOG5VZWdWgElxiaX1fopLhfzFyGTMu0FSDSUmHbmhfNhH tpVbQeherEgaauyec9c1ZIk= X-Google-Smtp-Source: APXvYqzbeRKouYr5bF85Wt+AqwjVchMmNGhD1HNBlibq5BEAHi6L4OMMFK9tITf1URFfULoWh0L+2w== X-Received: by 2002:a2e:7005:: with SMTP id l5mr2710981ljc.230.1576080865108; Wed, 11 Dec 2019 08:14:25 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id w16sm1488840lfc.1.2019.12.11.08.14.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 08:14:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Wed, 11 Dec 2019 18:14:22 +0200 Cc: Bob Briscoe , Richard Scheffenegger , tcpm IETF list , Mirja Kuehlewind Content-Transfer-Encoding: quoted-printable Message-Id: <1DF1AF6B-EEF9-4CE8-AEBC-553C0F9E0E90@gmail.com> References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> To: Matt Mathis X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 16:14:28 -0000 > On 11 Dec, 2019, at 5:43 pm, Matt Mathis = wrote: >=20 > As a general strategy I would strongly prefer to wrap all 3168 = compatibility language in SHOULDS, perhaps with a meta comment that this = language will all be obsolete at some point in the future. =20 I definitely object to the latter, not least because it's logically = inconsistent with the handshake protocol. Any AccECN client MUST be = prepared to have their AccECN-requesting SYN interpreted as an RFC-3168 = SYN by an RFC-3168 server, which will reply with an RFC-3168 SYN-ACK and = thereby put the whole connection in RFC-3168 mode. Therefore, RFC-3168 clients will always be at least as prevalent as = AccECN clients, *even if* AccECN servers for some unfathomable reason = decide to drop RFC-3168 support. I maintain that the advantage to doing = so is negligible in the most favourable interpretation. Therefore, you *cannot* assume in AccECN specifications that RFC-3168 = will "eventually" go away. - Jonathan Morton From nobody Wed Dec 11 10:07:57 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF77120088 for ; Wed, 11 Dec 2019 10:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0glgrYyjNU1a for ; Wed, 11 Dec 2019 10:07:54 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 02B32120024 for ; Wed, 11 Dec 2019 10:07:53 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id a22so8676690ios.3 for ; Wed, 11 Dec 2019 10:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5Rw5jfEfogMWtdm5X2EMA7NMs4EfIfcqKQWS9qbQ15Y=; b=vtrV74fmUEyoHXOyHKfuFMpfSxSJpumkvukxMkVA8WD5d0RirvXj86xHROE0sEJFLb 4njPrREccWsZls0tS86Anh92eKRffp3x4MX6goN4bHTyhKLTvQztWT7tI/2AmdBl96uw g630W7ro/HKJtJpxL0nLhoM1ALXRIboQJvihEfLnhTxkN7lLelNHBbjITvxe4lxJxctK AgWHvCsurFjE8eZynm+T4Kj6S3AsZyRVyliU9NmtwTCyAphVOphmGJB0BBDooJRLXu9o iYksYvQSh2625uWNxGnWF50q84za3+Gl5GHg8p0gfBsBd3LHMs5jF0rpOqjRzY/EwVUW Se6Q== 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=5Rw5jfEfogMWtdm5X2EMA7NMs4EfIfcqKQWS9qbQ15Y=; b=JpqSZ8y1UsjcUXxhxlYYgL2sOu5HdEzKMmeoRWKWw3/S7EZirs4rM0O3S1Xp+FHqi2 qrbHlgCVC+jq/o51BqI8xEC6BC/HVqwH7srZ1d2WZKVPE+q+L22IkBIZyDba93oL1FSv /3rUtVLM8Fv2E0Q4ppSWBjvCqv/XDD4ITsukkTPj2To8MB4sqX9HputllVUBhIKyNBf0 uboY4r99z1vdh23s3KS8o2vsd0ivDhDpQwvsEFHbCaBXdC9m3YIg3cPy1mrFp78bP3uC DgvHsNIQun3hMJeBMpflidGDEKg5l8IqGkjtTGQizdwtsD/TOk5gp484/0no0J+REKjX zxrQ== X-Gm-Message-State: APjAAAUSADpqGVprtWL9svkUShXZeO/r4fRI03iuHIk7T9CZuuBFvGZV JoI+jlsBPiBae8zDMuR2gWDAgBNImyE2lLQm3xOOsw== X-Google-Smtp-Source: APXvYqzaOef3CLHkqBo4/JnwIdZ/9OzDfzzR/7IViTJe4Z7JKiw25NJsQf2WRxcJLSzpptD8tGKjB4RSfReNFknA1o0= X-Received: by 2002:a6b:ee17:: with SMTP id i23mr3784810ioh.0.1576087673057; Wed, 11 Dec 2019 10:07:53 -0800 (PST) MIME-Version: 1.0 References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <1DF1AF6B-EEF9-4CE8-AEBC-553C0F9E0E90@gmail.com> In-Reply-To: <1DF1AF6B-EEF9-4CE8-AEBC-553C0F9E0E90@gmail.com> From: Matt Mathis Date: Wed, 11 Dec 2019 12:07:41 -0600 Message-ID: To: Jonathan Morton Cc: Bob Briscoe , Richard Scheffenegger , tcpm IETF list , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="000000000000e3b8c005997181e1" Archived-At: Subject: Re: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 18:07:56 -0000 --000000000000e3b8c005997181e1 Content-Type: text/plain; charset="UTF-8" Content providers who are using some version of DCTCP are constrained to use the same switch markings for all flows. It is inconceivable that anybody would do 3168 in such an environment, however DCTCP and AccECN are likely to work well enough to fly. I think you underestimate how quickly server side 3168 will evaporate once AccECN is far enough along, especially if we are explicit about discouraging distros from shipping it on by default, so the only server side 3168 is by people who are engaged in the research. Remember, by default content providers must stay up to date with upstream bug fixes. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. On Wed, Dec 11, 2019 at 10:14 AM Jonathan Morton wrote: > > On 11 Dec, 2019, at 5:43 pm, Matt Mathis 40google.com@dmarc.ietf.org> wrote: > > > > As a general strategy I would strongly prefer to wrap all 3168 > compatibility language in SHOULDS, perhaps with a meta comment that this > language will all be obsolete at some point in the future. > > I definitely object to the latter, not least because it's logically > inconsistent with the handshake protocol. Any AccECN client MUST be > prepared to have their AccECN-requesting SYN interpreted as an RFC-3168 SYN > by an RFC-3168 server, which will reply with an RFC-3168 SYN-ACK and > thereby put the whole connection in RFC-3168 mode. > > Therefore, RFC-3168 clients will always be at least as prevalent as AccECN > clients, *even if* AccECN servers for some unfathomable reason decide to > drop RFC-3168 support. I maintain that the advantage to doing so is > negligible in the most favourable interpretation. > > Therefore, you *cannot* assume in AccECN specifications that RFC-3168 will > "eventually" go away. > > - Jonathan Morton > > --000000000000e3b8c005997181e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Content providers who are using some version of DCTCP are = constrained to use the same switch=C2=A0markings=C2=A0for all flows.=C2=A0 = It is inconceivable=C2=A0that anybody would do 3168 in such an environment,= however DCTCP and AccECN are likely to work well enough to fly.

I think you underestimate=C2=A0how quickly server side 3168 will e= vaporate once AccECN is far enough along, especially=C2=A0if we are explici= t about discouraging distros from shipping it on by default, so the only se= rver side 3168 is by people who are engaged in the research.=C2=A0 =C2=A0Re= member, by default content providers must stay up to date with upstream bug= fixes.

Thanks,
--MM--
The best way to = predict the future is to create it. =C2=A0- Alan Kay

We must not tol= erate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however= our response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypocritical and risks spirali= ng out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too = weak risks being mistaken for tacit approval.
=


On Wed, Dec 11, 2019 at 10:14 AM Jonathan= Morton <chromatix99@gmail.com<= /a>> wrote:
&= gt; On 11 Dec, 2019, at 5:43 pm, Matt Mathis <mattmathis=3D40google.com@dmarc.ietf= .org> wrote:
>
> As a general strategy I would strongly prefer to wrap all 3168 compati= bility language in SHOULDS, perhaps with a meta comment that this language = will all be obsolete at some point in the future.=C2=A0 =C2=A0

I definitely object to the latter, not least because it's logically inc= onsistent with the handshake protocol.=C2=A0 Any AccECN client MUST be prep= ared to have their AccECN-requesting SYN interpreted as an RFC-3168 SYN by = an RFC-3168 server, which will reply with an RFC-3168 SYN-ACK and thereby p= ut the whole connection in RFC-3168 mode.

Therefore, RFC-3168 clients will always be at least as prevalent as AccECN = clients, *even if* AccECN servers for some unfathomable reason decide to dr= op RFC-3168 support.=C2=A0 I maintain that the advantage to doing so is neg= ligible in the most favourable interpretation.

Therefore, you *cannot* assume in AccECN specifications that RFC-3168 will = "eventually" go away.

=C2=A0- Jonathan Morton

--000000000000e3b8c005997181e1-- From nobody Wed Dec 11 10:12:37 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D37120088 for ; Wed, 11 Dec 2019 10:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 bz1wuvOeI3cy for ; Wed, 11 Dec 2019 10:12:32 -0800 (PST) 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 953A6120118 for ; Wed, 11 Dec 2019 10:12:32 -0800 (PST) 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=oIIUYj1sYSWhlad+n9X45ewuv7SzxriGx8h3gtYXWo0=; b=xKMPQG8WnWu+6SvIQIrX5vdzl geLPASQWzrvmKXswC8IDnWHRMIAdKD7sPFNHsMNg6ziKLs4j/2rNau6rPk8TcoY5ZLZ8g+ITazcE6 XAvpn1pBZUFQuPHDA8qACwgong8Gl2Eqjqiu8S0XrZEdC/OEwJybRMSVwLlciksBmsIRPpjyKhJHI 0E82MLcuh0pO2g28+53PChrr7MtDjtpE19AwWImA5ZsxpVobTGXh4uz4vGLwGitssj+nxVTdxflSp avH4mlUTjc2hV5XZ0zFUOwcHJ4OlMbAwPoomkBnI+Lw+VRfLGFnFzN2sC7bGOa4RTJ+gt1QdQm4KD KnuYlzmQA==; Received: from [31.185.128.31] (port=43622 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1if6TO-00076a-OZ; Wed, 11 Dec 2019 18:12:30 +0000 To: Wesley Eddy Cc: "tcpm@ietf.org" References: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net> <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com> <77bade9d-f090-9ec7-cc7a-29e4118321ad@mti-systems.com> From: Bob Briscoe Message-ID: Date: Wed, 11 Dec 2019 18:12:30 +0000 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: <77bade9d-f090-9ec7-cc7a-29e4118321ad@mti-systems.com> Content-Type: multipart/alternative; boundary="------------F639596781C1B0196DA0AE61" 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: [tcpm] RFC793bis draft 14 Reserved Bits X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 18:12:36 -0000 This is a multi-part message in MIME format. --------------F639596781C1B0196DA0AE61 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Wes, On 04/12/2019 14:59, Wesley Eddy wrote: >> Perhaps further explicitly: >> >> they MUST be ignored by the network and MUST traverse the network >> unchanged > > > This clarification seems good to me, and it looks like everyone who's > chimed in so far agrees, so I can put it into the upcoming revision. I think it's important to make this a requirement for middleboxes as well as just 'the network'. Where I would define middlebox as a function acting on L4 (TCP) fields without being a full implementation of TCP. I know some middlebox developers will ignore it. But their customers (operators) cannot require middleboxes to comply with IETF spec's if we don't write what middleboxes should do in our specs. You might find some of the text in the AccECN spec on middlebox requirements useful (and pls send comments if it could be improved): https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.3 Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------F639596781C1B0196DA0AE61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Wes,

On 04/12/2019 14:59, Wesley Eddy wrote:
Perhaps further explicitly:

they MUST be ignored by the network and MUST traverse the network unchanged


This clarification seems good to me, and it looks like everyone who's chimed in so far agrees, so I can put it into the upcoming revision.

I think it's important to make this a requirement for middleboxes as well as just 'the network'. Where I would define middlebox as a function acting on L4 (TCP) fields without being a full implementation of TCP.

I know some middlebox developers will ignore it. But their customers (operators) cannot require middleboxes to comply with IETF spec's if we don't write what middleboxes should do in our specs.

You might find some of the text in the AccECN spec on middlebox requirements useful (and pls send comments if it could be improved):
https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.3



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------F639596781C1B0196DA0AE61-- From nobody Wed Dec 11 10:35:07 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDFE1202DD for ; Wed, 11 Dec 2019 10:35:04 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 HXZAddZytS28 for ; Wed, 11 Dec 2019 10:35:02 -0800 (PST) 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 8B56E120273 for ; Wed, 11 Dec 2019 10:35:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=5Qjb4MB7nALNPROTMVKFq1ZEqfxgeaYrIsZ71nx4y2Q=; b=A6CJIgfdCOIQLkaZI7XoyTy/kc fpOa4GUrt+Nkf+fkYv90v0dNzFV7kd0WL1R7DaJftPzaVNckOhEYXFHWbFOLGM6YYE7KUwXIEJRi3 B/vz+7GfbQzxa2KZnMtkOfiBhKxmThqWo5+B8YHmgOpD4h3Y+gcqon74nIFLI1wW75AZ1Czy8q9Vc 3r1b8PKRKm4EJg2vuNHea/Btv4FCBg2D6D0rlpn051eCo82l4tJC699sn0q4RQtgmSm4UB3Mij23/ eaKK+kEGNCRbPGZGmfcdj95zgqv5OP+7Bfj0LTK2AaoPGChtrlosAdGFtRSj/WRzKBtdpqzaxDkeu LheMgeHg==; Received: from [31.185.128.31] (port=43668 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1if6pA-0003EV-Gs; Wed, 11 Dec 2019 18:35:00 +0000 To: Carles Gomez Montenegro Cc: tcpm IETF list , Jon Crowcroft References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> From: Bob Briscoe Message-ID: Date: Wed, 11 Dec 2019 18:34:59 +0000 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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: [tcpm] More motivating scenarios for tcpm-ack-pull X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 18:35:05 -0000 Carles, It strikes me that there is a lot of interest in doing something like ACK-pull, but also a lot of disagreement in where to draw the line between what to do and what not to do. Can I suggest that a way to resolve this would be to start with an informational requirements draft, that I am sure would be adopted as WG business immediately given the interest. Whereas any particular choice of mechanism at this stage would probably not get the necessary consensus to be adopted. The requirements draft could discuss solutions, not as a "on this we all agree" protocol, but in terms of their pros and cons, e.g. which mechanisms could satisfy which requirements, so they can be judged relative to each mechanism's complexity / traversibility / usage of bits / etc. I will warn you that a requirements draft could itself add years to the process (the accurate ECN requirements did [RFC7560]). But not if we agree to allow a solution draft to start in parallel once the requirements are starting to converge, rather than waiting for the requirements to go thru the full RFC process. You might prefer to continue evangelising ack-pull as a sufficient solution, so I don't want to say a requirements draft is the only way forward. But you saw my comment earlier - that once you've been through all the years of effort of getting anything changed in TCP, you sometimes feel that you wish you'd been more ambitious than just one bit at the start. Bob On 10/12/2019 13:37, Scheffenegger, Richard wrote: > > I believe your list here misses the AckCC option of RFC5690 (which is > only informational, not even experimental). Am Ack Ratio option of 1 > followed by a an Ack Ratio of n could serve the same purpose... > > Note that there have been multiple investigations showing good > traversability of new options across middleboxes nowadays. > > Best regards, >    Richard > > > Am 07.12.2019 um 12:30 schrieb Carles Gomez Montenegro: >> ess how the patch you mention offers a way >> to trigger immediate ACKs, and the related context and benefits. >> >> Perhaps a combination or (re)use of existing TCP header fields (e.g. >> CWR/PSH as per your suggestion below, or the Urgent pointer as suggested >> earlier by Bob) could be a way to enable triggering immediate ACKs. >> >> A concern with these techniques is that they are limited to some extent. >> For example, some applications produce small segments with the PSH flag >> set and benefit from Delayed ACKs (e.g. to piggyback ACKs and >> replies). In >> those cases, even regardless of the CWR flag, triggering immediate ACKs >> will avoid achieving performance benefits of Delayed ACKs. >> >> In contrast, a dedicated resource (e.g. a TCP header reserved bit, as we >> propose in the draft) will not suffer such limitations. However, that >> resource needs to be allocated. >> >> Summarizing, there may be two approaches to enable ACK Pull: >> >> 1.- Overloading semantics of existing TCP header fields. >> 2.- Dedicating a resource. >> >> Then the question is, considering pros and cons of both approaches: >> which >> one do we prefer? >> >> It would be great to hear the WG feedback on the above question! >> >> Thanks, > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Dec 11 10:44:03 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AB01201DB; Wed, 11 Dec 2019 10:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 6SJ8t7Usgy7Q; Wed, 11 Dec 2019 10:44:00 -0800 (PST) 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 5ED80120052; Wed, 11 Dec 2019 10:43:59 -0800 (PST) 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:From:Subject:Sender:Reply-To: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=iZf0ln2xWvyduJdYm+6HCXJ4zcnILvjc+GZIXz6fBb4=; b=dCBHwZ93LgK5Tej9Tzqr68DFs B8qVRZbbpVZueX3TvaK4DfG34j5P7sMHT7DiSEqDXI9rdxSXOvZfbGRMzR7PzFmof/lcO8JeekPu3 SETeZ78SehCwi8BO88QJv8yAB439IwQAKLbvwtcOV+wnMeuME7QDgYbRzy/NJ/sc3zLU8q4F/eOha lsnG9vbK4vaecbAi2U7uNsTsiblv948FyVtsMaO8GqSnw5nPxw3hTN4+MQQEirpEgZPLH79KFguIo u3EUqw34gRKN3AH2RKTmBUQ72ybAZvNP/4PbiHTCYQ7p8aJRrSShd85Yxj2ZShqUMwtUePbVLfsY+ 0/Je7A6Vg==; Received: from [31.185.128.31] (port=43688 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1if6xo-0004q0-AD; Wed, 11 Dec 2019 18:43:57 +0000 From: Bob Briscoe References: <83880058-a057-66bf-24a3-855480b29f00@bobbriscoe.net> Cc: tcpm IETF list , "tcpm-chairs@ietf.org" Message-ID: <49c9dfa7-019b-4d16-73f6-8a15c1077c73@bobbriscoe.net> Date: Wed, 11 Dec 2019 18:43:54 +0000 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: <83880058-a057-66bf-24a3-855480b29f00@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------40CC808DB767F34622237EAD" 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: [tcpm] Impact on AccECN draft of change from EXP to PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 18:44:02 -0000 This is a multi-part message in MIME format. --------------40CC808DB767F34622237EAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit tcpm chairs, At IETF-106 there was believed to be rough consensus in the room that AccECN ought to be stds track not expt track. I pointed out that we would need to check for that consensus on the list. We can't really move forward with the draft until that has been done. So would it be possible to do a consensus call on the list on that question ASAP? To provide some concrete data for the question, below I've quoted the analysis I did of what would have to be altered in the AccECN draft if it switched to the stds track. I've also just added one addendum to it. Thanks in advance Bob PS. (Also a consensus call on the list about the question of the process for assigning header flags pls.) On 23/11/2019 11:26, Bob Briscoe wrote: > tcpm-ers, > > Here's analysis of the things in draft-ietf-tcpm-accurate-ecn that > would have to be altered to upgrade it to PS from EXP. This was > generally favoured in the tcpm meeting today, but it has to be > ratified on this list, so I thought this info would be helpful. > > ==Header Block== > Intended Status: Proposed Standard > Updates: 3168 > > ==Throughout== > (substituting intelligently): > s/experimental/standards track/ > s/other experiments/experiments/ > s/other variants/variants/ > > ==1. Intro== > CURRENT: >  "Until the AccECN experiment succeeds, [RFC3168] will remain as the >    only standards track specification for adding ECN to TCP. " > PROPOSED: >   Instead, summarize here how this doc updates RFC3168, referring to a > new section XXX (below) that gives detailed updates. > > CURRENT: >  "It is completely independent of how TCP might respond to congestion >   feedback, which is out of scope. For that we refer to [RFC3168]..." > PROPOSED >  "It is completely independent of how TCP might respond to congestion >   feedback, which is out of scope. For that we refer to [RFC3168] and > [RFC8311], excepting the updates to RFC 3168 in Section XXX of the > present document that generalize the wording to include AccECN." > > ==1.1 Document Roadmap== > Remove ref to 1.3 & include a ref to the new section XXX detailing the > updates to 3168. > > ==1.3 Experiment Goals== > Delete section > > FYI, the two experiment goals are: > 1. fall-back strategies in the face of path traversal problems > 2. interaction of change-triggered ACKs and offloaded processing > > The two "MUST" requirements behind #2 have just been relaxed to > "SHOULD"s as part of the splitting up of change-triggered ACKs between > ACE and the AccECN TCP Option, as I mentioned in the presentation to > the WG. > > #1 is more likely to affect implementation than design, given the > design provides for fall-back in most conceivable circumstances (e.g. > it is designed for any or all AccECN TCP options to be sent but not > received {Note 1}) and there's considerable checking of mangling > already. Nonetheless, we might find byzantine middlebox behaviour, > e.g. stripping the TCP option from some packets but not others, > altering selected protocol fields, altering some header bits but not > others,... I'd like to see some large-scale testing over production > networks before the RFC is published. > > {Note 1}: Altho the latest change has made it necessary to receive the > first AccECN Option in each direction to be able to correctly > understand later options. > > ==XXX. Updates to RFC3168== > New section XXX between sections 3 & 4. > For content, see later in this email. > > ==3.2.6 The AccECN Option== > The Kind of the option can be assigned a permanent value, rather than > a 2B longer option with Kind=254 and a magic number. > > ==6. IANA Considerations== > Delete the para about using experimental option 254. > > > > ===Section XXX. Updates to RFC3168=== > > The following sections of RFC3168 would be updated by the AccECN > specification, if it were stds track: > > * The Introduction to Section "6. Support from the Transport > Protocol" that summarizes the way TCP feeds back ECN markings > * the whole of "6.1.1  TCP Initialization" > * The whole of "6.1.2. The TCP Sender" except the second, third and > last paras still apply to RFC5681 congestion control, but not > necessarily to other experimental forms of ECN congestion control > allowed by RFC8311 (specified by a suitable experimental RFC). > * The whole of "6.1.3.  The TCP Receiver" except the last two > sentences till stand (which are incidentally in the wrong section, > because they relate to TCP sender behaviour): >     "Some care >    is required if the TCP sender is to avoid unnecessary reductions of >    the congestion window when a window of data includes both dropped >    packets and (marked) CE packets.  This is illustrated in > [Floyd98]. " > * The following text within "6.1.5. Retransmitted TCP packets" is > updated as follows: > o CURRENT: > "the TCP data receiver SHOULD > ignore the ECN field on arriving data packets that are outside > of the > receiver's current window." > o UPDATED: > "The TCP data receiver MUST ignore the CE codepoint on incoming > segments that fail any validity check.  The validity check in > section > 5.2 of [RFC5961] is RECOMMENDED." > * Section "5.2 Dropped or Corrupted Packets" of RFC3168 says '"pure" > ACK packets MUST NOT indicate ECN-Capability.' The AccECN draft > will not update this aspect, but it will say what TCP should do if > it receives an ECN-capable pure ACK. > > I'm slightly unsure about this one - any opinions?: > > * Section "23.2 TCP header Flags" within the "IANA Considerations" > Section: > If AccECN is going to update 3168, we will need to consider > whether to update the names ECE and CWR. Even though they don't do > anything related to those names in AccECN, AccECN has to be able > to fall-back to 3168, so I suggest we keep these names. > > > ==Opportunities to close loop-holes== > > I would also like people to check through RFC3168 to look for > opportunities to make behaviour for currently unused values in > protocol fields unambiguous - in order to allow for forward > compatibility (or remove unnecessary restrictions on forward > compatibility) for other future protocols derived from RFC3168. > > As well as the changes that AccECN already makes to the TCP part of > 3168, making AccECN stds track would give an opportunity to update > some TCP feedback-related aspects of 3168 that might have been > overlooked when 8311 was written. I can't think of any, but I'll check > and it would be good if others did too. > > > > > Bob > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------40CC808DB767F34622237EAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit tcpm chairs,

At IETF-106 there was believed to be rough consensus in the room that AccECN ought to be stds track not expt track.

I pointed out that we would need to check for that consensus on the list. We can't really move forward with the draft until that has been done. So would it be possible to do a consensus call on the list on that question ASAP?

To provide some concrete data for the question, below I've quoted the analysis I did of what would have to be altered in the AccECN draft if it switched to the stds track. I've also just added one addendum to it.

Thanks in advance



Bob

PS. (Also a consensus call on the list about the question of the process for assigning header flags pls.)



On 23/11/2019 11:26, Bob Briscoe wrote:
tcpm-ers,

Here's analysis of the things in draft-ietf-tcpm-accurate-ecn that would have to be altered to upgrade it to PS from EXP. This was generally favoured in the tcpm meeting today, but it has to be ratified on this list, so I thought this info would be helpful.

==Header Block==
Intended Status: Proposed Standard
Updates: 3168

==Throughout==
(substituting intelligently):
s/experimental/standards track/
s/other experiments/experiments/
s/other variants/variants/

==1. Intro==
CURRENT:
 "Until the AccECN experiment succeeds, [RFC3168] will remain as the
   only standards track specification for adding ECN to TCP. "
PROPOSED:
  Instead, summarize here how this doc updates RFC3168, referring to a new section XXX (below) that gives detailed updates.

CURRENT:
 "It is completely independent of how TCP might respond to congestion
  feedback, which is out of scope. For that we refer to [RFC3168]..."
PROPOSED
 "It is completely independent of how TCP might respond to congestion
  feedback, which is out of scope. For that we refer to [RFC3168] and [RFC8311], excepting the updates to RFC 3168 in Section XXX of the present document that generalize the wording to include AccECN."

==1.1 Document Roadmap==
Remove ref to 1.3 & include a ref to the new section XXX detailing the updates to 3168.

==1.3 Experiment Goals==
Delete section

FYI, the two experiment goals are:
1. fall-back strategies in the face of path traversal problems
2. interaction of change-triggered ACKs and offloaded processing

The two "MUST" requirements behind #2 have just been relaxed to "SHOULD"s as part of the splitting up of change-triggered ACKs between ACE and the AccECN TCP Option, as I mentioned in the presentation to the WG.

#1 is more likely to affect implementation than design, given the design provides for fall-back in most conceivable circumstances (e.g. it is designed for any or all AccECN TCP options to be sent but not received {Note 1}) and there's considerable checking of mangling already. Nonetheless, we might find byzantine middlebox behaviour, e.g. stripping the TCP option from some packets but not others, altering selected protocol fields, altering some header bits but not others,... I'd like to see some large-scale testing over production networks before the RFC is published.

{Note 1}: Altho the latest change has made it necessary to receive the first AccECN Option in each direction to be able to correctly understand later options.

==XXX. Updates to RFC3168==
New section XXX between sections 3 & 4.
For content, see later in this email.

==3.2.6 The AccECN Option==
The Kind of the option can be assigned a permanent value, rather than a 2B longer option with Kind=254 and a magic number.

==6. IANA Considerations==
Delete the para about using experimental option 254.



===Section XXX. Updates to RFC3168===

The following sections of RFC3168 would be updated by the AccECN specification, if it were stds track:
  • The Introduction to Section "6. Support from the Transport Protocol" that summarizes the way TCP feeds back ECN markings
  • the whole of "6.1.1  TCP Initialization"
  • The whole of "6.1.2. The TCP Sender" except the second, third and last paras still apply to RFC5681 congestion control, but not necessarily to other experimental forms of ECN congestion control allowed by RFC8311 (specified by a suitable experimental RFC).
  • The whole of "6.1.3.  The TCP Receiver" except the last two sentences till stand (which are incidentally in the wrong section, because they relate to TCP sender behaviour):
        "Some care
       is required if the TCP sender is to avoid unnecessary reductions of
       the congestion window when a window of data includes both dropped
       packets and (marked) CE packets.  This is illustrated in [Floyd98]. "
  • The following text within "6.1.5. Retransmitted TCP packets" is updated as follows:
    • CURRENT:
      "the TCP data receiver SHOULD
      ignore the ECN field on arriving data packets that are outside of the
      receiver's current window."
    • UPDATED:
      "The TCP data receiver MUST ignore the CE codepoint on incoming
      segments that fail any validity check.  The validity check in section
      5.2 of [RFC5961] is RECOMMENDED."
  • Section "5.2 Dropped or Corrupted Packets" of RFC3168 says '"pure" ACK packets MUST NOT indicate ECN-Capability.' The AccECN draft will not update this aspect, but it will say what TCP should do if it receives an ECN-capable pure ACK.
I'm slightly unsure about this one - any opinions?:
  • Section "23.2 TCP header Flags" within the "IANA Considerations" Section:
    If AccECN is going to update 3168, we will need to consider whether to update the names ECE and CWR. Even though they don't do anything related to those names in AccECN, AccECN has to be able to fall-back to 3168, so I suggest we keep these names.

==Opportunities to close loop-holes==

I would also like people to check through RFC3168 to look for opportunities to make behaviour for currently unused values in protocol fields unambiguous - in order to allow for forward compatibility (or remove unnecessary restrictions on forward compatibility) for other future protocols derived from RFC3168.

As well as the changes that AccECN already makes to the TCP part of 3168, making AccECN stds track would give an opportunity to update some TCP feedback-related aspects of 3168 that might have been overlooked when 8311 was written. I can't think of any, but I'll check and it would be good if others did too.




Bob

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------40CC808DB767F34622237EAD-- From nobody Wed Dec 11 11:59:00 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C051120052 for ; Wed, 11 Dec 2019 11:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 1_fQpucUephe for ; Wed, 11 Dec 2019 11:58:58 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 B3AF812082C for ; Wed, 11 Dec 2019 11:58:57 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id e10so25464875ljj.6 for ; Wed, 11 Dec 2019 11:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0ZCgTbh7d/CVsq88sJsqQkO2NtZoRzXvgwFNEZ5tTi8=; b=ic+qvebaN3Ad2pmPDfTG3leLsrTdhufNwq/6KYZm3+1JPWJsbPjyICvgTUAJ+0csPy 2USgF8gxFL1dZ0wHOGX+q7qfM+d8MgRL8uXG6gcEs5g4ilThLo2ggwOuLWp7koXiALF0 oMiGG1/ObJmkYdt+NYrp7lwmhQuVVDLAlwDF+Pym3V1XrRZo3/nCz0qULhQm3X7hYrNe UwL0on0gfE31WsRWwwv9qPqbKaVU5RHtrSL0aYe77DUABF42Ere2lW8zFTtsALaNkdgi b0W5dEaFttG4JXQPgeA8hVMmxIyk4rF6kWjAchTvRCcAt9iebOL4EbGF+JyITBeIO/+A 1SYg== 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=0ZCgTbh7d/CVsq88sJsqQkO2NtZoRzXvgwFNEZ5tTi8=; b=fOshWIX4l7pGCiWGuUXzQihusEp7jhL32jUHrA6KTRqHwX3XLf8hLFBgQGTj9Tz65n URQWKn+HT1an35PG6/V15QgRDyfbFTsFFQPscjGw8O1gLY/V5Idhm8x1+t6tfKCDbT4B Bzh021+m8rUJJqh+ZkCfE4ZEwB2TKdpAddigCxF+bXuO4XtpuRxXUrw2qf+QPcdsThXX Ec9mZrLgXwdjp7kw7Uo4/UjzFtn7Nnw+BNobNLSQS9319Q6I8sfefwzhb06EmT7oxJGA 2FtbzsdF6JV3w61S0dZlvDAJcDtDNKb40rv0gnr4J8H0k5ZZB3P9UrDykomb10v8m7uL /Rsw== X-Gm-Message-State: APjAAAWEuSE0KhwB6HLfSedcmySOoNBjzLENfivahXiapmhugFIhVoLy Rm8DgP8KXXmJYWcVgQsfG84= X-Google-Smtp-Source: APXvYqyLl/t+4Z862dDlOD2pyEpYbhz018SuN6/dqZGBvRsW68+ukGG5luAHWYlSGApKd17eQs95gA== X-Received: by 2002:a2e:8045:: with SMTP id p5mr3394846ljg.251.1576094335965; Wed, 11 Dec 2019 11:58:55 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id q14sm1686549ljm.68.2019.12.11.11.58.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 11:58:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Wed, 11 Dec 2019 21:58:53 +0200 Cc: Bob Briscoe , Richard Scheffenegger , tcpm IETF list , Mirja Kuehlewind , "Black, David" Content-Transfer-Encoding: quoted-printable Message-Id: <019D15B2-18A4-499C-BD0E-EF76B851E0E2@gmail.com> References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <1DF1AF6B-EEF9-4CE8-AEBC-553C0F9E0E90@gmail.com> To: Matt Mathis X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 19:58:59 -0000 > On 11 Dec, 2019, at 8:07 pm, Matt Mathis = wrote: > Content providers who are using some version of DCTCP are constrained = to use the same switch markings for all flows. It is inconceivable that = anybody would do 3168 in such an environment, however DCTCP and AccECN = are likely to work well enough to fly. Content providers SHOULD NOT be using DCTCP on the open Internet. That = is the environment with which I am chiefly concerned. If they want to screw up their internal environments, that's no skin off = my nose. > I think you underestimate how quickly server side 3168 will evaporate = once AccECN is far enough along, especially if we are explicit about = discouraging distros from shipping it on by default, so the only server = side 3168 is by people who are engaged in the research. Remember, by = default content providers must stay up to date with upstream bug fixes. In other words, you are actively advocating for the deprecation of = RFC-3168, just as it is gaining traction and actively being deployed in = the real world. You may expect me to object to that at every = opportunity, given the work I've put into ECN-related technologies in = the past several years, and the clear advantages that RFC-3168 shows for = general Internet traffic. I think certain industry members would also = object on a similar basis. If I may be cynical for a moment, I also note that coexistence between = AccECN/L4S and SCE was a topic discussed at and around IETF-106. This = is one of the cornerstones of potentially allowing the L4S and SCE = experiments to run in parallel, and we in the SCE team have been careful = to ensure that we can coexist with AccECN/L4S endpoints, on the = assumption that both schemes would retain RFC-3168 compliance as a = fallback position. This notion that dropping RFC-3168 support would = become the norm appears, to us, to be explicitly designed to damage = SCE's prospects. I sincerely hope that is not actually the case, but = given appearances I would ask for a clarification of that point. The existing text in AccECN mandates falling back both halves of the = connection to RFC-3168 mode if either end supports it but not AccECN, = and the other end supports AccECN. I supported moving AccECN forward = (as EXP) with that language in place. I would feel obliged to withdraw = that support if the text were changed to make RFC-3168 support any less = than a SHOULD at the server end and a MUST at the client end - noting = that the definition of SHOULD is that a pretty solid justification has = to be made for not following the point. - Jonathan Morton From nobody Wed Dec 11 16:13:47 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B3912018D for ; Wed, 11 Dec 2019 16:13:45 -0800 (PST) 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_HELO_NONE=0.001, 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 Dh7I-dRmcJ3h for ; Wed, 11 Dec 2019 16:13:42 -0800 (PST) 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 673BD1200F4 for ; Wed, 11 Dec 2019 16:13:41 -0800 (PST) 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=3SGJfW+cyMIlov9QGtPK3P+4yWdrzVG3pqzcYt526Qk=; b=WowbgxcBz2G4rRMwM6OtrT3yP 2Cs8gaBovoOwhbnUC8KyUxOpLiUuJ/2Op6rksszyITYioI9KcDoMMTNOlGIFudgFo/hm4wIefEL4y pMP1qlCiK3dzq5athDeors/ljwsOnmjNtu1yDZRsl6aPdyzpKqJa3pZYtOzYBEVulAkq9bXjAy0ez HaA5KzGZzZQkdPaJ2FG068hv1a8jbu6rmXYEqJ5NSiBXV9ionh7kdiGmcSI8HDgUqk00J2/uDhz6t MpUihfg3kVt5Wax9OON+/KNFO8AW3RcXpCEgXBSfC5ANj50TXMvkADGDYQepkf7v4DpYG/UwSa9hU bPifTpLwA==; Received: from [31.185.128.31] (port=47238 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ifC6t-0005cv-7B; Thu, 12 Dec 2019 00:13:39 +0000 To: Mirja Kuehlewind Cc: Jonathan Morton , tcpm IETF list , Richard Scheffenegger References: <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> From: Bob Briscoe Message-ID: <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> Date: Thu, 12 Dec 2019 00:13:38 +0000 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: <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> Content-Type: multipart/alternative; boundary="------------1D4B36A9D018F092C4453689" 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: [tcpm] A possible simplification for AccECN servers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2019 00:13:45 -0000 This is a multi-part message in MIME format. --------------1D4B36A9D018F092C4453689 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mirja, On 11/12/2019 15:28, Mirja Kuehlewind wrote: > Hi Bob, > > Sorry I think I just got a bit lost here. > > So this point: >>>>> [BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use. >>> [BB] This cannot be said by referring to RFC3168 either. > I’m not sure I understand what you mean, given that the combination with AE=1 is/needs to be discussion in this draft. Are we again talking past each other (but actually agree)? In the context of these two rows in table 2: +--------+--------+------------+-----------+------------------------+ | A | B | SYN A->B | SYN/ACK | Feedback Mode | | | | | B->A | | +--------+--------+------------+-----------+------------------------+ | | | AE CWR ECE | AE CWR ECE| | ... | AccECN | ECN | 1 1 1 | 0 0 1 | classic ECN | ... | ECN | AccECN | 0 1 1 | 0 0 1 | classic ECN | In the first case, I'm saying the AccECN client (A) only falls back to classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas if in this case we merely said an AccECN client does what RFC3168 says, the AccECN client would have to switch to classic ECN if the SYN/ACK was X01, thus wasting a codepoint. In the second case, the AccECN server only falls back to classic ECN mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas, if in this case we merely said an AccECN server does what RFC3168 says, the server would have to switch to classic ECN if the SYN was X11, thus wasting another codepoint. This is a separate point from the MUST vs SHOULD language in the second case. I'll respond to Jonathan on that next. Bob > > Mirja > > > >> On 11. Dec 2019, at 11:12, Bob Briscoe wrote: >> >> Mirja, >> >> On 11/12/2019 08:48, Mirja Kuehlewind wrote: >>> Hi Bob, >>> >>> Sorry about your laptop (but if I remember correctly, it was broken anyway…). I think we do agree (and did from the beginning). Yes, I think my first statement below was overly broad and I did not meant to remove all normative language from that section. I was only referring to language that talked about RFC3168 negotiation. >>> >>> You propose below that an AccECN sender "MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use normative language here but rather say something like: “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.” Or something like that. That’s all :-) >> Pls respond to my two points (that keep getting overlooked), both starting with "This cannot be said by referring to 3168" further down the email. >> >> >> Bob >>> Mirja >>> >>> >>> >>>> On 11. Dec 2019, at 03:19, Bob Briscoe wrote: >>>> >>>> Mirja, >>>> >>>> On 23/1119 I sent an analysis of the changes that would need to be made to the AccECN draft if it became stds track (which would imply that it then updates RFC3168) instead of expt track. For context, please read and possibly respond to that before you respond to this email. >>>> >>>> However, my email below applies whether AccECN is stds track or expt track. >>>> >>>> I've shifted the quoting back into order below, so the context is more clear, and I've then responded inline... >>>>>> On 25. Nov 2019, at 22:41, Bob Briscoe wrote: >>>>>> >>>>>> Mirja, >>>>>> >>>>>> >>>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote: >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> [MK] Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me. >>>> [BB] Please be clear exactly which requirements you are talking about. When I read the above, I just gave up and threw my laptop out of the window. >>>> >>>> Having bought a new laptop, I'm now wondering... perhaps you didn't mean all of the normative requirements under table 2 when you said 'we should not have these normative requirements', altho from your earlier email I got the distinct impression you did mean that (which is why I wasted a laptop). >>>> >>>> What did you mean? Given the considerable amount of normative language in this part of the draft, and that it's all been stable for all 16 revisions since draft-kuehlewind-01, I think we deserve to see the actual text you are proposing, and some sound reasoning for why the current normative text suddenly all has to be junked. >>>> >>>> more... >>>> >>>>>>> [MK] Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions. >>>>>> [BB] In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol. >>>>>> >>>>>> This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!). >>>>>> >>>>>> The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes. >>>>>> >>>>>> In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0. >>>>>> >>>>>> The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN. >>>>>> >>>>>> I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0). >>>> On 02/12/2019 11:15, Mirja Kuehlewind wrote: >>>>> Hi Bob, >>>>> >>>>> Regarding the [above] sentence: >>>>> >>>>> This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead. >>>> [BB] But an AccECN /server/ does not have to support RFC3168. It might be desirable to support 3168 as well as AccECN, but strictly it doesn't have to for interoperability - it can fall-back to non-ECN if it receives a 3168 SYN. >>>> >>>> That was my reason for starting this thread. If an AccECN server supports 3168, it replies (0,0,1). But it can just not support 3168 at all. Then it replies (0,0,0). >>>> >>>> However, it cannot do neither. Hence why I said it MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0). >>>> >>>> This cannot be said by referring to 3168. >>>>>> [BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use. >>>> [BB] This cannot be said by referring to RFC3168 either. >>>> >>>> >>>> >>>> Bob >>>>>> >>>>>> Bob >>>>>>> Mirja >>>>>>> >>>>>>> >>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton wrote: >>>>>>>> >>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind wrote: >>>>>>>>> >>>>>>>>> I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode. >>>>>>>> I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement: >>>>>>>> >>>>>>>>> Therefore, as soon as an >>>>>>>>> AccECN-enabled TCP server (B) receives the SYN shown, it MUST set >>>>>>>>> both its half connections into the feedback mode shown in the >>>>>>>>> rightmost column. >>>>>>>> - Jonathan Morton >>>>>> -- >>>>>> ________________________________________________________________ >>>>>> Bob Briscoe http://bobbriscoe.net/ >>>>>> >>>>>> >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>>> >>>> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------1D4B36A9D018F092C4453689 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mirja,

On 11/12/2019 15:28, Mirja Kuehlewind wrote:
Hi Bob,

Sorry I think I just got a bit lost here.

So this point:

[BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.

[BB] This cannot be said by referring to RFC3168 either.

I’m not sure I understand what you mean, given that the combination with AE=1 is/needs to be discussion in this draft. Are we again talking past each other (but actually agree)?
In the context of these two rows in table 2:
   +--------+--------+------------+-----------+------------------------+
   | A      | B      |  SYN A->B  |  SYN/ACK  | Feedback Mode          |
   |        |        |            |    B->A   |                        |
   +--------+--------+------------+-----------+------------------------+
   |        |        | AE CWR ECE | AE CWR ECE|                        |
...
   | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            |
...
   | ECN    | AccECN | 0   1   1  | 0   0   1 | classic ECN            |

In the first case, I'm saying the AccECN client (A) only falls back to classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas if in this case we merely said an AccECN client does what RFC3168 says, the AccECN client would have to switch to classic ECN if the SYN/ACK was X01, thus wasting a codepoint.

In the second case, the AccECN server only falls back to classic ECN mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas, if in this case we merely said an AccECN server does what RFC3168 says, the server would have to switch to classic ECN if the SYN was X11, thus wasting another codepoint.


This is a separate point from the MUST vs SHOULD language in the second case. I'll respond to Jonathan on that next.


Bob


Mirja




On 11. Dec 2019, at 11:12, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Mirja,

On 11/12/2019 08:48, Mirja Kuehlewind wrote:

Hi Bob,

Sorry about your laptop (but if I remember correctly, it was broken anyway…). I think we do agree (and did from the beginning). Yes, I think my first statement below was overly broad and I did not meant to remove all normative language from that section. I was only referring to language that talked about RFC3168 negotiation.

You propose below that an AccECN sender "MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use normative language here but rather say something like: “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.” Or something like that. That’s all :-)

Pls respond to my two points (that keep getting overlooked), both starting with "This cannot be said by referring to 3168" further down the email.


Bob

Mirja




On 11. Dec 2019, at 03:19, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Mirja,

On 23/1119 I sent an analysis of the changes that would need to be made to the AccECN draft if it became stds track (which would imply that it then updates RFC3168) instead of expt track. For context, please read and possibly respond to that before you respond to this email.

However, my email below applies whether AccECN is stds track or expt track.

I've shifted the quoting back into order below, so the context is more clear, and I've then responded inline...

On 25. Nov 2019, at 22:41, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Mirja,


On 26/11/2019 01:02, Mirja Kuehlewind wrote:

Hi Jonathan,

[MK] Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me.

[BB] Please be clear exactly which requirements you are talking about. When I read the above, I just gave up and threw my laptop out of the window.

Having bought a new laptop, I'm now wondering... perhaps you didn't mean all of the normative requirements under table 2 when you said 'we should not have these normative requirements', altho from your earlier email I got the distinct impression you did mean that (which is why I wasted a laptop).

What did you mean? Given the considerable amount of normative language in this part of the draft, and that it's all been stable for all 16 revisions since draft-kuehlewind-01, I think we deserve to see the actual text you are proposing, and some sound reasoning for why the current normative text suddenly all has to be junked.

more...


[MK] Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.

[BB] In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol.

This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!).

The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes.

In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.

The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN.

I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).

On 02/12/2019 11:15, Mirja Kuehlewind wrote:

Hi Bob,

Regarding the [above] sentence:

This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead.

[BB] But an AccECN /server/ does not have to support RFC3168. It might be desirable to support 3168 as well as AccECN, but strictly it doesn't have to for interoperability - it can fall-back to non-ECN if it receives a 3168 SYN.

That was my reason for starting this thread. If an AccECN server supports 3168, it replies (0,0,1). But it can just not support 3168 at all. Then it replies (0,0,0).

However, it cannot do neither. Hence why I said it MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0).

This cannot be said by referring to 3168.

[BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.

[BB] This cannot be said by referring to RFC3168 either.



Bob


Bob

Mirja



On 25. Nov 2019, at 17:48, Jonathan Morton <chromatix99@gmail.com> wrote:


On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:

I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode.

I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement:


    Therefore, as soon as an
    AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
    both its half connections into the feedback mode shown in the
    rightmost column.

- Jonathan Morton

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



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



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




    

    

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

  


--------------1D4B36A9D018F092C4453689--


From nobody Wed Dec 11 17:36:57 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F1D120132 for ; Wed, 11 Dec 2019 17:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 nVE3c9X43ZIy for ; Wed, 11 Dec 2019 17:36:53 -0800 (PST)
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 4FD321200F7 for ; Wed, 11 Dec 2019 17:36:53 -0800 (PST)
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=PtBaBe75U+nOJD2ZtyA7MnPVqFWdK9mepWv+amcgI0o=; b=E/0lR8fvXiHGSgAEQMsSsWeOz YkWXEPSVXPZyAyX2hrJDrCzdwpkCRP8SpgMB3hudKdQUOUVLwT+YsNtnfcgVCzw9ydPgjPUxgVSGo waON5ewJToaVsTv1bKMDAUC5P36L9iT5I7qNZ+iX3bvituo6K1LNF2nRI/cbjUXZx8LCo7eHY3xbH TvDsGmKoohibp8i1S2+yyl9sVv8hUbbPU1GqNdiDaU6odx/e7/gYz24HNOelmDkRH4IMryGF9ZqZ0 d7Q0mg4Is6l4Ffmid+trtMaSVomeVsJPdmeJLOYAe0TRGs5plj98SYsU7TbcJWO/tlgMMhomu6CZc AWVx/eEAQ==;
Received: from [31.185.128.31] (port=47390 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ifDPO-0004jI-PR; Thu, 12 Dec 2019 01:36:51 +0000
To: Jonathan Morton , Matt Mathis 
Cc: Richard Scheffenegger , tcpm IETF list , Mirja Kuehlewind , "Black, David" 
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net>  <1DF1AF6B-EEF9-4CE8-AEBC-553C0F9E0E90@gmail.com>  <019D15B2-18A4-499C-BD0E-EF76B851E0E2@gmail.com>
From: Bob Briscoe 
Message-ID: <5720bd1b-06fd-b30d-4e55-5987add7b9d2@bobbriscoe.net>
Date: Thu, 12 Dec 2019 01:36:49 +0000
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: <019D15B2-18A4-499C-BD0E-EF76B851E0E2@gmail.com>
Content-Type: multipart/alternative; boundary="------------4EBB27C9DBBD67CF126820F6"
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: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 01:36:56 -0000

This is a multi-part message in MIME format.
--------------4EBB27C9DBBD67CF126820F6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Jonathan,

On 11/12/2019 19:58, Jonathan Morton wrote:
> The existing text in AccECN mandates falling back both halves of the connection to RFC-3168 mode if either end supports it but not AccECN, and the other end supports AccECN.  I supported moving AccECN forward (as EXP) with that language in place.  I would feel obliged to withdraw that support if the text were changed to make RFC-3168 support any less than a SHOULD at the server end and a MUST at the client end - noting that the definition of SHOULD is that a pretty solid justification has to be made for not following the point.
I think you are labouring under the common misconception that the IETF 
uses MUST or SHOULD language to advise implementers what the IETF thinks 
they ought to do. That's not the role of the IETF. MUST or SHOULD 
language tells an implementer who already wants to comply with an RFC, 
what is necessary or desirable to do to interoperate with others who 
also want to comply with that RFC. The initial decision on whether to 
choose to comply with an RFC is up to each implementer.

Don't worry, the AccECN spec says that the client MUST be able to 
fall-back to classic ECN support.

But it's not the IETF's role to tell an AccECN server implementer that 
they SHOULD fall back to classic ECN because that's not necessary for 
interoperation. All we need to say for interop is that an AccECN server 
that receives a classic ECN SYN MUST fall back to either classic ECN or 
non-ECN.

I've suggested some wording below to hint to implementers which choice 
they are likely to want to make. And I've only shown the ECN fallback 
case in the table, which is probably as much as many implementers will 
bother reading.

However, it would be an abuse of normative text to tell implementers 
they "SHOULD" make one of these choices - that's an improper use of 
"SHOULD" for evangelism rather than interoperability. We don't need to 
tell an implementer to act in their own best interests - they can work 
out for themselves that falling back to ECN gives better performance 
than non-ECN.

    3.  The third block shows the cases where the TCP server (B) supports
        AccECN but the TCP client (A) supports some earlier variant of
        TCP feedback, indicated in its SYN.

        When an AccECN-enabled TCP server (B) receives a SYN with
        AE,CWR,ECE = 0,1,1 it MUST do one of the following:

        *  set both its half connections into the classic ECN feedback
           mode and return a SYN/ACK with AE, CWR, ECE = 0,0,1 as shown.
           Then it MUST comply with with [RFC3168].

        *  set both its half-connections into No ECN mode and return a
           SYN/ACK with AE,CWR,ECE = 0,0,0.  This latter case is unlikely
           to be desirable, but it is allowed as a possibility, e.g. for
           minimal TCP implementations.

        When an AccECN-enabled TCP server (B) receives a SYN with
        AE,CWR,ECE = 0,0,0 it MUST set both its half connections into the
        Not ECN feedback mode and return a SYN/ACK with AE,CWR,ECE =
        0,0,0 as shown.



Bob

>
>   - Jonathan Morton
>

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


--------------4EBB27C9DBBD67CF126820F6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Jonathan,

    

    
On 11/12/2019 19:58, Jonathan Morton
      wrote:

    

    

      
The existing text in AccECN mandates falling back both halves of the connection to RFC-3168 mode if either end supports it but not AccECN, and the other end supports AccECN.  I supported moving AccECN forward (as EXP) with that language in place.  I would feel obliged to withdraw that support if the text were changed to make RFC-3168 support any less than a SHOULD at the server end and a MUST at the client end - noting that the definition of SHOULD is that a pretty solid justification has to be made for not following the point.

    

    I think you are labouring under the common misconception that the
    IETF uses MUST or SHOULD language to advise implementers what the
    IETF thinks they ought to do. That's not the role of the IETF. MUST
    or SHOULD language tells an implementer who already wants to comply
    with an RFC, what is necessary or desirable to do to interoperate
    with others who also want to comply with that RFC. The initial
    decision on whether to choose to comply with an RFC is up to each
    implementer.

    

    Don't worry, the AccECN spec says that the client MUST be able to
    fall-back to classic ECN support.

    

    But it's not the IETF's role to tell an AccECN server implementer
    that they SHOULD fall back to classic ECN because that's not
    necessary for interoperation. All we need to say for interop is that
    an AccECN server that receives a classic ECN SYN MUST fall back to
    either classic ECN or non-ECN.

    

    I've suggested some wording below to hint to implementers which
    choice they are likely to want to make. And I've only shown the ECN
    fallback case in the table, which is probably as much as many
    implementers will bother reading.

    

    However, it would be an abuse of normative text to tell implementers
    they "SHOULD" make one of these choices - that's an improper use of
    "SHOULD" for evangelism rather than interoperability. We don't need
    to tell an implementer to act in their own best interests - they can
    work out for themselves that falling back to ECN gives better
    performance than non-ECN.

    

    
   3.  The third block shows the cases where the TCP server (B) supports
       AccECN but the TCP client (A) supports some earlier variant of
       TCP feedback, indicated in its SYN.

       When an AccECN-enabled TCP server (B) receives a SYN with
       AE,CWR,ECE = 0,1,1 it MUST do one of the following:

       *  set both its half connections into the classic ECN feedback
          mode and return a SYN/ACK with AE, CWR, ECE = 0,0,1 as shown.
          Then it MUST comply with with [RFC3168].

       *  set both its half-connections into No ECN mode and return a
          SYN/ACK with AE,CWR,ECE = 0,0,0.  This latter case is unlikely
          to be desirable, but it is allowed as a possibility, e.g. for
          minimal TCP implementations.

       When an AccECN-enabled TCP server (B) receives a SYN with
       AE,CWR,ECE = 0,0,0 it MUST set both its half connections into the
       Not ECN feedback mode and return a SYN/ACK with AE,CWR,ECE =
       0,0,0 as shown.



    

    

    Bob

    

    

      

 - Jonathan Morton



    

    

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

  


--------------4EBB27C9DBBD67CF126820F6--


From nobody Thu Dec 12 01:17:00 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDCF12087E for ; Thu, 12 Dec 2019 01:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 ZxhvEBl31KMk for ; Thu, 12 Dec 2019 01:16:56 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 2458912087C for ; Thu, 12 Dec 2019 01:16:56 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.1.243]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ifKab-0006nG-K9; Thu, 12 Dec 2019 10:16:53 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net>
Date: Thu, 12 Dec 2019 10:16:52 +0100
Cc: Jonathan Morton , tcpm IETF list , Richard Scheffenegger 
Content-Transfer-Encoding: quoted-printable
Message-Id: <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net>
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576142216;cf7dead9;
X-HE-SMSGID: 1ifKab-0006nG-K9
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 09:16:58 -0000

Hi Bob,

Please see inline below.

> On 12. Dec 2019, at 01:13, Bob Briscoe  wrote:
>=20
> Mirja,
>=20
> On 11/12/2019 15:28, Mirja Kuehlewind wrote:
>> Hi Bob,
>>=20
>> Sorry I think I just got a bit lost here.
>>=20
>> So this point:
>>=20
>>>>>> [BB] It's also important that the spec defines all three bits in =
the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that =
the combinations with AE=3D1 are ruled out and therefore remain =
available for future use.
>>>>>>=20
>>>> [BB] This cannot be said by referring to RFC3168 either.
>>>>=20
>> I=E2=80=99m not sure I understand what you mean, given that the =
combination with AE=3D1 is/needs to be discussion in this draft. Are we =
again talking past each other (but actually agree)?
> In the context of these two rows in table 2:
>    =
+--------+--------+------------+-----------+------------------------+
>    | A      | B      |  SYN A->B  |  SYN/ACK  | Feedback Mode          =
|
>    |        |        |            |    B->A   |                        =
|
>    =
+--------+--------+------------+-----------+------------------------+
>    |        |        | AE CWR ECE | AE CWR ECE|                        =
|
> ...
>    | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            =
|
> ...
>    | ECN    | AccECN | 0   1   1  | 0   0   1 | classic ECN            =
|
>=20
>=20
> In the first case, I'm saying the AccECN client (A) only falls back to =
classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in =
response to a 111 SYN is reserved for future use. Whereas if in this =
case we merely said an AccECN client does what RFC3168 says, the AccECN =
client would have to switch to classic ECN if the SYN/ACK was X01, thus =
wasting a codepoint.=20


In this case the A has requested AccECN support but B only supports =
classic ECN and indicates that in the SYN/ACK. As soon as the SYN/ACK is =
received negotiation is done and A has to act as specified in RFC3168.

If B would reply with 101 in the SYN/ACK, then B is also an AccECN =
sender but wants to negotiate something that is not yet specified.=20

I don=E2=80=99t see any problem here.

>=20
> In the second case, the AccECN server only falls back to classic ECN =
mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 =
SYN is reserved for future use. Whereas, if in this case we merely said =
an AccECN server does what RFC3168 says, the server would have to switch =
to classic ECN if the SYN was X11, thus wasting another codepoint.

In the case where A requests classic ECN, B can still decide to either =
support classic ECN or not and respectively reply with 001 or 000. And =
all I=E2=80=99m saying that we should not specify this reply here =
because that=E2=80=99s already specified in RFC3168.

If A sends 111 it=E2=80=99s not a classic ECN sender and we can still =
specify it here but that=E2=80=99s not the case that is shown in the =
table.=20

Mirja



>=20
>=20
> This is a separate point from the MUST vs SHOULD language in the =
second case. I'll respond to Jonathan on that next.
>=20
>=20
> Bob
>=20
>>=20
>> Mirja
>>=20
>>=20
>>=20
>>=20
>>> On 11. Dec 2019, at 11:12, Bob Briscoe 
>>>  wrote:
>>>=20
>>> Mirja,
>>>=20
>>> On 11/12/2019 08:48, Mirja Kuehlewind wrote:
>>>=20
>>>> Hi Bob,
>>>>=20
>>>> Sorry about your laptop (but if I remember correctly, it was broken =
anyway=E2=80=A6). I think we do agree (and did from the beginning). Yes, =
I think my first statement below was overly broad and I did not meant to =
remove all normative language from that section. I was only referring to =
language that talked about RFC3168 negotiation.
>>>>=20
>>>> You propose below that an AccECN sender "MUST respond to a 3168 SYN =
with either (0,0,1) or (0,0,0)=E2=80=9D and I'm rather saying that we =
should not use normative language here but rather say something like: =
=E2=80=9CIf an AccECN sender received a 3168 SYN (without AE=3D1 =
respectively) is replies as specified in RFC3168 if it is configured to =
support classic ECN.=E2=80=9D Or something like that. That=E2=80=99s all =
:-)
>>>>=20
>>> Pls respond to my two points (that keep getting overlooked), both =
starting with "This cannot be said by referring to 3168" further down =
the email.
>>>=20
>>>=20
>>> Bob
>>>=20
>>>> Mirja
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On 11. Dec 2019, at 03:19, Bob Briscoe 
>>>>>  wrote:
>>>>>=20
>>>>> Mirja,
>>>>>=20
>>>>> On 23/1119 I sent an analysis of the changes that would need to be =
made to the AccECN draft if it became stds track (which would imply that =
it then updates RFC3168) instead of expt track. For context, please read =
and possibly respond to that before you respond to this email.
>>>>>=20
>>>>> However, my email below applies whether AccECN is stds track or =
expt track.
>>>>>=20
>>>>> I've shifted the quoting back into order below, so the context is =
more clear, and I've then responded inline...
>>>>>=20
>>>>>>> On 25. Nov 2019, at 22:41, Bob Briscoe 
>>>>>>>  wrote:
>>>>>>>=20
>>>>>>> Mirja,
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
>>>>>>>=20
>>>>>>>> Hi Jonathan,
>>>>>>>>=20
>>>>>>>> [MK] Sorry I wasn=E2=80=99t clear. I think we should not have =
these normative requirement in the draft and change the text to make it =
non-normative. This section was meant to explain which modes you end up =
in and the current use of normative language doesn=E2=80=99t seem to be =
right to me.
>>>>>>>>=20
>>>>> [BB] Please be clear exactly which requirements you are talking =
about. When I read the above, I just gave up and threw my laptop out of =
the window.
>>>>>=20
>>>>> Having bought a new laptop, I'm now wondering... perhaps you =
didn't mean all of the normative requirements under table 2 when you =
said 'we should not have these normative requirements', altho from your =
earlier email I got the distinct impression you did mean that (which is =
why I wasted a laptop).
>>>>>=20
>>>>> What did you mean? Given the considerable amount of normative =
language in this part of the draft, and that it's all been stable for =
all 16 revisions since draft-kuehlewind-01, I think we deserve to see =
the actual text you are proposing, and some sound reasoning for why the =
current normative text suddenly all has to be junked.
>>>>>=20
>>>>> more...
>>>>>=20
>>>>>=20
>>>>>>>> [MK] Likewise the table was also not meant to say whenever you =
implement AccECN, you MUST negotiate it in the handshake. And likewise =
the table does not show any classic ECN only transitions.
>>>>>>>>=20
>>>>>>> [BB] In the spec of AccECN, it's necessary and reasonable to =
state normative requirements for a node "that is AccECN-enabled". That =
doesn't mean that an AccECN implementation has to always support AccECN =
- it can always disable AccECN. But we do have to say what it is =
expected to do if it is following the AccECN protocol.
>>>>>>>=20
>>>>>>> This draft has included that normative language for the =
negotiation phase in all 16 revisions since the first individual draft =
(that you wrote!).
>>>>>>>=20
>>>>>>> The table shows only cases where one end or the other is =
AccECN-capable, and the text preceding and following the table gives =
normative requirements solely for the AccECN node(s) in those cases. It =
doesn't give any normative requirements for non-AccECN nodes.
>>>>>>>=20
>>>>>>> In block 3, the server is AccECN capable, so in the AccECN spec. =
it's perfectly reasonable to say what it ought to do in response to =
various types of SYN. In particular, if it receives a SYN with =
AE,CWR,ECE=3D0,0,0 the AccECN-enabled server MUST respond with =
AE,CWR,ECE=3D0,0,0.
>>>>>>>=20
>>>>>>> The only case that is in question, AFAIC, is whether we have to =
say what an AccECN-capable server does in response to a SYN from an =
RFC3168 client (AE,CWR,ECE=3D0,1,1). We need to somehow say an AccECN =
server can respond with a SYN-ACK that is either RFC3168 or non-ECN.
>>>>>>>=20
>>>>>>> I just proposed respectively SHOULD and MAY, but I can now see =
there is no need to make that judgement call. However, it is still =
important to say an AccECN-enabled server MUST respond with either =
(0,0,1) or (0,0,0).
>>>>>>>=20
>>>>> On 02/12/2019 11:15, Mirja Kuehlewind wrote:
>>>>>=20
>>>>>> Hi Bob,
>>>>>>=20
>>>>>> Regarding the [above] sentence:
>>>>>>=20
>>>>>> This is a normative statement that is defined in RFC3168 and we =
should not state it here again but refer to RFC3168 instead.
>>>>>>=20
>>>>> [BB] But an AccECN /server/ does not have to support RFC3168. It =
might be desirable to support 3168 as well as AccECN, but strictly it =
doesn't have to for interoperability - it can fall-back to non-ECN if it =
receives a 3168 SYN.
>>>>>=20
>>>>> That was my reason for starting this thread. If an AccECN server =
supports 3168, it replies (0,0,1). But it can just not support 3168 at =
all. Then it replies (0,0,0).
>>>>>=20
>>>>> However, it cannot do neither. Hence why I said it MUST respond to =
a 3168 SYN with either (0,0,1) or (0,0,0).
>>>>>=20
>>>>> This cannot be said by referring to 3168.
>>>>>=20
>>>>>>> [BB] It's also important that the spec defines all three bits in =
the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that =
the combinations with AE=3D1 are ruled out and therefore remain =
available for future use.
>>>>>>>=20
>>>>> [BB] This cannot be said by referring to RFC3168 either.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Bob
>>>>>=20
>>>>>>>=20
>>>>>>> Bob
>>>>>>>=20
>>>>>>>> Mirja
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton =

>>>>>>>>>  wrote:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind =

>>>>>>>>>>  wrote:
>>>>>>>>>>=20
>>>>>>>>>> I don=E2=80=99t think we can or should derive a normative =
requirement from this table. The table rather explains which mode you =
are in depending on the handshake that has happened. So it says: when =
client A is ECN capable and requests classic ECN support in the =
handshake and server B is AccECN capable and negotiated classic ECN =
support in the handshake then you are in classic ECN mode.
>>>>>>>>>>=20
>>>>>>>>> I will merely re-quote the final sentence from my quoted text, =
which transforms that table into a normative requirement:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>     Therefore, as soon as an
>>>>>>>>>>     AccECN-enabled TCP server (B) receives the SYN shown, it =
MUST set
>>>>>>>>>>     both its half connections into the feedback mode shown in =
the
>>>>>>>>>>     rightmost column.
>>>>>>>>>>=20
>>>>>>>>> - Jonathan Morton
>>>>>>>>>=20
>>>>>>> --=20
>>>>>>> ________________________________________________________________
>>>>>>> Bob Briscoe                              =20
>>>>>>> http://bobbriscoe.net/
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>> --=20
>>>>> ________________________________________________________________
>>>>> Bob Briscoe                              =20
>>>>> http://bobbriscoe.net/
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>> --=20
>>> ________________________________________________________________
>>> Bob Briscoe                              =20
>>> http://bobbriscoe.net/
>>>=20
>>>=20
>>>=20
>>>=20
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                              =20
> http://bobbriscoe.net/


From nobody Thu Dec 12 06:53:18 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF331200A1 for ; Thu, 12 Dec 2019 06:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 SNEDu4DA2J_C for ; Thu, 12 Dec 2019 06:53:12 -0800 (PST)
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 6321D120018 for ; Thu, 12 Dec 2019 06:53:11 -0800 (PST)
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:Cc: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=UFgtrovU8Xzx2S+N10fl5Hp1Ai36d469laiik04T7iw=; b=fmOqniCcOrIh7yHKXX34eAUyC NNVOA7aGccaVuQw1SOOJY2WtybkXv+ybO7RftO/mD/lzAfGGLy++x59mN8HEghwIqcOhPMBq8QCoq O+QQ/+peM/l8kaf6EvrYZ4geayMAs/R/ITL+kbeB0Zv475Sv0ZaxjLcpSrKzHS4+H3Prl3iTxrYX6 5jtf28v9rrD7PqARa5LDe72qd5YdHj9cvRqexOonhXmzggB80f9ibrp0SIZPR2p4DcoUtnteEzEni dbJolkDTsrmn1D4U/DvmyjAPuV/LSFXexVW/21t0QbSYb+TE98DpZyG1zzUxUsG8KEntgT8avFyX0 V164nicxg==;
Received: from [31.185.128.31] (port=36706 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ifPq0-0007Qm-Sc; Thu, 12 Dec 2019 14:53:09 +0000
From: Bob Briscoe 
To: Mirja Kuehlewind 
Cc: Jonathan Morton , tcpm IETF list , Richard Scheffenegger 
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net>
Message-ID: 
Date: Thu, 12 Dec 2019 14:53:07 +0000
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: <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net>
Content-Type: multipart/alternative; boundary="------------6D61EA5EA0426EDC267A48C2"
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: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 14:53:16 -0000

This is a multi-part message in MIME format.
--------------6D61EA5EA0426EDC267A48C2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Mirja,

On 12/12/2019 09:16, Mirja Kuehlewind wrote:
> Hi Bob,
>
> Please see inline below.
>
>> On 12. Dec 2019, at 01:13, Bob Briscoe  wrote:
>>
>> Mirja,
>>
>> On 11/12/2019 15:28, Mirja Kuehlewind wrote:
>>> Hi Bob,
>>>
>>> Sorry I think I just got a bit lost here.
>>>
>>> So this point:
>>>
>>>>>>> [BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.
>>>>>>>
>>>>> [BB] This cannot be said by referring to RFC3168 either.
>>>>>
>>> I’m not sure I understand what you mean, given that the combination with AE=1 is/needs to be discussion in this draft. Are we again talking past each other (but actually agree)?
>> In the context of these two rows in table 2:
>>     +--------+--------+------------+-----------+------------------------+
>>     | A      | B      |  SYN A->B  |  SYN/ACK  | Feedback Mode          |
>>     |        |        |            |    B->A   |                        |
>>     +--------+--------+------------+-----------+------------------------+
>>     |        |        | AE CWR ECE | AE CWR ECE|                        |
>> ...
>>     | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            |
>> ...
>>     | ECN    | AccECN | 0   1   1  | 0   0   1 | classic ECN            |
>>
>>
>> In the first case, I'm saying the AccECN client (A) only falls back to classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas if in this case we merely said an AccECN client does what RFC3168 says, the AccECN client would have to switch to classic ECN if the SYN/ACK was X01, thus wasting a codepoint.
> In this case the A has requested AccECN support but B only supports classic ECN and indicates that in the SYN/ACK. As soon as the SYN/ACK is received negotiation is done and A has to act as specified in RFC3168.
>
> If B would reply with 101 in the SYN/ACK, then B is also an AccECN sender but wants to negotiate something that is not yet specified.
>
> I don’t see any problem here.
You were saying we should just refer to RFC3168 in this case. I am 
saying we should not refer to RFC3168 for the wire protocol aspect. 
Rather we should specify the wire protocol part in the AccECN spec, 
because we can specify more tightly than RFC3168 that only a 001 SYN/ACK 
causes the client to fall back to classic ECN, whereas it would be an 
X01 SYN/ACK if we referred to 3168.

This was originally just a very minor disagreement about not referring 
off to another spec, but it got detached from its original context by 
the way the responses were posted.

Here's suggested text. Changes from -09 are in green:

    | AccECN | Nonce  | 1   1   1  | 1   0   1 |(Reserved)              |
    | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            |
    | AccECN | No ECN | 1   1   1  | 0   0   0 | Not ECN                |


    2.  The second block shows the cases where the TCP client (A)
        supports AccECN but the TCP server (B) supports some earlier
        variant of TCP feedback, indicated in its SYN/ACK.  Therefore, as
        soon as an AccECN-capable TCP client (A) receives the SYN/ACK
        shown it MUST set both its half connections into the feedback
        mode shown in the rightmost column.If it has set itself into classic ECN feedback mode it MUST then comply 
with [RFC3168].


Note that I've referred to RFC3168 for the behaviour after the wire 
protocol negotiation, but that's something I've been tightening up 
separately from this conversation.

Note that in the Nonce row, now that it's historic, I realized we 
should've changed "classic ECN" to "(Reserved)", so as not to burn that 
codepoint.

>> 
>> In the second case, the AccECN server only falls back to classic ECN mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas, if in this case we merely said an AccECN server does what RFC3168 says, the server would have to switch to classic ECN if the SYN was X11, thus wasting another codepoint.
>> 
Sorry, please consider my para above to be deleted. It was rubbish. I 
was just about to send a correction to my own posting when this response 
of yours came in. My response to your point below replaces it.

> In the case where A requests classic ECN, B can still decide to either support classic ECN or not and respectively reply with 001 or 000. And all I’m saying that we should not specify this reply here because that’s already specified in RFC3168.
I admit that I'd prefer not to add all that text to the AccECN spec that 
I suggested (in my response to Jonathan). However, my concern about 
referring off to RFC3168 is that there is so much about this in RFC3168, 
it is difficult to be specific about which bits of 3168 we mean and 
which bits we don't. Let's start from your suggested text:

    “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.”

I'll first just correct 'sender' to 'server' and make it more consistent 
with the current style of the AccECN text:

    "When an AccECN-enabled TCP server (B) receives a SYN with
    AE,CWR,ECE = 0,1,1 it replies as specified in RFC3168 if it is
    configured to support classic ECN."

That's nice in that it side-steps the controversy we have over whether 
to support classic ECN.
But it doesn't say what a server does if it is not configured to support 
classic ECN.
And it doesn't say that the SYN/ACK has to have AE=0 (although that is 
in the table).

This seems to be a disagreement over whether to write spec as precisely 
as pseudocode, or whether to write it on the assumption that an 
implementer will probably guess what we mean where we omit stuff that we 
think is obvious.



Bob

> If A sends 111 it’s not a classic ECN sender and we can still specify it here but that’s not the case that is shown in the table.
>
> Mirja
>
>
>
>> This is a separate point from the MUST vs SHOULD language in the second case. I'll respond to Jonathan on that next.
>>
>>
>> Bob
>>
>>> Mirja
>>>
>>>
>>>
>>>
>>>> On 11. Dec 2019, at 11:12, Bob Briscoe
>>>>   wrote:
>>>>
>>>> Mirja,
>>>>
>>>> On 11/12/2019 08:48, Mirja Kuehlewind wrote:
>>>>
>>>>> Hi Bob,
>>>>>
>>>>> Sorry about your laptop (but if I remember correctly, it was broken anyway…). I think we do agree (and did from the beginning). Yes, I think my first statement below was overly broad and I did not meant to remove all normative language from that section. I was only referring to language that talked about RFC3168 negotiation.
>>>>>
>>>>> You propose below that an AccECN sender "MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use normative language here but rather say something like: “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.” Or something like that. That’s all :-)
>>>>>
>>>> Pls respond to my two points (that keep getting overlooked), both starting with "This cannot be said by referring to 3168" further down the email.
>>>>
>>>>
>>>> Bob
>>>>
>>>>> Mirja
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 11. Dec 2019, at 03:19, Bob Briscoe
>>>>>>   wrote:
>>>>>>
>>>>>> Mirja,
>>>>>>
>>>>>> On 23/1119 I sent an analysis of the changes that would need to be made to the AccECN draft if it became stds track (which would imply that it then updates RFC3168) instead of expt track. For context, please read and possibly respond to that before you respond to this email.
>>>>>>
>>>>>> However, my email below applies whether AccECN is stds track or expt track.
>>>>>>
>>>>>> I've shifted the quoting back into order below, so the context is more clear, and I've then responded inline...
>>>>>>
>>>>>>>> On 25. Nov 2019, at 22:41, Bob Briscoe
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>> Mirja,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
>>>>>>>>
>>>>>>>>> Hi Jonathan,
>>>>>>>>>
>>>>>>>>> [MK] Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me.
>>>>>>>>>
>>>>>> [BB] Please be clear exactly which requirements you are talking about. When I read the above, I just gave up and threw my laptop out of the window.
>>>>>>
>>>>>> Having bought a new laptop, I'm now wondering... perhaps you didn't mean all of the normative requirements under table 2 when you said 'we should not have these normative requirements', altho from your earlier email I got the distinct impression you did mean that (which is why I wasted a laptop).
>>>>>>
>>>>>> What did you mean? Given the considerable amount of normative language in this part of the draft, and that it's all been stable for all 16 revisions since draft-kuehlewind-01, I think we deserve to see the actual text you are proposing, and some sound reasoning for why the current normative text suddenly all has to be junked.
>>>>>>
>>>>>> more...
>>>>>>
>>>>>>
>>>>>>>>> [MK] Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.
>>>>>>>>>
>>>>>>>> [BB] In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol.
>>>>>>>>
>>>>>>>> This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!).
>>>>>>>>
>>>>>>>> The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes.
>>>>>>>>
>>>>>>>> In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.
>>>>>>>>
>>>>>>>> The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN.
>>>>>>>>
>>>>>>>> I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).
>>>>>>>>
>>>>>> On 02/12/2019 11:15, Mirja Kuehlewind wrote:
>>>>>>
>>>>>>> Hi Bob,
>>>>>>>
>>>>>>> Regarding the [above] sentence:
>>>>>>>
>>>>>>> This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead.
>>>>>>>
>>>>>> [BB] But an AccECN /server/ does not have to support RFC3168. It might be desirable to support 3168 as well as AccECN, but strictly it doesn't have to for interoperability - it can fall-back to non-ECN if it receives a 3168 SYN.
>>>>>>
>>>>>> That was my reason for starting this thread. If an AccECN server supports 3168, it replies (0,0,1). But it can just not support 3168 at all. Then it replies (0,0,0).
>>>>>>
>>>>>> However, it cannot do neither. Hence why I said it MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0).
>>>>>>
>>>>>> This cannot be said by referring to 3168.
>>>>>>
>>>>>>>> [BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.
>>>>>>>>
>>>>>> [BB] This cannot be said by referring to RFC3168 either.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>>>> Bob
>>>>>>>>
>>>>>>>>> Mirja
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton
>>>>>>>>>>   wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind
>>>>>>>>>>>   wrote:
>>>>>>>>>>>
>>>>>>>>>>> I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode.
>>>>>>>>>>>
>>>>>>>>>> I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>      Therefore, as soon as an
>>>>>>>>>>>      AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
>>>>>>>>>>>      both its half connections into the feedback mode shown in the
>>>>>>>>>>>      rightmost column.
>>>>>>>>>>>
>>>>>>>>>> - Jonathan Morton
>>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> ________________________________________________________________
>>>>>>>> Bob Briscoe
>>>>>>>> http://bobbriscoe.net/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> -- 
>>>>>> ________________________________________________________________
>>>>>> Bob Briscoe
>>>>>> http://bobbriscoe.net/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> -- 
>>>> ________________________________________________________________
>>>> Bob Briscoe
>>>> http://bobbriscoe.net/
>>>>
>>>>
>>>>
>>>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoe
>> http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/


--------------6D61EA5EA0426EDC267A48C2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Mirja,

    

    
On 12/12/2019 09:16, Mirja Kuehlewind
      wrote:

    

    

      
Hi Bob,

Please see inline below.



      

        
On 12. Dec 2019, at 01:13, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Mirja,

On 11/12/2019 15:28, Mirja Kuehlewind wrote:


        

          
Hi Bob,

Sorry I think I just got a bit lost here.

So this point:



          

            

              

                

                  
[BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.



                

              

              
[BB] This cannot be said by referring to RFC3168 either.



            

          

          
I’m not sure I understand what you mean, given that the combination with AE=1 is/needs to be discussion in this draft. Are we again talking past each other (but actually agree)?


        

        
In the context of these two rows in table 2:
   +--------+--------+------------+-----------+------------------------+
   | A      | B      |  SYN A->B  |  SYN/ACK  | Feedback Mode          |
   |        |        |            |    B->A   |                        |
   +--------+--------+------------+-----------+------------------------+
   |        |        | AE CWR ECE | AE CWR ECE|                        |
...
   | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            |
...
   | ECN    | AccECN | 0   1   1  | 0   0   1 | classic ECN            |


In the first case, I'm saying the AccECN client (A) only falls back to classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas if in this case we merely said an AccECN client does what RFC3168 says, the AccECN client would have to switch to classic ECN if the SYN/ACK was X01, thus wasting a codepoint. 


      

      
In this case the A has requested AccECN support but B only supports classic ECN and indicates that in the SYN/ACK. As soon as the SYN/ACK is received negotiation is done and A has to act as specified in RFC3168.

If B would reply with 101 in the SYN/ACK, then B is also an AccECN sender but wants to negotiate something that is not yet specified. 

I don’t see any problem here.

    

    You were saying we should just refer to RFC3168 in this case. I am
    saying we should not refer to RFC3168 for the wire protocol aspect.
    Rather we should specify the wire protocol part in the AccECN spec,
    because we can specify more tightly than RFC3168 that only a 001
    SYN/ACK causes the client to fall back to classic ECN, whereas it
    would be an X01 SYN/ACK if we referred to 3168. 

    

    This was originally just a very minor disagreement about not
    referring off to another spec, but it got detached from its original
    context by the way the responses were posted.

    

    Here's suggested text. Changes from -09 are in green:

    

    
   | AccECN | Nonce  | 1   1   1  | 1   0   1 | (Reserved)             |
   | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            |
   | AccECN | No ECN | 1   1   1  | 0   0   0 | Not ECN                |


    

    
   2.  The second block shows the cases where the TCP client (A)
       supports AccECN but the TCP server (B) supports some earlier
       variant of TCP feedback, indicated in its SYN/ACK.  Therefore, as
       soon as an AccECN-capable TCP client (A) receives the SYN/ACK
       shown it MUST set both its half connections into the feedback
       mode shown in the rightmost column.  If it has set itself into
       classic ECN feedback mode it MUST then comply with [RFC3168].

    

    Note that I've referred to RFC3168 for the behaviour after the wire
    protocol negotiation, but that's something I've been tightening up
    separately from this conversation.

    

    Note that in the Nonce row, now that it's historic, I realized we
    should've changed "classic ECN" to "(Reserved)", so as not to burn
    that codepoint.

    

    

      

      

        
<STRIKETHROUGH>
In the second case, the AccECN server only falls back to classic ECN mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas, if in this case we merely said an AccECN server does what RFC3168 says, the server would have to switch to classic ECN if the SYN was X11, thus wasting another codepoint.
</STRIKETHROUGH>


      

    

    Sorry, please consider my para above to be deleted. It was rubbish.
    I was just about to send a correction to my own posting when this
    response of yours came in. My response to your point below replaces
    it.

    

    

      
In the case where A requests classic ECN, B can still decide to either support classic ECN or not and respectively reply with 001 or 000. And all I’m saying that we should not specify this reply here because that’s already specified in RFC3168.

    

    I admit that I'd prefer not to add all that text to the AccECN spec
    that I suggested (in my response to Jonathan). However, my concern
    about referring off to RFC3168 is that there is so much about this
    in RFC3168, it is difficult to be specific about which bits of 3168
    we mean and which bits we don't. Let's start from your suggested
    text:

    

      
“If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.”

    

    I'll first just correct 'sender' to 'server' and make it more
    consistent with the current style of the AccECN text:

    
"When an AccECN-enabled TCP server (B) receives a
        SYN with AE,CWR,ECE = 0,1,1 it replies as specified in RFC3168
        if it is configured to support classic ECN."

    

    That's nice in that it side-steps the controversy we have over
    whether to support classic ECN.

    But it doesn't say what a server does if it is not configured to
    support classic ECN.

    And it doesn't say that the SYN/ACK has to have AE=0 (although that
    is in the table).

    

    This seems to be a disagreement over whether to write spec as
    precisely as pseudocode, or whether to write it on the assumption
    that an implementer will probably guess what we mean where we omit
    stuff that we think is obvious.

    

    

    

    Bob

    

    

      
If A sends 111 it’s not a classic ECN sender and we can still specify it here but that’s not the case that is shown in the table. 

Mirja





      

        
This is a separate point from the MUST vs SHOULD language in the second case. I'll respond to Jonathan on that next.


Bob



        

          
Mirja






          

            
On 11. Dec 2019, at 11:12, Bob Briscoe <ietf@bobbriscoe.net>
 wrote:

Mirja,

On 11/12/2019 08:48, Mirja Kuehlewind wrote:



            

              
Hi Bob,

Sorry about your laptop (but if I remember correctly, it was broken anyway…). I think we do agree (and did from the beginning). Yes, I think my first statement below was overly broad and I did not meant to remove all normative language from that section. I was only referring to language that talked about RFC3168 negotiation.

You propose below that an AccECN sender "MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use normative language here but rather say something like: “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.” Or something like that. That’s all :-)



            

            
Pls respond to my two points (that keep getting overlooked), both starting with "This cannot be said by referring to 3168" further down the email.


Bob



            

              
Mirja






              

                
On 11. Dec 2019, at 03:19, Bob Briscoe <ietf@bobbriscoe.net>
 wrote:

Mirja,

On 23/1119 I sent an analysis of the changes that would need to be made to the AccECN draft if it became stds track (which would imply that it then updates RFC3168) instead of expt track. For context, please read and possibly respond to that before you respond to this email.

However, my email below applies whether AccECN is stds track or expt track.

I've shifted the quoting back into order below, so the context is more clear, and I've then responded inline...



                

                  

                    
On 25. Nov 2019, at 22:41, Bob Briscoe <ietf@bobbriscoe.net>
 wrote:

Mirja,


On 26/11/2019 01:02, Mirja Kuehlewind wrote:



                    

                      
Hi Jonathan,

[MK] Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me.



                    

                  

                

                
[BB] Please be clear exactly which requirements you are talking about. When I read the above, I just gave up and threw my laptop out of the window.

Having bought a new laptop, I'm now wondering... perhaps you didn't mean all of the normative requirements under table 2 when you said 'we should not have these normative requirements', altho from your earlier email I got the distinct impression you did mean that (which is why I wasted a laptop).

What did you mean? Given the considerable amount of normative language in this part of the draft, and that it's all been stable for all 16 revisions since draft-kuehlewind-01, I think we deserve to see the actual text you are proposing, and some sound reasoning for why the current normative text suddenly all has to be junked.

more...




                

                  

                    

                      
[MK] Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.



                    

                    
[BB] In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol.

This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!).

The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes.

In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.

The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN.

I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).



                  

                

                
On 02/12/2019 11:15, Mirja Kuehlewind wrote:



                

                  
Hi Bob,

Regarding the [above] sentence:

This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead.



                

                
[BB] But an AccECN /server/ does not have to support RFC3168. It might be desirable to support 3168 as well as AccECN, but strictly it doesn't have to for interoperability - it can fall-back to non-ECN if it receives a 3168 SYN.

That was my reason for starting this thread. If an AccECN server supports 3168, it replies (0,0,1). But it can just not support 3168 at all. Then it replies (0,0,0).

However, it cannot do neither. Hence why I said it MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0).

This cannot be said by referring to 3168.



                

                  

                    
[BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.



                  

                

                
[BB] This cannot be said by referring to RFC3168 either.



Bob



                

                  

                    
Bob



                    

                      
Mirja





                      

                        
On 25. Nov 2019, at 17:48, Jonathan Morton <chromatix99@gmail.com>
 wrote:




                        

                          
On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <ietf@kuehlewind.net>
 wrote:

I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode.



                        

                        
I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement:




                        

                          
    Therefore, as soon as an
    AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
    both its half connections into the feedback mode shown in the
    rightmost column.



                        

                        
- Jonathan Morton



                      

                    

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






                  

                

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






              

            

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






          

        

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


      

    

    

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

  


--------------6D61EA5EA0426EDC267A48C2--


From nobody Thu Dec 12 07:08:06 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B13812021D for ; Thu, 12 Dec 2019 07:08:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level: 
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 h57KvmqEb8k4 for ; Thu, 12 Dec 2019 07:08:00 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 F1FB91201CE for ; Thu, 12 Dec 2019 07:07:59 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id f82so3106304ioa.9 for ; Thu, 12 Dec 2019 07:07:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PoSF7a2uTZiCUgzd9WVl3Nj6wM04PXzYhDz1om2rlNo=; b=ozA9T4H6SOIv8AK1Moa+r+jlZGciH6hbIHoJpTeYBwnlpsOj3DIKvlpbo/k+5akCj7 LCR1hBNlzga0EqjPQsOYdIESJAK+fSmJxq+9pqD86HwDtdrYs/rjhayjzcJ5kyuR/4ZK c4gkS/BnE41Iq9XQEXpFcl9wA5vNqzFvV6TKQOBkCXVHTsGllNwhhSQoYnV1eqjtMX4U sTtTarrXNZCR/DzT8sh51t1W6YNhPAtIWZ122xe1MsCEaR651LOllB8YWnusLZjBTE1a JnI2xD2j8LF0098OHKPn0TCCxm5BaDFiXAssppD05SktjDqVdCfTUFpEbSRJeuArLD1i 4+7Q==
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=PoSF7a2uTZiCUgzd9WVl3Nj6wM04PXzYhDz1om2rlNo=; b=bmVBqPCwLBQNcNLZPoVyplj4SOTOwd6Tnlj9P81Ikl7lxzzcUe7OiNihX6c8Xy+z6p no59Y2VKCXesN9cMebFFglUbVQLyy2s8BVommq1L177K+aZVJJ2HdwyJmE6p4E8BZIaE AT03OpdeVI9DaCtqYE7uOr6Ct5RAqRu6UMyhfr52zt7udepnVofd82hUpMFhKB0kFLs0 B2+QRYCVFe81aa/NXn7yWbHUmH88zFeWdxVCUTh18sfcL8218yvwb1Agmsj/eScjMatg 5SLxS0psRqDD3RH+8oQdAdW1qbrHYmUnkq0YZoQOxsU5qhUf8NhFOaoGFxNTYAqGkjVY x9RA==
X-Gm-Message-State: APjAAAXlAxBje53G7TiVOwFWnNpwpoTHUHOtC7kl1FlqPXG5GE4a9Fca L4fq0ujg/tlStV5booGe8GgIDI7jrHts4cyBxHwOBQ==
X-Google-Smtp-Source: APXvYqxo7Hh86LljB4GdNfjKaLcb1piIM7LEc3XsnI+K+bOqxPv428sDtQOWH6uLu4wlb78BumYsjNRVATZ9kIHDr7w=
X-Received: by 2002:a6b:f60e:: with SMTP id n14mr3377414ioh.241.1576163278863;  Thu, 12 Dec 2019 07:07:58 -0800 (PST)
MIME-Version: 1.0
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net>
In-Reply-To: <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net>
From: Matt Mathis 
Date: Thu, 12 Dec 2019 09:07:47 -0600
Message-ID: 
To: Mirja Kuehlewind 
Cc: Bob Briscoe , tcpm IETF list ,  Richard Scheffenegger 
Content-Type: multipart/alternative; boundary="00000000000058a35e0599831cf4"
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 15:08:03 -0000

--00000000000058a35e0599831cf4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bob you said:
>Don't worry, the AccECN spec says that the client MUST be able to
fall-back to classic ECN support.

If the only choice is to downgrade to non-ECN, it would make the code and
documentation simpler.  It also has the property that you might be able to
reuse the 3168 codepoint in a couple of years (well, ok a decade).

Is there any reason to want to have 3168 and AccECN coexistence beyond a
transition?  Put another way, if we imagine fully supporting both 3168 and
AccECN, it there any reason to choose 3168 other than deployment inertia?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.


On Thu, Dec 12, 2019 at 3:17 AM Mirja Kuehlewind 
wrote:

> Hi Bob,
>
> Please see inline below.
>
> > On 12. Dec 2019, at 01:13, Bob Briscoe  wrote:
> >
> > Mirja,
> >
> > On 11/12/2019 15:28, Mirja Kuehlewind wrote:
> >> Hi Bob,
> >>
> >> Sorry I think I just got a bit lost here.
> >>
> >> So this point:
> >>
> >>>>>> [BB] It's also important that the spec defines all three bits in
> the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that t=
he
> combinations with AE=3D1 are ruled out and therefore remain available for
> future use.
> >>>>>>
> >>>> [BB] This cannot be said by referring to RFC3168 either.
> >>>>
> >> I=E2=80=99m not sure I understand what you mean, given that the combin=
ation
> with AE=3D1 is/needs to be discussion in this draft. Are we again talking
> past each other (but actually agree)?
> > In the context of these two rows in table 2:
> >    +--------+--------+------------+-----------+------------------------=
+
> >    | A      | B      |  SYN A->B  |  SYN/ACK  | Feedback Mode          =
|
> >    |        |        |            |    B->A   |                        =
|
> >    +--------+--------+------------+-----------+------------------------=
+
> >    |        |        | AE CWR ECE | AE CWR ECE|                        =
|
> > ...
> >    | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            =
|
> > ...
> >    | ECN    | AccECN | 0   1   1  | 0   0   1 | classic ECN            =
|
> >
> >
> > In the first case, I'm saying the AccECN client (A) only falls back to
> classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in
> response to a 111 SYN is reserved for future use. Whereas if in this case
> we merely said an AccECN client does what RFC3168 says, the AccECN client
> would have to switch to classic ECN if the SYN/ACK was X01, thus wasting =
a
> codepoint.
>
>
> In this case the A has requested AccECN support but B only supports
> classic ECN and indicates that in the SYN/ACK. As soon as the SYN/ACK is
> received negotiation is done and A has to act as specified in RFC3168.
>
> If B would reply with 101 in the SYN/ACK, then B is also an AccECN sender
> but wants to negotiate something that is not yet specified.
>
> I don=E2=80=99t see any problem here.
>
> >
> > In the second case, the AccECN server only falls back to classic ECN
> mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 S=
YN
> is reserved for future use. Whereas, if in this case we merely said an
> AccECN server does what RFC3168 says, the server would have to switch to
> classic ECN if the SYN was X11, thus wasting another codepoint.
>
> In the case where A requests classic ECN, B can still decide to either
> support classic ECN or not and respectively reply with 001 or 000. And al=
l
> I=E2=80=99m saying that we should not specify this reply here because tha=
t=E2=80=99s
> already specified in RFC3168.
>
> If A sends 111 it=E2=80=99s not a classic ECN sender and we can still spe=
cify it
> here but that=E2=80=99s not the case that is shown in the table.
>
> Mirja
>
>
>
> >
> >
> > This is a separate point from the MUST vs SHOULD language in the second
> case. I'll respond to Jonathan on that next.
> >
> >
> > Bob
> >
> >>
> >> Mirja
> >>
> >>
> >>
> >>
> >>> On 11. Dec 2019, at 11:12, Bob Briscoe 
> >>>  wrote:
> >>>
> >>> Mirja,
> >>>
> >>> On 11/12/2019 08:48, Mirja Kuehlewind wrote:
> >>>
> >>>> Hi Bob,
> >>>>
> >>>> Sorry about your laptop (but if I remember correctly, it was broken
> anyway=E2=80=A6). I think we do agree (and did from the beginning). Yes, =
I think my
> first statement below was overly broad and I did not meant to remove all
> normative language from that section. I was only referring to language th=
at
> talked about RFC3168 negotiation.
> >>>>
> >>>> You propose below that an AccECN sender "MUST respond to a 3168 SYN
> with either (0,0,1) or (0,0,0)=E2=80=9D and I'm rather saying that we sho=
uld not
> use normative language here but rather say something like: =E2=80=9CIf an=
 AccECN
> sender received a 3168 SYN (without AE=3D1 respectively) is replies as
> specified in RFC3168 if it is configured to support classic ECN.=E2=80=9D=
 Or
> something like that. That=E2=80=99s all :-)
> >>>>
> >>> Pls respond to my two points (that keep getting overlooked), both
> starting with "This cannot be said by referring to 3168" further down the
> email.
> >>>
> >>>
> >>> Bob
> >>>
> >>>> Mirja
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On 11. Dec 2019, at 03:19, Bob Briscoe 
> >>>>>  wrote:
> >>>>>
> >>>>> Mirja,
> >>>>>
> >>>>> On 23/1119 I sent an analysis of the changes that would need to be
> made to the AccECN draft if it became stds track (which would imply that =
it
> then updates RFC3168) instead of expt track. For context, please read and
> possibly respond to that before you respond to this email.
> >>>>>
> >>>>> However, my email below applies whether AccECN is stds track or exp=
t
> track.
> >>>>>
> >>>>> I've shifted the quoting back into order below, so the context is
> more clear, and I've then responded inline...
> >>>>>
> >>>>>>> On 25. Nov 2019, at 22:41, Bob Briscoe 
> >>>>>>>  wrote:
> >>>>>>>
> >>>>>>> Mirja,
> >>>>>>>
> >>>>>>>
> >>>>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
> >>>>>>>
> >>>>>>>> Hi Jonathan,
> >>>>>>>>
> >>>>>>>> [MK] Sorry I wasn=E2=80=99t clear. I think we should not have th=
ese
> normative requirement in the draft and change the text to make it
> non-normative. This section was meant to explain which modes you end up i=
n
> and the current use of normative language doesn=E2=80=99t seem to be righ=
t to me.
> >>>>>>>>
> >>>>> [BB] Please be clear exactly which requirements you are talking
> about. When I read the above, I just gave up and threw my laptop out of t=
he
> window.
> >>>>>
> >>>>> Having bought a new laptop, I'm now wondering... perhaps you didn't
> mean all of the normative requirements under table 2 when you said 'we
> should not have these normative requirements', altho from your earlier
> email I got the distinct impression you did mean that (which is why I
> wasted a laptop).
> >>>>>
> >>>>> What did you mean? Given the considerable amount of normative
> language in this part of the draft, and that it's all been stable for all
> 16 revisions since draft-kuehlewind-01, I think we deserve to see the
> actual text you are proposing, and some sound reasoning for why the curre=
nt
> normative text suddenly all has to be junked.
> >>>>>
> >>>>> more...
> >>>>>
> >>>>>
> >>>>>>>> [MK] Likewise the table was also not meant to say whenever you
> implement AccECN, you MUST negotiate it in the handshake. And likewise th=
e
> table does not show any classic ECN only transitions.
> >>>>>>>>
> >>>>>>> [BB] In the spec of AccECN, it's necessary and reasonable to stat=
e
> normative requirements for a node "that is AccECN-enabled". That doesn't
> mean that an AccECN implementation has to always support AccECN - it can
> always disable AccECN. But we do have to say what it is expected to do if
> it is following the AccECN protocol.
> >>>>>>>
> >>>>>>> This draft has included that normative language for the
> negotiation phase in all 16 revisions since the first individual draft
> (that you wrote!).
> >>>>>>>
> >>>>>>> The table shows only cases where one end or the other is
> AccECN-capable, and the text preceding and following the table gives
> normative requirements solely for the AccECN node(s) in those cases. It
> doesn't give any normative requirements for non-AccECN nodes.
> >>>>>>>
> >>>>>>> In block 3, the server is AccECN capable, so in the AccECN spec.
> it's perfectly reasonable to say what it ought to do in response to vario=
us
> types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=3D0,0,0=
 the
> AccECN-enabled server MUST respond with AE,CWR,ECE=3D0,0,0.
> >>>>>>>
> >>>>>>> The only case that is in question, AFAIC, is whether we have to
> say what an AccECN-capable server does in response to a SYN from an RFC31=
68
> client (AE,CWR,ECE=3D0,1,1). We need to somehow say an AccECN server can
> respond with a SYN-ACK that is either RFC3168 or non-ECN.
> >>>>>>>
> >>>>>>> I just proposed respectively SHOULD and MAY, but I can now see
> there is no need to make that judgement call. However, it is still
> important to say an AccECN-enabled server MUST respond with either (0,0,1=
)
> or (0,0,0).
> >>>>>>>
> >>>>> On 02/12/2019 11:15, Mirja Kuehlewind wrote:
> >>>>>
> >>>>>> Hi Bob,
> >>>>>>
> >>>>>> Regarding the [above] sentence:
> >>>>>>
> >>>>>> This is a normative statement that is defined in RFC3168 and we
> should not state it here again but refer to RFC3168 instead.
> >>>>>>
> >>>>> [BB] But an AccECN /server/ does not have to support RFC3168. It
> might be desirable to support 3168 as well as AccECN, but strictly it
> doesn't have to for interoperability - it can fall-back to non-ECN if it
> receives a 3168 SYN.
> >>>>>
> >>>>> That was my reason for starting this thread. If an AccECN server
> supports 3168, it replies (0,0,1). But it can just not support 3168 at al=
l.
> Then it replies (0,0,0).
> >>>>>
> >>>>> However, it cannot do neither. Hence why I said it MUST respond to =
a
> 3168 SYN with either (0,0,1) or (0,0,0).
> >>>>>
> >>>>> This cannot be said by referring to 3168.
> >>>>>
> >>>>>>> [BB] It's also important that the spec defines all three bits in
> the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that t=
he
> combinations with AE=3D1 are ruled out and therefore remain available for
> future use.
> >>>>>>>
> >>>>> [BB] This cannot be said by referring to RFC3168 either.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Bob
> >>>>>
> >>>>>>>
> >>>>>>> Bob
> >>>>>>>
> >>>>>>>> Mirja
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton <
> chromatix99@gmail.com>
> >>>>>>>>>  wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <
> ietf@kuehlewind.net>
> >>>>>>>>>>  wrote:
> >>>>>>>>>>
> >>>>>>>>>> I don=E2=80=99t think we can or should derive a normative requ=
irement
> from this table. The table rather explains which mode you are in dependin=
g
> on the handshake that has happened. So it says: when client A is ECN
> capable and requests classic ECN support in the handshake and server B is
> AccECN capable and negotiated classic ECN support in the handshake then y=
ou
> are in classic ECN mode.
> >>>>>>>>>>
> >>>>>>>>> I will merely re-quote the final sentence from my quoted text,
> which transforms that table into a normative requirement:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>     Therefore, as soon as an
> >>>>>>>>>>     AccECN-enabled TCP server (B) receives the SYN shown, it
> MUST set
> >>>>>>>>>>     both its half connections into the feedback mode shown in
> the
> >>>>>>>>>>     rightmost column.
> >>>>>>>>>>
> >>>>>>>>> - Jonathan Morton
> >>>>>>>>>
> >>>>>>> --
> >>>>>>> ________________________________________________________________
> >>>>>>> Bob Briscoe
> >>>>>>> http://bobbriscoe.net/
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> ________________________________________________________________
> >>>>> Bob Briscoe
> >>>>> http://bobbriscoe.net/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>> --
> >>> ________________________________________________________________
> >>> Bob Briscoe
> >>> http://bobbriscoe.net/
> >>>
> >>>
> >>>
> >>>
> >
> > --
> > ________________________________________________________________
> > Bob Briscoe
> > http://bobbriscoe.net/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

--00000000000058a35e0599831cf4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Bob you said:
>Don't worry, the AccECN spec say=
s that the client MUST be able to fall-back to classic ECN support.

If the only choice is to downgrade to non-ECN, it would m=
ake the code and documentation simpler.=C2=A0 It also has the property that=
 you might be able to reuse the 3168 codepoint in a couple of years (well, =
ok a decade).

Is there any reason to want to have =
3168 and AccECN coexistence=C2=A0beyond a transition?=C2=A0 Put another way=
, if we imagine fully supporting both 3168 and AccECN, it there any reason =
to choose 3168 other than deployment inertia?

Thank=
s,
--MM--
The best way to predict the future is to create it. =C2=
=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be carefully measure=
d:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong wou=
ld be hypocritical and risks spiraling out of control;
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mistaken for tacit app=
roval.


On Thu, Dec 12, 2=
019 at 3:17 AM Mirja Kuehlewind <=
ietf@kuehlewind.net> wrote:
Hi Bob,



Please see inline below.



> On 12. Dec 2019, at 01:13, Bob Briscoe <ietf@bobbriscoe.net> wrote:

> 

> Mirja,

> 

> On 11/12/2019 15:28, Mirja Kuehlewind wrote:

>> Hi Bob,

>> 

>> Sorry I think I just got a bit lost here.

>> 

>> So this point:

>> 

>>>>>> [BB] It's also important that the spec defines=
 all three bits in the SYN-ACK responses, not just the 2-bits defined in RF=
C3168 - so that the combinations with AE=3D1 are ruled out and therefore re=
main available for future use.

>>>>>> 

>>>> [BB] This cannot be said by referring to RFC3168 either.
>>>> 

>> I=E2=80=99m not sure I understand what you mean, given that the co=
mbination with AE=3D1 is/needs to be discussion in this draft. Are we again=
 talking past each other (but actually agree)?

> In the context of these two rows in table 2:

>=C2=A0 =C2=A0 +--------+--------+------------+-----------+-------------=
-----------+

>=C2=A0 =C2=A0 | A=C2=A0 =C2=A0 =C2=A0 | B=C2=A0 =C2=A0 =C2=A0 |=C2=A0 S=
YN A->B=C2=A0 |=C2=A0 SYN/ACK=C2=A0 | Feedback Mode=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=
 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 B->A=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 =C2=A0 +--------+--------+------------+-----------+-------------=
-----------+

>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 | AE CWR ECE | AE CWR ECE|=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 | AccECN | ECN=C2=A0 =C2=A0 | 1=C2=A0 =C2=A01=C2=A0 =C2=
=A01=C2=A0 | 0=C2=A0 =C2=A00=C2=A0 =C2=A01 | classic ECN=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |

> ...

>=C2=A0 =C2=A0 | ECN=C2=A0 =C2=A0 | AccECN | 0=C2=A0 =C2=A01=C2=A0 =C2=
=A01=C2=A0 | 0=C2=A0 =C2=A00=C2=A0 =C2=A01 | classic ECN=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |

> 

> 

> In the first case, I'm saying the AccECN client (A) only falls bac=
k to classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in =
response to a 111 SYN is reserved for future use. Whereas if in this case w=
e merely said an AccECN client does what RFC3168 says, the AccECN client wo=
uld have to switch to classic ECN if the SYN/ACK was X01, thus wasting a co=
depoint. 





In this case the A has requested AccECN support but B only supports classic=
 ECN and indicates that in the SYN/ACK. As soon as the SYN/ACK is received =
negotiation is done and A has to act as specified in RFC3168.



If B would reply with 101 in the SYN/ACK, then B is also an AccECN sender b=
ut wants to negotiate something that is not yet specified. 



I don=E2=80=99t see any problem here.



> 

> In the second case, the AccECN server only falls back to classic ECN m=
ode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 SYN =
is reserved for future use. Whereas, if in this case we merely said an AccE=
CN server does what RFC3168 says, the server would have to switch to classi=
c ECN if the SYN was X11, thus wasting another codepoint.



In the case where A requests classic ECN, B can still decide to either supp=
ort classic ECN or not and respectively reply with 001 or 000. And all I=E2=
=80=99m saying that we should not specify this reply here because that=E2=
=80=99s already specified in RFC3168.



If A sends 111 it=E2=80=99s not a classic ECN sender and we can still speci=
fy it here but that=E2=80=99s not the case that is shown in the table. 



Mirja







> 

> 

> This is a separate point from the MUST vs SHOULD language in the secon=
d case. I'll respond to Jonathan on that next.

> 

> 

> Bob

> 

>> 

>> Mirja

>> 

>> 

>> 

>> 

>>> On 11. Dec 2019, at 11:12, Bob Briscoe <ietf@bobbriscoe.net>

>>>=C2=A0 wrote:

>>> 

>>> Mirja,

>>> 

>>> On 11/12/2019 08:48, Mirja Kuehlewind wrote:

>>> 

>>>> Hi Bob,

>>>> 

>>>> Sorry about your laptop (but if I remember correctly, it w=
as broken anyway=E2=80=A6). I think we do agree (and did from the beginning=
). Yes, I think my first statement below was overly broad and I did not mea=
nt to remove all normative language from that section. I was only referring=
 to language that talked about RFC3168 negotiation.

>>>> 

>>>> You propose below that an AccECN sender "MUST respond=
 to a 3168 SYN with either (0,0,1) or (0,0,0)=E2=80=9D and I'm rather s=
aying that we should not use normative language here but rather say somethi=
ng like: =E2=80=9CIf an AccECN sender received a 3168 SYN (without AE=3D1 r=
espectively) is replies as specified in RFC3168 if it is configured to supp=
ort classic ECN.=E2=80=9D Or something like that. That=E2=80=99s all :-)
>>>> 

>>> Pls respond to my two points (that keep getting overlooked), b=
oth starting with "This cannot be said by referring to 3168" furt=
her down the email.

>>> 

>>> 

>>> Bob

>>> 

>>>> Mirja

>>>> 

>>>> 

>>>> 

>>>> 

>>>>> On 11. Dec 2019, at 03:19, Bob Briscoe <ietf@bobbriscoe.net>
>>>>>=C2=A0 wrote:

>>>>> 

>>>>> Mirja,

>>>>> 

>>>>> On 23/1119 I sent an analysis of the changes that woul=
d need to be made to the AccECN draft if it became stds track (which would =
imply that it then updates RFC3168) instead of expt track. For context, ple=
ase read and possibly respond to that before you respond to this email.

>>>>> 

>>>>> However, my email below applies whether AccECN is stds=
 track or expt track.

>>>>> 

>>>>> I've shifted the quoting back into order below, so=
 the context is more clear, and I've then responded inline...

>>>>> 

>>>>>>> On 25. Nov 2019, at 22:41, Bob Briscoe <ietf@bobbriscoe.net>

>>>>>>>=C2=A0 wrote:

>>>>>>> 

>>>>>>> Mirja,

>>>>>>> 

>>>>>>> 

>>>>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
>>>>>>> 

>>>>>>>> Hi Jonathan,

>>>>>>>> 

>>>>>>>> [MK] Sorry I wasn=E2=80=99t clear. I think=
 we should not have these normative requirement in the draft and change the=
 text to make it non-normative. This section was meant to explain which mod=
es you end up in and the current use of normative language doesn=E2=80=99t =
seem to be right to me.

>>>>>>>> 

>>>>> [BB] Please be clear exactly which requirements you ar=
e talking about. When I read the above, I just gave up and threw my laptop =
out of the window.

>>>>> 

>>>>> Having bought a new laptop, I'm now wondering... p=
erhaps you didn't mean all of the normative requirements under table 2 =
when you said 'we should not have these normative requirements', al=
tho from your earlier email I got the distinct impression you did mean that=
 (which is why I wasted a laptop).

>>>>> 

>>>>> What did you mean? Given the considerable amount of no=
rmative language in this part of the draft, and that it's all been stab=
le for all 16 revisions since draft-kuehlewind-01, I think we deserve to se=
e the actual text you are proposing, and some sound reasoning for why the c=
urrent normative text suddenly all has to be junked.

>>>>> 

>>>>> more...

>>>>> 

>>>>> 

>>>>>>>> [MK] Likewise the table was also not meant=
 to say whenever you implement AccECN, you MUST negotiate it in the handsha=
ke. And likewise the table does not show any classic ECN only transitions.<=
br>
>>>>>>>> 

>>>>>>> [BB] In the spec of AccECN, it's necessary=
 and reasonable to state normative requirements for a node "that is Ac=
cECN-enabled". That doesn't mean that an AccECN implementation has=
 to always support AccECN - it can always disable AccECN. But we do have to=
 say what it is expected to do if it is following the AccECN protocol.

>>>>>>> 

>>>>>>> This draft has included that normative languag=
e for the negotiation phase in all 16 revisions since the first individual =
draft (that you wrote!).

>>>>>>> 

>>>>>>> The table shows only cases where one end or th=
e other is AccECN-capable, and the text preceding and following the table g=
ives normative requirements solely for the AccECN node(s) in those cases. I=
t doesn't give any normative requirements for non-AccECN nodes.

>>>>>>> 

>>>>>>> In block 3, the server is AccECN capable, so i=
n the AccECN spec. it's perfectly reasonable to say what it ought to do=
 in response to various types of SYN. In particular, if it receives a SYN w=
ith AE,CWR,ECE=3D0,0,0 the AccECN-enabled server MUST respond with AE,CWR,E=
CE=3D0,0,0.

>>>>>>> 

>>>>>>> The only case that is in question, AFAIC, is w=
hether we have to say what an AccECN-capable server does in response to a S=
YN from an RFC3168 client (AE,CWR,ECE=3D0,1,1). We need to somehow say an A=
ccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN.<=
br>
>>>>>>> 

>>>>>>> I just proposed respectively SHOULD and MAY, b=
ut I can now see there is no need to make that judgement call. However, it =
is still important to say an AccECN-enabled server MUST respond with either=
 (0,0,1) or (0,0,0).

>>>>>>> 

>>>>> On 02/12/2019 11:15, Mirja Kuehlewind wrote:

>>>>> 

>>>>>> Hi Bob,

>>>>>> 

>>>>>> Regarding the [above] sentence:

>>>>>> 

>>>>>> This is a normative statement that is defined in R=
FC3168 and we should not state it here again but refer to RFC3168 instead.<=
br>
>>>>>> 

>>>>> [BB] But an AccECN /server/ does not have to support R=
FC3168. It might be desirable to support 3168 as well as AccECN, but strict=
ly it doesn't have to for interoperability - it can fall-back to non-EC=
N if it receives a 3168 SYN.

>>>>> 

>>>>> That was my reason for starting this thread. If an Acc=
ECN server supports 3168, it replies (0,0,1). But it can just not support 3=
168 at all. Then it replies (0,0,0).

>>>>> 

>>>>> However, it cannot do neither. Hence why I said it MUS=
T respond to a 3168 SYN with either (0,0,1) or (0,0,0).

>>>>> 

>>>>> This cannot be said by referring to 3168.

>>>>> 

>>>>>>> [BB] It's also important that the spec def=
ines all three bits in the SYN-ACK responses, not just the 2-bits defined i=
n RFC3168 - so that the combinations with AE=3D1 are ruled out and therefor=
e remain available for future use.

>>>>>>> 

>>>>> [BB] This cannot be said by referring to RFC3168 eithe=
r.

>>>>> 

>>>>> 

>>>>> 

>>>>> Bob

>>>>> 

>>>>>>> 

>>>>>>> Bob

>>>>>>> 

>>>>>>>> Mirja

>>>>>>>> 

>>>>>>>> 

>>>>>>>> 

>>>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Mo=
rton <chromat=
ix99@gmail.com>

>>>>>>>>>=C2=A0 wrote:

>>>>>>>>> 

>>>>>>>>> 

>>>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja=
 Kuehlewind <ie=
tf@kuehlewind.net>

>>>>>>>>>>=C2=A0 wrote:

>>>>>>>>>> 

>>>>>>>>>> I don=E2=80=99t think we can or sh=
ould derive a normative requirement from this table. The table rather expla=
ins which mode you are in depending on the handshake that has happened. So =
it says: when client A is ECN capable and requests classic ECN support in t=
he handshake and server B is AccECN capable and negotiated classic ECN supp=
ort in the handshake then you are in classic ECN mode.

>>>>>>>>>> 

>>>>>>>>> I will merely re-quote the final sente=
nce from my quoted text, which transforms that table into a normative requi=
rement:

>>>>>>>>> 

>>>>>>>>> 

>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0Therefore, as s=
oon as an

>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0AccECN-enabled =
TCP server (B) receives the SYN shown, it MUST set

>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0both its half c=
onnections into the feedback mode shown in the

>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0rightmost colum=
n.

>>>>>>>>>> 

>>>>>>>>> - Jonathan Morton

>>>>>>>>> 

>>>>>>> -- 

>>>>>>> ______________________________________________=
__________________

>>>>>>> Bob Briscoe=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 =C2=
=A0

>>>>>>> http://bobbriscoe.net/

>>>>>>> 

>>>>>>> 

>>>>>>> 

>>>>>>> 

>>>>> -- 

>>>>> ______________________________________________________=
__________

>>>>> Bob Briscoe=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 =C2=A0

>>>>> http://bobbriscoe.net/

>>>>> 

>>>>> 

>>>>> 

>>>>> 

>>> -- 

>>> ______________________________________________________________=
__

>>> Bob Briscoe=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 =C2=A0

>>> http://bobbriscoe.net/

>>> 

>>> 

>>> 

>>> 

> 

> -- 

> ________________________________________________________________

> Bob Briscoe=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 =C2=A0

> http://bobbriscoe.net/



_______________________________________________

tcpm mailing list

tcpm@ietf.org

https://www.ietf.org/mailman/listinfo/tcpm




--00000000000058a35e0599831cf4--


From nobody Thu Dec 12 07:09:06 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F5812083C for ; Thu, 12 Dec 2019 07:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level: 
X-Spam-Status: No, score=-1.22 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 w-_qCKjhKx4a for ; Thu, 12 Dec 2019 07:09:03 -0800 (PST)
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 D5F501201CE for ; Thu, 12 Dec 2019 07:09:03 -0800 (PST)
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=XwBaOMPALYo1eTlHBqf0RTvWNc4icD3LtJ4s36I2bJ8=; b=B3CkP8llZXlmaX9BjdbJtTWAS prqFvreENRczWHRTpbNbuduGBpDClzks8fzdYrsP1EQGMobHUPCHbsrAfBtxk8X/qj4rIXxUCtk3E 3UvQMaWWEuf0asg5EjPRJcaHmu4urq6tob6McptsY410xc98RgTHwGYnUGzG1VuVjcv9MHeT/tt03 ynazOEPPaDBpjrXC4+GN1++lmgGGslGh4SakqyBj0hIJUUIfxF6gIg04Um+6T4Hh1uwJf691EWgWg +1TFNcV7ak97m8E2ByoG2leGeLaa0OoQTUwjYqBDkvM09Xcspa2h0NZJi95xHfhRle8Mo4nvk8qvI 7QPQca9dA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56767 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ifQ5K-002cNB-Rt; Thu, 12 Dec 2019 10:09:03 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch 
In-Reply-To: 
Date: Thu, 12 Dec 2019 07:08:58 -0800
Cc: Wes Eddy , "tcpm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <35D83F55-0588-4EF7-AD7E-1E52742D93AC@strayalpha.com>
References: <201911280244.xAS2iX3T010083@gndrsh.dnsmgr.net> <991312DB-9503-4253-8C87-3CBCA6AB99F1@strayalpha.com> <77bade9d-f090-9ec7-cc7a-29e4118321ad@mti-systems.com> 
To: Bob Briscoe 
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: [tcpm] RFC793bis draft 14 Reserved Bits
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 15:09:04 -0000

> On Dec 11, 2019, at 10:12 AM, Bob Briscoe  wrote:
>=20
> Wes,
>=20
> On 04/12/2019 14:59, Wesley Eddy wrote:
>>> Perhaps further explicitly:=20
>>>=20
>>> they MUST be ignored by the network and MUST traverse the network =
unchanged=20
>>=20
>>=20
>> This clarification seems good to me, and it looks like everyone who's =
chimed in so far agrees, so I can put it into the upcoming revision.=20
>=20
> I think it's important to make this a requirement for middleboxes as =
well as just 'the network'. Where I would define middlebox as a function =
acting on L4 (TCP) fields without being a full implementation of TCP.

RFC1812. ;-)

> I know some middlebox developers will ignore it. But their customers =
(operators) cannot require middleboxes to comply with IETF spec's if we =
don't write what middleboxes should do in our specs.

That hasn=E2=80=99t helped in the past. Laws for the lawless aren=E2=80=99=
t productive.

Joe


From nobody Thu Dec 12 08:15:07 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CB51209A7; Thu, 12 Dec 2019 08:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 6YA1FmZ6pTHT; Thu, 12 Dec 2019 08:15:02 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 8258812099E; Thu, 12 Dec 2019 08:14:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576167255; bh=Jl+5hJiZBBKHstUt0LK+2aG1B83iH5GXY7tdGFv8Xfk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=bwawRMH0sAtdJU5R/6sRvBIHZPbQd3DyLMHMXCnuxHbGlzLu/SJzk+jhYSA49yjUU QNcGf/wiKVK2Gs9luSSGPJCRibS2Q2hXLffHlq742fiD8esTaIqdGoNMCRV84iQFxd sr10+wAQaRc1rvLhMhO3RoRdokcr4uamn3DAzUd4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.249.70.154] ([217.70.211.15]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N5GE1-1hhFDP3HiH-011EjN; Thu, 12 Dec 2019 17:14:14 +0100
To: Bob Briscoe 
Cc: tcpm IETF list , "tcpm-chairs@ietf.org" 
References: <83880058-a057-66bf-24a3-855480b29f00@bobbriscoe.net> <49c9dfa7-019b-4d16-73f6-8a15c1077c73@bobbriscoe.net>
From: "Scheffenegger, Richard" 
Message-ID: 
Date: Thu, 12 Dec 2019 17:14:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <49c9dfa7-019b-4d16-73f6-8a15c1077c73@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ZmVBwAsR0IQaFot0JTNvy/NzAnIvKHXn207udFQZg5ESgByA52B CNaBLY0yUFSfi0tvPVo21bUouzswQS08cSG3JCb/CUKhjUioqt1aJ/8jBIfJAnqCDwx9kiw XZHQiC14AUAOqSQrA91YiCfU9s1kr221P/EMTRmAwkaT7TnO1M1ocOG6O4y9uQY/O4Z0B6/ fcdz/O48GOcXRvzymIhYA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:T0h2BRtXgcc=:IDPaz+O0eD6mVbgFo8nMOI v3cRcbxqfKWBti62U383gyGoMKkmPxDuZkDDp6pJJxSV3BL7waSV61zWl+1TuWC30ehr8kdDg BKGqfTniEmbEcy0CGdYc4quyeWYUavjIbuBJo3Ukv/82m3mACjdDmEH1EYBjOY1SbIV7F32PU epzDw4VTzw4QZ324Pyd7GlPUavbc+T0jZ0ZRykPhZ8ecl99BS4648fAeV0k4xemlUOo0ZCrqN X5ln67aHRoyrnNkadwS0LYGs57c7UvwEGGAtNOWMbPOeiXnUFYypCXIiuDGDRgVjEm9BDU36v AAKv2GVnHolAKKTYPrkdzbvGZkl5XrvW4XCeV5bHtNO58fpKJcPlH1vav8ylNJXLzcyFFAd4o vLuXVMWh0ATcgUnAPTLgYNJcG0AoKp7LGfHIARR/7vi2M05XPeTLrqllvi9CxvAGS8xCrygQN SRiqpygTzZjBJ30gUwT3z/ygT+02aVTWM4KDQTTg6zvoqAaIJOQKwnRsgBidDVawqFc59fJl1 kJmO6pwkCO8faX3zYAX/pBQiAJp3eWkUqjGE5nDOpsUmUzCHJDT60CFA5YSp05ij3NMH44RN+ tv1MemnVttMJsssY6lsbLP9eYZYlL+vXvJLxs/y045/Sn5c1Su8UguS52xS0+iA2hRyACcVD9 HvFRm66a1w5DkvjrzvOFXtPs0io4OSnkijDukBRhkl9k6LienFC9hkuKYAU/Pgb/OK0mslUiI cEf/D7qxhQ0eTaaIgjaGDTpfWUeY7Md+jc8Jsvp8Nz5WiJj+CSQgQAWeLxZRFGXzNFAAOk6z+ OTqq599xH/8iFEpXWCx4qAjCmOWeGUQLVdEsFEBGbtIbMk+eK7zD7cNdYYgxR4VpqD8sY+BHb FYnbOPFXre4sfyH7IhjJNye/U6FTWn4qiei6EQGxpkNGRUTvcrgglleLN624UCrvY5wMj3T0u G35sMXjYw/9UjdhtZLSgp8SJYaXiecnBLLLBody4h+cL/wlqbGxreqnsYgjyXH8TRN4YFKpSi VdJVG8XLg123WBQSx8ql33St+LnOtKOKtWh7mBY+JuXrHu1/iNeliLkw5V8z2+JohUV8nJUtx Ddd6x30okJS/4XIspMWoP6MmF5vhLaeZ7yiydEgDlR1OUiYRyb+dwHKkKwukq5KyxX1BvPsOH LHQvYyQ0PIS0A4eDQN+gMfj6R2XdWEOmydrgWdV6qlM7KhXa4T/MUtEGqlCPVJa7T8Zmw0e53 oA1fiQqjdlPrXdnf4PFbdxbYG/sWPIvFQv9ak9A==
Archived-At: 
Subject: Re: [tcpm] Impact on AccECN draft of change from EXP to PS
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 16:15:05 -0000

As one of the authors, and also exposed to how the decision process in
corporations is driven by non-technical considerations, I do prefer
making AccECN standards track (PS).

Further, this would alleviate some of the procedural questions of
assigning a TCP header bit for the AccECN feedback, without violating
our (tcpm/ietf) own rules.

This is just to reiterate my preference - if the group consensus is to
have AccECN as Experimental (and a supporting standards-track document
allowing the assingment of the AE bit), I can live with that too - while
it will make deployment harder in certain environments.

Best regards,
   Richard


Am 11.12.2019 um 19:43 schrieb Bob Briscoe:
> tcpm chairs,
>
> At IETF-106 there was believed to be rough consensus in the room that
> AccECN ought to be stds track not expt track.
>
> I pointed out that we would need to check for that consensus on the
> list. We can't really move forward with the draft until that has been
> done. So would it be possible to do a consensus call on the list on that
> question ASAP?
>
> To provide some concrete data for the question, below I've quoted the
> analysis I did of what would have to be altered in the AccECN draft if
> it switched to the stds track. I've also just added one addendum to it.
>
> Thanks in advance
>
>
>
> Bob
>
> PS. (Also a consensus call on the list about the question of the process
> for assigning header flags pls.)
>
>
>
> On 23/11/2019 11:26, Bob Briscoe wrote:
>> tcpm-ers,
>>
>> Here's analysis of the things in draft-ietf-tcpm-accurate-ecn that
>> would have to be altered to upgrade it to PS from EXP. This was
>> generally favoured in the tcpm meeting today, but it has to be
>> ratified on this list, so I thought this info would be helpful.
>>
>> =3D=3DHeader Block=3D=3D
>> Intended Status: Proposed Standard
>> Updates: 3168
>>
>> =3D=3DThroughout=3D=3D
>> (substituting intelligently):
>> s/experimental/standards track/
>> s/other experiments/experiments/
>> s/other variants/variants/
>>
>> =3D=3D1. Intro=3D=3D
>> CURRENT:
>> =C2=A0"Until the AccECN experiment succeeds, [RFC3168] will remain as t=
he
>> =C2=A0=C2=A0 only standards track specification for adding ECN to TCP. =
"
>> PROPOSED:
>> =C2=A0 Instead, summarize here how this doc updates RFC3168, referring =
to a
>> new section XXX (below) that gives detailed updates.
>>
>> CURRENT:
>> =C2=A0"It is completely independent of how TCP might respond to congest=
ion
>> =C2=A0 feedback, which is out of scope. For that we refer to [RFC3168].=
.."
>> PROPOSED
>> =C2=A0"It is completely independent of how TCP might respond to congest=
ion
>> =C2=A0 feedback, which is out of scope. For that we refer to [RFC3168] =
and
>> [RFC8311], excepting the updates to RFC 3168 in Section XXX of the
>> present document that generalize the wording to include AccECN."
>>
>> =3D=3D1.1 Document Roadmap=3D=3D
>> Remove ref to 1.3 & include a ref to the new section XXX detailing the
>> updates to 3168.
>>
>> =3D=3D1.3 Experiment Goals=3D=3D
>> Delete section
>>
>> FYI, the two experiment goals are:
>> 1. fall-back strategies in the face of path traversal problems
>> 2. interaction of change-triggered ACKs and offloaded processing
>>
>> The two "MUST" requirements behind #2 have just been relaxed to
>> "SHOULD"s as part of the splitting up of change-triggered ACKs between
>> ACE and the AccECN TCP Option, as I mentioned in the presentation to
>> the WG.
>>
>> #1 is more likely to affect implementation than design, given the
>> design provides for fall-back in most conceivable circumstances (e.g.
>> it is designed for any or all AccECN TCP options to be sent but not
>> received {Note 1}) and there's considerable checking of mangling
>> already. Nonetheless, we might find byzantine middlebox behaviour,
>> e.g. stripping the TCP option from some packets but not others,
>> altering selected protocol fields, altering some header bits but not
>> others,... I'd like to see some large-scale testing over production
>> networks before the RFC is published.
>>
>> {Note 1}: Altho the latest change has made it necessary to receive the
>> first AccECN Option in each direction to be able to correctly
>> understand later options.
>>
>> =3D=3DXXX. Updates to RFC3168=3D=3D
>> New section XXX between sections 3 & 4.
>> For content, see later in this email.
>>
>> =3D=3D3.2.6 The AccECN Option=3D=3D
>> The Kind of the option can be assigned a permanent value, rather than
>> a 2B longer option with Kind=3D254 and a magic number.
>>
>> =3D=3D6. IANA Considerations=3D=3D
>> Delete the para about using experimental option 254.
>>
>>
>>
>> =3D=3D=3DSection XXX. Updates to RFC3168=3D=3D=3D
>>
>> The following sections of RFC3168 would be updated by the AccECN
>> specification, if it were stds track:
>>
>>   * The Introduction to Section "6. Support from the Transport
>>     Protocol" that summarizes the way TCP feeds back ECN markings
>>   * the whole of "6.1.1=C2=A0 TCP Initialization"
>>   * The whole of "6.1.2. The TCP Sender" except the second, third and
>>     last paras still apply to RFC5681 congestion control, but not
>>     necessarily to other experimental forms of ECN congestion control
>>     allowed by RFC8311 (specified by a suitable experimental RFC).
>>   * The whole of "6.1.3.=C2=A0 The TCP Receiver" except the last two
>>     sentences till stand (which are incidentally in the wrong section,
>>     because they relate to TCP sender behaviour):
>>     =C2=A0=C2=A0=C2=A0 "Some care
>>     =C2=A0=C2=A0 is required if the TCP sender is to avoid unnecessary =
reductions of
>>     =C2=A0=C2=A0 the congestion window when a window of data includes b=
oth dropped
>>     =C2=A0=C2=A0 packets and (marked) CE packets.=C2=A0 This is illustr=
ated in
>>     [Floyd98]. "
>>   * The following text within "6.1.5. Retransmitted TCP packets" is
>>     updated as follows:
>>       o CURRENT:
>>         "the TCP data receiver SHOULD
>>         ignore the ECN field on arriving data packets that are outside
>>         of the
>>         receiver's current window."
>>       o UPDATED:
>>         "The TCP data receiver MUST ignore the CE codepoint on incoming
>>         segments that fail any validity check.=C2=A0 The validity check=
 in
>>         section
>>         5.2 of [RFC5961] is RECOMMENDED."
>>   * Section "5.2 Dropped or Corrupted Packets" of RFC3168 says '"pure"
>>     ACK packets MUST NOT indicate ECN-Capability.' The AccECN draft
>>     will not update this aspect, but it will say what TCP should do if
>>     it receives an ECN-capable pure ACK.
>>
>> I'm slightly unsure about this one - any opinions?:
>>
>>   * Section "23.2 TCP header Flags" within the "IANA Considerations"
>>     Section:
>>     If AccECN is going to update 3168, we will need to consider
>>     whether to update the names ECE and CWR. Even though they don't do
>>     anything related to those names in AccECN, AccECN has to be able
>>     to fall-back to 3168, so I suggest we keep these names.
>>
>>
>> =3D=3DOpportunities to close loop-holes=3D=3D
>>
>> I would also like people to check through RFC3168 to look for
>> opportunities to make behaviour for currently unused values in
>> protocol fields unambiguous - in order to allow for forward
>> compatibility (or remove unnecessary restrictions on forward
>> compatibility) for other future protocols derived from RFC3168.
>>
>> As well as the changes that AccECN already makes to the TCP part of
>> 3168, making AccECN stds track would give an opportunity to update
>> some TCP feedback-related aspects of 3168 that might have been
>> overlooked when 8311 was written. I can't think of any, but I'll check
>> and it would be good if others did too.
>>
>>
>>
>>
>> Bob
>>
>> --
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/
>
> --
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>


From nobody Thu Dec 12 08:28:27 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1949F120975 for ; Thu, 12 Dec 2019 08:28:26 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 YNqyNf-bx5Wd for ; Thu, 12 Dec 2019 08:28:24 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.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 3C7DD12095F for ; Thu, 12 Dec 2019 08:28:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576168100; bh=ydr7WLcrxyvsiwsvlqZ9tGUrMeAW41yOhe4tdGJEnxY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ZeVSx3iwqm1xAIWqsojKHWsyWFoI1/LaQNA/obvSDQjewiLl8J+Lbzu+cpqdaSTlQ Lh49Mi9aZmYeVCW2xW2Bq5K2Or6kbpTRy9QJokEhv+ruapLB8Hd7BH37rz/yv0+U63 4VKIbDWfwok+hZJ9wZegh9GYgoVcAx1nLWZKC2GY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.249.70.154] ([217.70.211.15]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M6Udt-1idWaT0Yy9-006sgk for ; Thu, 12 Dec 2019 17:28:20 +0100
To: tcpm@ietf.org
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net> 
From: "Scheffenegger, Richard" 
Message-ID: <1199c56d-720c-46a6-4b47-4393a9c1469a@gmx.at>
Date: Thu, 12 Dec 2019 17:28:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:vD8RiRw97S6/eLELFJmvXhqloam1KiufTgqq8Jx9ubehFb6ga2f sgyVJuXyhdPLRcWcQ7BiQ0gIoGkZf5y0zVORcdtW6xqFbQPV02o86LsWp4mWSHGBAgjSkgi E1RxVHNOTMU2AiE827EBwx0Ku+o67+LivaBgtFqKaZ1MzCdwCtGir/a4QgckqwI4DQQiAon 6UiM4M572J02g7H9fuXig==
X-UI-Out-Filterresults: notjunk:1;V03:K0:kokydRhaUGI=:HiKSZc0FristvTuQnUtI6I h4PPe9dLvpvUr4V9b1+T6O+LzPlk2rxlrB9MqULe6/l0ZhJTpdhX9lL5m563tCYttROJHuUox HwqTOOmiIsQDrC7hwPhENRMs36BKultmxAFTaEZsiAZUnd7fjnNdL5CTdSZPeSI+TJbACYTR8 g3lxcm/mQd2XZf7DLWfvt3CwbamCywmfbLY6BMDYrZwmhXU7MFiJYEzjt7jeQuqTA+quel2WN CYiRIBTtemSEHWHvpK3rn3Nk1BdvK0kmCcTWGgkG4N3gUrLFjNuFWEKobrlMNrLQbLq42JLci KtiSkAVbwSQu3HxCxvZL3fvmTJAeV2ypIltne/8zGPKeAlVh1+b6fGa0qKi2s3wR7eN9FaiYz WnP+K8VbdPMO61WgLQT8xY4+0kCAeboRji1Ys1KV0BXrGzMZmwswFxEPKSyx/xUc1Py+/w1m6 FXx2ZJaK2NBiLXG07tzRwnWF7TIlTAZNKO/MQdAE3LItOuhkDV55nbuWuUpawdaNmtywtYsYq +V+vFV7o0IBuSJaexERcCZUCG7L3FDb39/I//Kw6vcYo2DNM2hOijNZMbLXydzgtlrwG+ASM6 TrN7EH5nrNjJnUSQOQy2cWjXJe1+DPttK6O4e58fQ8Kze2kypaJzGHI41jvl40WbE3L5aLPJ3 k3yPeWUxQ6IaeiHn3QxwHsLnUCDBFiBN8Ij9E82W1PHSa0VRb/cLhyo7a3trHQvPR3riku2ZG IzpJn1YzCUoIQ8Vf7Bx/OyyXF9fYco0Pi+n4sbas+4JuKezty2fzYW9BeUAdmt2oCpPOy4pga suDeZtagK31Wba0OmzL0ykhDJBdC0i51x8tcj86KjQ0H2BC7VNpOZxTte4Lhxi/9EtwvjUmJH SGjOYvpzAQv4JHPR5cnSkO/0OQNNN4uwsI6SWDvvy+g6UIL18MrpNAh5AdnRgJurf9D3ugCCn xkOKP0okoldo8kkQO4cPU1GLth7w4qwzAqlN2pI9GiE+u80GvAhIHprVUbSFTybw0Z9HkoRwr eeLffiO7TsMRXBoM+rLSIYA9AThEhGP/2ytlNZp5y3J4+cK8KITtafJhtTrG1dq+1+y+YENX4 jMbliQ1QCfJNJRV97II/2BchnUQmfgyJV7ZhBjalOFW96w2kZR4CPsQchp0bpkIqOVbf+n79S NLss88V9ktyTj7DFloL55zrpgjzoVfC2swRphYf0N7p/gO+QgN9hNJXXXRtPWo5cDDKHSm62t pvvAfqdUKjakvg0at4yBRG8wI29+3DwejAYp2OQ==
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 16:28:26 -0000

Am 12.12.2019 um 15:53 schrieb Bob Briscoe:
> You were saying we should just refer to RFC3168 in this case. I am
> saying we should not refer to RFC3168 for the wire protocol aspect.
> Rather we should specify the wire protocol part in the AccECN spec,
> because we can specify more tightly than RFC3168 that only a 001 SYN/ACK
> causes the client to fall back to classic ECN, whereas it would be an
> X01 SYN/ACK if we referred to 3168.
>
> This was originally just a very minor disagreement about not referring
> off to another spec, but it got detached from its original context by
> the way the responses were posted.
>
> Here's suggested text. Changes from -09 are in green:
>
>     | AccECN | Nonce  | 1   1   1  | 1   0   1 |(Reserved)              =
|
>     | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            =
|
>     | AccECN | No ECN | 1   1   1  | 0   0   0 | Not ECN                =
|
>
>
>     2.  The second block shows the cases where the TCP client (A)
>         supports AccECN but the TCP server (B) supports some earlier
>         variant of TCP feedback, indicated in its SYN/ACK.  Therefore, a=
s
>         soon as an AccECN-capable TCP client (A) receives the SYN/ACK
>         shown it MUST set both its half connections into the feedback
>         mode shown in the rightmost column.If it has set itself into cla=
ssic ECN feedback mode it MUST then comply
> with [RFC3168].
>
>
> Note that I've referred to RFC3168 for the behaviour after the wire
> protocol negotiation, but that's something I've been tightening up
> separately from this conversation.
>
> Note that in the Nonce row, now that it's historic, I realized we
> should've changed "classic ECN" to "(Reserved)", so as not to burn that
> codepoint.


A further comments here: Since Nonce is historic, should it even be
mentioned as a possible server behavior at all, in this table?

While the initial nonce sum was set to 1, and supposed to be included in
the SYN,ACK, a mangling of IP ECN bits could conceivable have masked
this (and a L4S sender, setting ECT1 on the SYN, would elicit the same
SYN,ACK response from both a RFC3168 server, as well as a RFC3540 Nonce
server...)

To be clear - I'd swap out the "Nonce" server to "Resrvd" or "Future"
(or SCE :) )...

Richard



From nobody Thu Dec 12 08:33:56 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9FD120939 for ; Thu, 12 Dec 2019 08:33:54 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 WSIZQldrOnnt for ; Thu, 12 Dec 2019 08:33:53 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D61A412091E for ; Thu, 12 Dec 2019 08:33:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576168428; bh=C7aFbNuFWBobpVGaZZIZETPEupkTGlla5ZAxunpVqyI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=JD+rcM8vZ8mMIxLCSerUged/LFYkT9BbPOFdopJlXpAIGX80qMzAgcW9pFV1cq+L2 Jg8LFOEZUFf+V2Y7+gXWJDTN+1KNu/+2m/cGrQWEeFe3NvjMKBoiylR+EFSPZSzXBJ PLu/6/1CPrrPLhpMzVzjE49HIBGOjSfqmu6EU3WU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.249.70.154] ([217.70.211.15]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MEm27-1iU8bH0nUp-00GM4P for ; Thu, 12 Dec 2019 17:33:48 +0100
To: tcpm@ietf.org
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net> 
From: "Scheffenegger, Richard" 
Message-ID: <5021f4c4-082e-4dd1-e94f-fd72f9699cf6@gmx.at>
Date: Thu, 12 Dec 2019 17:33:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:/F5AzopLpsgg6rxJwPm5/fYxDvjP1YVzEspRbjSmj+JRFadfsJx xKxt5qJZ4UuAZUSsTbA4auOtO2+GeaHFcUu1SlWRmEDIweHymLFexorkYMJl64SM6gml2Hb gDot537hwiEjM3zcpHoo71QZn61RWJYglNVYswQgQkPfskDprm0+pRxD2GGI6p2YR5zOSIL d9zTYjE23GxWcrBW20bEg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Xw5ATo7vW2o=:sS5fnJVjjjxmXmBWFdhXDw pEjO55YINTNVFigRK126SoL+JcXA7I/HFbfvOW7J6cNIuY+shKqXrjHDW0RjF2HKL7l9s6MyE iD2rjbnhIPl1mOYqrcqk3h663jtYcobfV2Tcqr2Qcsl14XWFCXC0/EknhOvbviv1Xctf9hng+ RhTZ3J5QJYrz4PCXGIi1sph62QRwv8cbOFsj03MMYXEtURVOmSJWKL1hvLlCLBX3ZYG5iVde/ u/OdLgl54cCWu4SqRQJO98ClvxYitcF+dEud6RudLG/fYOcfe1n77Dbes/pJ0YM7shhRzPehe Joa195tiYPvbl+a//eK25Rj5cAp6ub0EUdMtlettPk+KEyZ5kxTIi4QbIOPjxvUmIKoq9E4Yk lwAJZONAoPSl4DN3iY3u0NO9jWQw4OgjCHx4U3yPt6kfq6KZnhtROJLztU9GayrzW43SsNrjP s8xb7cTFUAtMuMlJUscdbYicMBJw0XQ6wyGmd4zkRlQxXWqZwZqOxjeqz38XfU8NhXquTU/sw 2+kfkVqx7yS99JWVbuAJzYF0ppmSRKBO2tCi8gy7iPg/O8Xf7mVSTklH9k9JUejD0O1fIME8v NjQR8ApTjxMmcXxB6u3ObsKzU7sCqIg8GZ/1uMUecffnHVqCzavI4eX2SSmWm5ImG3zGztTvh bNG9nrGEPVnjFKbnn+fskBnZ4ZNrEQn78W/HbTLpZVvjLMKpbbG+8VXeRMF63YPz5wBAuCoNJ +l6YPIGD65kqPGTRy85++xvdLKstWMEq1tzu/64EFF6nZPbaHqPw53J2mRJVZP634hCE/kQod /bkCm0B55eHo7sP23iKpQmL3JOlgaY9/gXXeeT4XajBvmbJwTUoraE6RKbwb71pGo9az6nY8M nfF1wpqOR+gg43uVpYDd1tskXPxQ9jiyGP2rmT1T11JMjlf+gvuFzx94USjSKefBC/YEmZ95D 7EYtRznarppFhLsRnrIBPLJ6f8RPM6Hw/uN2aSqxrNlbUjDxa6f4FVBvHQq2E1nx03+/s9Yyr 9KU+cic0ThWpPhf4qCECKtMdxKUBna/ANCnNIF7X+FcdUM1YrjKCuzyI7suIeUhfwQgH44ZQL ELFPc2UtmNVBcl+2/pb6rJenxMRMpCtmxNkdkDAaG7aWF0teNuLLCmHVdhdhMfaKyArSHkVg5 nlNTsRas6Ew5op0TT9I4MnLL5t3GimSLcyLI/d7Fhu/KN5cH1DEqT8DeiJ4eK9ouvED99sRuJ Z4kBcgkrUKYE1/phYdBK+S4equefEk3xCwVs86A==
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 16:33:55 -0000

I want to note, that the deployment inertia is already there in generic
IP-level ECN support - not only the end hosts.

Interestingly, certain carrier-class gear doesn't support ECN at all,
while other data-center class gear ONLY supports the DCTCP / L4S variant
of instanteous, shallow queue marking...

I guess that is an argument (or rather hint) along the same lines, for
eventual phasing-out of RFC3168 ECN....

Richard



Am 12.12.2019 um 16:07 schrieb Matt Mathis:
> Bob you said:
>  >Don't worry, the AccECN spec says that the client MUST be able to
> fall-back to classic ECN support.
>
> If the only choice is to downgrade to non-ECN, it would make the code
> and documentation simpler.=C2=A0 It also has the property that you might=
 be
> able to reuse the 3168 codepoint in a couple of years (well, ok a decade=
).
>
> Is there any reason to want to have 3168 and AccECN coexistence=C2=A0bey=
ond a
> transition?=C2=A0 Put another way, if we imagine fully supporting both 3=
168
> and AccECN, it there any reason to choose 3168 other than deployment
> inertia?
>
> Thanks,
> --MM--


From nobody Thu Dec 12 08:37:07 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D40A120975 for ; Thu, 12 Dec 2019 08:37:05 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 WO-1-pm3nIwm for ; Thu, 12 Dec 2019 08:37:03 -0800 (PST)
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 9FB6312096D for ; Thu, 12 Dec 2019 08:37:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=yTyt9QvSaBL8MmUiNab5OxrhvcJdwePYwHFxS2VEdZk=; b=sft1ls+SFJgcfZuxt9JSJSBWdg z4PWzXz+fODE/2lAVs0x5QjBjZguSixy9euG9iUjvupQtwkqOrZjLPKYQx8MxMBy7VrMQQkOtJBk2 4P3KTlzs/pmz2m/lONXm90f/u6P62f8s++2J3yvSb12xZVDX5EKNC49yVujP1Bjy2HsglX7pVAJ2U 8o6D0/56HmHdk8MqhDBWqNdHaI9o9PNyBQP+TV5HzQvAN/A1Qv+jGBWfPmfFgi/gw1wxw6K9p8lMI QKDLAaPc8NGbu4FnoUC/8xAQirstwwiqYoQjjGW3vNKWnMV9sgFMGC8o92juOIy5aDwVe3TeD/EvF WDB2isiQ==;
Received: from 188.29.164.197.threembb.co.uk ([188.29.164.197]:46919 helo=[172.20.10.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ifRSY-0002WD-4z; Thu, 12 Dec 2019 16:37:02 +0000
To: "Scheffenegger, Richard" 
Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, tcpm IETF list , Richard Scheffenegger , Mirja Kuehlewind 
References: <201911261949.xAQJnrjK004168@gndrsh.dnsmgr.net> <38984214-7d4b-81b1-9c15-8347ad411c0b@gmx.at>
From: Bob Briscoe 
Message-ID: <8ccd0d82-7fc5-453b-ba06-435e7d14a799@bobbriscoe.net>
Date: Thu, 12 Dec 2019 16:37:01 +0000
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: <38984214-7d4b-81b1-9c15-8347ad411c0b@gmx.at>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
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: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 16:37:06 -0000

Richard,

On 28/11/2019 11:34, Scheffenegger, Richard wrote:
>
> Hi,
>
> I support the new text that Bob has suggested to allow a AccECN server
> to choose to not support RFC3168 ECN.
Can you give reasons - I'm trying to understand what to do given 
conflicting preferences.

>
> I also support Rod's suggestion to replace references to "classic" ECN
> with RFC3168 ECN.
Ditto. Reasons?



Bob
>
> However, as bob also pointed out, "ECT" is usually interpreted in the
> context of the IP header, but the AccECN draft only concerns itself with
> the TCP layer, where "ECN mode" / "non ECN mode" is the correct
> description of the state of the TCP sessions feedback...
>
> Best regards,
>   Richard
>
>
> Am 26.11.2019 um 02:49 schrieb Rodney W. Grimes:
>> tcpm'ers:
>>
>>          I believe the more common terminology is "Not ECT" (Not
>> ECN Capable Transport), rather than Non ECN.  Many new
>> instances of "Classic" has crept in with the new text, which I
>> do think we should avoid.
>>
>>          Comments inline marked [RWG].
>>
>> Regards,
>> Rod
>>
>>> Jonathan,
>>>
>>> On 24/11/2019 13:20, Jonathan Morton wrote:
>>>>> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger 
>>>>>  wrote:
>>>>>
>>>>> My reading of bob?s suggestion is
>>>>>
>>>>> Syn - accecn
>>>>> Syn-ack no ect
>>> I think Richard meant 'no ECN' at the TCP layer, rather than 'no ect',
>>> which implies the IP layer. I don't think this led to any confusion so
>>> far on the thread, but I've corrected it in case someone else gets 
>>> confused.
>>>
>>>>>
>>>>> I don?t see any problem there ;
>>>> That is indeed a valid transaction, but one which represents an 
>>>> AccECN client (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  
>>>> Of course, it is also legal by protocol to request RFC-3168 ECN 
>>>> (that is, CWR|ECE without AE on SYN) with a Not-ECT server.
>>>>
>>>> What the draft currently (and correctly, IMO) forbids is for an 
>>>> AccECN server to downgrade RFC-3168 clients to Not-ECT. I don't see 
>>>> any reason for allowing this, because the difference in code 
>>>> complexity must be very small, and the benefit to the RFC-3168 
>>>> supporting clients which are ubiquitous today (even if they don't 
>>>> always advertise it) in terms of avoiding packet loss and 
>>>> retransmissions just for the sake of a congestion signal is 
>>>> significant.
>>> I also "don't see any reason for allowing this", but that isn't what
>>> motivates text in RFCs. If there is no interoperability reason to
>>> disallow such a downgrade, then we should not disallow it.
>>>>
>>>> It does appear that I missed part of Bob's proposal through trying 
>>>> to read it on a phone at the airport.  It made me think that he was 
>>>> proposing that AccECN *clients* might not support RFC-3168 as 
>>>> well.  I now see that he was proposing this only for servers.  I 
>>>> still think this is wrong-headed, but it technically doesn't break 
>>>> the protocol on the wire.
>>> Yes, that's my point.
>>>
>>> If it doesn't break the protocol, it's not up to the IETF to tell
>>> implementers what is "right-headed". The two examples I gave are
>>> possible valid reasons an implementer might have (but even if no-one
>>> could think of a valid reason now, there's no need to preclude this):
>>> i) a cut-down lightweight TCP implementation
>>> ii) an implementer wishing to rationalize the server code she has to
>>> maintain when, in the long term future (recall that RFCs last for ever)
>>> AccECN might have become pervasive and 3168 ECN hardly ever seen.
>>>
>>> Here's how I propose to alter the text:
>>>
>>> CURRENT:
>>>
>>>      3.  The third block shows the cases where the TCP server (B) 
>>> supports
>>>          AccECN but the TCP client (A) supports some earlier variant of
>>>          TCP feedback, indicated in its SYN.Therefore, as soon as an 
>>> AccECN-enabled TCP server (B) receives the SYN
>>> shown, it MUST set both its half connections into the feedback mode
>>> shown in the rightmost column.
>>>
>>>
>>> PROPOSED:
>>>
>>>      3.  The third block shows the cases where the TCP server (B) 
>>> supports
>>>          AccECN but the TCP client (A) supports some earlier variant of
>>>          TCP feedback, indicated in its SYN.When an AccECN-enabled 
>>> TCP server (B) receives a SYN from a client in
>>> classic ECN feedback mode (AE,CWR,ECE = 0,1,1) it SHOULD set both its
>>
>> classic -> RFC3168
>>
>>> half connections into the classic ECN feedback mode as shown in the
>>
>> ditto
>>
>>> rightmost column and return a SYN-ACK as shown (AE, CWR, ECE = 0,0,1).
>>> The "SHOULD" allows for the unlikely case where a server might not wish
>>> to implement classic ECN. When an AccECN-enabled TCP server (B) 
>>> receives
>>
>> Ditto
>>
>>> a SYN from a client in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set 
>>> both
>>
>> No ECN -> Not ECT
>>
>>> its half connections into the No ECN feedback mode as shown in the
>>
>> No ECN -> Not ECT
>>
>>> rightmost column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0).
>>>
>>>
>>> Bob
>>>>
>>>>    - Jonathan Morton
>>>
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoe http://bobbriscoe.net/
>>>
>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>

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


From nobody Thu Dec 12 08:39:45 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C021209C0 for ; Thu, 12 Dec 2019 08:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 4dU1WT2ru5tm for ; Thu, 12 Dec 2019 08:39:41 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 B85CA1209C8 for ; Thu, 12 Dec 2019 08:39:40 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.1.243]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ifRV5-0001m9-8F; Thu, 12 Dec 2019 17:39:39 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Thu, 12 Dec 2019 17:39:38 +0100
Cc: Bob Briscoe , tcpm IETF list , Richard Scheffenegger 
Content-Transfer-Encoding: quoted-printable
Message-Id: <42AC05FC-DDA6-436F-9594-7458A0DE72B4@kuehlewind.net>
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net> 
To: Matt Mathis 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576168780;3aacd7a6;
X-HE-SMSGID: 1ifRV5-0001m9-8F
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 16:39:43 -0000

Hi Matt,

AccECN was always backward compatible with classic ECN, meaning when the =
sender of the SYN requests AccECN (111) and the receiver does not =
understand AccECN is will ignore the AE (former NS) bit and only see =
(11) and think the sender requested classic ECN and may decide to =
negotiate it, otherwise we would not be able to reuse the ECN TCP bit at =
all.

Mirja



> On 12. Dec 2019, at 16:07, Matt Mathis  wrote:
>=20
> Bob you said:
> >Don't worry, the AccECN spec says that the client MUST be able to =
fall-back to classic ECN support.
>=20
> If the only choice is to downgrade to non-ECN, it would make the code =
and documentation simpler.  It also has the property that you might be =
able to reuse the 3168 codepoint in a couple of years (well, ok a =
decade).
>=20
> Is there any reason to want to have 3168 and AccECN coexistence beyond =
a transition?  Put another way, if we imagine fully supporting both 3168 =
and AccECN, it there any reason to choose 3168 other than deployment =
inertia?
>=20
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>=20
> We must not tolerate intolerance;
>        however our response must be carefully measured:=20
>             too strong would be hypocritical and risks spiraling out =
of control;
>             too weak risks being mistaken for tacit approval.
>=20
>=20
> On Thu, Dec 12, 2019 at 3:17 AM Mirja Kuehlewind  =
wrote:
> Hi Bob,
>=20
> Please see inline below.
>=20
> > On 12. Dec 2019, at 01:13, Bob Briscoe  wrote:
> >=20
> > Mirja,
> >=20
> > On 11/12/2019 15:28, Mirja Kuehlewind wrote:
> >> Hi Bob,
> >>=20
> >> Sorry I think I just got a bit lost here.
> >>=20
> >> So this point:
> >>=20
> >>>>>> [BB] It's also important that the spec defines all three bits =
in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so =
that the combinations with AE=3D1 are ruled out and therefore remain =
available for future use.
> >>>>>>=20
> >>>> [BB] This cannot be said by referring to RFC3168 either.
> >>>>=20
> >> I=E2=80=99m not sure I understand what you mean, given that the =
combination with AE=3D1 is/needs to be discussion in this draft. Are we =
again talking past each other (but actually agree)?
> > In the context of these two rows in table 2:
> >    =
+--------+--------+------------+-----------+------------------------+
> >    | A      | B      |  SYN A->B  |  SYN/ACK  | Feedback Mode        =
  |
> >    |        |        |            |    B->A   |                      =
  |
> >    =
+--------+--------+------------+-----------+------------------------+
> >    |        |        | AE CWR ECE | AE CWR ECE|                      =
  |
> > ...
> >    | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN          =
  |
> > ...
> >    | ECN    | AccECN | 0   1   1  | 0   0   1 | classic ECN          =
  |
> >=20
> >=20
> > In the first case, I'm saying the AccECN client (A) only falls back =
to classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in =
response to a 111 SYN is reserved for future use. Whereas if in this =
case we merely said an AccECN client does what RFC3168 says, the AccECN =
client would have to switch to classic ECN if the SYN/ACK was X01, thus =
wasting a codepoint.=20
>=20
>=20
> In this case the A has requested AccECN support but B only supports =
classic ECN and indicates that in the SYN/ACK. As soon as the SYN/ACK is =
received negotiation is done and A has to act as specified in RFC3168.
>=20
> If B would reply with 101 in the SYN/ACK, then B is also an AccECN =
sender but wants to negotiate something that is not yet specified.=20
>=20
> I don=E2=80=99t see any problem here.
>=20
> >=20
> > In the second case, the AccECN server only falls back to classic ECN =
mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 =
SYN is reserved for future use. Whereas, if in this case we merely said =
an AccECN server does what RFC3168 says, the server would have to switch =
to classic ECN if the SYN was X11, thus wasting another codepoint.
>=20
> In the case where A requests classic ECN, B can still decide to either =
support classic ECN or not and respectively reply with 001 or 000. And =
all I=E2=80=99m saying that we should not specify this reply here =
because that=E2=80=99s already specified in RFC3168.
>=20
> If A sends 111 it=E2=80=99s not a classic ECN sender and we can still =
specify it here but that=E2=80=99s not the case that is shown in the =
table.=20
>=20
> Mirja
>=20
>=20
>=20
> >=20
> >=20
> > This is a separate point from the MUST vs SHOULD language in the =
second case. I'll respond to Jonathan on that next.
> >=20
> >=20
> > Bob
> >=20
> >>=20
> >> Mirja
> >>=20
> >>=20
> >>=20
> >>=20
> >>> On 11. Dec 2019, at 11:12, Bob Briscoe 
> >>>  wrote:
> >>>=20
> >>> Mirja,
> >>>=20
> >>> On 11/12/2019 08:48, Mirja Kuehlewind wrote:
> >>>=20
> >>>> Hi Bob,
> >>>>=20
> >>>> Sorry about your laptop (but if I remember correctly, it was =
broken anyway=E2=80=A6). I think we do agree (and did from the =
beginning). Yes, I think my first statement below was overly broad and I =
did not meant to remove all normative language from that section. I was =
only referring to language that talked about RFC3168 negotiation.
> >>>>=20
> >>>> You propose below that an AccECN sender "MUST respond to a 3168 =
SYN with either (0,0,1) or (0,0,0)=E2=80=9D and I'm rather saying that =
we should not use normative language here but rather say something like: =
=E2=80=9CIf an AccECN sender received a 3168 SYN (without AE=3D1 =
respectively) is replies as specified in RFC3168 if it is configured to =
support classic ECN.=E2=80=9D Or something like that. That=E2=80=99s all =
:-)
> >>>>=20
> >>> Pls respond to my two points (that keep getting overlooked), both =
starting with "This cannot be said by referring to 3168" further down =
the email.
> >>>=20
> >>>=20
> >>> Bob
> >>>=20
> >>>> Mirja
> >>>>=20
> >>>>=20
> >>>>=20
> >>>>=20
> >>>>> On 11. Dec 2019, at 03:19, Bob Briscoe 
> >>>>>  wrote:
> >>>>>=20
> >>>>> Mirja,
> >>>>>=20
> >>>>> On 23/1119 I sent an analysis of the changes that would need to =
be made to the AccECN draft if it became stds track (which would imply =
that it then updates RFC3168) instead of expt track. For context, please =
read and possibly respond to that before you respond to this email.
> >>>>>=20
> >>>>> However, my email below applies whether AccECN is stds track or =
expt track.
> >>>>>=20
> >>>>> I've shifted the quoting back into order below, so the context =
is more clear, and I've then responded inline...
> >>>>>=20
> >>>>>>> On 25. Nov 2019, at 22:41, Bob Briscoe 
> >>>>>>>  wrote:
> >>>>>>>=20
> >>>>>>> Mirja,
> >>>>>>>=20
> >>>>>>>=20
> >>>>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
> >>>>>>>=20
> >>>>>>>> Hi Jonathan,
> >>>>>>>>=20
> >>>>>>>> [MK] Sorry I wasn=E2=80=99t clear. I think we should not have =
these normative requirement in the draft and change the text to make it =
non-normative. This section was meant to explain which modes you end up =
in and the current use of normative language doesn=E2=80=99t seem to be =
right to me.
> >>>>>>>>=20
> >>>>> [BB] Please be clear exactly which requirements you are talking =
about. When I read the above, I just gave up and threw my laptop out of =
the window.
> >>>>>=20
> >>>>> Having bought a new laptop, I'm now wondering... perhaps you =
didn't mean all of the normative requirements under table 2 when you =
said 'we should not have these normative requirements', altho from your =
earlier email I got the distinct impression you did mean that (which is =
why I wasted a laptop).
> >>>>>=20
> >>>>> What did you mean? Given the considerable amount of normative =
language in this part of the draft, and that it's all been stable for =
all 16 revisions since draft-kuehlewind-01, I think we deserve to see =
the actual text you are proposing, and some sound reasoning for why the =
current normative text suddenly all has to be junked.
> >>>>>=20
> >>>>> more...
> >>>>>=20
> >>>>>=20
> >>>>>>>> [MK] Likewise the table was also not meant to say whenever =
you implement AccECN, you MUST negotiate it in the handshake. And =
likewise the table does not show any classic ECN only transitions.
> >>>>>>>>=20
> >>>>>>> [BB] In the spec of AccECN, it's necessary and reasonable to =
state normative requirements for a node "that is AccECN-enabled". That =
doesn't mean that an AccECN implementation has to always support AccECN =
- it can always disable AccECN. But we do have to say what it is =
expected to do if it is following the AccECN protocol.
> >>>>>>>=20
> >>>>>>> This draft has included that normative language for the =
negotiation phase in all 16 revisions since the first individual draft =
(that you wrote!).
> >>>>>>>=20
> >>>>>>> The table shows only cases where one end or the other is =
AccECN-capable, and the text preceding and following the table gives =
normative requirements solely for the AccECN node(s) in those cases. It =
doesn't give any normative requirements for non-AccECN nodes.
> >>>>>>>=20
> >>>>>>> In block 3, the server is AccECN capable, so in the AccECN =
spec. it's perfectly reasonable to say what it ought to do in response =
to various types of SYN. In particular, if it receives a SYN with =
AE,CWR,ECE=3D0,0,0 the AccECN-enabled server MUST respond with =
AE,CWR,ECE=3D0,0,0.
> >>>>>>>=20
> >>>>>>> The only case that is in question, AFAIC, is whether we have =
to say what an AccECN-capable server does in response to a SYN from an =
RFC3168 client (AE,CWR,ECE=3D0,1,1). We need to somehow say an AccECN =
server can respond with a SYN-ACK that is either RFC3168 or non-ECN.
> >>>>>>>=20
> >>>>>>> I just proposed respectively SHOULD and MAY, but I can now see =
there is no need to make that judgement call. However, it is still =
important to say an AccECN-enabled server MUST respond with either =
(0,0,1) or (0,0,0).
> >>>>>>>=20
> >>>>> On 02/12/2019 11:15, Mirja Kuehlewind wrote:
> >>>>>=20
> >>>>>> Hi Bob,
> >>>>>>=20
> >>>>>> Regarding the [above] sentence:
> >>>>>>=20
> >>>>>> This is a normative statement that is defined in RFC3168 and we =
should not state it here again but refer to RFC3168 instead.
> >>>>>>=20
> >>>>> [BB] But an AccECN /server/ does not have to support RFC3168. It =
might be desirable to support 3168 as well as AccECN, but strictly it =
doesn't have to for interoperability - it can fall-back to non-ECN if it =
receives a 3168 SYN.
> >>>>>=20
> >>>>> That was my reason for starting this thread. If an AccECN server =
supports 3168, it replies (0,0,1). But it can just not support 3168 at =
all. Then it replies (0,0,0).
> >>>>>=20
> >>>>> However, it cannot do neither. Hence why I said it MUST respond =
to a 3168 SYN with either (0,0,1) or (0,0,0).
> >>>>>=20
> >>>>> This cannot be said by referring to 3168.
> >>>>>=20
> >>>>>>> [BB] It's also important that the spec defines all three bits =
in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so =
that the combinations with AE=3D1 are ruled out and therefore remain =
available for future use.
> >>>>>>>=20
> >>>>> [BB] This cannot be said by referring to RFC3168 either.
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>> Bob
> >>>>>=20
> >>>>>>>=20
> >>>>>>> Bob
> >>>>>>>=20
> >>>>>>>> Mirja
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton =

> >>>>>>>>>  wrote:
> >>>>>>>>>=20
> >>>>>>>>>=20
> >>>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind =

> >>>>>>>>>>  wrote:
> >>>>>>>>>>=20
> >>>>>>>>>> I don=E2=80=99t think we can or should derive a normative =
requirement from this table. The table rather explains which mode you =
are in depending on the handshake that has happened. So it says: when =
client A is ECN capable and requests classic ECN support in the =
handshake and server B is AccECN capable and negotiated classic ECN =
support in the handshake then you are in classic ECN mode.
> >>>>>>>>>>=20
> >>>>>>>>> I will merely re-quote the final sentence from my quoted =
text, which transforms that table into a normative requirement:
> >>>>>>>>>=20
> >>>>>>>>>=20
> >>>>>>>>>>     Therefore, as soon as an
> >>>>>>>>>>     AccECN-enabled TCP server (B) receives the SYN shown, =
it MUST set
> >>>>>>>>>>     both its half connections into the feedback mode shown =
in the
> >>>>>>>>>>     rightmost column.
> >>>>>>>>>>=20
> >>>>>>>>> - Jonathan Morton
> >>>>>>>>>=20
> >>>>>>> --=20
> >>>>>>> =
________________________________________________________________
> >>>>>>> Bob Briscoe                              =20
> >>>>>>> http://bobbriscoe.net/
> >>>>>>>=20
> >>>>>>>=20
> >>>>>>>=20
> >>>>>>>=20
> >>>>> --=20
> >>>>> ________________________________________________________________
> >>>>> Bob Briscoe                              =20
> >>>>> http://bobbriscoe.net/
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>> --=20
> >>> ________________________________________________________________
> >>> Bob Briscoe                              =20
> >>> http://bobbriscoe.net/
> >>>=20
> >>>=20
> >>>=20
> >>>=20
> >=20
> > --=20
> > ________________________________________________________________
> > Bob Briscoe                              =20
> > http://bobbriscoe.net/
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Thu Dec 12 09:06:44 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2871209F0 for ; Thu, 12 Dec 2019 09:06:42 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 BLY9C75VBj4r for ; Thu, 12 Dec 2019 09:06:40 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 18E5F120A22 for ; Thu, 12 Dec 2019 09:06:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576170397; bh=4rSETD4H2nz6fGN0klRntbOFedB5cTW4ZB6FxHV1f2k=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=kPHfR6HDhK9XMnCLncjOIAHSxvKfSKhw8+XVMDWyUSuqgqdPCqqp4aPiZM/vT66RQ WAqzlmqMYbzxdUkaqT4gAp56QVENJeSISZIxZahAXCnnP8KqsrnKC2EQtJevRWJSbv 4UFcgArNqF1x/iES2lH489sx5vLw2klPDOIpPVaM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.249.70.154] ([217.70.211.15]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mkpex-1i0ahP17yJ-00mJLg; Thu, 12 Dec 2019 18:00:12 +0100
To: Bob Briscoe 
Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, tcpm IETF list , Richard Scheffenegger , Mirja Kuehlewind 
References: <201911261949.xAQJnrjK004168@gndrsh.dnsmgr.net> <38984214-7d4b-81b1-9c15-8347ad411c0b@gmx.at> <8ccd0d82-7fc5-453b-ba06-435e7d14a799@bobbriscoe.net>
From: "Scheffenegger, Richard" 
Message-ID: <9b47df69-dd7e-ab18-4ce6-2c064f06c718@gmx.at>
Date: Thu, 12 Dec 2019 18:00:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <8ccd0d82-7fc5-453b-ba06-435e7d14a799@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:BzFz7ZytNQTFRf8mTc9XrDXlUOQPUrycE8D/ISETRGc0tVyXYZs ZSB9/Yj4vyto6MCmJVDySPxG+51yngF2u5jjNrJZGxIHQgjUhyj7D+NOLK2+OH96FpZqOTf f6lbu3YEdyjhOwSNdrbWBfSnoWTkOVzonmiyhVlOR2P9hOb6oFBl4sGCHuC/KavNsz7SzzV NCPqwn9kQbqQN2W6MTQbQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:1ntXnw1eo74=:nGTu2Frhu42bf+Ez/MKYIi dHTO/0nxEthIGxTc6fGwj5IQtnvFGlhcKNovVOEHOOFLzdGLsIkczYqb3KBJ2Sji3UPTqzKwt kdHQGLAG0Rth2BxVF7VHyY2j0xTqoRAn3OnhclrQQrWOY13duX7lIX1/ypERvUYvNRUDas1e4 aD/R6Y6OLigQbA/VBuAA7gqBNuLcTHptjRWWA29mUbzr4tlBWC0TXtT1mJ9YOMe7eQ6OApMYB HecFeztfNbtLn3q8d145CS6fIUv1sTKCrCVbr2aRhjueAKyDHCbSwPthjXXMv6vzErNzV494E i0xmMjUqLhD++9AwtdoAJETwD0CiBXju8TH2Mi+eV2VFHunVKY8ltH9ZN/i06xx3o2Bq0xc/L 7JN0vnpxXXJDCU+bprtWDqZkkXdRsEXewKcMmCEIH/VPFG5a0Q1WDa96UTGQIhqbFeyyBWm7J e0SiuM7b4TQy86+dq4p2MQ2Y+JRLtyE/VcaZ85qiWndtMf7tgVDbBJqQez9Bafu58i2r4nVE7 Pb6mDmGq7wS/LyG8p2gOrEnjjeys/Xt91sPIOAxXyRx7v4R7SN4SUCiMtlWx+UfH7hQMyJz0G UVQPsdva8B39rK+MkaGB+GDG0deqgu7eFFUofzAuvoI4RsE+4dkM8z0760x6Vtcfm0gA5mjJK E73HDbnwyyLPS+8Ps3/0Fo1AYRL0inMRYxIS3QcMTmV0VuHvOmOuRFgHTXJtufeXlBiRdSLxp qGtQlh3RdI23xbVBHnuWVl2e6ZFEoWnRszYpQ0neH7wwpRmIyZnjkTHvspLZU3ybao/blpyZZ WW0qHjwEIG+pF6hpZTF7w4eKYEy4/xy8ht533HG8xeb5Gah9kWttmGtRmpNWBITKfthiLZyau 5BH/RPRB8H2k9bJsTuj9ffebFan1HKEl0o2zN7Y1/K5klzsp+qQUFbVKtK4ngA6/VtXFv99h/ XkJfLmhhRqzUf7hCZPnZ/AKsC3oGCCcHknraXWcLqvPkh0X8pM3JktN/nP+YouNr4l5sDHN1x iICMAjy+U8m2PxDbrlrjRFVQ9fUBihxlPzwuYTfB7VZI4FDv0Oe0U9LIFGCvIHzIKIva5zP2S rpXRn90f0D5jFkuvPevEahjSL2cXjYuEFbX7Gj2fa81w7dXzadnn7FwlSTnLR4HCcT2RpRYQg xnEg9FAP4i4b2e6hlPbVtUA0L8PPcYxYuNJGbycMmOFss74tnlcpDL3xaVdoIdJuqMb4rnodB vGztSnHwkTnDJBngWGzdHBEIId5GNLSjNWO8Vow==
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 17:06:43 -0000

Am 12.12.2019 um 17:37 schrieb Bob Briscoe:
> Richard,
>
> On 28/11/2019 11:34, Scheffenegger, Richard wrote:
>>
>> Hi,
>>
>> I support the new text that Bob has suggested to allow a AccECN server
>> to choose to not support RFC3168 ECN.
> Can you give reasons - I'm trying to understand what to do given
> conflicting preferences.

I think it is not unreasonable to leave the decision, if a particular
server chooses to not fall back to ECN, if an RFC3168 client asks for
ECN support, to the deployer of the server.

By itself, ECT0 can already be seen as a classifier (we've had this
discussion with L4S and ECT1). In this light, non-ECT vs ECT0 (or ECT1)
can end up in different queues. If the server operates in an environment
that doesn't lend itself to good interoperability with RFC3168 ECN, the
server might want to not run ECN at all with a RFC3168 client. Thus
preferring to operate in loss-only congestion feedback rather than a
potenial problematic ECN feedback.

While at the same time, it may want to utilize the full potential when
in a session with another AccECN client...


>> I also support Rod's suggestion to replace references to "classic" ECN
>> with RFC3168 ECN.
> Ditto. Reasons?


This is mostly semantics and possible conotations of the prose-term
"classic". When I followed the discussion around this, it appeared to me
that while this is not objectable to native speakers, non-native english
speakers may have a different set of conotations attached to specific word=
s.

In this context, RFC3168 is as neutral and specific as it can get. Thus
it appears to me, that this would be less contended reference.

Hope this helps.

Richard


From nobody Thu Dec 12 10:32:33 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0281209F4 for ; Thu, 12 Dec 2019 10:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 JNjZCOHQxck2 for ; Thu, 12 Dec 2019 10:32:31 -0800 (PST)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 37BC41209EA for ; Thu, 12 Dec 2019 10:32:31 -0800 (PST)
Received: by mail-lj1-x244.google.com with SMTP id 21so3415154ljr.0 for ; Thu, 12 Dec 2019 10:32:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b64tWe0/NZ+2Im/6BvZuqc00BN/OG9KyUmJPszfO0Wk=; b=jn6BK2/6MnhNDjOQJc1neufXX9LTaU1//zmM+1QEGtqZ6p9Rxq79Pp7rsRe1kl2YmG fHwTsuiS19DlhjaxRrHDnOsaJkihjs1mEsrRQrmQ09Ell9NN2meiTT4d2dDY/CpLnBhX tcOEXJsCxPVJCX2Sx+yfgs2Ri3rZBcsBKorCs0Ekp2MVkBO6CXV5WVLpOjLnr/Ipkr3O y6tXThuiwfF8ll2ai0scgite0g2Zfe6EYeWyt3o11rfk1zemXIDlueqnFNW5Bvuz4ZPA aEZIb4IwLYy5JlvZaLVGBZVm5lWF17/ma8IW9gz1ZTg7lqu78KtobRpEz1+a1E0qtu0c QYCg==
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=b64tWe0/NZ+2Im/6BvZuqc00BN/OG9KyUmJPszfO0Wk=; b=EJH0t4udV8r8LL+F037E/HMm+bdlGXLSIZulkkcBI7baFlPxfsfIL2ixseDrA1CXri t15MBbb2nHhnHauTds0FF3yThEYKhAIzbsOIvfd6MJVTs3UUjFZAnKGMmXyE4EZPDqKc 6ZRS2Qf3fvjQldqQ2TOebAiInEqqRcgK45MwjkI4aikB1natt12vZ6wDIirmUE8qZvgy xhAWf5JXJP7f9iXu4rSPckoU/Pjb3DelGkZ1eDubfhx/iVyJoUuyePu1niIf5cNWjsup 4mVItlHuvAKvH41BYoAuxJHx2mcdcFEbGk9UPrGsP2WnmDECOSa31adqHhajt5bHPQQT cSTg==
X-Gm-Message-State: APjAAAVdA0YKkmqw7CN86hEEUv+pFJRrDgO386y0lvnRtzC4zpoyTRKk u8ZXe6U+UAgFYh1w65pgrQQ=
X-Google-Smtp-Source: APXvYqxUhX6Tsd81pYEJYjoUaEczhcLO5jeQO/YvnEmhk0EC3WHu8lIPPPEiBUrIHXlGZ5bZ6CAjrA==
X-Received: by 2002:a2e:9a8b:: with SMTP id p11mr6870201lji.5.1576175549404; Thu, 12 Dec 2019 10:32:29 -0800 (PST)
Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id z26sm3322493lfq.69.2019.12.12.10.32.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Dec 2019 10:32:28 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton 
In-Reply-To: 
Date: Thu, 12 Dec 2019 20:32:27 +0200
Cc: Mirja Kuehlewind , Richard Scheffenegger , tcpm IETF list 
Content-Transfer-Encoding: quoted-printable
Message-Id: <10B9ACEE-DDA5-45E6-A639-BBB6CD51DDB5@gmail.com>
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net> 
To: Matt Mathis 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 18:32:32 -0000

> On 12 Dec, 2019, at 5:07 pm, Matt Mathis =
 wrote:
>=20
> Is there any reason to want to have 3168 and AccECN coexistence beyond =
a transition?  Put another way, if we imagine fully supporting both 3168 =
and AccECN, it there any reason to choose 3168 other than deployment =
inertia?

Because there are still potential valid experiments which build upon =
RFC-3168 signalling, including SCE, which may yet prove popular.  I =
think it would be exceedingly short-sighted to prevent such experiments =
from succeeding, and not just because I happen to be involved in one.

And because there's an *awful lot* of RFC-3168 compliant endpoints out =
there.  Every current Apple product requests RFC-3168 ECN by default.  =
Some major Linux distros do as well, and for all others it's a mere =
sysctl away.  Even Windows users can turn it on just as easily, though =
it is not on by default.

The ECN-aware middleboxes intended for use on last-mile links and as =
wifi APs also universally signal in the RFC-3168 manner and expect an =
RFC-3168 (or RFC-8511) compliant response.  I've found CPE advertising =
support for exactly this on the shelf.  The recent "make wifi fast" =
modifications to the Linux wifi stack include a built-in fq_codel AQM =
for the very common ath9k, ath10k and mt76 hardware.

That deployment remains low in the carrier-grade market is increasingly =
anomalous (and mostly due to a chicken-and-egg situation whereby =
carriers can't turn it on because HW doesn't support it, and HW vendors =
don't implement it because their customers don't make a stink about it). =
 Nevertheless, at least two major European ISPs are known to have =
deployed fq_codel in both directions, in the name of improving =
customers' QoS.

This is what I mean by RFC-3168 deployment "taking off" in the past few =
years.  There's a lot more of it now than there was five years ago, due =
in large part to the superlative performance of Codel AQM - which is =
*specifically* designed around RFC-3168 response characteristics.  We've =
already discussed this somewhat in TSVWG.

 - Jonathan Morton


From nobody Thu Dec 12 10:39:46 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C86120A17; Thu, 12 Dec 2019 10:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 zNtog6XfVHgs; Thu, 12 Dec 2019 10:39:44 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 231941209EA; Thu, 12 Dec 2019 10:39:44 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id n12so30773lfe.3; Thu, 12 Dec 2019 10:39:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Io8VfoTj0+HNGhkop3lbtwZ5P32W0GU4nRTjTVu9yoI=; b=JI3ieBI111ij0dh0G70F+mMf0Glyr/JBaAwrub2r5os1cL/U/yLs87/n53ewsgaGt5 Vmhxx+kG5QNpeolKHYtFR/q3QlXxh0UuOsW9Vf6AHR/d3ohs9ZqqnYLzG7AhOYG8YlBJ FEUWvFb51p5MD9i8D5H0m8oUxYu1U/hXsr20kxLw4lV+Y8wGU7C3s6rBHq8oMmI73coL cyznRFhz9w8kyVEBBk5rjhuVMuZka848U9ZIsnXCWeCaiR0MORO3ZpcvXiJOCHFBT/Lu LISchNr+msa3rn5Eh+WtYLmCiEqtWgwHjDIsapE6VvyX80JipbWWRWOdRov7ij/UHunV JDnw==
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=Io8VfoTj0+HNGhkop3lbtwZ5P32W0GU4nRTjTVu9yoI=; b=k82pPafjE2U/krjiN/U+L/NPUE8f4cWnO1q0y+0Hba2txUP8R+535zMiBDjaS+ZJBY Pw3bWJMR4N2jbMWvm2wAaO+X9D3uDw8Tjf7PCqkMTqTBT94KgF77LnVZDgq2rDbl6sfq 0NFAHrez5RzTzH2Fjtuu21T45zxMqLcEq9a7xycfwq2nIeSTxJjT9Wfba/jC5+QJJEjX 86m2RDWE3O4BBPGLYdGB1+QZJeq9TQlNd1fZ6RVihCNYik54bXVDIRAmZ3ldugK2c/UG W8ayy26vPMU+Qjxs7eI8ViEpofJSLIKKgxNKS82rrKxsquKmCk+Xb97QfsyTE8T+h1gH 8WMQ==
X-Gm-Message-State: APjAAAWyGJEiTRHgu4hxl7JSlOImoRcy/icoRkux4sAiE2ODl9RgcwLo Wub4lDyGmzrMDmuGaEj9nvCewWN7
X-Google-Smtp-Source: APXvYqwOiRhB0fdh+hMWbptGKbr1rcbYMOOeLhwvtqcuzBgag6AlSKuFlCTt1Xpu+wx4pK/cGe6gTg==
X-Received: by 2002:ac2:420e:: with SMTP id y14mr6704855lfh.145.1576175982402;  Thu, 12 Dec 2019 10:39:42 -0800 (PST)
Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id h24sm3439893ljl.80.2019.12.12.10.39.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Dec 2019 10:39:41 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton 
In-Reply-To: <49c9dfa7-019b-4d16-73f6-8a15c1077c73@bobbriscoe.net>
Date: Thu, 12 Dec 2019 20:39:40 +0200
Cc: tcpm IETF list , "tcpm-chairs@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <83880058-a057-66bf-24a3-855480b29f00@bobbriscoe.net> <49c9dfa7-019b-4d16-73f6-8a15c1077c73@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] Impact on AccECN draft of change from EXP to PS
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 18:39:45 -0000

> On 11 Dec, 2019, at 8:43 pm, Bob Briscoe  wrote:
>=20
> At IETF-106 there was believed to be rough consensus in the room that =
AccECN ought to be stds track not expt track.
>=20
> I pointed out that we would need to check for that consensus on the =
list. We can't really move forward with the draft until that has been =
done. So would it be possible to do a consensus call on the list on that =
question ASAP?=20

Please put me down in the EXP camp.

One justification I have for this is that there are suddenly proposals =
for substantive and controversial changes to the normative text of the =
draft, which should not be happening during a call to promote to =
Proposed Standard.

 - Jonathan Morton


From nobody Thu Dec 12 10:53:33 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E64120024 for ; Thu, 12 Dec 2019 10:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 w8t4iMUdBBPS for ; Thu, 12 Dec 2019 10:53:30 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 2369A1200C3 for ; Thu, 12 Dec 2019 10:53:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576176802; bh=45+7/Jth2Eqeb77bGryVlguU2qeE4bEZY4E5raEAsOQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=GwyHT6kGb7yoqnIeVtK9hQg2fT15rvbkxTfIfpjecOVp1Gd9+Z1YVXSUooHgFHkvZ mBMLNAFB2x+kg8gYqd450a863/UOvzbVU6TwofERuxehxyBQ0EvcykcWCSiJgBb9E2 YwQmw5xx2Su9lsQqKue8keIotKL5/xvEJSXSihZ0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [213.162.73.13] ([213.162.73.13]) by msvc-mesg-gmx024.server.lan (via HTTP); Thu, 12 Dec 2019 19:53:22 +0100
MIME-Version: 1.0
Message-ID: 
From: "Richard Scheffenegger" 
To: "Jonathan Morton" 
Cc: "tcpm IETF list" , "Mirja Kuehlewind" , "Matt Mathis" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Dec 2019 19:53:22 +0100
In-Reply-To: <10B9ACEE-DDA5-45E6-A639-BBB6CD51DDB5@gmail.com>
References:  <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net>  <10B9ACEE-DDA5-45E6-A639-BBB6CD51DDB5@gmail.com>
X-Provags-ID: V03:K1:7ly2rVbMVHz5zz+gxdl5ySOKWMoQjieykrHS9h8An9vmJqVIwr0Luc2iFtFtjSd2uM/9/ gKGGZXCpWd2GxMFzHPVDGdmW7J6/TEyJpHsw/xRbSe1l7betuTZc7p4mqBhcGZ1/yh3/tBQkDoXz KeSQEXNvsyUGogA36PNVM/rpKgCTbuCEf3wvnc8gDMWEYqstH0t5D3OdkFN5uqd9BDe/wNvTKCHR evzT6y03f+wzuCOgQecCKJi7N5vTlxlELvBzm4wJIoHU+6RqqRLL5W4+tVuKGOuOUELevXObv1bj y0=
X-UI-Out-Filterresults: notjunk:1;V03:K0:8s9xOFEag/0=:LJw/HJh7n/VNikAbSULCrB 88C9SLGAReTcUXQUunoZDyTbvCKj8YPiBxVXJEn6Tb/l8OsMSBGmrTdCDsYTOy9EDivNN/MR2 UB7yeoUw5L0NCdsQ3gQ+CNJoGfzRaq4T5lHG0EYb8ih94i51VpAok3Si7EzQEgsDlk3FR2jny IIbBrKNA4//e0iws6OSKVHg+Q3o6iGhdYZSg96H37/F6bVxrK3ttcBJz+9wSHPy3J6qi2Q1YN M8Z+BcJZ7s2BX0EnuJ6ndtMJJJMjedaEb+woGIkI9IaapSomBx0GQqj6l2WBHdKAWoamf5EAk T+8fwKzKNnexuwUjB2x7yu+dXsHBTBL6t8C7cq3S+a59vn5ZQ/6RQeHldzNHYY3h9O4yldjfH xvcCKc7K5Z4ucPqg8cs1SgJorulUdRBV/AAHNTcnA69M+jZAkwKxWRvEkQMr044WyQkx1d+J/ q4d9bXucOJuQ5zUTGVxwt6D0YwIBOBlYzVBND66lzEMYik5HUns92BfwjigTKi1JNOEQ/6KZ4 lFJLjQ7RTGV60bCAbe+zJL7aUK1MHskSY6erQH4E2EOnxEpxn4at1k/7gchJWR25QmDNFWqW2 cIEoyHe2vdSl5XrtnXmB7jKci3KPDLm0xT7zrUOPyKyN2JVMTGTDYZJyP5tpGNfeYBm4cqrGE ItdNvpei7fHexoYDzEBhtVTGZd/gz/vj8/B8np9pW+GXDse3SO5foxPB0VSTvC4zmWUSab5Cr PpjVXueBJZ0aslWDlFuXljtzW3PXquaTa/EYk4lTw3R1SU2Ai5einukeH+U=
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2019 18:53:32 -0000

Just remember that windows will nowadays go with dctcp if you turn on ecn, =
and the server is less than 10ms rtt away (which is possible in cities wher=
e a cdn colocates with your isp=2E=2E=2E)

Just sayin=E2=80=99 :)

Gesendet mit der GMX Mail App

Am 12=2E12=2E19 um 19:32 schrieb Jonathan Morton

> > On 12 Dec, 2019, at 5:07 pm, Matt Mathis  wrote:
> >=20
> > Is there any reason to want to have 3168 and AccECN coexistence beyond=
 a transition?  Put another way, if we imagine fully supporting both 3168 a=
nd AccECN, it there any reason to choose 3168 other than deployment inertia=
?
>=20
> Because there are still potential valid experiments which build upon RFC=
-3168 signalling, including SCE, which may yet prove popular=2E  I think it=
 would be exceedingly short-sighted to prevent such experiments from succee=
ding, and not just because I happen to be involved in one=2E
>=20
> And because there's an *awful lot* of RFC-3168 compliant endpoints out t=
here=2E  Every current Apple product requests RFC-3168 ECN by default=2E  S=
ome major Linux distros do as well, and for all others it's a mere sysctl a=
way=2E  Even Windows users can turn it on just as easily, though it is not =
on by default=2E
>=20
> The ECN-aware middleboxes intended for use on last-mile links and as wif=
i APs also universally signal in the RFC-3168 manner and expect an RFC-3168=
 (or RFC-8511) compliant response=2E  I've found CPE advertising support fo=
r exactly this on the shelf=2E  The recent "make wifi fast" modifications t=
o the Linux wifi stack include a built-in fq_codel AQM for the very common =
ath9k, ath10k and mt76 hardware=2E
>=20
> That deployment remains low in the carrier-grade market is increasingly =
anomalous (and mostly due to a chicken-and-egg situation whereby carriers c=
an't turn it on because HW doesn't support it, and HW vendors don't impleme=
nt it because their customers don't make a stink about it)=2E  Nevertheless=
, at least two major European ISPs are known to have deployed fq_codel in b=
oth directions, in the name of improving customers' QoS=2E
>=20
> This is what I mean by RFC-3168 deployment "taking off" in the past few =
years=2E  There's a lot more of it now than there was five years ago, due i=
n large part to the superlative performance of Codel AQM - which is *specif=
ically* designed around RFC-3168 response characteristics=2E  We've already=
 discussed this somewhat in TSVWG=2E
>=20
>  - Jonathan Morton


From nobody Fri Dec 13 01:17:53 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209DD1201EA for ; Fri, 13 Dec 2019 01:17:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 PDRsqmbcrly8 for ; Fri, 13 Dec 2019 01:17:51 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 ACC5D120115 for ; Fri, 13 Dec 2019 01:17:50 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id j42so5776159wrj.12 for ; Fri, 13 Dec 2019 01:17:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=ku9/r7Cwg1dalxEUCnXpYREPxnK+xC959lxvDYKkrfY=; b=ZtSzsxO3zeMGSgr94sZIFSEVEbMivcpPxi24Jsk5xu/MuKJfJBsVSOdBvj8iEU3/3/ fWWOWjgekEsz5cR+mWFvBZ2WTsd79CvQIz/gOmQ3o3ckh3RLwGOGltmXXkEkdcPrynJ9 5G3BNWgMSw1k+hgGEbxIRSvLolRV7dzuHXhwVXIqAhKGABlrt+9fKHZ/BDIvnBiZxRPC WQkmE1EAAk3XI/55trSp/OMOGz1/Pk3SYi2RHxX5H33chNwQ4nD6VVJxCbsR8WshM/Ld PdR/p/EEGmx+ISWJuIJukYNs6VB6v45qrRpO1ngosRSOmuHkAFhIkngrjW8uQSWGKs9S fAtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ku9/r7Cwg1dalxEUCnXpYREPxnK+xC959lxvDYKkrfY=; b=PRFqR7iRKHnzqYRP8ZogylvXJgEWZbdNKHJvVnqrPPGuIti8hGkZgWQjxgvDrDfFjw xro0luu8Pj3N0OemydBy4xJQnypPs0YWxTikOfEEbaTT8mxiacl7wp6PqzGCdNzkIpNc Ho2ohVRW4E2hiKe05EtuHqunX6UxSa3+NJb6zVIOD47E6C1b4ZdCehLrQ8XrjKhjACz9 FWziAG4E6Y0wLRTQFipUIkBLwzLMZanpn3upk24tmPfVDrqYHLIWJPCSH+GWv+/xhi5N B8+ssKikOEX5t0KEQVJo87WoBwbH1+IfF/UeXM0KxHExZYthC1ibs7/5rw1QnMMK9OKH ZZeg==
X-Gm-Message-State: APjAAAW7mBT8vRvYDXMlwThfuht1J4TY7YgYesJ38Ykp/xsvb9by9kJI ewRvvHeyeHLNmvBerBp2OkzOfLep5cvN+vfqs3Gsq8Yb
X-Google-Smtp-Source: APXvYqzYhS5qqIf1sVDI1qMtQ6mwPk2wSYtsPxw4Aw8ecC+D0JbVwuU3Mq/W9yIFpIlUUticcydvjSy9lnBJrrwS+Eo=
X-Received: by 2002:a5d:558d:: with SMTP id i13mr11604597wrv.364.1576228668628;  Fri, 13 Dec 2019 01:17:48 -0800 (PST)
MIME-Version: 1.0
From: Yoshifumi Nishida 
Date: Fri, 13 Dec 2019 01:17:36 -0800
Message-ID: 
To: "tcpm@ietf.org Extensions" 
Content-Type: multipart/alternative; boundary="000000000000e0e4d60599925532"
Archived-At: 
Subject: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2019 09:17:52 -0000

--000000000000e0e4d60599925532
Content-Type: text/plain; charset="UTF-8"

Hi folks,

We would like to get feedback for the intended status
of draft-ietf-tcpm-accurate-ecn.
The current intended status of this draft is experimental, but we've seen
some voices that PS is more preferable for the draft during Singapore
meeting and on the ML. So, we would like to check the consensus on it.

There are some on-going related discussions such as flag registration
policy, SCE, ECN++, etc, however, we believe the intended status
discussions is independent from them and can proceed it separately. (If you
have concerns on it, please share your opinion here)

We appreciate your feedback.

Thanks,
--
Yoshi on behalf of tcpm co-chairs.

--000000000000e0e4d60599925532
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi folks,

=

We would like to get feedback for the intended status of=C2=A0dra=
ft-ietf-tcpm-accurate-ecn.=C2=A0
The current intended=
 status of this draft is experimental, but we've seen some voices that =
PS is more preferable for the draft during Singapore meeting and on the ML.=
 So, we would like to check the consensus on it.

T=
here are some on-going related discussions such as flag registration policy=
, SCE, ECN++, etc, however, we believe the intended status discussions is i=
ndependent from them and can proceed it separately. (If you have concerns o=
n it, please share your opinion here)

We appreciat=
e your feedback.

Thanks,
--
Yo=
shi on behalf of tcpm co-chairs.


<=
/div>

--000000000000e0e4d60599925532--


From nobody Fri Dec 13 05:45:07 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24071120104 for ; Fri, 13 Dec 2019 05:45:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 kQFZCGthoY4I for ; Fri, 13 Dec 2019 05:45:03 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 0456F1200FE for ; Fri, 13 Dec 2019 05:45:03 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id y1so1992964lfb.6 for ; Fri, 13 Dec 2019 05:45:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Hwp/HxKYcTCVPg3y3j5X8pDiSZhBNy0osweXMBaSofY=; b=fP2RRpIG5rh6oMBnt09Fjprw9ei6A/qLgk2xjBPl77eDBqaf4bKKS3n7fPox9ngdpG eQhrQ4Jv0IAbB2xYJcsZ+NC1u0dcP1c55PzCHX8yJYsaVLFbw3dHCbTsmFsKhvP11DZM xyaCsHAeAJy9UBUjBXdlmCLRHwCbAmqRu4Oak1CXbjo1shCxKweS8JUkJz/jgDtD4UR1 ToqOkz5TYpyV4+jzA0ZaYMYZOTZdlcim+QhflbXxyLV/jL9L+hVd2qOberL1XzWpGsOQ tmXztOKX+GLvWJ2MtVmGmUMSiDg0W2O4xXpad+RS4XblczI3RoniJmlI0uR/3MXXyVpV DY/w==
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=Hwp/HxKYcTCVPg3y3j5X8pDiSZhBNy0osweXMBaSofY=; b=QlxIzB+bUeYA6+5V2KKOz4d9AGfLBDAveyR7iUtrYtQoYUM8Yc7FSNixu9/XmcfXov ahAHR2SqFs9SNTP4hkbbrQwaJbCWe9T5yHjYizqFQAAmsZrKXL6BQk6SghkrG/cqRCjk wJbaF2vYFJDbuRM2yR1bhy0+Czb7A9Wz/5sedFHjQ2Z1yfIBeteE4jpdnszAOjHYIsVo XxAaqimlxfI2/fmcTImzznIgIKxk6L54PIJwJ/jtEHZuoSLtqihTXVtSottAJVcslZHe +fLEz4fTox3TfMTDZngtVxsBoAcuOstZKr33WLRM1pydlq+gQgjUw6QZ1jAkLMDvLuvf F1eA==
X-Gm-Message-State: APjAAAWjVZGv+AUxVPv8BCYAaMsWFN3OydzzaLcNGRYpVDgt3fJHOahK hFZlRLF/QLoqgBL0HsFRB8fwEJv9
X-Google-Smtp-Source: APXvYqxzsz1Fv1VmK+Tm+/bdyYqe5AvfiZmIVKfISCjZO8jvYzS2s2OzQ1vNfrHlTQUXhzxucffuew==
X-Received: by 2002:ac2:5468:: with SMTP id e8mr9004106lfn.113.1576244701474;  Fri, 13 Dec 2019 05:45:01 -0800 (PST)
Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id r23sm4792229ljk.53.2019.12.13.05.45.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Dec 2019 05:45:00 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton 
In-Reply-To: 
Date: Fri, 13 Dec 2019 15:44:59 +0200
Cc: "tcpm@ietf.org Extensions" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <68EDA6E5-EFBF-494C-A17D-672EC079F83B@gmail.com>
References: 
To: Yoshifumi Nishida 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2019 13:45:04 -0000

> On 13 Dec, 2019, at 11:17 am, Yoshifumi Nishida  =
wrote:
>=20
> We would like to get feedback for the intended status of =
draft-ietf-tcpm-accurate-ecn.=20
> The current intended status of this draft is experimental, but we've =
seen some voices that PS is more preferable for the draft during =
Singapore meeting and on the ML. So, we would like to check the =
consensus on it.

I say it should stay as EXP for the time being.

 - Jonathan Morton


From nobody Fri Dec 13 09:29:06 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D72C120854 for ; Fri, 13 Dec 2019 09:29:04 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 3kfBDWNofeHA for ; Fri, 13 Dec 2019 09:29:01 -0800 (PST)
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 C623C1208DC for ; Fri, 13 Dec 2019 09:29:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=TWjpO03YobBgzvYe1pfukFRyhoXT5swmqnMU6jFnECs=; b=xTC584sEu5fwjBoRVnnnN4KVh5 NQC7eHKMfIwx/c+JmGH02S8HKeuBLR4LILEd3d2PNxzQ9SVL7m0shPDJ/yi4iOp8Qfv1OExWjKDh8 HCrnwHpd6RMGJMz86jIzpQBp//O8vGLxIyPGt/rkCFQ0E8fxESQcVo8f7oN1UdBUf8uWoH2McnmZ0 leeGhZ3P0k3dDJwxYu7926SvB6d925sL4BvaWrxkhVG9oUfQkNhOadnp5J97YSCsYxKD6xc4As+Fj eAqwd3A34oXUZY6ueIF6rw/irlaNzAcg60Tpom+v+fzPqj207oI3TkKOQErLgbvn8Pa7TKEt4wmL/ YflXtoSA==;
Received: from 92.40.249.2.threembb.co.uk ([92.40.249.2]:45939 helo=[172.20.10.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1ifokN-0001TX-5B; Fri, 13 Dec 2019 17:28:59 +0000
To: Carles Gomez Montenegro 
Cc: "Scheffenegger, Richard" , tcpm IETF list , Jon Crowcroft 
References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu>  <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at>  
From: Bob Briscoe 
Message-ID: <7a071358-74e6-c88f-6f88-b45941b90991@bobbriscoe.net>
Date: Fri, 13 Dec 2019 17:28:58 +0000
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: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
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: [tcpm] More motivating scenarios for tcpm-ack-pull
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2019 17:29:04 -0000

Carles, Jon,

Another motivating scenario for ack-pull (or similar) brought to my 
attention by Richard Scheffenegger and Neal Cardwell:

Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives
https://lists.openwall.net/netdev/2018/07/25/10




Bob


On 10/12/2019 13:37, Scheffenegger, Richard wrote:
>
> I believe your list here misses the AckCC option of RFC5690 (which is
> only informational, not even experimental). Am Ack Ratio option of 1
> followed by a an Ack Ratio of n could serve the same purpose...
>
> Note that there have been multiple investigations showing good
> traversability of new options across middleboxes nowadays.
>
> Best regards,
>    Richard
>
>
> Am 07.12.2019 um 12:30 schrieb Carles Gomez Montenegro:
>> ess how the patch you mention offers a way
>> to trigger immediate ACKs, and the related context and benefits.
>>
>> Perhaps a combination or (re)use of existing TCP header fields (e.g.
>> CWR/PSH as per your suggestion below, or the Urgent pointer as suggested
>> earlier by Bob) could be a way to enable triggering immediate ACKs.
>>
>> A concern with these techniques is that they are limited to some extent.
>> For example, some applications produce small segments with the PSH flag
>> set and benefit from Delayed ACKs (e.g. to piggyback ACKs and 
>> replies). In
>> those cases, even regardless of the CWR flag, triggering immediate ACKs
>> will avoid achieving performance benefits of Delayed ACKs.
>>
>> In contrast, a dedicated resource (e.g. a TCP header reserved bit, as we
>> propose in the draft) will not suffer such limitations. However, that
>> resource needs to be allocated.
>>
>> Summarizing, there may be two approaches to enable ACK Pull:
>>
>> 1.- Overloading semantics of existing TCP header fields.
>> 2.- Dedicating a resource.
>>
>> Then the question is, considering pros and cons of both approaches: 
>> which
>> one do we prefer?
>>
>> It would be great to hear the WG feedback on the above question!
>>
>> Thanks,
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

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


From nobody Sun Dec 15 11:14:38 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C8312008C for ; Sun, 15 Dec 2019 11:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 kY_B-cJwsijn for ; Sun, 15 Dec 2019 11:14:34 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943FE12004D for ; Sun, 15 Dec 2019 11:14:34 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 98F5825A19; Sun, 15 Dec 2019 20:14:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1576437272; bh=EAzFdLUjYQu5I7wo/ddczWwiQ4j/uENMkSX57L1N0YE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=IZw8cOFtDDitwmz+Ofkmzxm4KwX0XD+HNk1C7lN4NIeIGToYnC+1pLhSktB2JpHhM yU39GawP0hZPSUSkBCRhGpohZd2ljqQO5h2yULnzOu9QSOBeywJDhxRWm68Hco5gZJ ppJ3QlcH2PP58PZ7vy760c0K5pwgHKqcwUfVRA84=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qQZPC79MODC; Sun, 15 Dec 2019 20:14:32 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 15 Dec 2019 20:14:32 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.242]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Sun, 15 Dec 2019 20:14:31 +0100
From: "Scharf, Michael" 
To: "Scheffenegger, Richard" , Bob Briscoe 
CC: Mirja Kuehlewind , tcpm IETF list , Richard Scheffenegger , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Thread-Topic: [tcpm] A possible simplification for AccECN servers
Thread-Index: AQHVofETELtCyBn04EKb2ALrvNxa4aeYud8AgAEQQdiAAkgygIABvl+AgAKaRACAFlUngIAABnmAgATpw7A=
Date: Sun, 15 Dec 2019 19:14:31 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D84EA6C@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <201911261949.xAQJnrjK004168@gndrsh.dnsmgr.net> <38984214-7d4b-81b1-9c15-8347ad411c0b@gmx.at> <8ccd0d82-7fc5-453b-ba06-435e7d14a799@bobbriscoe.net> <9b47df69-dd7e-ab18-4ce6-2c064f06c718@gmx.at>
In-Reply-To: <9b47df69-dd7e-ab18-4ce6-2c064f06c718@gmx.at>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Dec 2019 19:14:36 -0000

> >> I also support Rod's suggestion to replace references to "classic" ECN
> >> with RFC3168 ECN.
> > Ditto. Reasons?
>=20
>=20
> This is mostly semantics and possible conotations of the prose-term
> "classic". When I followed the discussion around this, it appeared to me
> that while this is not objectable to native speakers, non-native english
> speakers may have a different set of conotations attached to specific wor=
ds.
>=20
> In this context, RFC3168 is as neutral and specific as it can get. Thus
> it appears to me, that this would be less contended reference.

The TCPM chairs also got a (private) note from the TSVWG chairs that "RFC31=
68-ECN" is their preferred term. Probably TCPM documents should use the ter=
minology preferred by TSVWG for ECN.

Does TCPM really need to run a formal consensus call on this kind of termin=
ology?

Michael


From nobody Tue Dec 17 06:29:29 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955A71209E1 for ; Tue, 17 Dec 2019 06:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 UbmsbXm4uYdE for ; Tue, 17 Dec 2019 06:29:24 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 96835120A05 for ; Tue, 17 Dec 2019 06:29:24 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id z76so5380476qka.2 for ; Tue, 17 Dec 2019 06:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=jGxjd999Ns1+NrfSgWoadbL3VkngNbERPcxirHvxltk=; b=GdKXkyL2Evu3IzSo4HQq1BP8RGBThWTg9JCI5GdsnZ9fkJSMmEEA8S9Ev9879+xrOx 8qV8GBpgHhG//hbKa6I8WYNiI39QVUzwj2WsSrhJxAC7amZZ6WUhl2jgcWw8jZRMYdXj Ssl9fv8pwpHL+JexltY4usLk/LqWIxF2S8iETjZvlV+Ords/6ZPU4HE8Gkg6BD+PmRc8 l1nQ52shsNYRIoDs/r4aSOuBkz8aro9kp2O8dvknEng8bs2kdh7wTHtjKrilJIR/J/nN Po0CHAXGB16/IvYKA9pZVRN04gw7HaPA3HG293VzgIeNH7vrmjwEKQpBmSkdH2yps9Xi jKzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jGxjd999Ns1+NrfSgWoadbL3VkngNbERPcxirHvxltk=; b=TGIFXSXlmrFvUzQd1acw72KiT8NAmzO7aAgY/nNjfl9tz7z9ZGg7bPGreDBsVQebis PatgSzXEBoV8XYkt7jd2a7UJhwpcuV1VrJ9Z0j76rn5m/s5yTnfc4GCQ5ajUJLzviabL QAWgld9i99IkPLDSSBw/zyGpUnAOWFuW8KknqyEtzHJdJUTzEyKZTU5kpXBT86VL6iQJ PEmhm1lxoW5oGNg+kO7GCbauiHw3/u0Hkpp8lQbb+0XT7hWT/zza4RJyuCAOB1G3VqnP w3QT0r5fK+MUzNbRESWTLIulNZxc+Y+xjRW6captzzgLD9U0XLWSEblmgctCBprouvKt BaYA==
X-Gm-Message-State: APjAAAV4mzX+na7FjNpbhrD4HJZxMRbMuKIMB11wDbz0GPIAXii67aP0 OmybHuBn7T+AyQO1QCSpJ650uwwI7+Q=
X-Google-Smtp-Source: APXvYqxNaRnisBUJ4MwWvxMNXb/nVXfE6y9R+/YYZ8gbU1LmYhSG5fb7eURkNkcPIJRXdaN+wcH9lg==
X-Received: by 2002:a37:4d45:: with SMTP id a66mr5406540qkb.65.1576592962179;  Tue, 17 Dec 2019 06:29:22 -0800 (PST)
Received: from [172.31.98.33] (rrcs-74-142-241-228.central.biz.rr.com. [74.142.241.228]) by smtp.gmail.com with ESMTPSA id z28sm8308253qtz.69.2019.12.17.06.29.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 06:29:21 -0800 (PST)
To: gorry@erg.abdn.ac.uk, "tcpm@ietf.org" 
References: <5D669BDA.3000506@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: 
Date: Tue, 17 Dec 2019 09:29:19 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D669BDA.3000506@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2019 14:29:27 -0000

Hi Gorry, I've been applying all of the editorial comments from your 
review, and they should show up in an update later this week.

There are some of them that I had quick responses to.


> ---
> OLD:
>   An "XXX" indicates a segment which is lost or rejected.
> - rejected seems odd here.
> NEW:
>   An "XXX" indicates a segment that is lost (not processed by the 
> receiving TCP endpoint).

Strangely, it seems like in 793, the "XXX" is explained, but never 
occurs otherwise in the text or diagrams.  I think we can just remove 
this sentence entirely?


> multiple OLD: "TCPs" and "a TCP"
> - This use of a "TCP" as an entity read as very ugly to me. I had to 
> read the sentences several times to parse them, could we explain that 
> we mean, i.e. "TCP endpoints" or "TCP implementations" etc. (usually 
> this seems to mean implementation). 
I'm fine with doing this.  It's a lot of changes though, so I wanted to 
quickly see if anyone strongly disagrees with doing this.


> OLD:
>    SYN (pun intended)
> - I didn't see the pun, can this be explained or omitted?

I think the intent from Jon (or whoever originally wrote this part) was 
"original sin".  We should probably remove this anyways in order to 
avoid cultural references that may not be understood by everyone.



From nobody Tue Dec 17 06:55:49 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7376120852 for ; Tue, 17 Dec 2019 06:55:46 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_NONE=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 KWfK2cwQVccX for ; Tue, 17 Dec 2019 06:55:44 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id C4CAB1201A3 for ; Tue, 17 Dec 2019 06:55:44 -0800 (PST)
Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:bcc7:9be3:9906:f232]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 906DD1B00244; Tue, 17 Dec 2019 14:55:40 +0000 (GMT)
To: Wesley Eddy , "tcpm@ietf.org" 
References: <5D669BDA.3000506@erg.abdn.ac.uk> 
From: Gorry Fairhurst 
Message-ID: <3c9adea8-5224-b6eb-cab3-4adedf8368b7@erg.abdn.ac.uk>
Date: Tue, 17 Dec 2019 14:55:40 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2019 14:55:47 -0000

On 17/12/2019 14:29, Wesley Eddy wrote:
> Hi Gorry, I've been applying all of the editorial comments from your 
> review, and they should show up in an update later this week.
>
> There are some of them that I had quick responses to.
>
>
>> ---
>> OLD:
>>   An "XXX" indicates a segment which is lost or rejected.
>> - rejected seems odd here.
>> NEW:
>>   An "XXX" indicates a segment that is lost (not processed by the 
>> receiving TCP endpoint).
>
> Strangely, it seems like in 793, the "XXX" is explained, but never 
> occurs otherwise in the text or diagrams.  I think we can just remove 
> this sentence entirely?
>
>
>> multiple OLD: "TCPs" and "a TCP"
>> - This use of a "TCP" as an entity read as very ugly to me. I had to 
>> read the sentences several times to parse them, could we explain that 
>> we mean, i.e. "TCP endpoints" or "TCP implementations" etc. (usually 
>> this seems to mean implementation). 
> I'm fine with doing this.  It's a lot of changes though, so I wanted 
> to quickly see if anyone strongly disagrees with doing this.
>
>
>> OLD:
>>    SYN (pun intended)
>> - I didn't see the pun, can this be explained or omitted?
>
> I think the intent from Jon (or whoever originally wrote this part) 
> was "original sin".  We should probably remove this anyways in order 
> to avoid cultural references that may not be understood by everyone.
>

Understood. That sounds fine. I'm sure you'll do the correct thing,

Gorry



From nobody Tue Dec 17 08:49:12 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0D0120B54 for ; Tue, 17 Dec 2019 08:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 KETZIknHfubJ for ; Tue, 17 Dec 2019 08:49:07 -0800 (PST)
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 9E206120B4E for ; Tue, 17 Dec 2019 08:49:07 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xBHGn01q098281; Tue, 17 Dec 2019 08:49:01 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xBHGn05i098280; Tue, 17 Dec 2019 08:49:00 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" 
Message-Id: <201912171649.xBHGn05i098280@gndrsh.dnsmgr.net>
In-Reply-To: 
To: Wesley Eddy 
Date: Tue, 17 Dec 2019 08:49:00 -0800 (PST)
CC: gorry@erg.abdn.ac.uk, "tcpm@ietf.org" 
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: 
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2019 16:49:12 -0000

> Hi Gorry, I've been applying all of the editorial comments from your 
> review, and they should show up in an update later this week.
> 
> There are some of them that I had quick responses to.

Some feedback on inteneded actions.

> 
> > ---
> > OLD:
> > ? An "XXX" indicates a segment which is lost or rejected.
> > - rejected seems odd here.
> > NEW:
> > ? An "XXX" indicates a segment that is lost (not processed by the 
> > receiving TCP endpoint).
> 
> Strangely, it seems like in 793, the "XXX" is explained, but never 
> occurs otherwise in the text or diagrams.? I think we can just remove 
> this sentence entirely?

Searching 761 (obsoleted by 793) I see the same text, definition of XXX,
but no usage.  I suspect a diagram was revised, dropping out the XXX
and the refering text was not updated.

> 
> > multiple OLD: "TCPs" and "a TCP"
> > - This use of a "TCP" as an entity read as very ugly to me. I had to 
> > read the sentences several times to parse them, could we explain that 
> > we mean, i.e. "TCP endpoints" or "TCP implementations" etc. (usually 
> > this seems to mean implementation). 
> I'm fine with doing this.? It's a lot of changes though, so I wanted to 
> quickly see if anyone strongly disagrees with doing this.

This has always bothered me in documents that use TCP in this manner,
though I believe it goes beyond RFC793, correcting it here may be a
good idea, though making sure that all the corrections are right
shall take a keen editorial eye.

> 
> > OLD:
> > ?? SYN (pun intended)
> > - I didn't see the pun, can this be explained or omitted?
> 
> I think the intent from Jon (or whoever originally wrote this part) was 
> "original sin".? We should probably remove this anyways in order to 
> avoid cultural references that may not be understood by everyone.

Agreed, Pun's are fine on email lists and in personal communications,
they however do not have a place in standards documents.

--
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Tue Dec 17 09:12:29 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63427120220 for ; Tue, 17 Dec 2019 09:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 WjxJeIy-GZbD for ; Tue, 17 Dec 2019 09:12:26 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 2B511120B80 for ; Tue, 17 Dec 2019 09:12:26 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id j5so9273215qtq.9 for ; Tue, 17 Dec 2019 09:12:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=KrWqjCIjqJNUCUV0w1jR2By8De2J4tnLno+Z81MeulQ=; b=sa3aYk8uondXMNO3qWPQRxFiFGRQpniH84IUq+UUSb+4ie+yZOli02D2Yg4RSZKjKD bVUvTWIuZdMAe/CK/JqwO7w+5ClkBDdnho7H9j84cqNloa3fsfS0NTE3EWe4wRA9t7Dj HLqKJFyEoRfLcC3CdE/tdPrsf9/GfV3u4K7r9P0al5HcCNXWmj1chAN1ijYaHbOCLsnO suZKg5dEKG254dIjnBjbyhhZlrRghAtFUVJD5SRAlilTZpDC+0fE6Zpg8qbbVe8t0oar duStpDjsk4nCtpmDZwdViEXmgBq2lp0mhtBGTj/Sy2O3hg3QO+HAtZwwlqZKgKisWKgr tY2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KrWqjCIjqJNUCUV0w1jR2By8De2J4tnLno+Z81MeulQ=; b=MIHIRTesEDOpNqxImBozchQCKiY3OrQT3GjtxE3NWDRTRjBBwOt5Z4UvPwn8yxU7zm aRNeCdylk9/cTfNj0J8onQ2sSFTV7M6vQ852KPt6yCyTmcjcIsqF35SNAx+f+NlP0HsD 478WcRF/8DE4YpJX1kB5eIjRpzcnxupuUrxfF8ZzOrqd2+GNgoDHWBQFkLfkf/3z0miq gbEsr5GEF4Jd4f/Bf9TM4/rEBw1yfFLXVkMCWHjKASXji3b4nnHruP4KHaFWXfIbhSYY 9duFi2iFTHGbo1nvonTWpFzji4IWPSXLH/y07vx+u78ph4G3PPwOclZJligbVIuQ0fQW dWIQ==
X-Gm-Message-State: APjAAAVxFMcM+YdbyPiM9B4c0LHP7Un3ZAzo3WRQpJFmd8XjiaKrw593 74hwaLvr5jN7HK5kxZs/cUiV065/CDI=
X-Google-Smtp-Source: APXvYqx3uLO4BdLp4y8WoMxeZgB/u6bdFLXqZFv81hlapvMwPUU+BRP/OFvTmy5xQHtlun2vTUIEew==
X-Received: by 2002:ac8:71cf:: with SMTP id i15mr5461587qtp.383.1576602745098;  Tue, 17 Dec 2019 09:12:25 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id y91sm8295859qtd.28.2019.12.17.09.12.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 09:12:24 -0800 (PST)
To: gorry@erg.abdn.ac.uk, "tcpm@ietf.org" 
References: <5D669BDA.3000506@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: <38ac444f-a709-9641-da53-2d242953c167@mti-systems.com>
Date: Tue, 17 Dec 2019 12:12:23 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D669BDA.3000506@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2019 17:12:28 -0000

I've been working on this comment a bit, and wanted to consult the 
wisdom of the working group:

On 8/28/2019 11:20 AM, Gorry Fairhurst wrote:
> I was amused at the frequent reference to "crash" or "crashing". I'm 
> not sure that presents the correct view of the IETf about the 
> stability of the TCP stack and certainly is not what IO would expect 
> in an RFC that could be promoted to full standard. I think this needs 
> to be changed. 


I was looking at the way "crash" is used on a case-by-case basis, and I 
think we could mostly change this to "endpoint failures" or a host 
"rebooting" rather than "crashing"?  Is there any other terminology or 
condition that should be explicitly mentioned somehow?  The important 
point in most places where "crash" is used is that the host has lost all 
of its memory about connections in-progress and associated connection 
state, and that's easy to retain without saying "crash".



From nobody Tue Dec 17 10:25:58 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB32120874 for ; Tue, 17 Dec 2019 10:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 DG07xkGUcFj5 for ; Tue, 17 Dec 2019 10:25:54 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 7AD9C120873 for ; Tue, 17 Dec 2019 10:25:54 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id j6so12085216lja.2 for ; Tue, 17 Dec 2019 10:25:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2pJC4QU1fY9ucttgMq/bhDZOvquW/PFVQ72CeN+/dmE=; b=Ht/dj5Dkx6y4DcUUBzNqpfm8WRix3p0do2IMMPpKf/BZaxeDZND+vj+HjgvHXHRblY sxMD/JgLsC6giJnrm4jq6nergQvD7tNRPe19epSi5yKVaj3K835nn9QRMLRFl7BBcABc PJkG2YJiooPkJQz3xEVuUuDPhjdo1CC4BYmAUU5B1HeEqsU68I2w7G1M2ajGDV+IzC7W uhdZ7M6Ag/BWJotYF3hqd9pP+3HwRWqpOxEkE3i4ebP3dVCTRQ5TKfhJpWTFDQuKq9aF 7l1bJLzOaGikgwjz8WIUFTRqz348iLcXZm/IPu7C62lzZ3Nb4cbKWiEpVqSRHB+qBOMq myBg==
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=2pJC4QU1fY9ucttgMq/bhDZOvquW/PFVQ72CeN+/dmE=; b=DJxlFqKUK1YQ+5CiPGFVlb6SIZHDv+brdi6vSaNeVsmZVXDCSxuEAi2ul11ReZXGIA LOwi4P16hui5x3NZDmL8l/PtTOGh4qQH3KAdhfJIP5bA6cuHLL+ikfUJp6c/CI7qIRZr 7aPFYKAja7vFbq/9YXjcFz5RoN3lnEPB1P0rhP29s/A+zotdcPSBNWEiMiV/MHto71HV yrdTiW4nsS5bF82iz0UKZFStHeIFBAZ/jkJ0k/4977Sf4Jigbtx8rlUOo/HWw2AM+6EP Q320UhukG79OrAvVBE9fagJzjMsJ4kbFiHsz/AQep4+ktRh4k3hywQxdJnanETyaLcQh fDvg==
X-Gm-Message-State: APjAAAXtrL7Q6eyLH60oJyOT4kBeprZ8RSsJZB3q3D47A52R8QsLf8z+ 6T46fW8MVl7+mjMHO69RGII=
X-Google-Smtp-Source: APXvYqwiiOwTYvg6L5i3C26YOjq1xNoSEwlDSvOqYBHg75loRCLIK5v7bYvT5W3i3jmlVW5J5FEhEw==
X-Received: by 2002:a2e:5843:: with SMTP id x3mr4217161ljd.64.1576607152533; Tue, 17 Dec 2019 10:25:52 -0800 (PST)
Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id k12sm6082800lfc.33.2019.12.17.10.25.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 10:25:51 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton 
In-Reply-To: <38ac444f-a709-9641-da53-2d242953c167@mti-systems.com>
Date: Tue, 17 Dec 2019 20:25:50 +0200
Cc: gorry@erg.abdn.ac.uk, "tcpm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5D669BDA.3000506@erg.abdn.ac.uk> <38ac444f-a709-9641-da53-2d242953c167@mti-systems.com>
To: Wesley Eddy 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2019 18:25:56 -0000

> On 17 Dec, 2019, at 7:12 pm, Wesley Eddy  wrote:
>=20
> I was looking at the way "crash" is used on a case-by-case basis, and =
I think we could mostly change this to "endpoint failures" or a host =
"rebooting" rather than "crashing"?  Is there any other terminology or =
condition that should be explicitly mentioned somehow?  The important =
point in most places where "crash" is used is that the host has lost all =
of its memory about connections in-progress and associated connection =
state, and that's easy to retain without saying "crash".

I think using "reboot" would be a good substitute here.

 - Jonathan Morton=


From nobody Tue Dec 17 10:31:42 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B67B120C79 for ; Tue, 17 Dec 2019 10:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 Ki5nqVqWzad8 for ; Tue, 17 Dec 2019 10:31:40 -0800 (PST)
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 C8C111209DF for ; Tue, 17 Dec 2019 10:31:40 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xBHIVcem098563; Tue, 17 Dec 2019 10:31:38 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xBHIVctl098562; Tue, 17 Dec 2019 10:31:38 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" 
Message-Id: <201912171831.xBHIVctl098562@gndrsh.dnsmgr.net>
In-Reply-To: 
To: Jonathan Morton 
Date: Tue, 17 Dec 2019 10:31:38 -0800 (PST)
CC: Wesley Eddy , "tcpm@ietf.org" 
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: 
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2019 18:31:41 -0000

> > On 17 Dec, 2019, at 7:12 pm, Wesley Eddy  wrote:
> > 
> > I was looking at the way "crash" is used on a case-by-case basis, and I think we could mostly change this to "endpoint failures" or a host "rebooting" rather than "crashing"?  Is there any other terminology or condition that should be explicitly mentioned somehow?  The important point in most places where "crash" is used is that the host has lost all of its memory about connections in-progress and associated connection state, and that's easy to retain without saying "crash".
> 
> I think using "reboot" would be a good substitute here.

Or define CRASH as terminology:

CRASH:	Lost of state by an endpoint, which may be the result of a reboot, power failure, software failure or any other mechanisim.

Then you can leave all the other text as is, and just s/crash/CRASH/g


>  - Jonathan Morton

--
Rod Grimes                                                 rgrimes@freebsd.org


From nobody Tue Dec 17 15:01:06 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09027120100 for ; Tue, 17 Dec 2019 15:00:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 jmQYXA2QB-Jg for ; Tue, 17 Dec 2019 15:00:49 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138D11200D6 for ; Tue, 17 Dec 2019 15:00:49 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7EB1625A1A for ; Wed, 18 Dec 2019 00:00:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1576623647; bh=zKGdpx1Vy9oTFLD0FKmb3/5ZUXnGP9jBCfRF3s/hGYg=; h=From:To:Subject:Date:From; b=Dlxy3yK9A8wHLuI7aMyPI97Ru7KuL8PBGgfGPGNIBJbv4jrqwHPOh5wewfGkRypZi 9f7X2flMp2IF4XvFyM62wTdsfr68zj3XgKFUOCRaXMblWv0cATgPkBOk8E/O/00XyP OQyuyILwf3K13XDmnHkq9usFfqMRIkRN/DsO0Voo=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCIbl9MLT2xg for ; Wed, 18 Dec 2019 00:00:45 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Wed, 18 Dec 2019 00:00:45 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.242]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Wed, 18 Dec 2019 00:00:45 +0100
From: "Scharf, Michael" 
To: tcpm IETF list 
Thread-Topic: Follow-up questions on allocating reserved TCP header bits
Thread-Index: AdW1LdAUeKqWjjxKQwah/eH8sS7TVA==
Date: Tue, 17 Dec 2019 23:00:44 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D854280@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D854280rznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] Follow-up questions on allocating reserved TCP header bits
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2019 23:00:54 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2D854280rznt8114rzntrzd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpBcyBjaGFpciwgSSBoYXZlIHN0b3BwZWQgdGhlIGRpc2N1c3Npb24gb24gYWRv
cHRpb24gb2YgZHJhZnQta3VlaGxld2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwIGR1cmluZyBJ
RVRGIDEwNi4gSSBzdGFuZCBieSBteSBkZWNpc2lvbiB0aGF0IFRDUE0gZG9lcyBub3QgZGlzY3Vz
cyBhZG9wdGlvbiBvZiBhbnkgZG9jdW1lbnQgc3VibWl0dGVkIGFmdGVyIHRoZSBjdXRvZmYgZGVh
ZGxpbmUuDQoNClRoZSByZW1haW5kZXIgb2YgdGhpcyBlLW1haWwgaXMgd3JpdHRlbiBhcyBpbmRp
dmlkdWFsIGNvbnRyaWJ1dG9yIGluIG9yZGVyIHRvIGZhY2lsaXRhdGUgYSBsaXN0IGRpc2N1c3Np
b24gYWJvdXQgcG90ZW50aWFsIGZvbGxvdy11cCBzdGVwcyBpbiB0aGlzIHNwYWNlLCBpZiB0aGV5
IHdlcmUgbmVlZGVkLg0KDQpJdCBpcyB3ZWxsLWtub3duIHRoYXQgYSB1c2UgY2FzZSBmb3IgZHJh
ZnQta3VlaGxld2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwIGNvdWxkIGJlIGRyYWZ0LWlldGYt
dGNwbS1hY2N1cmF0ZS1lY24uIElmIElFVEYgZGVjaWRlcyB0byBwdWJsaXNoIHRoZSBBY2NFQ04g
c3BlYyBvbiBTdGFuZGFyZHMgVHJhY2ssIHRoZSBBY2NFQ04gSS1EIGNhbiBkaXJlY3RseSByZWdp
c3RlciBUQ1AgaGVhZGVyIGJpdCA3IGFjY29yZGluZyB0byB0aGUgZXhpc3RpbmcgcmVnaXN0cnkg
cG9saWN5IGRlZmluZWQgaW4gUkZDIDI3ODAuIEluIHRoYXQgY2FzZSwgbm8gY2hhbmdlIG9mIHJl
Z2lzdHJhdGlvbiBwb2xpY2llcyBpcyBuZWVkZWQgdG8gZmluaXNoIGRyYWZ0LWlldGYtdGNwbS1h
Y2N1cmF0ZS1lY24uIFRoZSB0YXJnZXQgc3RhdHVzIG9mIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0
ZS1lY24gaXMgY3VycmVudGx5IHVuZGVyIGRpc2N1c3Npb24gYW5kIHRoZXJlIGlzIGEgbWFpbGlu
ZyBsaXN0IHRocmVhZCBmb3IgdGhhdDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo
L21zZy90Y3BtLzRPQjJaSUl2SUJYNVhYT2xlR084WWpQNjRwUQ0KDQpXaGlsZSB0aGUgb3V0Y29t
ZSBpcyBzdGlsbCB0byBiZSBkZXRlcm1pbmVkLCBJIGFzc3VtZSBmb3IgdGhlIHJlc3Qgb2YgdGhp
cyBlLW1haWwgdGhhdCBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuIGNhbiByZWdpc3RlciBi
aXQgNyB3aXRob3V0IHJlcXVpcmluZyBhIGRvY3VtZW50IGxpa2UgZHJhZnQta3VlaGxld2luZC10
Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwLiBUaGVuIHRoZSByZW1haW5pbmcgcXVlc3Rpb24gaXMgd2hl
dGhlciBmdXJ0aGVyIHN0YW5kYXJkaXphdGlvbiBpcyBuZWVkZWQsIGUuZy4sIGZvciBiaXRzIDQs
IDUsIGFuZCA2IGluIHRoZSBUQ1AgaGVhZGVyLiBJZiB0aGUgQWNjRUNOIHNwZWNpZmljYXRpb24g
c3RheXMgZXhwZXJpbWVudGFsLCBhIHNvbHV0aW9uIGZvciBiaXQgNyBtYXkgYmUgbmVlZGVkLCBi
dXQgdGhhdCBhbGxvY2F0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGhhdmUgdG8gYmUgaWRlbnRp
Y2FsIHRvIHRoZSBoYW5kbGluZyBvZiBvdGhlciByZXNlcnZlZCBiaXRzLiBTbyBldmVuIGluIHRo
YXQgY2FzZSB0aGVyZSBhcmUgYSBudW1iZXIgb2Ygb3BlbiBxdWVzdGlvbnMuDQoNCg0KSSBiZWxp
ZXZlIGZ1cnRoZXIgbGlzdCBkaXNjdXNzaW9uIHdvdWxkIGJlIHVzZWZ1bCByZWdhcmRpbmcgdGhl
IGZvbGxvd2luZyBxdWVzdGlvbnMsIHdoaWNoIGFyZSBub3QgZW50aXJlbHkgb3J0aG9nb25hbCwg
YnV0IGRlYWwgd2l0aCBkaWZmZXJlbnQgYXNwZWN0czoNCg0KDQpRdWVzdGlvbiAxOiBTaG91bGQg
YW4gSUFOQSByZWdpc3RyeSBiZSBjcmVhdGVkIGZvciBiaXRzIDQsIDUsIGFuZCA2IHdpdGggc3Rh
dHVzICJSZXNlcnZlZCIsIHdoaWNoIGFyZSBtaXNzaW5nIG9uIGh0dHBzOi8vd3d3LmlhbmEub3Jn
L2Fzc2lnbm1lbnRzL3RjcC1oZWFkZXItZmxhZ3MvdGNwLWhlYWRlci1mbGFncy54aHRtbD8NCg0K
ICBEaXNjdXNzaW9uOg0KDQogIFRoaXMgaGFzIGFscmVhZHkgYmVlbiBwcm9wb3NlZCBiZWZvcmUu
IEl0IGNvdWxkIHBlcmhhcHMganVzdCBiZSBzb3J0ZWQgb3V0IGJ5IDc5M2JpcywgYXMgbG9uZyBh
cyB0aGUgcmVnaXN0cmF0aW9uIHByb2NlZHVyZSAiU3RhbmRhcmRzIEFjdGlvbiIgaXMgbm90IG1v
ZGlmaWVkIGNvbXBhcmVkIHRvIFJGQyAyNzgwLg0KDQoNClF1ZXN0aW9uIDI6IFNob3VsZCB0aGUg
SUFOQSByZWdpc3RyeSBtb3ZlIHRvIGEgc3ViLXJlZ2lzdHJ5IG9uIHRoZSBUcmFuc21pc3Npb24g
Q29udHJvbCBQcm90b2NvbCAoVENQKSBQYXJhbWV0ZXJzIHBhZ2UgKGh0dHBzOi8vd3d3LmlhbmEu
b3JnL2Fzc2lnbm1lbnRzL3RjcC1wYXJhbWV0ZXJzL3RjcC1wYXJhbWV0ZXJzLnhodG1sKS4NCg0K
ICBEaXNjdXNzaW9uOg0KDQogIFRoaXMgd291bGQgbW9zdGx5IGJlIGEgY2xlYW4tdXAgdGhhdCBj
b3VsZCBwb3NzaWJseSBiZSBkb25lIGJ5IDc5M2JpcyBhcyB3ZWxsLg0KDQoNClF1ZXN0aW9uIDM6
IFNob3VsZCBwYXN0IChhbmQgY3VycmVudCkgdXNlIG9mIGJpdHMgYmUgZG9jdW1lbnRlZCBpbiB0
aGUgSUFOQSByZWdpc3RyeSwgYW5kLCBpZiBzbywgaG93Pw0KDQogIERpc2N1c3Npb246DQoNCiAg
ZHJhZnQta3VlaGxld2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwIHByb3Bvc2VzICJhc3NpZ25t
ZW50cyBiYXNlZCBvbiBleHBlcmltZW50YWwgUkZDIHNob3VsZCBiZSBtYXJrZWQgYXMgc3VjaCBp
biB0aGUgIkNvbW1lbnRzIiBmaWVsZCBhbmQgcG90ZW50aWFsbHkgZXZlbiBwcm92aWRlIGhpbnRz
IGFib3V0IHRoZSBuYXR1cmUgb2YgdGhlIGV4cGVyaW1lbnQgb3IgcHJvdmlkZSBhIHBvaW50ZXIg
dG8gYSBzZWN0aW9uIGluIGFuIFJGQyB3aGVyZSB0aGUgZXhwZXJpbWVudCBpcyBleHBsYWluZWQu
Ig0KDQogIE9uZSB1c2UgY2FzZSBmb3IgdGhpcyB3b3VsZCBiZSB0aGUgcGFzdCBhbGxvY2F0aW9u
IG9mIGJpdCA3IGJ5IEhpc3RvcmljIFtSRkMzNTQwXSwgd2hpY2ggaGFkIG5vIGtub3duIHVzZSBv
ciBpbXBsZW1lbnRhdGlvbi4gSWYgYml0IDcgZ2V0cyByZWFsbG9jYXRlZCBhbmQgcG9zc2libHkg
Z2V0cyBhbm90aGVyICJuYW1lIiwgaXQgaXMgYW4gb3BlbiBxdWVzdGlvbiB3aGV0aGVyIGFuZCBo
b3cgdGhlIHBhc3QgYWxsb2NhdGlvbiB3b3VsZCBuZWVkIHRvIGJlIGxpc3RlZCBpbiB0aGUgSUFO
QSByZWdpc3RyeS4NCg0KICBBbm90aGVyIHJlbGF0ZWQgcXVlc3Rpb24gbWF5IGJlIHdoZXRoZXIg
bm9uLVNZTiB1c2Ugb2YgdGhlIHR3byBSRkMzMTY4LUVDTiBiaXRzIGluIHRoZSBUQ1AgaGVhZGVy
IGRpZmZlcmVudCB0byBSRkMgMzE2OCBzaG91bGQgYmUgZG9jdW1lbnRlZCBpbiB0aGUgSUFOQSBy
ZWdpc3RyeS4NCg0KDQpRdWVzdGlvbiA0OiBJZiBhbnkgb2YgdGhlIGN1cnJlbnRseSByZXNlcnZl
ZCBUQ1AgaGVhZGVyIGJpdHMgd2lsbCBiZSB1c2VkIGluIGZ1dHVyZSwgc2hvdWxkIHRoZSBzcGVj
aWZpY2F0aW9uIHVzdWFsbHkgYmUgZXhwZXJpbWVudGFsIGZpcnN0Pw0KDQogIERpc2N1c3Npb246
DQoNCiAgVGhpcyBpcyBhbGwgYWJvdXQgSUVURiBwcm9jZXNzZXMuDQoNCiAgZHJhZnQta3VlaGxl
d2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwIHN0YXRlczogIlRoaXMgZHJhZnQgY2hhbmdlcyB0
aGUgcmVnaXN0cmF0aW9uIHBvbGljeSBvZiB0aGUgcmVnaXN0cmF0aW9uIHRvIElFVEYgUmV2aWV3
IGFzIHVzdWFsbHkgbmV3IFRDUCBtZWNoYW5pc21zIHRoYXQgY291bGQgdXNlIHRoZSByZW1haW5p
bmcgcmVzZXJ2ZWQgZmxhZ3Mgd2lsbCBiZSBmaXJzdCBzcGVjaWZpZWQgYXMgZXhwZXJpbWVudGFs
LiINCg0KICBGb3IgdGhlIHNha2Ugb2YgY29tcGxldGVuZXNzLCB0aGUgZGVmaW5pdGlvbiBvZiBF
eHBlcmltZW50YWwgY2FuIGJlIGZvdW5kIGluIHJlZmVyZW5jZSBbMV0sIHdoaWNoIGlzIGNvcGll
ZCBhdCB0aGUgZW5kIG9mIHRoZSBlLW1haWwuIEZ1cnRoZXIgZXhwbGFuYXRpb24gb24gdGhlIHVz
ZSBvZiBFeHBlcmltZW50YWwgUkZDcyBjYW4gYWxzbyBiZSBmb3VuZCBpbiBbMl0uIEluIHRoZSBj
b250ZXh0IG9mIHRoaXMgcXVlc3Rpb24sIGFsc28gdGhlIGRlZmluaXRpb24gb2YgcHJvcG9zZWQg
c3RhbmRhcmQgaW4gWzNdIG1heSBiZSByZWxldmFudCwgd2hpY2ggbWVudGlvbnMgdGhhdCB0aGUg
IklFU0cgbWF5IHJlcXVpcmUgaW1wbGVtZW50YXRpb24gYW5kL29yIG9wZXJhdGlvbmFsIGV4cGVy
aWVuY2UiIGZvciBhIFByb3Bvc2VkIFN0YW5kYXJkLg0KDQogIFRoaXMgbWF5IGNvbWUgZG93biB0
byB0aGUgcXVlc3Rpb24gd2hldGhlciB0aGUgSUVURiBzaG91bGQgaW4gZnV0dXJlIHNwZWNpZnkg
dXNlIG9mIFRDUCBoZWFkZXIgYml0cyBmb3IgZXhwZXJpbWVudHMgdGhhdCBoYXZlIG5vIGltcGxl
bWVudGF0aW9uIG9yIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UsIG9yIGZvciBwcm90b2NvbHMgdGhh
dCBjYW5ub3QgYmUgcHVibGlzaGVkIGFzIFBTIGZvciBvdGhlciByZWFzb25zIChlLmcuLCB0aGUg
Y2FzZXMgbWVudGlvbmVkIGluIHJlZmVyZW5jZSBbMl0pLg0KDQoNClF1ZXN0aW9uIDU6IFdoYXQg
c3RhbmRhcmRpemF0aW9uIHBvbGljeSB3b3VsZCBiZSBhcHByb3ByYXRlIGluc3RlYWQgb2YgIlN0
YW5kYXJkcyBBY3Rpb24iLCBpZiBhIGRvd25ncmFkZSBpcyBuZWVkZWQ/DQoNCiAgRGlzY3Vzc2lv
bjoNCg0KICBSRkMgODEyNiBkZWZpbmVzIGRpZmZlcmVudCBvcHRpb25zLg0KDQogIGRyYWZ0LWt1
ZWhsZXdpbmQtdGNwbS1mbGFncy1yZWdpc3RyeS0wMCBwcm9wb3NlcyAiSUVURiBSZXZpZXcgb3Ig
SUVTRyBBcHByb3ZhbCIuIEV2ZW4gaWYgdGhlcmUgd2FzIGNvbnNlbnN1cyB0byByZXBsYWNlIHRo
ZSBwb2xpY3kgIlN0YW5kYXJkcyBBY3Rpb24iIGluIFJGQyAyNzgwIGJ5IHNvbWV0aGluZyBlbHNl
LCBvbmUgY291bGQgZS5nLiBxdWVzdGlvbiB3aHkgIklFU0cgYXBwcm92YWwiIHdvdWxkIGluZGVl
ZCBiZSBhcHByb3ByaWF0ZSBmb3IgYSBwZXJtYW5lbnQgY2hhbmdlIG9mIG9uZSBvZiB0aGUgY29y
ZSBJbnRlcm5ldCBwcm90b2NvbHMuIFJGQyA4MTI2IGV4cGxhaW5zIHRoYXQgIklFU0cgQXBwcm92
YWwgaXMgbm90IGludGVuZGVkIHRvIGJlIHVzZWQgb2Z0ZW4gb3IgYXMgYSAiY29tbW9uIGNhc2Ui
OyBpbmRlZWQsIGl0IGhhcyBzZWxkb20gYmVlbiB1c2VkIGluIHByYWN0aWNlLiINCg0KDQpRdWVz
dGlvbiA2OiBIb3cgdG8gZGVhbCB3aXRoIGZ1dHVyZSBhbGxvY2F0aW9ucyBub3QgYmVpbmcgdXNl
ZD8NCg0KICBEaXNjdXNzaW9uOg0KDQogIEFzIHRoaXMgaXMgYSBub24tdHJpdmlhbCBxdWVzdGlv
biwgaGVyZSBpcyBhIGNvcHkgb2YgdGhlIHRleHQgaW4gZHJhZnQta3VlaGxld2luZC10Y3BtLWZs
YWdzLXJlZ2lzdHJ5LTAwOg0KDQogICBUaGVyZWZvcmUsIGFueSBleHBlcmltZW50YWwgUkZDIHRo
YXQgcmVnaXN0ZXJzIGEgcmVzZXJ2ZWQgZmxhZ3MgaW4NCiAgIHRoZSBUQ1AgZmxhZ3MgcmVnaXN0
cnkgTVVTVCBwcm92aWRlIHdheXMgdG8gYWx0ZXIgdGhlIHByb3Bvc2VkDQogICBtZWNoYW5pc20g
YXQgdGhlIGVuZCBvZiB0aGUgZXhwZXJpbWVudGFsIHBoYXNlIHdpdGhvdXQgdXNpbmcNCiAgIGFk
ZGl0aW9uYWwgVENQIGhlYWRlciBmbGFncy4gIEUuZy4gaXQgd291bGQgYmUgcG9zc2libGUgdG8g
YWRkIGFuDQogICBhZGRpdGlvbmFsIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBhZnRlciB0aGUgVENQ
IGhhbmRzaGFrZSB0aGF0IHdvdWxkDQogICBtYWtlIGl0IHBvc3NpYmxlIHRvIHVzZSBkaWZmZXJl
bnQgdmVyc2lvbnMgb2YgdGhlIGdlbmVyYWwgbWVjaGFuaXNtLw0KICAgZXh0ZW5zaW9uIHRoYXQg
d2FzIG5lZ290aWF0ZWQgb3IgaW5kaWNhdGVkIGR1cmluZyB0aGUgVENQIGhhbmRzaGFrZQ0KICAg
dXNpbmcgdGhlIG5ld2x5IGFzc2lnbmVkIGZsYWcuICBGdXJ0aGVyLCBhbnkgZXhwZXJpbWVudGFs
IGV4dGVuc2lvbg0KICAgU0hPVUxEIGRpc2N1c3Npb24gdGhlIHNjb3BlIG9mIHRoZSBleHBlcmlt
ZW50IGFuZCBwb3RlbnRpYWwgZmFpbHVyZQ0KICAgY2FzZXMgb3Igb3BlbiBxdWVzdGlvbnMgdGhh
dCBuZWVkIHRvIGJlIGFuc3dlcmVkIHdoZW4gcnVubmluZyB0aGUNCiAgIGV4cGVyaW1lbnQgYW5k
IGV4cGxhaW4gaG93IHRoZXNlIGNvdWxkIGJlIGFkZHJlc3NlZCBpbiBhbiB1cGRhdGVkDQogICB2
ZXJzaW9uLg0KDQogICBUQ1AgZmxhZ3MgY2FuIG9ubHkgYmUgZGUtYXNzaWduZWQgaWYgbm8gZGVw
bG95bWVudCBvZiBhbiBleHBlcmltZW50YWwNCiAgIGV4dGVuc2lvbiBoYXBwZW5lZC4gIFRoaXMg
c2hvdWxkIGJlIGV2YWx1YXRlZCBzb21lIHllYXJzIGFmdGVyIHRoZQ0KICAgYXNzaWdubWVudCB0
byBhbiBleHBlcmltZW50YWwgZXh0ZW5zaW9uLCBpbiBvcmRlciB0byBjaGFuZ2UgdGhlDQogICBy
ZWdpc3RyeSBlbnRyeSBiYWNrIHRvICJSRVNFUlZFRCIgYW5kIG1vdmUgdGhlIHJlc3BlY3RpdmUN
CiAgIGV4cGVyaW1lbnRhbCBSRkMgdG8gaGlzdG9yeSwgb3IgYXNzaWduIGl0IHBlcm1hbmVudGx5
Lg0KDQogIElmIG9uZSBnb2VzIGRvd24gdGhhdCByb2FkLCBvbmUgbWF5IHJ1biBpbnRvIGEgbnVt
YmVyIG9mIGZvbGxvdy11cCBxdWVzdGlvbnMsIHN1Y2ggYXM6DQoNCiAgUTYuMTogV2hhdCB3b3Vs
ZCBiZSB0aGUgZXhhY3Qgbm9ybWF0aXZlIHN0YXRlbWVudCB0aGF0IGV4cGVyaW1lbnRzIHdvdWxk
IG5lZWQgdG8gY29tcGx5IHRvPw0KDQogIFE2LjI6IEhvdyB3b3VsZCAiYWRkaXRpb25hbCBuZWdv
dGlhdGlvbiBtZWNoYW5pc21zIiB3b3JrIHJvYnVzdGx5LCBnaXZlbiB0aGF0IFRDUCBzdHJ1Z2ds
ZXMgd2l0aCByZWxpYWJseSB0cmFuc3BvcnRpbmcgY29udHJvbCBpbmZvcm1hdGlvbiBhZnRlciB0
aGUgU1lOPw0KDQogIFE2LjM6IFdvdWxkIGEgbmV3IGZvbGxvdy11cCB1c2VyIG9mIGEgYml0IG5l
ZWQgdG8gaW1wbGVtZW50IHRoZSBwcmV2aW91cyBmYWlsZWQgZXhwZXJpbWVudCB0byBtYWtlIHVz
ZSBvZiBzdWNoIGEgImFkZGl0aW9uYWwgbmVnb3RpYXRpb24gbWVjaGFuaXNtIj8NCg0KICBRNi40
OiBXb3VsZCB0aGVyZSBiZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugb24gaG93IGRlYWxsb2NhdGlvbiAi
c2hvdWxkIGJlIGV2YWx1YXRlZCBzb21lIHllYXJzIGFmdGVyIHRoZSBhc3NpZ25tZW50Ij8gSWYg
c28sIHdoYXQ/DQoNCiAgUTYuNTogSG93IHRvIGRlYWwgd2l0aCBwYXJ0aWFsIGRlcGxveW1lbnQg
b2YgYW4gZXhwZXJpbWVudCBlLmcuIG9ubHkgaW4gY29udHJvbGxlZCBlbnZpcm9ubWVudHMsIGJ1
dCBub3QgaW4gdGhlIG9wZW4gSW50ZXJuZXQ/IFdvdWxkIHRoZSBleHBlcmltZW50IHRoZW4gY29u
dGludWUgdXNpbmcgYW4gZXhwZXJpbWVudGFsIGJpdCBhbGxvY2F0aW9uLCBvciB3b3VsZCBhIGZv
bGxvdy11cCBQUyBiZSBuZWVkZWQgYWZ0ZXIgc29tZSB0aW1lLCBvciB3b3VsZCB0aGUgYWxsb2Nh
dGlvbiBiZSByZW1vdmVkPw0KDQoNClF1ZXN0aW9uIDc6IENvdWxkIG9uZSBvZiB0aGUgYml0cyA0
LCA1LCBvciA2IGJlIHJlZ2lzdGVyZWQgYnkgc2V2ZXJhbCBleHBlcmltZW50cyBpbiBwYXJhbGxl
bD8NCg0KICBEaXNjdXNzaW9uOg0KDQogIEFzIGFmdGVyIGFsbG9jYXRpb24gb2YgYml0IDcgb25s
eSB0aHJlZSByZXNlcnZlZCBiaXRzIGFyZSBsZWZ0LCBhbmQgdGhlcmUgYXJlIGFscmVhZHkgYSBu
dW1iZXIgb2YgcHJvcG9zYWxzIGZvciBvdGhlciB1c2UgY2FzZXMsIGluIGFkZGl0aW9uIHRvIHBs
ZW50eSByZXNlYXJjaCBwYXBlcnMgb24gVENQLCBhbmQgcHJvYmFibHkgbWFueSBtb3JlIHRvIGNv
bWUgaW4gZnV0dXJlLCBpdCBpcyBub3QgY2xlYXIgd2hldGhlciB0aGVyZSB3b3VsZCBiZSBlbm91
Z2ggYml0cyBpbiB0aGUgaGVhZGVyIGZvciBhbGwgZXhwZXJpbWVudGVycyBhbmQgcmVzZWFyY2hl
cnMgd2l0aG91dCBzb21lIGFkZGl0aW9uYWwgbWVjaGFuaXNtIG9mIGNvLWV4aXN0ZW5jZS4gRm9y
IGEgcHJvY2VzcyBkb2N1bWVudCwgdGhlIHF1ZXN0aW9uIGlzIGlmIGFuIElBTkEgcmVnaXN0cnkg
d291bGQgbmVlZCB0byBmb3Jlc2VlIG1vcmUgdGhhbiBvbmUgZXhwZXJpbWVudC4NCg0KDQpRdWVz
dGlvbiA4OiBIb3cgbWFueSBiaXRzIGNhbiByZWFzb25hYmx5IGJlIGFsbG9jYXRlZCBpbiB0aGUg
bmV4dCBmZXcgeWVhcnM/DQoNCiBEaXNjdXNzaW9uOg0KDQogIFRoaXMgaXMgbm90IGEgdGVjaG5p
Y2FsIGJ1dCBtb3JlIGEgc3RyYXRlZ2ljIHF1ZXN0aW9uLiBJdCBtYXkgYmUgbW9zdGx5IG9ydGhv
Z29uYWwgdG8gdGhlIGZvcm1hbCBwcm9jZXNzIGhvdyB0byBhbGxvY2F0ZSBiaXRzLCBidXQgZ2l2
ZW4gdGhhdCB0aGVyZSBhcmUgb25seSAzIG9yIDQgcmVzZXJ2ZWQgYml0cyBsZWZ0LCB0aGV5IGFy
ZSBhIHZlcnkgc2NhcmNlIHJlc291cmNlLiBCYXNlZCBvbiB0aGUgY3VycmVudCBsZXZlbCBvZiBk
ZXBsb3ltZW50IGFuZCB1c2Ugb2YgVENQLCBUQ1Agd2lsbCBwcm9iYWJseSBzdGlsbCBiZSBpbiB1
c2UgZm9yIHNldmVyYWwgZGVjYWRlcywgZXZlbiBpZiBzdWNjZXNzb3IgcHJvdG9jb2xzIG1heSB0
YWtlIG92ZXIgc2lnbmlmaWNhbnQgcGFydHMgb2YgdGhlIGN1cnJlbnQgVENQLWJhc2VkIHRyYWZm
aWMuIEdpdmVuIHRoYXQgZnV0dXJlIG5lZWRzIGluLCBzYXksIDIwIHllYXJzIGZyb20gbm93IGFy
ZSB1bmtub3duLCBpcyB0aGVyZSBhIHN0cmF0ZWdpYyBuZWVkIHRvIGtlZXAgYmFjayBzb21lIHJl
c2VydmVkIGJpdHMgZm9yIHRoZXNlIGZ1dHVyZSB1bmtub3duIG5lZWRzPyBJZiB0aGUgYW5zd2Vy
IGlzIHllcywgaXQgcmVxdWlyZXMgZGlzY3Vzc2lvbiB3aGV0aGVyIGNoYW5naW5nIHRoZSByZWdp
c3RyYXRpb24gcG9saWN5IGZvciBfYWxsXyBiaXRzIGlzIHN0cmF0ZWdpY2FsbHkgdGhlIHJpZ2h0
IGNvbmNlcHQgbm93LiBBbiBhbHRlcm5hdGl2ZSBjb3VsZCBiZSBlLmcuIHRvIGZvY3VzIGNoYW5n
ZXMgb25seSBvbiBhIHN1Yi1zZXQgb2YgdGhlIHJlbWFpbmluZyByZXNlcnZlZCBiaXRzIChpZiB0
aGVyZSB3YXMgYWN0dWFsbHkgYSBuZWVkIGZvciBhbnkgY2hhbmdlKS4NCg0KDQpRdWVzdGlvbiA5
OiBBbGwtaW4tb25lIHBvbGljeSBjaGFuZ2Ugbm93IG9yIGZ1dHVyZSBjYXNlLWJ5LWNhc2UgaGFu
ZGxpbmc/DQoNCiAgRGlzY3Vzc2lvbjoNCg0KICBJZiBiaXQgNyBjYW4gYmUgYXNzaWduZWQgd2l0
aG91dCBjaGFuZ2luZyB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeSwgaXQgaXMgdW5jbGVhciB3aGV0
aGVyIHRoZXJlIGlzIGluZGVlZCBhbiB1cmdlbnQgbmVlZCBmb3IgZnVydGhlciBjaGFuZ2VzIG9m
IHRoZSByZWdpc3RyYXRpb24gcG9saWN5LCBlLmcuLCBmb3IgYml0cyA0LCA1LCBhbmQgNi4gRm9y
IGluc3RhbmNlLCBhbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBzb3J0IG91dCBmdXR1cmUgYWxs
b2NhdGlvbiBvZiByZXNlcnZlZCBiaXRzIGNhc2UtYnktY2FzZSBvbmNlIHRoZSB1c2UgY2FzZSBp
cyB3ZWxsIHVuZGVyc3Rvb2QgYW5kIHRoZSBhZGRlZCB2YWx1ZSBvZiB1c2luZyBhIFRDUCBoZWFk
ZXIgYml0IGlzIGNsZWFyLCBhbmQgb25jZSBpdCBpcyBhbHNvIHVuZGVyc3Rvb2Qgd2h5IHRoZSBh
cHByb2FjaCBvZiBhIFBTIGlzIG5vdCBhcHBsaWNhYmxlIGZvciB0aGF0IGV4cGVyaW1lbnQuIEZv
ciBjYXNlLWJ5LWNhc2UgaGFuZGxpbmcsIG5vIGFsbC1pbi1vbmUgcG9saWN5IGNoYW5nZSB3b3Vs
ZCBiZSBuZWVkZWQgZm9yIHRoZSB0aW1lIGJlaW5nLg0KDQoNCkkgYmVsaWV2ZSB0aGUgVENQTSBj
b21tdW5pdHkgc2hvdWxkIGRpc2N1c3MgdGhlc2UgcXVlc3Rpb25zIGluIG9yZGVyIHRvIHVuZGVy
c3RhbmQgd2hldGhlciBzb21lIG5ldyBkb2N1bWVudCBpcyBuZWVkZWQsIGFuZCwgaWYgc28sIHdo
YXQgaXQgc2hvdWxkIGNvbnRhaW4uIEZvcm1hbCBwcm9jZWR1cmUgZG9jdW1lbnRzIGNhbiBiZSBz
aG9ydCwgYnV0IHRoZSBleGFjdCB3b3JkaW5nIG1hdHRlcnMsIGFuZCBJIGJlbGlldmUgdGhlcmUg
YXJlIHF1aXRlIGEgbnVtYmVyIG9mIG5vbi10cml2aWFsIGRldGFpbHMuIEFuZCBjaGFuZ2VzIHRv
IHRoZSBtYWluIFRDUCBoZWFkZXIgc2hvdWxkIHByb2JhYmx5IGJlIGRpc2N1c3NlZCBjYXJlZnVs
bHkgYW5kIGJlIGJhY2tlZCBieSBzdHJvbmcgY29uc2Vuc3VzLg0KDQpUaHVzLCBmZWVsIGZyZWUg
dG8gY29tbWVudC4NCg0KTWljaGFlbCAod2l0aCBubyBoYXQpDQoNCg0KDQpSZWZlcmVuY2VzDQoN
ClsxXSBEZWZpbml0aW9uIG9mIGFuIEV4cGVyaW1lbnRhbCBSRkMgaW4gUkZDIDIwMjYNCg0KPC9z
bmlwPg0KNC4yLjEgIEV4cGVyaW1lbnRhbA0KDQogICBUaGUgIkV4cGVyaW1lbnRhbCIgZGVzaWdu
YXRpb24gdHlwaWNhbGx5IGRlbm90ZXMgYSBzcGVjaWZpY2F0aW9uIHRoYXQNCiAgIGlzIHBhcnQg
b2Ygc29tZSByZXNlYXJjaCBvciBkZXZlbG9wbWVudCBlZmZvcnQuICBTdWNoIGEgc3BlY2lmaWNh
dGlvbg0KICAgaXMgcHVibGlzaGVkIGZvciB0aGUgZ2VuZXJhbCBpbmZvcm1hdGlvbiBvZiB0aGUg
SW50ZXJuZXQgdGVjaG5pY2FsDQogICBjb21tdW5pdHkgYW5kIGFzIGFuIGFyY2hpdmFsIHJlY29y
ZCBvZiB0aGUgd29yaywgc3ViamVjdCBvbmx5IHRvDQogICBlZGl0b3JpYWwgY29uc2lkZXJhdGlv
bnMgYW5kIHRvIHZlcmlmaWNhdGlvbiB0aGF0IHRoZXJlIGhhcyBiZWVuDQogICBhZGVxdWF0ZSBj
b29yZGluYXRpb24gd2l0aCB0aGUgc3RhbmRhcmRzIHByb2Nlc3MgKHNlZSBiZWxvdykuICBBbg0K
ICAgRXhwZXJpbWVudGFsIHNwZWNpZmljYXRpb24gbWF5IGJlIHRoZSBvdXRwdXQgb2YgYW4gb3Jn
YW5pemVkIEludGVybmV0DQogICByZXNlYXJjaCBlZmZvcnQgKGUuZy4sIGEgUmVzZWFyY2ggR3Jv
dXAgb2YgdGhlIElSVEYpLCBhbiBJRVRGIFdvcmtpbmcNCiAgIEdyb3VwLCBvciBpdCBtYXkgYmUg
YW4gaW5kaXZpZHVhbCBjb250cmlidXRpb24uDQo8L3NuaXA+DQoNCg0KWzJdIElFU0cgZ3VpZGVs
aW5lcyBmb3IgRXhwZXJpbWVudGFsIFJGQ3Mgb24gaHR0cHM6Ly9pZXRmLm9yZy9zdGFuZGFyZHMv
cHJvY2Vzcy9pbmZvcm1hdGlvbmFsLXZzLWV4cGVyaW1lbnRhbC8NCg0KPHNuaXA+DQpUaGUgZm9s
bG93aW5nIHNldCBvZiBndWlkZWxpbmVzIHdpbGwgYmUgdXNlZCBieSB0aGUgSUVTRy4gVGhlIGxp
c3QgaXMgcmVhZCBmcm9tIHRvcCB0byBib3R0b207IHRoZSBmaXJzdCBvbmUgdGhhdCBzZWVtcyB0
byBhcHBseSBpcyBwcm9iYWJseSB0aGUgb25lIHRoYXQgbWFrZXMgc2Vuc2UgdG8gZm9sbG93Lg0K
DQpbLi4uXQ0KDQo0LiBJZiB0aGUgSUVURiBtYXkgcHVibGlzaCBzb21ldGhpbmcgYmFzZWQgb24g
dGhpcyBvbiB0aGUgc3RhbmRhcmRzIHRyYWNrIG9uY2Ugd2Uga25vdyBob3cgd2VsbCB0aGlzIG9u
ZSB3b3JrcywgaXQncyBFeHBlcmltZW50YWwuIFRoaXMgaXMgdGhlIHR5cGljYWwgY2FzZSBvZiBu
b3QgYmVpbmcgYWJsZSB0byBkZWNpZGUgd2hpY2ggcHJvdG9jb2wgaXMgImJldHRlciIgYmVmb3Jl
IHdlIGhhdmUgZXhwZXJpZW5jZSBvZiBkZWFsaW5nIHdpdGggdGhlbSBmcm9tIGEgc3RhYmxlIHNw
ZWNpZmljYXRpb24uIENhc2UgaW4gcG9pbnQ6ICJQR00gUmVsaWFibGUgVHJhbnNwb3J0IFByb3Rv
Y29sIFNwZWNpZmljYXRpb24iIChSRkMgMzIwOCkNCg0KNS4gSWYgdGhlIGRvY3VtZW50IGNvbnRh
aW5zIGltcGxpY2l0IG9yIGV4cGxpY2l0IHN1Y2Nlc3MvZmFpbHVyZSBjcml0ZXJpYSwgYW5kIGl0
J3MgY2xlYXIgdGhhdCB0aGUgb3V0Y29tZSBjYW4gYmUgdXNlZCBhcyB0aGUgYmFzaXMgZm9yIGEg
cmVjb21tZW5kYXRpb24gdG8gdGhlIElFVEYgY29tbXVuaXR5LCBpdCdzIEV4cGVyaW1lbnRhbC4g
Q2FzZSBpbiBwb2ludDogUkZDIDE3OTcgIkNsYXNzIEEgU3VibmV0IEV4cGVyaW1lbnQiIHdoaWNo
IGxlZCB0byBSRkMgMTg3OSAiQ2xhc3MgQSBTdWJuZXQgRXhwZXJpbWVudCBSZXN1bHRzIGFuZCBS
ZWNvbW1lbmRhdGlvbnMiDQo8L3NuaXA+DQoNCg0KWzNdIERlZmluaXRpb24gb2YgYSBQcm9wb3Nl
ZCBTdGFuZGFyZCBpbiBSRkMgNzEyNw0KDQo8c25pcD4NCjMuMS4gIENoYXJhY3Rlcml6YXRpb24g
b2YgSUVURiBQcm9wb3NlZCBTdGFuZGFyZCBTcGVjaWZpY2F0aW9ucw0KDQogICBUaGUgZW50cnkt
bGV2ZWwgbWF0dXJpdHkgZm9yIHRoZSBzdGFuZGFyZHMgdHJhY2sgaXMgIlByb3Bvc2VkDQogICBT
dGFuZGFyZCIuICBBIHNwZWNpZmljIGFjdGlvbiBieSB0aGUgSUVTRyBpcyByZXF1aXJlZCB0byBt
b3ZlIGENCiAgIHNwZWNpZmljYXRpb24gb250byB0aGUgc3RhbmRhcmRzIHRyYWNrIGF0IHRoZSAi
UHJvcG9zZWQgU3RhbmRhcmQiDQogICBsZXZlbC4NCg0KICAgQSBQcm9wb3NlZCBTdGFuZGFyZCBz
cGVjaWZpY2F0aW9uIGlzIHN0YWJsZSwgaGFzIHJlc29sdmVkIGtub3duDQogICBkZXNpZ24gY2hv
aWNlcywgaGFzIHJlY2VpdmVkIHNpZ25pZmljYW50IGNvbW11bml0eSByZXZpZXcsIGFuZA0KICAg
YXBwZWFycyB0byBlbmpveSBlbm91Z2ggY29tbXVuaXR5IGludGVyZXN0IHRvIGJlIGNvbnNpZGVy
ZWQgdmFsdWFibGUuDQoNCiAgIFVzdWFsbHksIG5laXRoZXIgaW1wbGVtZW50YXRpb24gbm9yIG9w
ZXJhdGlvbmFsIGV4cGVyaWVuY2UgaXMNCiAgIHJlcXVpcmVkIGZvciB0aGUgZGVzaWduYXRpb24g
b2YgYSBzcGVjaWZpY2F0aW9uIGFzIGEgUHJvcG9zZWQNCiAgIFN0YW5kYXJkLiAgSG93ZXZlciwg
c3VjaCBleHBlcmllbmNlIGlzIGhpZ2hseSBkZXNpcmFibGUgYW5kIHdpbGwNCiAgIHVzdWFsbHkg
cmVwcmVzZW50IGEgc3Ryb25nIGFyZ3VtZW50IGluIGZhdm9yIG9mIGEgUHJvcG9zZWQgU3RhbmRh
cmQNCiAgIGRlc2lnbmF0aW9uLg0KDQogICBUaGUgSUVTRyBtYXkgcmVxdWlyZSBpbXBsZW1lbnRh
dGlvbiBhbmQvb3Igb3BlcmF0aW9uYWwgZXhwZXJpZW5jZQ0KICAgcHJpb3IgdG8gZ3JhbnRpbmcg
UHJvcG9zZWQgU3RhbmRhcmQgc3RhdHVzIHRvIGEgc3BlY2lmaWNhdGlvbiB0aGF0DQogICBtYXRl
cmlhbGx5IGFmZmVjdHMgdGhlIGNvcmUgSW50ZXJuZXQgcHJvdG9jb2xzIG9yIHRoYXQgc3BlY2lm
aWVzDQogICBiZWhhdmlvciB0aGF0IG1heSBoYXZlIHNpZ25pZmljYW50IG9wZXJhdGlvbmFsIGlt
cGFjdCBvbiB0aGUNCiAgIEludGVybmV0Lg0KDQogICBBIFByb3Bvc2VkIFN0YW5kYXJkIHdpbGwg
aGF2ZSBubyBrbm93biB0ZWNobmljYWwgb21pc3Npb25zIHdpdGgNCiAgIHJlc3BlY3QgdG8gdGhl
IHJlcXVpcmVtZW50cyBwbGFjZWQgdXBvbiBpdC4gIFByb3Bvc2VkIFN0YW5kYXJkcyBhcmUNCiAg
IG9mIHN1Y2ggcXVhbGl0eSB0aGF0IGltcGxlbWVudGF0aW9ucyBjYW4gYmUgZGVwbG95ZWQgaW4g
dGhlIEludGVybmV0Lg0KICAgSG93ZXZlciwgYXMgd2l0aCBhbGwgdGVjaG5pY2FsIHNwZWNpZmlj
YXRpb25zLCBQcm9wb3NlZCBTdGFuZGFyZHMgbWF5DQogICBiZSByZXZpc2VkIGlmIHByb2JsZW1z
IGFyZSBmb3VuZCBvciBiZXR0ZXIgc29sdXRpb25zIGFyZSBpZGVudGlmaWVkLA0KICAgd2hlbiBl
eHBlcmllbmNlcyB3aXRoIGRlcGxveWluZyBpbXBsZW1lbnRhdGlvbnMgb2Ygc3VjaCB0ZWNobm9s
b2dpZXMNCiAgIGF0IHNjYWxlIGlzIGdhdGhlcmVkLg0KPC9zbmlwPg0KDQo=

--_000_6EC6417807D9754DA64F3087E2E2E03E2D854280rznt8114rzntrzd_
Content-Type: text/html; charset="utf-8"
Content-ID: <2C16CC1B22F13444ABBCBD26B9AEAE33@exchange.hs-esslingen.de>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v
bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn
aW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUi
Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFs
bCw8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFzIGNoYWlyLCBJIGhhdmUgc3RvcHBlZCB0aGUgZGlzY3Vzc2lvbiBv
biBhZG9wdGlvbiBvZiBkcmFmdC1rdWVobGV3aW5kLXRjcG0tZmxhZ3MtcmVnaXN0cnktMDAgZHVy
aW5nIElFVEYgMTA2LiBJIHN0YW5kIGJ5IG15IGRlY2lzaW9uIHRoYXQgVENQTSBkb2VzIG5vdCBk
aXNjdXNzIGFkb3B0aW9uIG9mIGFueSBkb2N1bWVudCBzdWJtaXR0ZWQgYWZ0ZXIgdGhlIGN1dG9m
ZiBkZWFkbGluZS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZW1haW5kZXIgb2YgdGhpcyBlLW1haWwgaXMg
d3JpdHRlbiBhcyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yIGluIG9yZGVyIHRvIGZhY2lsaXRhdGUg
YSBsaXN0IGRpc2N1c3Npb24gYWJvdXQgcG90ZW50aWFsIGZvbGxvdy11cCBzdGVwcyBpbiB0aGlz
IHNwYWNlLCBpZiB0aGV5IHdlcmUgbmVlZGVkLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgd2VsbC1rbm93
biB0aGF0IGEgdXNlIGNhc2UgZm9yIGRyYWZ0LWt1ZWhsZXdpbmQtdGNwbS1mbGFncy1yZWdpc3Ry
eS0wMCBjb3VsZCBiZSBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLiBJZiBJRVRGIGRlY2lk
ZXMgdG8gcHVibGlzaCB0aGUgQWNjRUNOIHNwZWMgb24gU3RhbmRhcmRzIFRyYWNrLCB0aGUgQWNj
RUNOIEktRCBjYW4gZGlyZWN0bHkgcmVnaXN0ZXIgVENQIGhlYWRlciBiaXQgNyBhY2NvcmRpbmcN
CiB0byB0aGUgZXhpc3RpbmcgcmVnaXN0cnkgcG9saWN5IGRlZmluZWQgaW4gUkZDIDI3ODAuIElu
IHRoYXQgY2FzZSwgbm8gY2hhbmdlIG9mIHJlZ2lzdHJhdGlvbiBwb2xpY2llcyBpcyBuZWVkZWQg
dG8gZmluaXNoIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24uIFRoZSB0YXJnZXQgc3RhdHVz
IG9mIGRyYWZ0LWlldGYtdGNwbS1hY2N1cmF0ZS1lY24gaXMgY3VycmVudGx5IHVuZGVyIGRpc2N1
c3Npb24gYW5kIHRoZXJlIGlzIGEgbWFpbGluZyBsaXN0DQogdGhyZWFkIGZvciB0aGF0OiBodHRw
czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3RjcG0vNE9CMlpJSXZJQlg1WFhPbGVH
TzhZalA2NHBRPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSB0aGUgb3V0Y29tZSBpcyBzdGlsbCB0byBiZSBk
ZXRlcm1pbmVkLCBJIGFzc3VtZSBmb3IgdGhlIHJlc3Qgb2YgdGhpcyBlLW1haWwgdGhhdCBkcmFm
dC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuIGNhbiByZWdpc3RlciBiaXQgNyB3aXRob3V0IHJlcXVp
cmluZyBhIGRvY3VtZW50IGxpa2UgZHJhZnQta3VlaGxld2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5
LTAwLiBUaGVuIHRoZSByZW1haW5pbmcgcXVlc3Rpb24NCiBpcyB3aGV0aGVyIGZ1cnRoZXIgc3Rh
bmRhcmRpemF0aW9uIGlzIG5lZWRlZCwgZS5nLiwgZm9yIGJpdHMgNCwgNSwgYW5kIDYgaW4gdGhl
IFRDUCBoZWFkZXIuIElmIHRoZSBBY2NFQ04gc3BlY2lmaWNhdGlvbiBzdGF5cyBleHBlcmltZW50
YWwsIGEgc29sdXRpb24gZm9yIGJpdCA3IG1heSBiZSBuZWVkZWQsIGJ1dCB0aGF0IGFsbG9jYXRp
b24gZG9lcyBub3QgbmVjZXNzYXJpbHkgaGF2ZSB0byBiZSBpZGVudGljYWwgdG8gdGhlIGhhbmRs
aW5nIG9mDQogb3RoZXIgcmVzZXJ2ZWQgYml0cy4gU28gZXZlbiBpbiB0aGF0IGNhc2UgdGhlcmUg
YXJlIGEgbnVtYmVyIG9mIG9wZW4gcXVlc3Rpb25zLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgZnVydGhlciBsaXN0IGRp
c2N1c3Npb24gd291bGQgYmUgdXNlZnVsIHJlZ2FyZGluZyB0aGUgZm9sbG93aW5nIHF1ZXN0aW9u
cywgd2hpY2ggYXJlIG5vdCBlbnRpcmVseSBvcnRob2dvbmFsLCBidXQgZGVhbCB3aXRoIGRpZmZl
cmVudCBhc3BlY3RzOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5RdWVzdGlvbiAxOiBTaG91bGQgYW4gSUFOQSByZWdpc3RyeSBiZSBjcmVh
dGVkIGZvciBiaXRzIDQsIDUsIGFuZCA2IHdpdGggc3RhdHVzICZxdW90O1Jlc2VydmVkJnF1b3Q7
LCB3aGljaCBhcmUgbWlzc2luZyBvbiBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy90
Y3AtaGVhZGVyLWZsYWdzL3RjcC1oZWFkZXItZmxhZ3MueGh0bWw/PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsgRGlzY3Vzc2lvbjo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBUaGlzIGhhcyBhbHJlYWR5IGJlZW4g
cHJvcG9zZWQgYmVmb3JlLiBJdCBjb3VsZCBwZXJoYXBzIGp1c3QgYmUgc29ydGVkIG91dCBieSA3
OTNiaXMsIGFzIGxvbmcgYXMgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmUgJnF1b3Q7U3RhbmRh
cmRzIEFjdGlvbiZxdW90OyBpcyBub3QgbW9kaWZpZWQgY29tcGFyZWQgdG8gUkZDIDI3ODAuPC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1
ZXN0aW9uIDI6IFNob3VsZCB0aGUgSUFOQSByZWdpc3RyeSBtb3ZlIHRvIGEgc3ViLXJlZ2lzdHJ5
IG9uIHRoZSBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCAoVENQKSBQYXJhbWV0ZXJzIHBh
Z2UgKGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3RjcC1wYXJhbWV0ZXJzL3RjcC1w
YXJhbWV0ZXJzLnhodG1sKS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBEaXNjdXNzaW9uOjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7IFRoaXMgd291bGQgbW9zdGx5IGJlIGEgY2xlYW4tdXAgdGhhdCBjb3VsZCBw
b3NzaWJseSBiZSBkb25lIGJ5IDc5M2JpcyBhcyB3ZWxsLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RdWVzdGlvbiAzOiBTaG91bGQgcGFz
dCAoYW5kIGN1cnJlbnQpIHVzZSBvZiBiaXRzIGJlIGRvY3VtZW50ZWQgaW4gdGhlIElBTkEgcmVn
aXN0cnksIGFuZCwgaWYgc28sIGhvdz88L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBEaXNjdXNzaW9uOjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7IGRyYWZ0LWt1ZWhsZXdpbmQtdGNwbS1mbGFncy1yZWdpc3RyeS0w
MCBwcm9wb3NlcyAmcXVvdDthc3NpZ25tZW50cyBiYXNlZCBvbiBleHBlcmltZW50YWwgUkZDIHNo
b3VsZCBiZSBtYXJrZWQgYXMgc3VjaCBpbiB0aGUgJnF1b3Q7Q29tbWVudHMmcXVvdDsgZmllbGQg
YW5kIHBvdGVudGlhbGx5IGV2ZW4gcHJvdmlkZSBoaW50cyBhYm91dCB0aGUgbmF0dXJlIG9mIHRo
ZSBleHBlcmltZW50IG9yIHByb3ZpZGUgYSBwb2ludGVyIHRvIGEgc2VjdGlvbg0KIGluIGFuIFJG
QyB3aGVyZSB0aGUgZXhwZXJpbWVudCBpcyBleHBsYWluZWQuJnF1b3Q7PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsgT25lIHVzZSBjYXNlIGZvciB0aGlzIHdvdWxkIGJlIHRoZSBwYXN0IGFsbG9jYXRpb24g
b2YgYml0IDcgYnkgSGlzdG9yaWMgW1JGQzM1NDBdLCB3aGljaCBoYWQgbm8ga25vd24gdXNlIG9y
IGltcGxlbWVudGF0aW9uLiBJZiBiaXQgNyBnZXRzIHJlYWxsb2NhdGVkIGFuZCBwb3NzaWJseSBn
ZXRzIGFub3RoZXIgJnF1b3Q7bmFtZSZxdW90OywgaXQgaXMgYW4gb3BlbiBxdWVzdGlvbiB3aGV0
aGVyIGFuZCBob3cgdGhlIHBhc3QgYWxsb2NhdGlvbg0KIHdvdWxkIG5lZWQgdG8gYmUgbGlzdGVk
IGluIHRoZSBJQU5BIHJlZ2lzdHJ5LjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IEFub3RoZXIgcmVsYXRl
ZCBxdWVzdGlvbiBtYXkgYmUgd2hldGhlciBub24tU1lOIHVzZSBvZiB0aGUgdHdvIFJGQzMxNjgt
RUNOIGJpdHMgaW4gdGhlIFRDUCBoZWFkZXIgZGlmZmVyZW50IHRvIFJGQyAzMTY4IHNob3VsZCBi
ZSBkb2N1bWVudGVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RdWVzdGlvbiA0OiBJZiBhbnkgb2Yg
dGhlIGN1cnJlbnRseSByZXNlcnZlZCBUQ1AgaGVhZGVyIGJpdHMgd2lsbCBiZSB1c2VkIGluIGZ1
dHVyZSwgc2hvdWxkIHRoZSBzcGVjaWZpY2F0aW9uIHVzdWFsbHkgYmUgZXhwZXJpbWVudGFsIGZp
cnN0PzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IERpc2N1c3Npb246PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg
VGhpcyBpcyBhbGwgYWJvdXQgSUVURiBwcm9jZXNzZXMuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgZHJh
ZnQta3VlaGxld2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwIHN0YXRlczogJnF1b3Q7VGhpcyBk
cmFmdCBjaGFuZ2VzIHRoZSByZWdpc3RyYXRpb24gcG9saWN5IG9mIHRoZSByZWdpc3RyYXRpb24g
dG8gSUVURiBSZXZpZXcgYXMgdXN1YWxseSBuZXcgVENQIG1lY2hhbmlzbXMgdGhhdCBjb3VsZCB1
c2UgdGhlIHJlbWFpbmluZyByZXNlcnZlZCBmbGFncyB3aWxsIGJlIGZpcnN0IHNwZWNpZmllZCBh
cyBleHBlcmltZW50YWwuJnF1b3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgRm9yIHRoZSBzYWtlIG9m
IGNvbXBsZXRlbmVzcywgdGhlIGRlZmluaXRpb24gb2YgRXhwZXJpbWVudGFsIGNhbiBiZSBmb3Vu
ZCBpbiByZWZlcmVuY2UgWzFdLCB3aGljaCBpcyBjb3BpZWQgYXQgdGhlIGVuZCBvZiB0aGUgZS1t
YWlsLiBGdXJ0aGVyIGV4cGxhbmF0aW9uIG9uIHRoZSB1c2Ugb2YgRXhwZXJpbWVudGFsIFJGQ3Mg
Y2FuIGFsc28gYmUgZm91bmQgaW4gWzJdLiBJbiB0aGUgY29udGV4dCBvZiB0aGlzDQogcXVlc3Rp
b24sIGFsc28gdGhlIGRlZmluaXRpb24gb2YgcHJvcG9zZWQgc3RhbmRhcmQgaW4gWzNdIG1heSBi
ZSByZWxldmFudCwgd2hpY2ggbWVudGlvbnMgdGhhdCB0aGUgJnF1b3Q7SUVTRyBtYXkgcmVxdWly
ZSBpbXBsZW1lbnRhdGlvbiBhbmQvb3Igb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSZxdW90OyBmb3Ig
YSBQcm9wb3NlZCBTdGFuZGFyZC4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IFRoaXMgbWF5IGNvbWUg
ZG93biB0byB0aGUgcXVlc3Rpb24gd2hldGhlciB0aGUgSUVURiBzaG91bGQgaW4gZnV0dXJlIHNw
ZWNpZnkgdXNlIG9mIFRDUCBoZWFkZXIgYml0cyBmb3IgZXhwZXJpbWVudHMgdGhhdCBoYXZlIG5v
IGltcGxlbWVudGF0aW9uIG9yIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UsIG9yIGZvciBwcm90b2Nv
bHMgdGhhdCBjYW5ub3QgYmUgcHVibGlzaGVkIGFzIFBTIGZvciBvdGhlciByZWFzb25zDQogKGUu
Zy4sIHRoZSBjYXNlcyBtZW50aW9uZWQgaW4gcmVmZXJlbmNlIFsyXSkuPC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1ZXN0aW9uIDU6IFdo
YXQgc3RhbmRhcmRpemF0aW9uIHBvbGljeSB3b3VsZCBiZSBhcHByb3ByYXRlIGluc3RlYWQgb2Yg
JnF1b3Q7U3RhbmRhcmRzIEFjdGlvbiZxdW90OywgaWYgYSBkb3duZ3JhZGUgaXMgbmVlZGVkPzwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7IERpc2N1c3Npb246PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgUkZDIDgx
MjYgZGVmaW5lcyBkaWZmZXJlbnQgb3B0aW9ucy48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBkcmFmdC1r
dWVobGV3aW5kLXRjcG0tZmxhZ3MtcmVnaXN0cnktMDAgcHJvcG9zZXMgJnF1b3Q7SUVURiBSZXZp
ZXcgb3IgSUVTRyBBcHByb3ZhbCZxdW90Oy4gRXZlbiBpZiB0aGVyZSB3YXMgY29uc2Vuc3VzIHRv
IHJlcGxhY2UgdGhlIHBvbGljeSAmcXVvdDtTdGFuZGFyZHMgQWN0aW9uJnF1b3Q7IGluIFJGQyAy
NzgwIGJ5IHNvbWV0aGluZyBlbHNlLCBvbmUgY291bGQgZS5nLiBxdWVzdGlvbiB3aHkgJnF1b3Q7
SUVTRyBhcHByb3ZhbCZxdW90OyB3b3VsZCBpbmRlZWQNCiBiZSBhcHByb3ByaWF0ZSBmb3IgYSBw
ZXJtYW5lbnQgY2hhbmdlIG9mIG9uZSBvZiB0aGUgY29yZSBJbnRlcm5ldCBwcm90b2NvbHMuIFJG
QyA4MTI2IGV4cGxhaW5zIHRoYXQgJnF1b3Q7SUVTRyBBcHByb3ZhbCBpcyBub3QgaW50ZW5kZWQg
dG8gYmUgdXNlZCBvZnRlbiBvciBhcyBhICZxdW90O2NvbW1vbiBjYXNlJnF1b3Q7OyBpbmRlZWQs
IGl0IGhhcyBzZWxkb20gYmVlbiB1c2VkIGluIHByYWN0aWNlLiZxdW90OzwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RdWVzdGlvbiA2OiBI
b3cgdG8gZGVhbCB3aXRoIGZ1dHVyZSBhbGxvY2F0aW9ucyBub3QgYmVpbmcgdXNlZD88L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOyBEaXNjdXNzaW9uOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IEFzIHRoaXMgaXMg
YSBub24tdHJpdmlhbCBxdWVzdGlvbiwgaGVyZSBpcyBhIGNvcHkgb2YgdGhlIHRleHQgaW4gZHJh
ZnQta3VlaGxld2luZC10Y3BtLWZsYWdzLXJlZ2lzdHJ5LTAwOjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
Jm5ic3A7IFRoZXJlZm9yZSwgYW55IGV4cGVyaW1lbnRhbCBSRkMgdGhhdCByZWdpc3RlcnMgYSBy
ZXNlcnZlZCBmbGFncyBpbjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB0
aGUgVENQIGZsYWdzIHJlZ2lzdHJ5IE1VU1QgcHJvdmlkZSB3YXlzIHRvIGFsdGVyIHRoZSBwcm9w
b3NlZDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBtZWNoYW5pc20gYXQg
dGhlIGVuZCBvZiB0aGUgZXhwZXJpbWVudGFsIHBoYXNlIHdpdGhvdXQgdXNpbmc8L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYWRkaXRpb25hbCBUQ1AgaGVhZGVyIGZsYWdz
LiZuYnNwOyBFLmcuIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGFkZCBhbjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBhZGRpdGlvbmFsIG5lZ290aWF0aW9uIG1lY2hhbmlz
bSBhZnRlciB0aGUgVENQIGhhbmRzaGFrZSB0aGF0IHdvdWxkPC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7Jm5ic3A7IG1ha2UgaXQgcG9zc2libGUgdG8gdXNlIGRpZmZlcmVudCB2ZXJz
aW9ucyBvZiB0aGUgZ2VuZXJhbCBtZWNoYW5pc20vPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7Jm5ic3A7IGV4dGVuc2lvbiB0aGF0IHdhcyBuZWdvdGlhdGVkIG9yIGluZGljYXRlZCBk
dXJpbmcgdGhlIFRDUCBoYW5kc2hha2U8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm
bmJzcDsgdXNpbmcgdGhlIG5ld2x5IGFzc2lnbmVkIGZsYWcuJm5ic3A7IEZ1cnRoZXIsIGFueSBl
eHBlcmltZW50YWwgZXh0ZW5zaW9uPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i
c3A7IFNIT1VMRCBkaXNjdXNzaW9uIHRoZSBzY29wZSBvZiB0aGUgZXhwZXJpbWVudCBhbmQgcG90
ZW50aWFsIGZhaWx1cmU8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgY2Fz
ZXMgb3Igb3BlbiBxdWVzdGlvbnMgdGhhdCBuZWVkIHRvIGJlIGFuc3dlcmVkIHdoZW4gcnVubmlu
ZyB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgZXhwZXJpbWVudCBh
bmQgZXhwbGFpbiBob3cgdGhlc2UgY291bGQgYmUgYWRkcmVzc2VkIGluIGFuIHVwZGF0ZWQ8L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgdmVyc2lvbi48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyZuYnNwOyBUQ1AgZmxhZ3MgY2FuIG9ubHkgYmUgZGUtYXNzaWduZWQgaWYgbm8gZGVw
bG95bWVudCBvZiBhbiBleHBlcmltZW50YWw8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsmbmJzcDsgZXh0ZW5zaW9uIGhhcHBlbmVkLiZuYnNwOyBUaGlzIHNob3VsZCBiZSBldmFsdWF0
ZWQgc29tZSB5ZWFycyBhZnRlciB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm
bmJzcDsgYXNzaWdubWVudCB0byBhbiBleHBlcmltZW50YWwgZXh0ZW5zaW9uLCBpbiBvcmRlciB0
byBjaGFuZ2UgdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHJlZ2lz
dHJ5IGVudHJ5IGJhY2sgdG8gJnF1b3Q7UkVTRVJWRUQmcXVvdDsgYW5kIG1vdmUgdGhlIHJlc3Bl
Y3RpdmU8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgZXhwZXJpbWVudGFs
IFJGQyB0byBoaXN0b3J5LCBvciBhc3NpZ24gaXQgcGVybWFuZW50bHkuPC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsgSWYgb25lIGdvZXMgZG93biB0aGF0IHJvYWQsIG9uZSBtYXkgcnVuIGludG8gYSBudW1i
ZXIgb2YgZm9sbG93LXVwIHF1ZXN0aW9ucywgc3VjaCBhczo8L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBR
Ni4xOiBXaGF0IHdvdWxkIGJlIHRoZSBleGFjdCBub3JtYXRpdmUgc3RhdGVtZW50IHRoYXQgZXhw
ZXJpbWVudHMgd291bGQgbmVlZCB0byBjb21wbHkgdG8/PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgUTYu
MjogSG93IHdvdWxkICZxdW90O2FkZGl0aW9uYWwgbmVnb3RpYXRpb24gbWVjaGFuaXNtcyZxdW90
OyB3b3JrIHJvYnVzdGx5LCBnaXZlbiB0aGF0IFRDUCBzdHJ1Z2dsZXMgd2l0aCByZWxpYWJseSB0
cmFuc3BvcnRpbmcgY29udHJvbCBpbmZvcm1hdGlvbiBhZnRlciB0aGUgU1lOPzwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7IFE2LjM6IFdvdWxkIGEgbmV3IGZvbGxvdy11cCB1c2VyIG9mIGEgYml0IG5lZWQg
dG8gaW1wbGVtZW50IHRoZSBwcmV2aW91cyBmYWlsZWQgZXhwZXJpbWVudCB0byBtYWtlIHVzZSBv
ZiBzdWNoIGEgJnF1b3Q7YWRkaXRpb25hbCBuZWdvdGlhdGlvbiBtZWNoYW5pc20mcXVvdDs/PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsgUTYuNDogV291bGQgdGhlcmUgYmUgbm9ybWF0aXZlIGxhbmd1YWdl
IG9uIGhvdyBkZWFsbG9jYXRpb24gJnF1b3Q7c2hvdWxkIGJlIGV2YWx1YXRlZCBzb21lIHllYXJz
IGFmdGVyIHRoZSBhc3NpZ25tZW50JnF1b3Q7PyBJZiBzbywgd2hhdD88L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyBRNi41OiBIb3cgdG8gZGVhbCB3aXRoIHBhcnRpYWwgZGVwbG95bWVudCBvZiBhbiBleHBl
cmltZW50IGUuZy4gb25seSBpbiBjb250cm9sbGVkIGVudmlyb25tZW50cywgYnV0IG5vdCBpbiB0
aGUgb3BlbiBJbnRlcm5ldD8gV291bGQgdGhlIGV4cGVyaW1lbnQgdGhlbiBjb250aW51ZSB1c2lu
ZyBhbiBleHBlcmltZW50YWwgYml0IGFsbG9jYXRpb24sIG9yIHdvdWxkIGEgZm9sbG93LXVwIFBT
IGJlIG5lZWRlZA0KIGFmdGVyIHNvbWUgdGltZSwgb3Igd291bGQgdGhlIGFsbG9jYXRpb24gYmUg
cmVtb3ZlZD88L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+UXVlc3Rpb24gNzogQ291bGQgb25lIG9mIHRoZSBiaXRzIDQsIDUsIG9yIDYgYmUg
cmVnaXN0ZXJlZCBieSBzZXZlcmFsIGV4cGVyaW1lbnRzIGluIHBhcmFsbGVsPzwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7IERpc2N1c3Npb246PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgQXMgYWZ0ZXIgYWxsb2Nh
dGlvbiBvZiBiaXQgNyBvbmx5IHRocmVlIHJlc2VydmVkIGJpdHMgYXJlIGxlZnQsIGFuZCB0aGVy
ZSBhcmUgYWxyZWFkeSBhIG51bWJlciBvZiBwcm9wb3NhbHMgZm9yIG90aGVyIHVzZSBjYXNlcywg
aW4gYWRkaXRpb24gdG8gcGxlbnR5IHJlc2VhcmNoIHBhcGVycyBvbiBUQ1AsIGFuZCBwcm9iYWJs
eSBtYW55IG1vcmUgdG8gY29tZSBpbiBmdXR1cmUsIGl0IGlzIG5vdCBjbGVhciB3aGV0aGVyDQog
dGhlcmUgd291bGQgYmUgZW5vdWdoIGJpdHMgaW4gdGhlIGhlYWRlciBmb3IgYWxsIGV4cGVyaW1l
bnRlcnMgYW5kIHJlc2VhcmNoZXJzIHdpdGhvdXQgc29tZSBhZGRpdGlvbmFsIG1lY2hhbmlzbSBv
ZiBjby1leGlzdGVuY2UuIEZvciBhIHByb2Nlc3MgZG9jdW1lbnQsIHRoZSBxdWVzdGlvbiBpcyBp
ZiBhbiBJQU5BIHJlZ2lzdHJ5IHdvdWxkIG5lZWQgdG8gZm9yZXNlZSBtb3JlIHRoYW4gb25lIGV4
cGVyaW1lbnQuDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+UXVlc3Rpb24gODogSG93IG1hbnkgYml0cyBjYW4gcmVhc29uYWJseSBiZSBh
bGxvY2F0ZWQgaW4gdGhlIG5leHQgZmV3IHllYXJzPzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7RGlzY3Vz
c2lvbjo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBUaGlzIGlzIG5vdCBhIHRlY2huaWNhbCBidXQgbW9y
ZSBhIHN0cmF0ZWdpYyBxdWVzdGlvbi4gSXQgbWF5IGJlIG1vc3RseSBvcnRob2dvbmFsIHRvIHRo
ZSBmb3JtYWwgcHJvY2VzcyBob3cgdG8gYWxsb2NhdGUgYml0cywgYnV0IGdpdmVuIHRoYXQgdGhl
cmUgYXJlIG9ubHkgMyBvciA0IHJlc2VydmVkIGJpdHMgbGVmdCwgdGhleSBhcmUgYSB2ZXJ5IHNj
YXJjZSByZXNvdXJjZS4gQmFzZWQgb24gdGhlIGN1cnJlbnQNCiBsZXZlbCBvZiBkZXBsb3ltZW50
IGFuZCB1c2Ugb2YgVENQLCBUQ1Agd2lsbCBwcm9iYWJseSBzdGlsbCBiZSBpbiB1c2UgZm9yIHNl
dmVyYWwgZGVjYWRlcywgZXZlbiBpZiBzdWNjZXNzb3IgcHJvdG9jb2xzIG1heSB0YWtlIG92ZXIg
c2lnbmlmaWNhbnQgcGFydHMgb2YgdGhlIGN1cnJlbnQgVENQLWJhc2VkIHRyYWZmaWMuIEdpdmVu
IHRoYXQgZnV0dXJlIG5lZWRzIGluLCBzYXksIDIwIHllYXJzIGZyb20gbm93IGFyZSB1bmtub3du
LCBpcyB0aGVyZQ0KIGEgc3RyYXRlZ2ljIG5lZWQgdG8ga2VlcCBiYWNrIHNvbWUgcmVzZXJ2ZWQg
Yml0cyBmb3IgdGhlc2UgZnV0dXJlIHVua25vd24gbmVlZHM/IElmIHRoZSBhbnN3ZXIgaXMgeWVz
LCBpdCByZXF1aXJlcyBkaXNjdXNzaW9uIHdoZXRoZXIgY2hhbmdpbmcgdGhlIHJlZ2lzdHJhdGlv
biBwb2xpY3kgZm9yIF9hbGxfIGJpdHMgaXMgc3RyYXRlZ2ljYWxseSB0aGUgcmlnaHQgY29uY2Vw
dCBub3cuIEFuIGFsdGVybmF0aXZlIGNvdWxkIGJlIGUuZy4gdG8gZm9jdXMNCiBjaGFuZ2VzIG9u
bHkgb24gYSBzdWItc2V0IG9mIHRoZSByZW1haW5pbmcgcmVzZXJ2ZWQgYml0cyAoaWYgdGhlcmUg
d2FzIGFjdHVhbGx5IGEgbmVlZCBmb3IgYW55IGNoYW5nZSkuPC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1ZXN0aW9uIDk6IEFsbC1pbi1v
bmUgcG9saWN5IGNoYW5nZSBub3cgb3IgZnV0dXJlIGNhc2UtYnktY2FzZSBoYW5kbGluZz88L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOyBEaXNjdXNzaW9uOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IElmIGJpdCA3
IGNhbiBiZSBhc3NpZ25lZCB3aXRob3V0IGNoYW5naW5nIHRoZSByZWdpc3RyYXRpb24gcG9saWN5
LCBpdCBpcyB1bmNsZWFyIHdoZXRoZXIgdGhlcmUgaXMgaW5kZWVkIGFuIHVyZ2VudCBuZWVkIGZv
ciBmdXJ0aGVyIGNoYW5nZXMgb2YgdGhlIHJlZ2lzdHJhdGlvbiBwb2xpY3ksIGUuZy4sIGZvciBi
aXRzIDQsIDUsIGFuZCA2LiBGb3IgaW5zdGFuY2UsIGFuIGFsdGVybmF0aXZlIHdvdWxkIGJlDQog
dG8gc29ydCBvdXQgZnV0dXJlIGFsbG9jYXRpb24gb2YgcmVzZXJ2ZWQgYml0cyBjYXNlLWJ5LWNh
c2Ugb25jZSB0aGUgdXNlIGNhc2UgaXMgd2VsbCB1bmRlcnN0b29kIGFuZCB0aGUgYWRkZWQgdmFs
dWUgb2YgdXNpbmcgYSBUQ1AgaGVhZGVyIGJpdCBpcyBjbGVhciwgYW5kIG9uY2UgaXQgaXMgYWxz
byB1bmRlcnN0b29kIHdoeSB0aGUgYXBwcm9hY2ggb2YgYSBQUyBpcyBub3QgYXBwbGljYWJsZSBm
b3IgdGhhdCBleHBlcmltZW50LiBGb3IgY2FzZS1ieS1jYXNlDQogaGFuZGxpbmcsIG5vIGFsbC1p
bi1vbmUgcG9saWN5IGNoYW5nZSB3b3VsZCBiZSBuZWVkZWQgZm9yIHRoZSB0aW1lIGJlaW5nLjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IGJlbGlldmUgdGhlIFRDUE0gY29tbXVuaXR5IHNob3VsZCBkaXNjdXNzIHRoZXNlIHF1ZXN0aW9u
cyBpbiBvcmRlciB0byB1bmRlcnN0YW5kIHdoZXRoZXIgc29tZSBuZXcgZG9jdW1lbnQgaXMgbmVl
ZGVkLCBhbmQsIGlmIHNvLCB3aGF0IGl0IHNob3VsZCBjb250YWluLiBGb3JtYWwgcHJvY2VkdXJl
IGRvY3VtZW50cyBjYW4gYmUgc2hvcnQsIGJ1dCB0aGUgZXhhY3Qgd29yZGluZyBtYXR0ZXJzLCBh
bmQgSSBiZWxpZXZlDQogdGhlcmUgYXJlIHF1aXRlIGEgbnVtYmVyIG9mIG5vbi10cml2aWFsIGRl
dGFpbHMuIEFuZCBjaGFuZ2VzIHRvIHRoZSBtYWluIFRDUCBoZWFkZXIgc2hvdWxkIHByb2JhYmx5
IGJlIGRpc2N1c3NlZCBjYXJlZnVsbHkgYW5kIGJlIGJhY2tlZCBieSBzdHJvbmcgY29uc2Vuc3Vz
Lg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaHVzLCBmZWVsIGZyZWUgdG8gY29tbWVudC48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk1pY2hhZWwgKHdpdGggbm8gaGF0KTwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlJlZmVyZW5jZXM8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSBEZWZpbml0aW9uIG9mIGFuIEV4
cGVyaW1lbnRhbCBSRkMgaW4gUkZDIDIwMjY8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDsvc25pcCZndDs8L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LjIuMSZuYnNwOyBFeHBlcmltZW50YWw8L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOyZuYnNwOyBUaGUgJnF1b3Q7RXhwZXJpbWVudGFsJnF1b3Q7IGRlc2lnbmF0aW9u
IHR5cGljYWxseSBkZW5vdGVzIGEgc3BlY2lmaWNhdGlvbiB0aGF0PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGlzIHBhcnQgb2Ygc29tZSByZXNlYXJjaCBvciBkZXZlbG9w
bWVudCBlZmZvcnQuJm5ic3A7IFN1Y2ggYSBzcGVjaWZpY2F0aW9uPC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGlzIHB1Ymxpc2hlZCBmb3IgdGhlIGdlbmVyYWwgaW5mb3Jt
YXRpb24gb2YgdGhlIEludGVybmV0IHRlY2huaWNhbDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyZuYnNwOyBjb21tdW5pdHkgYW5kIGFzIGFuIGFyY2hpdmFsIHJlY29yZCBvZiB0aGUg
d29yaywgc3ViamVjdCBvbmx5IHRvPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i
c3A7IGVkaXRvcmlhbCBjb25zaWRlcmF0aW9ucyBhbmQgdG8gdmVyaWZpY2F0aW9uIHRoYXQgdGhl
cmUgaGFzIGJlZW48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYWRlcXVh
dGUgY29vcmRpbmF0aW9uIHdpdGggdGhlIHN0YW5kYXJkcyBwcm9jZXNzIChzZWUgYmVsb3cpLiZu
YnNwOyBBbjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBFeHBlcmltZW50
YWwgc3BlY2lmaWNhdGlvbiBtYXkgYmUgdGhlIG91dHB1dCBvZiBhbiBvcmdhbml6ZWQgSW50ZXJu
ZXQ8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgcmVzZWFyY2ggZWZmb3J0
IChlLmcuLCBhIFJlc2VhcmNoIEdyb3VwIG9mIHRoZSBJUlRGKSwgYW4gSUVURiBXb3JraW5nPC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IEdyb3VwLCBvciBpdCBtYXkgYmUg
YW4gaW5kaXZpZHVhbCBjb250cmlidXRpb24uPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0
Oy9zbmlwJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5bMl0gSUVTRyBndWlkZWxpbmVzIGZvciBFeHBlcmltZW50YWwgUkZDcyBvbiBo
dHRwczovL2lldGYub3JnL3N0YW5kYXJkcy9wcm9jZXNzL2luZm9ybWF0aW9uYWwtdnMtZXhwZXJp
bWVudGFsLzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O3NuaXAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VGhlIGZvbGxvd2luZyBzZXQgb2YgZ3VpZGVsaW5lcyB3aWxsIGJlIHVzZWQgYnkgdGhlIElF
U0cuIFRoZSBsaXN0IGlzIHJlYWQgZnJvbSB0b3AgdG8gYm90dG9tOyB0aGUgZmlyc3Qgb25lIHRo
YXQgc2VlbXMgdG8gYXBwbHkgaXMgcHJvYmFibHkgdGhlIG9uZSB0aGF0IG1ha2VzIHNlbnNlIHRv
IGZvbGxvdy48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsuLi5dPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBJZiB0aGUgSUVURiBt
YXkgcHVibGlzaCBzb21ldGhpbmcgYmFzZWQgb24gdGhpcyBvbiB0aGUgc3RhbmRhcmRzIHRyYWNr
IG9uY2Ugd2Uga25vdyBob3cgd2VsbCB0aGlzIG9uZSB3b3JrcywgaXQncyBFeHBlcmltZW50YWwu
IFRoaXMgaXMgdGhlIHR5cGljYWwgY2FzZSBvZiBub3QgYmVpbmcgYWJsZSB0byBkZWNpZGUgd2hp
Y2ggcHJvdG9jb2wgaXMgJnF1b3Q7YmV0dGVyJnF1b3Q7IGJlZm9yZSB3ZSBoYXZlIGV4cGVyaWVu
Y2UNCiBvZiBkZWFsaW5nIHdpdGggdGhlbSBmcm9tIGEgc3RhYmxlIHNwZWNpZmljYXRpb24uIENh
c2UgaW4gcG9pbnQ6ICZxdW90O1BHTSBSZWxpYWJsZSBUcmFuc3BvcnQgUHJvdG9jb2wgU3BlY2lm
aWNhdGlvbiZxdW90OyAoUkZDIDMyMDgpPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41LiBJZiB0aGUgZG9jdW1lbnQg
Y29udGFpbnMgaW1wbGljaXQgb3IgZXhwbGljaXQgc3VjY2Vzcy9mYWlsdXJlIGNyaXRlcmlhLCBh
bmQgaXQncyBjbGVhciB0aGF0IHRoZSBvdXRjb21lIGNhbiBiZSB1c2VkIGFzIHRoZSBiYXNpcyBm
b3IgYSByZWNvbW1lbmRhdGlvbiB0byB0aGUgSUVURiBjb21tdW5pdHksIGl0J3MgRXhwZXJpbWVu
dGFsLiBDYXNlIGluIHBvaW50OiBSRkMgMTc5NyAmcXVvdDtDbGFzcyBBIFN1Ym5ldCBFeHBlcmlt
ZW50JnF1b3Q7DQogd2hpY2ggbGVkIHRvIFJGQyAxODc5ICZxdW90O0NsYXNzIEEgU3VibmV0IEV4
cGVyaW1lbnQgUmVzdWx0cyBhbmQgUmVjb21tZW5kYXRpb25zJnF1b3Q7PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jmx0Oy9zbmlwJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bM10gRGVmaW5pdGlvbiBvZiBhIFByb3Bvc2VkIFN0
YW5kYXJkIGluIFJGQyA3MTI3PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7c25pcCZndDs8L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4zLjEuJm5ic3A7IENoYXJhY3Rlcml6YXRpb24gb2YgSUVURiBQcm9wb3Nl
ZCBTdGFuZGFyZCBTcGVjaWZpY2F0aW9uczwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFRoZSBl
bnRyeS1sZXZlbCBtYXR1cml0eSBmb3IgdGhlIHN0YW5kYXJkcyB0cmFjayBpcyAmcXVvdDtQcm9w
b3NlZDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBTdGFuZGFyZCZxdW90
Oy4mbmJzcDsgQSBzcGVjaWZpYyBhY3Rpb24gYnkgdGhlIElFU0cgaXMgcmVxdWlyZWQgdG8gbW92
ZSBhPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24g
b250byB0aGUgc3RhbmRhcmRzIHRyYWNrIGF0IHRoZSAmcXVvdDtQcm9wb3NlZCBTdGFuZGFyZCZx
dW90OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBsZXZlbC48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOyZuYnNwOyBBIFByb3Bvc2VkIFN0YW5kYXJkIHNwZWNpZmljYXRpb24gaXMg
c3RhYmxlLCBoYXMgcmVzb2x2ZWQga25vd248L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsmbmJzcDsgZGVzaWduIGNob2ljZXMsIGhhcyByZWNlaXZlZCBzaWduaWZpY2FudCBjb21tdW5p
dHkgcmV2aWV3LCBhbmQ8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYXBw
ZWFycyB0byBlbmpveSBlbm91Z2ggY29tbXVuaXR5IGludGVyZXN0IHRvIGJlIGNvbnNpZGVyZWQg
dmFsdWFibGUuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgVXN1YWxseSwgbmVpdGhlciBpbXBs
ZW1lbnRhdGlvbiBub3Igb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBpczwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyByZXF1aXJlZCBmb3IgdGhlIGRlc2lnbmF0aW9uIG9mIGEg
c3BlY2lmaWNhdGlvbiBhcyBhIFByb3Bvc2VkPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7Jm5ic3A7IFN0YW5kYXJkLiZuYnNwOyBIb3dldmVyLCBzdWNoIGV4cGVyaWVuY2UgaXMgaGln
aGx5IGRlc2lyYWJsZSBhbmQgd2lsbDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu
YnNwOyB1c3VhbGx5IHJlcHJlc2VudCBhIHN0cm9uZyBhcmd1bWVudCBpbiBmYXZvciBvZiBhIFBy
b3Bvc2VkIFN0YW5kYXJkPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGRl
c2lnbmF0aW9uLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFRoZSBJRVNHIG1heSByZXF1aXJl
IGltcGxlbWVudGF0aW9uIGFuZC9vciBvcGVyYXRpb25hbCBleHBlcmllbmNlPC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHByaW9yIHRvIGdyYW50aW5nIFByb3Bvc2VkIFN0
YW5kYXJkIHN0YXR1cyB0byBhIHNwZWNpZmljYXRpb24gdGhhdDwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOyZuYnNwOyBtYXRlcmlhbGx5IGFmZmVjdHMgdGhlIGNvcmUgSW50ZXJuZXQg
cHJvdG9jb2xzIG9yIHRoYXQgc3BlY2lmaWVzPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7Jm5ic3A7IGJlaGF2aW9yIHRoYXQgbWF5IGhhdmUgc2lnbmlmaWNhbnQgb3BlcmF0aW9uYWwg
aW1wYWN0IG9uIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBJbnRl
cm5ldC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBBIFByb3Bvc2VkIFN0YW5kYXJkIHdpbGwg
aGF2ZSBubyBrbm93biB0ZWNobmljYWwgb21pc3Npb25zIHdpdGg8L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDsmbmJzcDsgcmVzcGVjdCB0byB0aGUgcmVxdWlyZW1lbnRzIHBsYWNlZCB1
cG9uIGl0LiZuYnNwOyBQcm9wb3NlZCBTdGFuZGFyZHMgYXJlPC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7Jm5ic3A7IG9mIHN1Y2ggcXVhbGl0eSB0aGF0IGltcGxlbWVudGF0aW9ucyBj
YW4gYmUgZGVwbG95ZWQgaW4gdGhlIEludGVybmV0LjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyZuYnNwOyBIb3dldmVyLCBhcyB3aXRoIGFsbCB0ZWNobmljYWwgc3BlY2lmaWNhdGlv
bnMsIFByb3Bvc2VkIFN0YW5kYXJkcyBtYXk8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsmbmJzcDsgYmUgcmV2aXNlZCBpZiBwcm9ibGVtcyBhcmUgZm91bmQgb3IgYmV0dGVyIHNvbHV0
aW9ucyBhcmUgaWRlbnRpZmllZCw8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz
cDsgd2hlbiBleHBlcmllbmNlcyB3aXRoIGRlcGxveWluZyBpbXBsZW1lbnRhdGlvbnMgb2Ygc3Vj
aCB0ZWNobm9sb2dpZXM8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYXQg
c2NhbGUgaXMgZ2F0aGVyZWQuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0Oy9zbmlwJmd0
OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_6EC6417807D9754DA64F3087E2E2E03E2D854280rznt8114rzntrzd_--



From nobody Tue Dec 17 21:23:09 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C98E120898 for ; Tue, 17 Dec 2019 21:23:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level: 
X-Spam-Status: No, score=-1.22 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 ghA4Hsc7H1Nh for ; Tue, 17 Dec 2019 21:23:07 -0800 (PST)
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 213471200A1 for ; Tue, 17 Dec 2019 21:23:07 -0800 (PST)
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=cceU8M4E4Aum8FSJ9GiXuLxJjIe0DaOK37zdYZeRcCY=; b=HH5WBuezLmZhvUCCtg4HdmzZ5 N7qkoSXRYWfeozE7nPHxU9OPlW+BLnVgEFy1QbEwgq8mzvj/sjNlbc6CQYdiASEoFgcxdxgLWVWQN /uRLUvetHYk4m4nvOvzchnvTmNG+YOeLQxOzVwMbD/99px1JBpPQeO2p6JWoZwKzmdrYEHdLiJb1K gSv/bT+Lko+0c55/x+bWDj0NsifkuqjYzGHr95DuUz46Qz6KGaXAI0C3yarcCsHbqoqUk/WYgKvSX q0gNpZ0IbORP3gCiYaGpM9Nx7uPCXc9r9b792+qJPNmnRjofVvWCJCbNAgrHQvY+W758zu+dCnbt6 jzrO5bByg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50871 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ihRnZ-0002d3-NX; Wed, 18 Dec 2019 00:23:06 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_0A0F2B86-313C-4C8F-864C-8DA7A196C218"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch 
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D854280@rznt8114.rznt.rzdir.fht-esslingen.de>
Date: Tue, 17 Dec 2019 21:23:00 -0800
Cc: tcpm IETF list 
Message-Id: 
References: <6EC6417807D9754DA64F3087E2E2E03E2D854280@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" 
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: [tcpm] Follow-up questions on allocating reserved TCP header bits
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Dec 2019 05:23:08 -0000

--Apple-Mail=_0A0F2B86-313C-4C8F-864C-8DA7A196C218
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I wanted to focus on just this one point:

> On Dec 17, 2019, at 3:00 PM, Scharf, Michael =
 wrote:
>=20
>   Q6.2: How would "additional negotiation mechanisms" work robustly,

They wouldn=E2=80=99t...

> given that TCP struggles with reliably transporting control =
information after the SYN?

Because it isn=E2=80=99t so much =E2=80=9Cstruggles with=E2=80=9D as =
=E2=80=9Cdoes not support=E2=80=9D.

These flags shouldn=E2=80=99t be part of negotiation; that=E2=80=99s =
what options are for.  If TCP wants to define the flags for a =
connection, why not use the option space? If so, why bother with the =
flags at all?

Joe=

--Apple-Mail=_0A0F2B86-313C-4C8F-864C-8DA7A196C218
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
wanted to focus on just this one point:

On Dec =
17, 2019, at 3:00 PM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

  Q6.2: How would "additional negotiation =
mechanisms" work robustly,

They wouldn=E2=80=99t...

 given that TCP struggles with =
reliably transporting control information after the =
SYN?

Because =
it isn=E2=80=99t so much =E2=80=9Cstruggles with=E2=80=9D as =E2=80=9Cdoes=
 not support=E2=80=9D.

These flags shouldn=E2=80=99t be part of negotiation; =
that=E2=80=99s what options are for.  If TCP wants to define the =
flags for a connection, why not use the option space? If so, why bother =
with the flags at all?

Joe
=

--Apple-Mail=_0A0F2B86-313C-4C8F-864C-8DA7A196C218--


From nobody Tue Dec 17 23:28:40 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660891200D5 for ; Tue, 17 Dec 2019 23:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 voTM10ecsGx5 for ; Tue, 17 Dec 2019 23:28:36 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D1A1200E0 for ; Tue, 17 Dec 2019 23:28:35 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 47d67Q1hBTz7tNB; Wed, 18 Dec 2019 08:28:34 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 47d67Q0f96z5vNG; Wed, 18 Dec 2019 08:28:34 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 18 Dec 2019 08:28:33 +0100
From: 
To: Joe Touch 
CC: Wes Eddy , tcpm IETF list 
Thread-Topic: [tcpm] New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
Thread-Index: AQHVVkFr0tWCBeCP2kWXw8QKZsjuZafAOLCg
Date: Wed, 18 Dec 2019 07:28:33 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313EC7A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <156450882804.14172.17458284787319017749.idtracker@ietfa.amsl.com> <10a8eba2-0d55-bd5d-ad22-4884f485a3de@mti-systems.com> <787AE7BB302AE849A7480A190F8B9330312EB6CE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313EC7A9OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Dec 2019 07:28:39 -0000

--_000_787AE7BB302AE849A7480A190F8B9330313EC7A9OPEXCAUBMA2corp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9l
IFRvdWNoIFttYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb21dDQpFbnZvecOpIDogbHVuZGkgMTkg
YW/Du3QgMjAxOSAwNTo1Mg0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQpDYyA6IFdl
cyBFZGR5OyB0Y3BtIElFVEYgbGlzdA0KT2JqZXQgOiBSZTogW3RjcG1dIE5ldyBWZXJzaW9uIE5v
dGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNC50eHQNCg0KSGksIGFs
bCwNCg0KUkVTRVJWRUQgIT0gVU5BU1NJR05FRA0KW01lZF0gU3VyZS4gVGhpcyBpcyB3aGF0IHRo
ZSBpbml0aWFsIGNvbW1lbnQgd2FzIGFib3V0Lg0KDQpVbmFzc2lnbmVkIG1lYW5zIG5vdCBjdXJy
ZW50bHkgYXNzaWduZWQgYnV0IHRoYXQgdGhlcmXigJlzIGEgcHJvY2VzcyBpbiBwbGFjZSBmb3Ig
YXNzaWdubWVudCwgSU1PLg0KW01lZF0gVGhlIGF1dGhvcml0YXRpdmUgcmVmZXJlbmNlIGlzIGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTI2I3NlY3Rpb24tNi8uIFRoYXQgUkZDIHNh
eXM6DQoNCiAgICAgIFVuYXNzaWduZWQ6ICBOb3QgY3VycmVudGx5IGFzc2lnbmVkLCBhbmQgYXZh
aWxhYmxlIGZvciBhc3NpZ25tZW50DQogICAgICAgICAgICB2aWEgZG9jdW1lbnRlZCBwcm9jZWR1
cmVzLiAgV2hpbGUgaXQncyBnZW5lcmFsbHkgY2xlYXIgdGhhdA0KICAgICAgICAgICAgYW55IHZh
bHVlcyB0aGF0IGFyZSBub3QgcmVnaXN0ZXJlZCBhcmUgdW5hc3NpZ25lZCBhbmQNCiAgICAgICAg
ICAgIGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudCwgaXQgaXMgc29tZXRpbWVzIHVzZWZ1bCB0bw0K
ICAgICAgICAgICAgZXhwbGljaXRseSBzcGVjaWZ5IHRoYXQgc2l0dWF0aW9uLiAgTm90ZSB0aGF0
IHRoaXMgaXMNCiAgICAgICAgICAgIGRpc3RpbmN0bHkgZGlmZmVyZW50IGZyb20gIlJlc2VydmVk
Ii4NCg0KUmVzZXJ2ZWQgbWVhbnMgdGhhdCB0aGV5IHdvdWxkIGJlIGRlZmluZWQgb25seSBieSBh
IGNoYW5nZSB0byB0aGUgcHJvdG9jb2wgc3BlYyBpdHNlbGYsIG5vdCBtZXJlbHkgYnkgYW4gYXNz
aWdubWVudCBtZWNoYW5pc20uDQpbTWVkXSBBZ2FpbiwgdGhlIGF1dGhvcml0YXRpdmUgUkZDIHNh
eXMgdGhlIGZvbGxvd2luZzoNCg0KDQogICAgICBSZXNlcnZlZDogIE5vdCBhc3NpZ25lZCBhbmQg
bm90IGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudC4NCg0KICAgICAgICAgICAgUmVzZXJ2ZWQgdmFs
dWVzIGFyZSBoZWxkIGZvciBzcGVjaWFsIHVzZXMsIHN1Y2ggYXMgdG8gZXh0ZW5kDQoNCiAgICAg
ICAgICAgIHRoZSBuYW1lc3BhY2Ugd2hlbiBpdCBiZWNvbWVzIGV4aGF1c3RlZC4gICJSZXNlcnZl
ZCIgaXMgYWxzbw0KDQogICAgICAgICAgICBzb21ldGltZXMgdXNlZCB0byBkZXNpZ25hdGUgdmFs
dWVzIHRoYXQgaGFkIGJlZW4gYXNzaWduZWQNCg0KICAgICAgICAgICAgYnV0IGFyZSBubyBsb25n
ZXIgaW4gdXNlLCBrZWVwaW5nIHRoZW0gc2V0IGFzaWRlIGFzIGxvbmcgYXMNCg0KICAgICAgICAg
ICAgb3RoZXIgdW5hc3NpZ25lZCB2YWx1ZXMgYXJlIGF2YWlsYWJsZS4gIE5vdGUgdGhhdCB0aGlz
IGlzDQoNCiAgICAgICAgICAgIGRpc3RpbmN0bHkgZGlmZmVyZW50IGZyb20gIlVuYXNzaWduZWQi
Lg0KDQpJIHdvdWxkIHN0cm9uZ2x5IHN1Z2dlc3Qgc3RpY2tpbmcgd2l0aCBSRVNFUlZFRCwgcGVy
IHRoZSBvcmlnaW5hbCBkb2MuDQpbTWVkXSBUaGVzZSBiaXRzIHdlcmUgYXNzaWduZWQgaW4gdGhl
IHBhc3QgKGUuZy4sIFJGQzMxNjgpIHdpdGhvdXQgaGF2aW5nIHRvIGVkaXQgYSA3OTNiaXMuIEZ1
dHVyZSBSRkNzIGNhbiBhc2sgZm9yIGEgZmxhZyBiaXQgdG8gYmUgYXNzaWduZWQuDQoNCkkgZG9u
4oCZdCB0aGluayB3ZeKAmXJlIGluIHRoZSBidXNpbmVzcyBpbiB0aGlzIGRvYyBvZiBjaGFuZ2lu
ZyB0aGUgc3BlY3MgcGVyIHNlLg0KW01lZF0gV2UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgc3BlYy4g
V2UgYXJlIGNsYXJpZnlpbmcgdGhlIGludGVudCBhbmQgYWxpZ25pbmcgaXQgd2l0aCB0b2RheeKA
mXMgSUVURiBsYW5ndWFnZS4gVGhhdOKAmXMgc3RyYWlnaHRmb3J3YXJkLCBKb2UuIFdlIGFyZSBh
bGlnbmluZyB0aGUgbGFuZ3VhZ2Ugd2l0aCBSRkMyNzgwIHdoaWNoIHNheXM6DQoNCj09PQ0KOS4y
IFJlc2VydmVkIEJpdHMgaW4gVENQIEhlYWRlcg0KDQogICBUaGUgcmVzZXJ2ZWQgYml0cyBpbiB0
aGUgVENQIGhlYWRlciBhcmUgYXNzaWduZWQgZm9sbG93aW5nIGENCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KICAgIFN0YW5k
YXJkcyBBY3Rpb24gcHJvY2Vzcy4NCiAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj09PT0N
Cg0KDQpKb2UNCg0KDQpPbiBKdWwgMzAsIDIwMTksIGF0IDEwOjQyIFBNLCBtb2hhbWVkLmJvdWNh
ZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90
ZToNCg0KSGkgV2VzLA0KDQpZb3VyIHN1Z2dlc3Rpb24gb24gcmVzZXJ2ZWQgYml0cyB3b3JrcyBm
b3IgbWUuIFRoYW5rcy4NCg0KQXMgd2UgYXJlIHRoZXJlIGFyZSwgSSBzdWdnZXN0IHRvIGFkZCBh
IHNlY29uZCBhY3Rpb24gYXNraW5nIElBTkEgdG8gbW92ZSB0aGUgKG9ycGhhbikgVENQIGZsYWcg
cmVnaXN0cnkgdG8gYmUgYSBzdWItcmVnaXN0cnkgdW5kZXIgdGhlIGdsb2JhbCDigJxUcmFuc21p
c3Npb24gQ29udHJvbCBQcm90b2NvbCAoVENQKSBQYXJhbWV0ZXJz4oCdIChodHRwczovL3d3dy5p
YW5hLm9yZy9hc3NpZ25tZW50cy90Y3AtcGFyYW1ldGVycy90Y3AtcGFyYW1ldGVycy54aHRtbCku
DQoNCkFsc28sIGFkZCB0byB0aGUgZHJhZnQgYSByZW1pbmRlciB0aGF0IOKAnHJlc2VydmVkIGJp
dHPigJ0gYXJlIGFzc2lnbmVkIGZvbGxvd2luZyBTdGFuZGFyZCBBY3Rpb24gYXMgcGVyIFNlY3Rp
b24gOS4yIG9mIFJGQyAyNzgwLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiB0Y3BtIFttYWlsdG86
dGNwbS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFdlc2xleSBFZGR5DQpFbnZvecOp
IDogbWFyZGkgMzAganVpbGxldCAyMDE5IDE5OjU3DQrDgCA6IHRjcG0gSUVURiBsaXN0DQpPYmpl
dCA6IFt0Y3BtXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10
Y3BtLXJmYzc5M2Jpcy0xNC50eHQNCg0KSGVsbG8sIHRoaXMgaW5jb3Jwb3JhdGVzIHNvbWUgc21h
bGwgY2xlYW51cHMgdGhhdCBhY2N1bXVsYXRlZCBwcmlvciB0byB0aGUgSUVURiBtZWV0aW5nLCBh
cyB3ZWxsIGFzIHNvbWUgb2YgdGhlIGZlZWRiYWNrIHJlY2VpdmVkIHNpbmNlIHRoZW4gb24gdGhl
IG1haWxpbmcgbGlzdC4NCkEgY291cGxlIHNwZWNpZmljIHRoaW5ncyBub3QgeWV0IGRvbmUgKGJl
Y2F1c2UgaXQgZG9lc24ndCBsb29rIGxpa2Ugd2UgY29udmVyZ2VkIG9uIHRoZSBsaXN0IHlldCk6
DQotIERpZCBub3QgeWV0IGNoYW5nZSByZXNlcnZlZCBiaXRzIHRvICJ1bmFzc2lnbmVkIiAobm9y
IGluZGljYXRlIHRoZW0gaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbikuICBSb2Qg
R3JpbWVzIGhhcyBhIGdvb2QgcG9pbnQgYWJvdXQgdGhlc2UgYmVpbmcgdmVyeSBjb21tb25seSBy
ZWZlcnJlZCB0byBhcyAidGhlIHJlc2VydmVkIGJpdHMiIGluIG90aGVyIHBsYWNlcy4gIEknbSB0
aGlua2luZyB3ZSBjb3VsZCBhZGQgYSBub3RlIHRvIHNheSB0aGF0IGluIElBTkEgdGVybXMgdGhl
eSdyZSAiVW5hc3NpZ25lZCIgdG8gYWRkIHRoZSBjbGFyaXR5IHRoYXQgTW9oYW1lZCBpcyBhZHZv
Y2F0aW5nLCBidXQgbm90IGNoYW5nZSB0aGUgbmFtZT8NCi0gRGlkIG5vdCB5ZXQgbW92ZSBzZWN0
aW9uIDIuMS4NCi0gRGlkIG5vdCB5ZXQgcmVtb3ZlIHRoZSBub3RlIGFib3V0IG15IGNvbmZ1c2lv
biBvbiBNVVNUIHZzIFNIT1VMRCByZWdhcmRpbmcgcmVwb3J0aW5nIG9mIGV4Y2Vzc2l2ZSByZXRy
YW5zbWlzc2lvbnMgaW4gUkZDIDExMjIgKHdpbGwgY29uZmlybSBvbiB0aGUgbWFpbGluZyBsaXN0
IHRoZSAibm8gY2hhbmdlIiBwcm9wb3NhbCB0aGF0IHdhcyBzdWdnZXN0ZWQgYXQgdGhlIG1lZXRp
bmcpDQoNCg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoN
Ck5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0x
NC50eHQNCg0KRGF0ZToNCg0KVHVlLCAzMCBKdWwgMjAxOSAxMDo0NzowOCAtMDcwMA0KDQpGcm9t
Og0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm
Lm9yZz4NCg0KVG86DQoNCldlc2xleSBNLiBFZGR5IDx3ZXNAbXRpLXN5c3RlbXMuY29tPjxtYWls
dG86d2VzQG10aS1zeXN0ZW1zLmNvbT4sIFdlc2xleSBFZGR5IDx3ZXNAbXRpLXN5c3RlbXMuY29t
PjxtYWlsdG86d2VzQG10aS1zeXN0ZW1zLmNvbT4NCg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ
LUQsIGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs
bHkgc3VibWl0dGVkIGJ5IFdlc2xleSBNLiBFZGR5IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJl
cG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMNClJldmlzaW9uOiAx
NA0KVGl0bGU6IFRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sIFNwZWNpZmljYXRpb24NCkRv
Y3VtZW50IGRhdGU6IDIwMTktMDctMzANCkdyb3VwOiB0Y3BtDQpQYWdlczogMTA0DQpVUkw6IGh0
dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXRjcG0tcmZjNzkz
YmlzLTE0LnR4dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1pZXRmLXRjcG0tcmZjNzkzYmlzLw0KSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0DQpIdG1saXplZDogaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzDQpEaWZm
OiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10Y3BtLXJmYzc5
M2Jpcy0xNA0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBJbnRlcm5l
dCdzIFRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sDQooVENQKS4gVENQIGlzIGFuIGltcG9y
dGFudCB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2wgaW4gdGhlIEludGVybmV0DQpzdGFjaywgYW5k
IGhhcyBjb250aW51b3VzbHkgZXZvbHZlZCBvdmVyIGRlY2FkZXMgb2YgdXNlIGFuZCBncm93dGgg
b2YNCnRoZSBJbnRlcm5ldC4gT3ZlciB0aGlzIHRpbWUsIGEgbnVtYmVyIG9mIGNoYW5nZXMgaGF2
ZSBiZWVuIG1hZGUgdG8NClRDUCBhcyBpdCB3YXMgc3BlY2lmaWVkIGluIFJGQyA3OTMsIHRob3Vn
aCB0aGVzZSBoYXZlIG9ubHkgYmVlbg0KZG9jdW1lbnRlZCBpbiBhIHBpZWNlbWVhbCBmYXNoaW9u
LiBUaGlzIGRvY3VtZW50IGNvbGxlY3RzIGFuZCBicmluZ3MNCnRob3NlIGNoYW5nZXMgdG9nZXRo
ZXIgd2l0aCB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBmcm9tIFJGQyA3OTMuDQpUaGlzIGRv
Y3VtZW50IG9ic29sZXRlcyBSRkMgNzkzLCBhcyB3ZWxsIGFzIDg3OSwgMjg3MywgNjA5MywgNjQy
OSwNCjY1MjgsIGFuZCA2NjkxIHRoYXQgdXBkYXRlZCBwYXJ0cyBvZiBSRkMgNzkzLiBJdCB1cGRh
dGVzIFJGQyAxMTIyLA0KYW5kIHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIGEgcmVwbGFjZW1lbnQg
Zm9yIHRoZSBwb3J0aW9ucyBvZiB0aGF0DQpkb2N1bWVudCBkZWFsaW5nIHdpdGggVENQIHJlcXVp
cmVtZW50cy4gSXQgdXBkYXRlcyBSRkMgNTk2MSBkdWUgdG8gYQ0Kc21hbGwgY2xhcmlmaWNhdGlv
biBpbiByZXNldCBoYW5kbGluZyB3aGlsZSBpbiB0aGUgU1lOLVJFQ0VJVkVEDQpzdGF0ZS4NCg0K
UkZDIEVESVRPUiBOT1RFOiBJZiBhcHByb3ZlZCBmb3IgcHVibGljYXRpb24gYXMgYW4gUkZDLCB0
aGlzIHNob3VsZA0KYmUgbWFya2VkIGFkZGl0aW9uYWxseSBhcyAiU1REOiA3IiBhbmQgcmVwbGFj
ZSBSRkMgNzkzIGluIHRoYXQgcm9sZS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg
dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50
aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p
ZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0Y3BtIG1h
aWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KDQo=

--_000_787AE7BB302AE849A7480A190F8B9330313EC7A9OPEXCAUBMA2corp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N
c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD
qWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bh
bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk
LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu
LlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2Fy
IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTD
qSBIVE1MIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJ
e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw
Ljg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj
dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm
YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv
OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh
W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJw
dXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNw
YWNlO2xpbmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEpv
ZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgaW5saW5lLg0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lZDwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBzdHJheWFscGhh
LmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAxOSBhb8O7dCAyMDE5IDA1
OjUyPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOPGJyPg0K
PGI+Q2MmbmJzcDs6PC9iPiBXZXMgRWRkeTsgdGNwbSBJRVRGIGxpc3Q8YnI+DQo8Yj5PYmpldCZu
YnNwOzo8L2I+IFJlOiBbdGNwbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1p
ZXRmLXRjcG0tcmZjNzkzYmlzLTE0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkhpLCBhbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5SRVNFUlZFRCAhPSBVTkFTU0lHTkVEPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+W01lZF0gU3VyZS4gVGhpcyBpcyB3aGF0IHRoZSBpbml0aWFsIGNvbW1lbnQgd2FzIGFib3V0
Lg0KPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VW5hc3NpZ25l
ZCBtZWFucyBub3QgY3VycmVudGx5IGFzc2lnbmVkIGJ1dCB0aGF0IHRoZXJl4oCZcyBhIHByb2Nl
c3MgaW4gcGxhY2UNCjwvc3Bhbj5mb3IgYXNzaWdubWVudCwgSU1PLjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPltNZWRdIFRoZSBhdXRob3JpdGF0aXZlIHJlZmVyZW5jZSBpcw0KPC9zcGFuPjwvaT48
L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9yZmM4MTI2I3NlY3Rpb24tNi8iPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTI2
I3NlY3Rpb24tNi88L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE
Ij4uIFRoYXQgUkZDIHNheXM6ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtVbmFzc2lnbmVkOiZuYnNw
OyBOb3QgY3VycmVudGx5IGFzc2lnbmVkLCBhbmQgYXZhaWxhYmxlIGZvciBhc3NpZ25tZW50PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgdmlhIGRvY3VtZW50ZWQgcHJvY2VkdXJlcy4mbmJzcDsgV2hpbGUg
aXQncyBnZW5lcmFsbHkgY2xlYXIgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFueSB2YWx1ZXMg
dGhhdCBhcmUgbm90IHJlZ2lzdGVyZWQgYXJlIHVuYXNzaWduZWQgYW5kPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgYXZhaWxhYmxlIGZvciBhc3NpZ25tZW50LCBpdCBpcyBzb21ldGltZXMgdXNlZnVsIHRv
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhwbGljaXRseSBzcGVjaWZ5IHRoYXQgc2l0dWF0aW9uLiZu
YnNwOyBOb3RlIHRoYXQgdGhpcyBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPmRpc3RpbmN0bHkgZGlmZmVyZW50IGZyb20gJnF1b3Q7UmVzZXJ2ZWQmcXVvdDsuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXNlcnZlZCBtZWFu
cyB0aGF0IHRoZXkgd291bGQgYmUgZGVmaW5lZCBvbmx5IGJ5IGEgY2hhbmdlIHRvIHRoZSBwcm90
b2NvbCBzcGVjIGl0c2VsZiwgbm90IG1lcmVseSBieSBhbiBhc3NpZ25tZW50IG1lY2hhbmlzbS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01lZF0gQWdhaW4sIHRoZSBhdXRob3JpdGF0
aXZlIFJGQyBzYXlzIHRoZSBmb2xsb3dpbmc6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwcmU+PHNw
YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNlcnZlZDom
bmJzcDsgTm90IGFzc2lnbmVkIGFuZCBub3QgYXZhaWxhYmxlIGZvciBhc3NpZ25tZW50LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJl
c2VydmVkIHZhbHVlcyBhcmUgaGVsZCBmb3Igc3BlY2lhbCB1c2VzLCBzdWNoIGFzIHRvIGV4dGVu
ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHRoZSBuYW1lc3BhY2Ugd2hlbiBpdCBiZWNvbWVzIGV4aGF1c3RlZC4mbmJzcDsgJnF1b3Q7
UmVzZXJ2ZWQmcXVvdDsgaXMgYWxzbzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvbWV0aW1lcyB1c2VkIHRvIGRlc2lnbmF0ZSB2YWx1
ZXMgdGhhdCBoYWQgYmVlbiBhc3NpZ25lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ1dCBhcmUgbm8gbG9uZ2VyIGluIHVzZSwga2Vl
cGluZyB0aGVtIHNldCBhc2lkZSBhcyBsb25nIGFzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3RoZXIgdW5hc3NpZ25lZCB2YWx1ZXMg
YXJlIGF2YWlsYWJsZS4mbmJzcDsgTm90ZSB0aGF0IHRoaXMgaXM8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkaXN0aW5jdGx5IGRpZmZl
cmVudCBmcm9tICZxdW90O1VuYXNzaWduZWQmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB3b3VsZCBzdHJv
bmdseSBzdWdnZXN0IHN0aWNraW5nIHdpdGggUkVTRVJWRUQsIHBlciB0aGUgb3JpZ2luYWwgZG9j
LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPltNZWRdIFRoZXNlIGJpdHMgd2VyZSBhc3NpZ25lZCBpbiB0aGUgcGFzdCAoZS5n
LiwgUkZDMzE2OCkgd2l0aG91dCBoYXZpbmcgdG8gZWRpdCBhIDc5M2Jpcy4gRnV0dXJlIFJGQ3Mg
Y2FuIGFzayBmb3IgYSBmbGFnIGJpdCB0byBiZSBhc3NpZ25lZC4NCjxvOnA+PC9vOnA+PC9zcGFu
PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZG9u4oCZdCB0aGlu
ayB3ZeKAmXJlIGluIHRoZSBidXNpbmVzcyBpbiB0aGlzIGRvYyBvZiBjaGFuZ2luZyB0aGUgc3Bl
Y3MgcGVyIHNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBXZSBhcmUgbm90
IGNoYW5naW5nIHRoZSBzcGVjLiBXZSBhcmUgY2xhcmlmeWluZyB0aGUgaW50ZW50IGFuZCBhbGln
bmluZyBpdCB3aXRoIHRvZGF54oCZcyBJRVRGIGxhbmd1YWdlLiBUaGF04oCZcyBzdHJhaWdodGZv
cndhcmQsIEpvZS4gV2UgYXJlIGFsaWduaW5nDQogdGhlIGxhbmd1YWdlIHdpdGggUkZDMjc4MCB3
aGljaCBzYXlzOiA8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj49PT08bzpwPjwvbzpwPjwvc3Bh
bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1
LjVwdCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjkuMiBSZXNl
cnZlZCBCaXRzIGluIFRDUCBIZWFkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjVwdCI+PGI+PGk+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0
Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7
IFRoZSByZXNlcnZlZCBiaXRzIGluIHRoZSBUQ1AgaGVhZGVyIGFyZSBhc3NpZ25lZCBmb2xsb3dp
bmcgYTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXjxvOnA+PC9vOnA+PC9zcGFuPjwv
aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDtTdGFuZGFyZHMgQWN0aW9uIHBy
b2Nlc3MuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPj09PT0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPkpvZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBKdWwg
MzAsIDIwMTksIGF0IDEwOjQyIFBNLCA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91
Y2FkYWlyQG9yYW5nZS5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIj5tb2hhbWVkLmJvdWNhZGFpckBv
cmFuZ2UuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+IHdyb3RlOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+SGkNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2VzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+WW91ciBzdWdnZXN0aW9uIG9uIHJlc2VydmVkIGJpdHMgd29ya3MgZm9yIG1lLiBU
aGFua3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
QXMgd2UgYXJlIHRoZXJlIGFyZSwgSSBzdWdnZXN0IHRvIGFkZCBhIHNlY29uZCBhY3Rpb24gYXNr
aW5nIElBTkEgdG8gbW92ZSB0aGUgKG9ycGhhbikgVENQIGZsYWcgcmVnaXN0cnkgdG8gYmUgYSBz
dWItcmVnaXN0cnkgdW5kZXIgdGhlIGdsb2JhbA0KIOKAnFRyYW5zbWlzc2lvbiBDb250cm9sIFBy
b3RvY29sIChUQ1ApIFBhcmFtZXRlcnPigJ0gKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlhbmEub3Jn
L2Fzc2lnbm1lbnRzL3RjcC1wYXJhbWV0ZXJzL3RjcC1wYXJhbWV0ZXJzLnhodG1sIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy90Y3At
cGFyYW1ldGVycy90Y3AtcGFyYW1ldGVycy54aHRtbDwvc3Bhbj48L2E+KS48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbHNvLCBhZGQgdG8gdGhlIGRy
YWZ0IGEgcmVtaW5kZXIgdGhhdCDigJxyZXNlcnZlZCBiaXRz4oCdIGFyZSBhc3NpZ25lZCBmb2xs
b3dpbmcgU3RhbmRhcmQgQWN0aW9uIGFzIHBlciBTZWN0aW9uIDkuMiBvZiBSRkMgMjc4MC48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DaGVlcnMsPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TWVkPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRl
Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPnRjcG0NCiBbPGEgaHJlZj0ibWFpbHRvOnRjcG0tYm91bmNlc0BpZXRm
Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnRjcG0tYm91bmNlc0BpZXRm
Lm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48Yj5EZSBsYSBwYXJ0IGRlPC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj5XZXNsZXkgRWRkeTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9i
PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYXJkaSAz
MCBqdWlsbGV0IDIwMTkgMTk6NTc8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnRjcG0gSUVURiBsaXN0PGJyPg0KPGI+
T2JqZXQmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj5bdGNwbV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWll
dGYtdGNwbS1yZmM3OTNiaXMtMTQudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KSGVsbG8sIHRoaXMgaW5jb3Jwb3JhdGVzIHNvbWUg
c21hbGwgY2xlYW51cHMgdGhhdCBhY2N1bXVsYXRlZCBwcmlvciB0byB0aGUgSUVURiBtZWV0aW5n
LCBhcyB3ZWxsIGFzIHNvbWUgb2YgdGhlIGZlZWRiYWNrIHJlY2VpdmVkIHNpbmNlIHRoZW4gb24g
dGhlIG1haWxpbmcgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzti
YWNrZ3JvdW5kOndoaXRlIj4NCkEgY291cGxlIHNwZWNpZmljIHRoaW5ncyBub3QgeWV0IGRvbmUg
KGJlY2F1c2UgaXQgZG9lc24ndCBsb29rIGxpa2Ugd2UgY29udmVyZ2VkIG9uIHRoZSBsaXN0IHll
dCk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0
ZSI+DQotIERpZCBub3QgeWV0IGNoYW5nZSByZXNlcnZlZCBiaXRzIHRvICZxdW90O3VuYXNzaWdu
ZWQmcXVvdDsgKG5vciBpbmRpY2F0ZSB0aGVtIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNl
Y3Rpb24pLiZuYnNwOyBSb2QgR3JpbWVzIGhhcyBhIGdvb2QgcG9pbnQgYWJvdXQgdGhlc2UgYmVp
bmcgdmVyeSBjb21tb25seSByZWZlcnJlZCB0byBhcyAmcXVvdDt0aGUgcmVzZXJ2ZWQgYml0cyZx
dW90OyBpbiBvdGhlciBwbGFjZXMuJm5ic3A7IEknbSB0aGlua2luZyB3ZSBjb3VsZCBhZGQgYSBu
b3RlIHRvDQogc2F5IHRoYXQgaW4gSUFOQSB0ZXJtcyB0aGV5J3JlICZxdW90O1VuYXNzaWduZWQm
cXVvdDsgdG8gYWRkIHRoZSBjbGFyaXR5IHRoYXQgTW9oYW1lZCBpcyBhZHZvY2F0aW5nLCBidXQg
bm90IGNoYW5nZSB0aGUgbmFtZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bztiYWNrZ3JvdW5kOndoaXRlIj4NCi0gRGlkIG5vdCB5ZXQgbW92ZSBzZWN0aW9uIDIuMS48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCi0g
RGlkIG5vdCB5ZXQgcmVtb3ZlIHRoZSBub3RlIGFib3V0IG15IGNvbmZ1c2lvbiBvbiBNVVNUIHZz
IFNIT1VMRCByZWdhcmRpbmcgcmVwb3J0aW5nIG9mIGV4Y2Vzc2l2ZSByZXRyYW5zbWlzc2lvbnMg
aW4gUkZDIDExMjIgKHdpbGwgY29uZmlybSBvbiB0aGUgbWFpbGluZyBsaXN0IHRoZSAmcXVvdDtu
byBjaGFuZ2UmcXVvdDsgcHJvcG9zYWwgdGhhdCB3YXMgc3VnZ2VzdGVkIGF0IHRoZSBtZWV0aW5n
KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3Nh
Z2UgLS0tLS0tLS08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi
IGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0
cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt
IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFs
aWduOnJpZ2h0Ij48Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRk
aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmV3IFZl
cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0LnR4dDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIg
dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5EYXRl
OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHVlLCAzMCBKdWwgMjAxOSAxMDo0NzowOCAt
MDcwMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dy
YXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48
Yj5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt
IDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmludGVy
bmV0LWRyYWZ0c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4N
CjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzow
Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHls
ZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9
InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X
ZXNsZXkgTS4gRWRkeTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48YSBocmVmPSJtYWlsdG86d2VzQG10aS1zeXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNv
bG9yOnB1cnBsZSI+Jmx0O3dlc0BtdGktc3lzdGVtcy5jb20mZ3Q7PC9zcGFuPjwvYT4sIFdlc2xl
eSBFZGR5PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh
IGhyZWY9Im1haWx0bzp3ZXNAbXRpLXN5c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj4mbHQ7d2VzQG10aS1zeXN0ZW1zLmNvbSZndDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxi
cj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXRjcG0tcmZj
NzkzYmlzLTE0LnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2Vz
bGV5IE0uIEVkZHkgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0K
PGJyPg0KTmFtZTogZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpczxicj4NClJldmlzaW9uOiAxNDxi
cj4NClRpdGxlOiBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCBTcGVjaWZpY2F0aW9uPGJy
Pg0KRG9jdW1lbnQgZGF0ZTogMjAxOS0wNy0zMDxicj4NCkdyb3VwOiB0Y3BtPGJyPg0KUGFnZXM6
IDEwNDxicj4NClVSTDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0
LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQudHh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5
M2Jpcy0xNC50eHQ8L3NwYW4+PC9hPjxicj4NClN0YXR1czo8c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy8iPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGNw
bS1yZmM3OTNiaXMvPC9zcGFuPjwvYT48YnI+DQpIdG1saXplZDo8c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTQiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZj
NzkzYmlzLTE0PC9zcGFuPjwvYT48YnI+DQpIdG1saXplZDo8c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0
LWlldGYtdGNwbS1yZmM3OTNiaXM8L3NwYW4+PC9hPjxicj4NCkRpZmY6PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE0Ij48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh
ZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6
PGJyPg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIEludGVybmV0J3MgVHJhbnNtaXNzaW9u
IENvbnRyb2wgUHJvdG9jb2w8YnI+DQooVENQKS4gVENQIGlzIGFuIGltcG9ydGFudCB0cmFuc3Bv
cnQgbGF5ZXIgcHJvdG9jb2wgaW4gdGhlIEludGVybmV0PGJyPg0Kc3RhY2ssIGFuZCBoYXMgY29u
dGludW91c2x5IGV2b2x2ZWQgb3ZlciBkZWNhZGVzIG9mIHVzZSBhbmQgZ3Jvd3RoIG9mPGJyPg0K
dGhlIEludGVybmV0LiBPdmVyIHRoaXMgdGltZSwgYSBudW1iZXIgb2YgY2hhbmdlcyBoYXZlIGJl
ZW4gbWFkZSB0bzxicj4NClRDUCBhcyBpdCB3YXMgc3BlY2lmaWVkIGluIFJGQyA3OTMsIHRob3Vn
aCB0aGVzZSBoYXZlIG9ubHkgYmVlbjxicj4NCmRvY3VtZW50ZWQgaW4gYSBwaWVjZW1lYWwgZmFz
aGlvbi4gVGhpcyBkb2N1bWVudCBjb2xsZWN0cyBhbmQgYnJpbmdzPGJyPg0KdGhvc2UgY2hhbmdl
cyB0b2dldGhlciB3aXRoIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGZyb20gUkZDIDc5My48
YnI+DQpUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgNzkzLCBhcyB3ZWxsIGFzIDg3OSwgMjg3
MywgNjA5MywgNjQyOSw8YnI+DQo2NTI4LCBhbmQgNjY5MSB0aGF0IHVwZGF0ZWQgcGFydHMgb2Yg
UkZDIDc5My4gSXQgdXBkYXRlcyBSRkMgMTEyMiw8YnI+DQphbmQgc2hvdWxkIGJlIGNvbnNpZGVy
ZWQgYXMgYSByZXBsYWNlbWVudCBmb3IgdGhlIHBvcnRpb25zIG9mIHRoYXQ8YnI+DQpkb2N1bWVu
dCBkZWFsaW5nIHdpdGggVENQIHJlcXVpcmVtZW50cy4gSXQgdXBkYXRlcyBSRkMgNTk2MSBkdWUg
dG8gYTxicj4NCnNtYWxsIGNsYXJpZmljYXRpb24gaW4gcmVzZXQgaGFuZGxpbmcgd2hpbGUgaW4g
dGhlIFNZTi1SRUNFSVZFRDxicj4NCnN0YXRlLjxicj4NCjxicj4NClJGQyBFRElUT1IgTk9URTog
SWYgYXBwcm92ZWQgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQywgdGhpcyBzaG91bGQ8YnI+DQpi
ZSBtYXJrZWQgYWRkaXRpb25hbGx5IGFzICZxdW90O1NURDogNyZxdW90OyBhbmQgcmVwbGFjZSBS
RkMgNzkzIGluIHRoYXQgcm9sZS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ug
bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv
ZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl
IGF2YWlsYWJsZSBhdDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj50b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNl
Y3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOndoaXRlIj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+dGNwbSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0
Y3BtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnB1cnBsZTti
YWNrZ3JvdW5kOndoaXRlIj50Y3BtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby90Y3BtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3RjcG08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_787AE7BB302AE849A7480A190F8B9330313EC7A9OPEXCAUBMA2corp_--


From nobody Wed Dec 18 13:33:52 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC209120236 for ; Wed, 18 Dec 2019 13:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 Kvf6x_4VBb6x for ; Wed, 18 Dec 2019 13:33:49 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 12D5F12001A for ; Wed, 18 Dec 2019 13:33:49 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id x1so1363211qvr.8 for ; Wed, 18 Dec 2019 13:33:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=4lXR6nrbkczf/UKfTg1rKu3Lhy1Qe5Vn6FgbLfDjWdc=; b=QLmin/ZdYRzK0oJwgZuo4RVGu5ZZZ+PBDMjAPU3qFbnnbrDVdiy0xjWzZ7EkWtO9D1 orUWkY9Fzyr86qE0eB2ouE0PN1GpoDTCLiVFkUTuCgYcmXiYj3w/nA5/21Xa9uMbf3k8 8IoQGUvBvfnghGXdEsMN7EQh3g8xjpMarPNkbWFuVQ2P3KLwvltucRD3HtQoVc6PKJc0 pT7xw7X/WoF52ZUJ3yLP+SOqQ5vQ+Lhke29s2mSGNDldmq7Xl87YsGVhCDGsXYqwdvui n3ratwasgVPDsHE9MwL/g+jzopEmJ8WEj7PLpSxL/onv96lR4d7hwlAvga+3dNL+HroW 4m1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=4lXR6nrbkczf/UKfTg1rKu3Lhy1Qe5Vn6FgbLfDjWdc=; b=r2X/K2fIJN/UvHF/FIkG0HcTJyN1UM03yUsUbTvuQEJfGOnpW6mubCfzfIYb5405YB 42cEfzAGXfpneNQSDusE20zCwZe8HlGPgiT4OOdBUv0vOOgYH833I1XEhQTH5rcrHPiF ipnw6+HKdFsvBP2nw8b6QYFScegAQAoD0rhWOZbUH1mO7VtV8BnPs/UWKMEwarHZ6eVJ EFnGl+nglvcYxaNRpfpCJCTh4vgddAPxHyJZ/d8K9w4TaDY4sC4GhzkUMDyuqsEYUXEu b0PC9rti3JKUJ86cF28X4+LBv9kgSBFJxe1uleN5FhL7j38c5FyLfl71XgvC7KK5z0Nf U2Cg==
X-Gm-Message-State: APjAAAXcUhVfL06vQaNuum56CYY258RnOqqiAVmA+PTnO9jF7tQ7ctwh lSaZCyPE1qdoJfeVY9GDfUCgN6XLIZ8=
X-Google-Smtp-Source: APXvYqy+9BRiZzwIj5NE+PYKMiftumi+RPN6n+Ts/qpfA8FhZo4g3RW8BdRoL1DBgCrbU5zW93XmpA==
X-Received: by 2002:a0c:fac1:: with SMTP id p1mr4578873qvo.231.1576704827965;  Wed, 18 Dec 2019 13:33:47 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id x6sm1054689qkh.20.2019.12.18.13.33.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Dec 2019 13:33:47 -0800 (PST)
To: gorry@erg.abdn.ac.uk, "tcpm@ietf.org" 
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com>
Date: Wed, 18 Dec 2019 16:33:46 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D66A044.3060904@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [tcpm] 793bis: TCP Quiet Time
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Dec 2019 21:33:51 -0000

I don't think I noticed anyone responding to Gorry's comment below, and 
I haven't made any alterations in the 793bis draft with regard to this 
(other than fixing some spelling mistakes).  I wanted to pull this into 
its own thread in case other people have thoughts or would like to 
discuss further what the quiet time concept's relevance is in 2020.

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> OLD, Section: "   The TCP Quiet Time Concept"
> - Found this section quite amusing. Is this concept widely implemented 
> in stacks?
> - The examples given need updated, for instance one example starts "At 
> 2 megabits/sec. it takes 4.5 hours to", clearly at 10 Gbps this line 
> of thinking becomes problematic.
> - There is an odd sentence that states:
> "In the absence of knowledge
>    about the sequence numbers used on a particular connection, the TCP
>    specification recommends that the source delay for MSL seconds before
>    emitting segments on the connection, to allow time for segments from
>    the earlier connection incarnation to drain from the system."
> - how would the "source" know the MSL rather than use the Internet 
> default?
> - To me, this section raises many questions about whether this is best 
> current practice. 


From nobody Wed Dec 18 17:28:16 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF50612000F for ; Wed, 18 Dec 2019 17:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 T7Ug6lSVo_TZ for ; Wed, 18 Dec 2019 17:28:11 -0800 (PST)
Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 3C0A8120026 for ; Wed, 18 Dec 2019 17:28:11 -0800 (PST)
Received: by mail-vk1-xa2e.google.com with SMTP id u6so1184573vkn.13 for ; Wed, 18 Dec 2019 17:28:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cloJFExcYZ2YkAqBpGQs4M0jRGk/Az9cYrLsqM/vXwo=; b=gCknme6nxsZz3oOyWHrTi0LvyQrQ/OLzqCABOGvGvQgUYin1DQMVLrPKLVhF6Nx+95 aVPsOgyaF0B5X1OcTZJ1j2c55Xlp/PTnAzfPo8dkFsK0gdNlBNi7hqn/0J70LDCFb9v7 K2QgUqDPRTE4HAXfJOV1ojYGlAkF37AV2mnhgNDYvtMfB38cR0feTGeaWD+j+YOcTeu4 6YjQqbqXAoSbS5irshf2OBEC4DuruliFvzNN4yjf7v9Zjhm+BNdeA0pYTOhfMbBPbB9P JStiXZ8taoX6aOx+AIkBbd0RNeuaS3g/qGlcYzhKLGZMqXt0OCyYwegYSRKjt3qj0pCT rg6Q==
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=cloJFExcYZ2YkAqBpGQs4M0jRGk/Az9cYrLsqM/vXwo=; b=NJbT0RZarwDSNYPNNe5bYED7i5izQ8zw3LT2aPoINqUIT5tft87Vrj5VmBRTVdt/Mz Q3f2j8xa1kMNWE6dBZvWeGX7t7+3vd/YJiGZg9XlxGol5+4kiP5vupw+S33+0kZhnIU/ ewmqW68o3FNhCaz/bVONpE8TEK2lFOhFbbT0G1jYNC+G0r6YNuntt9Ahp8CrKZxyOD0R XePcO3BwwdwEX3+GlqB/PBOaGbYOViZlyHXgEa47vT+ugFIP9OUljaxJuItJyT8hs/cU IAQz+M5wxRhq8nZIKg8xHso8sAADLVOHnqiIfLplnIiwtdtYSN/8trQ7VTGRLNO3QCK7 6TQw==
X-Gm-Message-State: APjAAAWtSA+kAqKN/HgrtqXNhumxwxh5ximUKVwD5LVdi/L98a2TKi3l ST6mvXnB7rQzpj5QE7yFb/gHr1sI2yv44EFL8ctx8urpIg0=
X-Google-Smtp-Source: APXvYqzWgDDSiGbOUwB6j/spj9q2fS/7P7jO78Og4LZ6KOvH06VLX8vG2l3bzExpyx+UOf/kiYLb2kj+ALmVPjhNkuE=
X-Received: by 2002:a1f:2106:: with SMTP id h6mr4218408vkh.91.1576718889834; Wed, 18 Dec 2019 17:28:09 -0800 (PST)
MIME-Version: 1.0
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com>
In-Reply-To: <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com>
From: Yuchung Cheng 
Date: Wed, 18 Dec 2019 17:27:33 -0800
Message-ID: 
To: Wesley Eddy 
Cc: Gorry Fairhurst , "tcpm@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tcpm] 793bis: TCP Quiet Time
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 01:28:15 -0000

On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy  wrote:
>
> I don't think I noticed anyone responding to Gorry's comment below, and
> I haven't made any alterations in the 793bis draft with regard to this
> (other than fixing some spelling mistakes).  I wanted to pull this into
> its own thread in case other people have thoughts or would like to
> discuss further what the quiet time concept's relevance is in 2020.
I probably am missing something. What's the issue of the text? Linux
to my knowledge does
not implement this quiet time.
But there are other injection attacks or basic checksum issues etc to
corrupt TCP. (Serious) application that solely relying on TCP's
integrity is signing up for troubles already ...

>
> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> > OLD, Section: "   The TCP Quiet Time Concept"
> > - Found this section quite amusing. Is this concept widely implemented
> > in stacks?
> > - The examples given need updated, for instance one example starts "At
> > 2 megabits/sec. it takes 4.5 hours to", clearly at 10 Gbps this line
> > of thinking becomes problematic.
> > - There is an odd sentence that states:
> > "In the absence of knowledge
> >    about the sequence numbers used on a particular connection, the TCP
> >    specification recommends that the source delay for MSL seconds before
> >    emitting segments on the connection, to allow time for segments from
> >    the earlier connection incarnation to drain from the system."
> > - how would the "source" know the MSL rather than use the Internet
> > default?
> > - To me, this section raises many questions about whether this is best
> > current practice.
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Wed Dec 18 20:16:36 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449CE120091 for ; Wed, 18 Dec 2019 20:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 bfxEuPj6nNwU for ; Wed, 18 Dec 2019 20:16:32 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 EC6BA12004F for ; Wed, 18 Dec 2019 20:16:31 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id 77so5411475oty.6 for ; Wed, 18 Dec 2019 20:16:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QfODdJeCHeNxjqCowcoAC3OqffDyBvfQzwfQX7anH0A=; b=UOJF5nA/XHiFULoJNdBRze86sGo4RoxId07MmboYpaVgeqp/HQcZ5uAEE4UqInOGJv IXHq279D9tVJlitpUhYL+X4uR36lyxHs6+9wQRo0sTX3FGGXN7isOX5aZuupQSdYRZ3z V+XNzqtjcRz0cb3QA7d7Um2eR0Q8lsmEd24+A7G7Sr6ygp2YHNXKsTiQQeBp2KscyUCF qOoRImDqv1wecxtHqMBCxyqjLWfTVVEnvFOGZURJPPRvMBFgc/xVqbQxRh8fkbbBlmrn TGYsgWaI5ldI+I8Fb5iOIdncyDh9/1n4BIuLQectyLYFVcN6nxdPni6FVFJodq9eMSgm Dq+A==
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=QfODdJeCHeNxjqCowcoAC3OqffDyBvfQzwfQX7anH0A=; b=bkxRX22r4h4iBcVZP6VNE8tCEQBY8pX4g6r/M2UYnarMuxv4db6VEq4rc2ojOmGGAw w/g922Tnf6El1/CJweU7YuXzLLpCZ8wPf/4T4Gy9/Iiz+k5MqqTfPYRyBtnwJkU0sMLK S04NXM23jwoYLcHCQWQqN9XoVPCK3EThdJ/amO4bE5K6NVdvugLQpAhO1pm1aeWqHe+d vj6d5E3SeeHcY0H7GLsRdeMIPVCuEQglMfXyDJ3jpYMsbPxsF1bjRWK3NpENSFANsP9f MzJoEILNWZ4QRLaHhznjL6SQvvTGQaxF3z9SymNRymNwUD1TwJ2WwI2/DycOwMYhN5+A pITw==
X-Gm-Message-State: APjAAAVlpglq1MPk9viR9EdZYKEdT2Rt/6Xwc920DSplCaImp1oVxEOP H8lzAGaJ7cWe2xId3/IdCTtzrAzOSJediiz8UHLzM80PmDk=
X-Google-Smtp-Source: APXvYqxtxfr+KtSKUXLNEvPFaY3hxW7ipXedvlnlKs3ObzMwHaDqkL4WTI2X4VKnttbikIQaCTlTR8yvjuGBBTab2/Y=
X-Received: by 2002:a9d:4c94:: with SMTP id m20mr1213611otf.341.1576728990717;  Wed, 18 Dec 2019 20:16:30 -0800 (PST)
MIME-Version: 1.0
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com> 
In-Reply-To: 
From: Neal Cardwell 
Date: Wed, 18 Dec 2019 23:16:14 -0500
Message-ID: 
To: Yuchung Cheng 
Cc: Wesley Eddy , "tcpm@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tcpm] 793bis: TCP Quiet Time
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 04:16:34 -0000

On Wed, Dec 18, 2019 at 8:28 PM Yuchung Cheng
 wrote:
>
> On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy  wrote:
> >
> > I don't think I noticed anyone responding to Gorry's comment below, and
> > I haven't made any alterations in the 793bis draft with regard to this
> > (other than fixing some spelling mistakes).  I wanted to pull this into
> > its own thread in case other people have thoughts or would like to
> > discuss further what the quiet time concept's relevance is in 2020.
> I probably am missing something. What's the issue of the text? Linux
> to my knowledge does
> not implement this quiet time.
> But there are other injection attacks or basic checksum issues etc to
> corrupt TCP. (Serious) application that solely relying on TCP's
> integrity is signing up for troubles already ...

I would agree with Yuchung's remarks and the general point that the
"TCP Quiet Time Concept" from RFC 793 does not seem to be of practical
importance today, from a number of perspectives:

o I'm not aware of any major TCP implementation that actually follows
the "TCP Quiet Time" approach.

o Most production applications AFAIK end up using SO_REUSEADDR,
indicating a need to reuse ports quickly and a lack of concern about
this kind of issue with old packets ending up mixed into new
connections.

o Applications that care about this should be using cryptography.

o Users today expect to be able to reboot a machine and get back on
the network in less than 2 minutes.

best,
neal


From nobody Wed Dec 18 21:39:41 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD450120073 for ; Wed, 18 Dec 2019 21:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level: 
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 a6sz1emf7zN4 for ; Wed, 18 Dec 2019 21:39:37 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 AD96B120018 for ; Wed, 18 Dec 2019 21:39:37 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id r13so4509701ioa.3 for ; Wed, 18 Dec 2019 21:39:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mj+VLcHSc1E65pfppZGYL0Fe6zlNBMInccMPTIX5ySE=; b=A+S6FyzlJ3csyWzipzw5w99QLTJYTnk3eaSF0oHsHwqdSQPHCQCwGNP6ZGyKiJ897s h6uK0gsfudJtwr14l/JDCc3zeuY+xTeSEOc7oZVYMAlaqgGiBTeJaB/X88P/AzU3yuj0 5Xlf1aXhFA+aa3rQaakx5W09H79XqOw2tGcBpiOfSn55d2Beto2gS/EYRvKkhL/fRa9B O/ETZZUQUksIKGgos6Zpl781X/8cFxewkVLtzs05txPb2Fboqn3VqKjLzxVtaZpqsObB LtMjh7S00S5XLZSmE2U3dCFvFz6mIUx0myN6nZvfO7iC72ObZQYCVGn7A6VQAExEcoBZ Vgcg==
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=mj+VLcHSc1E65pfppZGYL0Fe6zlNBMInccMPTIX5ySE=; b=dXSCYLw82zDrb6WquCt+NAlCCqyk+IhyBypIbeiE9adcJya7cG3KLxJyf3Bj9/Dxym izJ24LZ6dJ7FHTDHjJsmXvMtJFFAe/oeslwwzqSlc/foOS3bWQsqKUPyQjHAO/yyFQF5 u7BG+acXov/Xs//9eE1MVThS46sCnVTlFUzdkpXxVpWdsODYOHRHo48dnZcK9mv7rSYL yrSDU5edYbWpTPRwYjDNJxQmc0n2OoaaSWmOR2KdBGMtTD+Fyg8rYDKZZ1qd8DCEaIe2 wH/AENdj2QygY7wb59CEPWTElUi71TUvqJ4CEn3WCroCmXRuUNMP47vgdvoAW6TIi/DY /fMQ==
X-Gm-Message-State: APjAAAU6ePMikR5hH9EOILU0uqbmc7YLZHop6WYIOt9Q/nBRWOx3Zdme yODFcmNfDHm4MleZdW7SkBHB80gVq8PJd5U9jLTsfw==
X-Google-Smtp-Source: APXvYqwXOvmBbW6oIVpdFiX/N65z2orjE+dn1bJNajYRKoBItnSsQ/x1eiSddQ0h4LgII5gnlebWakfY7z94baYFbRI=
X-Received: by 2002:a5d:899a:: with SMTP id m26mr4616456iol.241.1576733976773;  Wed, 18 Dec 2019 21:39:36 -0800 (PST)
MIME-Version: 1.0
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com>  
In-Reply-To: 
From: Matt Mathis 
Date: Wed, 18 Dec 2019 21:39:23 -0800
Message-ID: 
To: Neal Cardwell 
Cc: Yuchung Cheng , "tcpm@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000097938c059a07fc1e"
Archived-At: 
Subject: Re: [tcpm] 793bis: TCP Quiet Time
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 05:39:40 -0000

--00000000000097938c059a07fc1e
Content-Type: text/plain; charset="UTF-8"

I am under the impression that web servers do something different:
Normally the client sends the FIN, and the server holds FIN wait, but often
discards it before 2MSL to reduce memory pressure, however if the server
receives a new SYN for the same connection 4tuple (before it is discarded),
the server has the option to continue in the same sequence space, one byte
after the FIN.

I haven't looked, but what happens if a connection is in FIN wait, and a
new SYN arrives?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.


On Wed, Dec 18, 2019 at 8:16 PM Neal Cardwell  wrote:

> On Wed, Dec 18, 2019 at 8:28 PM Yuchung Cheng
>  wrote:
> >
> > On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy  wrote:
> > >
> > > I don't think I noticed anyone responding to Gorry's comment below, and
> > > I haven't made any alterations in the 793bis draft with regard to this
> > > (other than fixing some spelling mistakes).  I wanted to pull this into
> > > its own thread in case other people have thoughts or would like to
> > > discuss further what the quiet time concept's relevance is in 2020.
> > I probably am missing something. What's the issue of the text? Linux
> > to my knowledge does
> > not implement this quiet time.
> > But there are other injection attacks or basic checksum issues etc to
> > corrupt TCP. (Serious) application that solely relying on TCP's
> > integrity is signing up for troubles already ...
>
> I would agree with Yuchung's remarks and the general point that the
> "TCP Quiet Time Concept" from RFC 793 does not seem to be of practical
> importance today, from a number of perspectives:
>
> o I'm not aware of any major TCP implementation that actually follows
> the "TCP Quiet Time" approach.
>
> o Most production applications AFAIK end up using SO_REUSEADDR,
> indicating a need to reuse ports quickly and a lack of concern about
> this kind of issue with old packets ending up mixed into new
> connections.
>
> o Applications that care about this should be using cryptography.
>
> o Users today expect to be able to reboot a machine and get back on
> the network in less than 2 minutes.
>
> best,
> neal
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

--00000000000097938c059a07fc1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I am under the impression that web servers do something di=
fferent:=C2=A0 Normally the client sends the FIN, and the server holds FIN =
wait, but often discards it before 2MSL to reduce memory pressure, however =
if the server receives a new SYN for the same connection 4tuple (before it =
is discarded), the server has the option to continue in the same sequence s=
pace, one byte after the FIN.

I haven't looked, but =
what happens if a connection is in FIN wait, and a new SYN arrives?

Thanks,
--MM--
The best way to predict the futu=
re is to create it. =C2=A0- Alan Kay

We must not tolerate intoleranc=
e;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response mu=
st be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 too strong would be hypocritical and risks spiraling out of cont=
rol;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks bei=
ng mistaken for tacit approval.

On Wed, Dec 18, 2019 at 8:16 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org&g=
t; wrote:
On Wed=
, Dec 18, 2019 at 8:28 PM Yuchung Cheng

<ycheng=3D40google.com@dmarc.ietf.org> wrote:

>

> On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy <wes@mti-systems.com> wrote:

> >

> > I don't think I noticed anyone responding to Gorry's comm=
ent below, and

> > I haven't made any alterations in the 793bis draft with regar=
d to this

> > (other than fixing some spelling mistakes).=C2=A0 I wanted to pul=
l this into

> > its own thread in case other people have thoughts or would like t=
o

> > discuss further what the quiet time concept's relevance is in=
 2020.

> I probably am missing something. What's the issue of the text? Lin=
ux

> to my knowledge does

> not implement this quiet time.

> But there are other injection attacks or basic checksum issues etc to<=
br>
> corrupt TCP. (Serious) application that solely relying on TCP's
> integrity is signing up for troubles already ...



I would agree with Yuchung's remarks and the general point that the

"TCP Quiet Time Concept" from RFC 793 does not seem to be of prac=
tical

importance today, from a number of perspectives:



o I'm not aware of any major TCP implementation that actually follows
the "TCP Quiet Time" approach.



o Most production applications AFAIK end up using SO_REUSEADDR,

indicating a need to reuse ports quickly and a lack of concern about

this kind of issue with old packets ending up mixed into new

connections.



o Applications that care about this should be using cryptography.



o Users today expect to be able to reboot a machine and get back on

the network in less than 2 minutes.



best,

neal



_______________________________________________

tcpm mailing list

tcpm@ietf.org

https://www.ietf.org/mailman/listinfo/tcpm




--00000000000097938c059a07fc1e--


From nobody Thu Dec 19 06:57:26 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C3612002F for ; Thu, 19 Dec 2019 06:57:25 -0800 (PST)
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 CNOezRV-SauQ for ; Thu, 19 Dec 2019 06:57:23 -0800 (PST)
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 3E490120059 for ; Thu, 19 Dec 2019 06:57:23 -0800 (PST)
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=Sh8xtmjc1RCNFpvfZvZe+wYlW2H9EFUh5EPGiB/9lk0=; b=akLLO3KwOnt0KbBYQRSsfv52c lGGHjoHa6E+2OclK89cduHYZZmIoIhH9Jjw2wObq/yMkTYV23zIVisrhnhAYV1VkcdxtvsAdNy645 Wx+dciIpL+3lusP7IbrR2XdrYkTzzwGZV5u+/WnVlQ4jfDRv73EI87uvrfFkhh077fKO1+4HjjDkB Oe87mUxWOKFvVt92DPHmRkmJIwhukwIEEQPqTYgDe6WZdlIygfrcsWtimWmFUwGMKCm6BXb9Hz1iN eA0/MLUNFgiWw+g1ccpJinauPlo2YOjHvfY/zGTJPyv6pJDdkKyiK8KbdyW+eVLlwbnhHGV4If4KZ TL19ARF0Q==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59605 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ihxEs-002rhS-6S; Thu, 19 Dec 2019 09:57:22 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_0DC306B6-15A3-4A54-9875-2B2F439DF216"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch 
In-Reply-To: 
Date: Thu, 19 Dec 2019 06:57:17 -0800
Cc: Neal Cardwell , Yuchung Cheng , "tcpm@ietf.org" 
Message-Id: 
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com>   
To: Matt Mathis 
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: [tcpm] 793bis: TCP Quiet Time
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 14:57:25 -0000

--Apple-Mail=_0DC306B6-15A3-4A54-9875-2B2F439DF216
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This discussion seems to be overlooking the effect of timestamps.

Joe

> On Dec 18, 2019, at 9:39 PM, Matt Mathis =
 wrote:
>=20
> I am under the impression that web servers do something different:  =
Normally the client sends the FIN, and the server holds FIN wait, but =
often discards it before 2MSL to reduce memory pressure, however if the =
server receives a new SYN for the same connection 4tuple (before it is =
discarded), the server has the option to continue in the same sequence =
space, one byte after the FIN.
>=20
> I haven't looked, but what happens if a connection is in FIN wait, and =
a new SYN arrives?
>=20
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>=20
> We must not tolerate intolerance;
>        however our response must be carefully measured:=20
>             too strong would be hypocritical and risks spiraling out =
of control;
>             too weak risks being mistaken for tacit approval.
>=20
>=20
> On Wed, Dec 18, 2019 at 8:16 PM Neal Cardwell =
> wrote:
> On Wed, Dec 18, 2019 at 8:28 PM Yuchung Cheng
> > wrote:
> >
> > On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy > wrote:
> > >
> > > I don't think I noticed anyone responding to Gorry's comment =
below, and
> > > I haven't made any alterations in the 793bis draft with regard to =
this
> > > (other than fixing some spelling mistakes).  I wanted to pull this =
into
> > > its own thread in case other people have thoughts or would like to
> > > discuss further what the quiet time concept's relevance is in =
2020.
> > I probably am missing something. What's the issue of the text? Linux
> > to my knowledge does
> > not implement this quiet time.
> > But there are other injection attacks or basic checksum issues etc =
to
> > corrupt TCP. (Serious) application that solely relying on TCP's
> > integrity is signing up for troubles already ...
>=20
> I would agree with Yuchung's remarks and the general point that the
> "TCP Quiet Time Concept" from RFC 793 does not seem to be of practical
> importance today, from a number of perspectives:
>=20
> o I'm not aware of any major TCP implementation that actually follows
> the "TCP Quiet Time" approach.
>=20
> o Most production applications AFAIK end up using SO_REUSEADDR,
> indicating a need to reuse ports quickly and a lack of concern about
> this kind of issue with old packets ending up mixed into new
> connections.
>=20
> o Applications that care about this should be using cryptography.
>=20
> o Users today expect to be able to reboot a machine and get back on
> the network in less than 2 minutes.
>=20
> best,
> neal
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org 
> https://www.ietf.org/mailman/listinfo/tcpm =

> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


--Apple-Mail=_0DC306B6-15A3-4A54-9875-2B2F439DF216
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

This =
discussion seems to be overlooking the effect of timestamps.

Joe
On Dec =
18, 2019, at 9:39 PM, Matt Mathis <mattmathis=3D40google.com@dmarc.ietf.org> =
wrote:

I am under the impression that web servers do =
something different:  Normally the client sends the FIN, and the =
server holds FIN wait, but often discards it before 2MSL to reduce =
memory pressure, however if the server receives a new SYN for the same =
connection 4tuple (before it is discarded), the server has the option to =
continue in the same sequence space, one byte after the FIN.

I haven't looked, but =
what happens if a connection is in FIN wait, and a new SYN =
arrives?

Thanks,
--MM--
The best =
way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response =
must be carefully measured: 
    =
        too strong would be hypocritical and risks =
spiraling out of control;
      =
      too weak risks being mistaken for tacit =
approval.


On Wed, Dec 18, 2019 at 8:16 PM Neal =
Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
On Wed, Dec 18, 2019 at 8:28 PM =
Yuchung Cheng

<ycheng=3D40google.com@dmarc.ietf.org> =
wrote:

>

> On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy <wes@mti-systems.com> wrote:

> >

> > I don't think I noticed anyone responding to Gorry's comment =
below, and

> > I haven't made any alterations in the 793bis draft with regard =
to this

> > (other than fixing some spelling mistakes).  I wanted to =
pull this into

> > its own thread in case other people have thoughts or would =
like to

> > discuss further what the quiet time concept's relevance is in =
2020.

> I probably am missing something. What's the issue of the text? =
Linux

> to my knowledge does

> not implement this quiet time.

> But there are other injection attacks or basic checksum issues etc =
to

> corrupt TCP. (Serious) application that solely relying on TCP's

> integrity is signing up for troubles already ...



I would agree with Yuchung's remarks and the general point that the

"TCP Quiet Time Concept" from RFC 793 does not seem to be of =
practical

importance today, from a number of perspectives:



o I'm not aware of any major TCP implementation that actually follows

the "TCP Quiet Time" approach.



o Most production applications AFAIK end up using SO_REUSEADDR,

indicating a need to reuse ports quickly and a lack of concern about

this kind of issue with old packets ending up mixed into new

connections.



o Applications that care about this should be using cryptography.



o Users today expect to be able to reboot a machine and get back on

the network in less than 2 minutes.



best,

neal



_______________________________________________

tcpm mailing list

tcpm@ietf.org

https://www.ietf.org/mailman/listinfo/tcpm



_______________________________________________
tcpm =
mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

=

--Apple-Mail=_0DC306B6-15A3-4A54-9875-2B2F439DF216--


From nobody Thu Dec 19 08:22:59 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC683120998 for ; Thu, 19 Dec 2019 08:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 kIqRsb8BqNeI for ; Thu, 19 Dec 2019 08:22:51 -0800 (PST)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 E551E120980 for ; Thu, 19 Dec 2019 08:22:35 -0800 (PST)
Received: by mail-qk1-x72d.google.com with SMTP id t129so5068495qke.10 for ; Thu, 19 Dec 2019 08:22:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=qwb45s+wEHaJ/WB4BGDVF8zTQn2gkSxQnKVn78gPvnc=; b=U5qgUN48DcrE6h0HdNiY+Lo2klpXh+tjxnfzQcngbg3S7mf95l0t05eejwMt11FD/v uEr75CpOdPkqjSjxHiNEGCS+RbjDPRsjnP776dVMKgM+DKvHNaENr0CKiuWKpS1+qssY pHR2rP/yZrgfK6TM3My5Oe/9MW2rVNPgJHywp4BlchJ7XJatf2oNkkIrVG+EwEAO4xDY u9SX0vzDjla+sYG8Hc8mxtwYX4CQ1ouTNRzozkVgC5bcTcFNO7l48SCK0OmtJZyZqxxg t59v1s1hhiVSlTF3FTiTGjgah+/s/uYs042ipq3cf7lA8WAK6lL44qiQxt3XJ8/zP78n Fpnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qwb45s+wEHaJ/WB4BGDVF8zTQn2gkSxQnKVn78gPvnc=; b=Ipqm5RKLy9nqjhGlVcgxiNFOVM9epsvM1YeE+UwmXGqud8eVqwRqca1pNp6ato1q0c ULpvcoINq7fTRySP/iprYHnU+ykI45lAcU3kI5oFQBsNd/oFPb9+WRmPIOHAiNy/36T7 pkPU6e1ceGwZnBT4TPaaNNZnjW2MrhPSaZTQ/6V4Y6tqGIXkjwxsNZ2S9meY0QuoHXqj G9GhUR9HUHBNfGIWv1Hn6jHXTkDMMZy16zcrhZTinxn012+YLH3T1ILRyNSwDBeHyAYF hoZoci+FKKLUkD9YsPiffp97m88MiYzIFvZ5etAVccKsnlsQZKTK+N5/uvQKLvu+hQmf pRmg==
X-Gm-Message-State: APjAAAWobUnOpoQxU1S+kAHCqewATYiGJ7PiPB1YUBewv1rLlYM9+ZH5 S+U3X/OvD33oEOImtrIYbUpleeBdL0Q=
X-Google-Smtp-Source: APXvYqy5FT9meqKkAry0SjEi2tH7tHPxzpTCedCLpOH54vW4krd7TsQkag7/wO43ShLcAqp3LBXlaA==
X-Received: by 2002:a37:88c2:: with SMTP id k185mr9110248qkd.317.1576772554749;  Thu, 19 Dec 2019 08:22:34 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id b3sm1964384qtr.86.2019.12.19.08.22.34 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2019 08:22:34 -0800 (PST)
To: tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: 
Date: Thu, 19 Dec 2019 11:22:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D66A044.3060904@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [tcpm] 793bis: reset generation section
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 16:22:58 -0000

Gorry had a few comments on the "Reset Generation" section of 793bis 
that I have some proposed responses for:


On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> ---
> OLD:
>     As a general rule, reset (RST) must be sent whenever...
> - I can't fathom what was intended, isn't this a RFC2119 SHOULD?

I think there's more specific text elsewhere, so we probably shouldn't 
put 2119 language here.  Instead of "must be sent" we might just say "is 
sent".


> ---
> OLD:
>    SYNs addressed to a non-existent connection are
>    rejected by this means.
> - Is that a complicated way of saying an RST is sent, or is it 
> something else, please clarify,
> is the word "addressed" correct here? Could this be rewritten as a 
> "SYN segment that
> does not match an existing connection..."

I'm fine with this editorial change, if nobody objects.


> - This then leads me to ask why this does not refer to SYN cookies?

I'm not sure that's needed or directly relevant, because SYN cookies are 
for protecting actual listening sockets (not non-existent ones).


> ---
> OLD:
>       any unacceptable segment (out of window sequence number or
>       unacceptable acknowledgment number) must elicit only an empty
>       acknowledgment segment containing
> - what does "elicit" mean here and what is an empty ACK segment?

I think it's just editorial, but we could change:

"elicit only an empty acknowledgement segment"

to:

"be responded to with an empty acknowledgement segment (without any user 
data)"



From nobody Thu Dec 19 08:26:06 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486301200E3 for ; Thu, 19 Dec 2019 08:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 BubkyNKBtb-5 for ; Thu, 19 Dec 2019 08:26:04 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 D29531200A4 for ; Thu, 19 Dec 2019 08:26:03 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id j5so5505266qtq.9 for ; Thu, 19 Dec 2019 08:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=qYeZ6d7dzbnK8EFI3TH11bkRNWDPjBxWrfQjO/kh7/U=; b=kWf75RF9pu6e5FRZKLvhiRQ1JqfL68+h6oTaxpreC0wjVby8dCUhSxfPQE9ldycrCg 1dLFPqyaQUgVsCVetqlwZdUk4hXhrcZzN7Hl2x4u00BPgWXbwg7XBudOIHQwcRtyTRMw VWq8BOn8h92d8PNh9axC2dnXGM13E7Joym0vzbZn0kLzEqLFv4ZLtjp0FMeOfDesUbYC dT7g6piFpa2rNX7L/RoUBw4lwb96kyoO39mZa6/4/LOJKtKswW9IH0BYgo97MU5o9gOq vNYLcN5gsPLkoKjqehh6Smy1L5K+PvJgEl6dSR7LDt+qZT4U26T4gxM2nmmerGV0iaTS H5Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qYeZ6d7dzbnK8EFI3TH11bkRNWDPjBxWrfQjO/kh7/U=; b=XDwBfl7M/eKbw7KHeiHdIxu2Zs4H3YmjvnH7no5D527w14RXaVTLf2DiDG2bXnOkQ/ P4EUlQpgQJiBYt9Tjo3rQzVOmNiz1pak8c347cG1lqt96jovS/DwK6Y0rZHdiXikr7y4 pnlwwHq3wplbkQdx3WGLkHCqbOip/CdAkju8NxvmbaxCe7N8QG64R0nKllWqki4YVdz0 VDX9o6KiPSKtAhs8fi0Z9Wim/OqXKRMQgJWZj9oFuKh5VcE0Cy7nd70rLhg0Q36Dv1sP LYLJvqQXfoD9yoZVMkZNMVYis96SbmW78ssMEwu4UcRSRERYZ/J6jz43bvZHpm0cR712 7/FA==
X-Gm-Message-State: APjAAAXHI+OgjBMbwQNjZeT1ITjbT2P/Q2LdO9vNp4CJ/EhVB5BE3Oj0 MmyvcySJ1dZPZkOKRm9mS0INSmdK30M=
X-Google-Smtp-Source: APXvYqyCcc0l7L+ufrxgCYosZgZ6OjuP4O+7AtvWePyysJ/VzYHGSgV/TJmR0L5iUM3ePGaZvJnraA==
X-Received: by 2002:aed:3e21:: with SMTP id l30mr7854056qtf.357.1576772762718;  Thu, 19 Dec 2019 08:26:02 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id j1sm1827800qkl.86.2019.12.19.08.26.01 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2019 08:26:02 -0800 (PST)
To: tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: <1af8bf06-62af-8b78-65fc-121b6c51513f@mti-systems.com>
Date: Thu, 19 Dec 2019 11:26:01 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D66A044.3060904@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [tcpm] 793bis: IPv6 jumbograms
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 16:26:05 -0000

I'm planning to apply Gorry's suggested text below directly, unless 
anyone has objections or other thoughts?

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> OLD:
> 3.7.5.  IPv6 Jumbograms
>
>    In order to support TCP over IPv6 jumbograms, implementations need to
>    be able to send TCP segments larger than the 64KB limit that the MSS
>    option can convey.  RFC 2675 [6] defines that an MSS value of 65,535
>    bytes is to be treated as infinity, and Path MTU Discovery [3] is
>    used to determine the actual MSS.
> - This was discussed in the 6Man WG in Montreal, and while there was no
> consensus reached to obsolete jumbograms, there was encouragement
> to ensure that specs describe jumbo grams appropriate, rather than
> suggesting support is required. In this sense, I recommend adding
> something like:
> NEW:
>    The Jumbo Payload option need not be implemented or understood by
>    IPv6 nodes that do not support attachment to links with a MTU greater
>    than 65,575 [RFC2675], and  the present IPv6 Node Requirements
>    does not include support for Jumbograms [RFC8504]. 


From nobody Thu Dec 19 08:53:45 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E381200E3 for ; Thu, 19 Dec 2019 08:53:43 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=mti-systems-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 T00Qrkb62o-R for ; Thu, 19 Dec 2019 08:53:41 -0800 (PST)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 5EDC21200A4 for ; Thu, 19 Dec 2019 08:53:41 -0800 (PST)
Received: by mail-qt1-x834.google.com with SMTP id 38so5571115qtb.13 for ; Thu, 19 Dec 2019 08:53:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=gsMf/wgN1vTWDhOy+Y2HVfIvb+me21asppvn0bPF84E=; b=BvhVVGfNfmXFOo5p9OrazUAu2bmx2LEvdPhJNnWf6d6Tae+ORKYiycr129BmYqoDW0 ICM71f52HV63yC/IjWrbU4C3DSRiUd5g5ORTsb86Umw+LKDLdZeQzCaxceUoADm03ccG qayYI+xtWmj2ka5sKoFw5kXjNTprwK0STTUv2J65CU201lOTVdxsE3sZ3NBMbmwYmCxl tcC2qy6rvqJNe7/Dzrj5unjy9lCVopoqr8yFJXgS/fJ/oD/1lRfarn628/ZPAgIhXPDb 1Zx7XCRwUYAxjchsu7ICGlFw4L/zKFRIwd+RA3fjj2q9QNt0Hh4CIyMf0FQQhzWWQWC5 M3Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=gsMf/wgN1vTWDhOy+Y2HVfIvb+me21asppvn0bPF84E=; b=euS5J0edpzRDpxuifmQY/b2KBOxQwTy+0dL6Hx0NMIip0pG3j5itSXof/Sz984eYen kbEp8+s3AAzX7sJ9c9NxmQJY5MFIyUlDovE7exwvBKV1iRQFSYT9xulKPoAC354AVDGS GVnhD7uwIgC8bJklPLF0Jn411h98bVysdhRUlwpO08WxeBY1q79WHdXgT6LHZUCRWV9/ dpqATnO1edEFvrdgjKy69icsneqkjFASq8v0JtLSn7FxjkXuM/gIP0LY/9+zAIp8Hkag oblV3ayVSb2x16BRQh4BwmXk7tw0YdpdPrNQqKlRJ355NGnk859RPwzKT8zN+YQ6CkO7 GLqA==
X-Gm-Message-State: APjAAAWc/1vUdBQv32XdGZjW34E4IGicx2Cq+Ub5bdZTeMDlNjrLcq/f ogS1G/XIu+SFnjDVjNBY0Tgp8UokzVM=
X-Google-Smtp-Source: APXvYqxSMlReMKWO8beokWNlV74HMkYeWAx4cc/BGkrZRHJFrtv02yH1W2aRRBYrASinIIDOWFsjuQ==
X-Received: by 2002:ac8:681:: with SMTP id f1mr7802623qth.58.1576774420377; Thu, 19 Dec 2019 08:53:40 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id 4sm1881755qki.51.2019.12.19.08.53.39 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2019 08:53:39 -0800 (PST)
To: tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: <06dc557e-9ec1-abd5-4c81-59d123c33bf2@mti-systems.com>
Date: Thu, 19 Dec 2019 11:53:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D66A044.3060904@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [tcpm] 793bis: variable MTU
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 16:53:44 -0000

I'm not sure the comment & suggested NEW text below is quite correct.  I 
tracked the text in question down to being from RFC 6691 (and it first 
appeared in -03 of draft-ietf-tcpm-tcpmss-03, and it looks like it came 
about from a thread here: 
https://mailarchive.ietf.org/arch/msg/tcpm/LjfmysjQAKmTudpBgBa2Jp20O3M ).

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> OLD:
>    As a result, when the effective MTU of an interface varies, TCP
>    SHOULD use the smallest effective MTU of the interface to calculate
>    the value to advertise in the MSS option (SHLD-6).
> - what does "varies" mean here? The MSS is computed when the SYN is 
> exchanged
> is this actually just:
> NEW:
>    When multiple IP interfaces have different effective MTUs, TCP
>    SHOULD use the smallest effective MTU of the interface to calculate
>    the value to advertise in the MSS option (SHLD-6). 




From nobody Thu Dec 19 09:04:38 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACA11200A4 for ; Thu, 19 Dec 2019 09:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 BaJRsNwZQN9h for ; Thu, 19 Dec 2019 09:04:34 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 532E5120271 for ; Thu, 19 Dec 2019 09:04:34 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id q20so5642154qtp.3 for ; Thu, 19 Dec 2019 09:04:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=0eo1IpI8J07aTXAHLKHmBnJ2U0vpWEXcCJ83uKda9Xw=; b=bsvQdt6fn1psQMm0R4mU43JFkQbvmlVu177M7CDrH3kVlXwg3F9T5zLrC24r9B8DZh B5+/+sgiSJ+nvGHW8CPQisrM3M7m4lKYcFADMSjCjNZV0y2Bh5lMEJsvY9SYBqZW1rcK XAFbhImzoEJJ4mIzzzR3RYeMUGYiKs/AxIfSRV6bR3Ur0c1Xl8RyF2SBIwwq/xqB2+L+ V7axrd18X9CMYEZOGdUD19pI6q4gqmCcPq6FeqvZb6+8NXweZhPe6P1OhaNp+cdwuRa3 fIfIEMf8pKw1Gc/1JnhWL7F2ejuqkHnwyTwTbbWgi6Mcg9injn233JEo2F8KBuiaFjNj ha7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=0eo1IpI8J07aTXAHLKHmBnJ2U0vpWEXcCJ83uKda9Xw=; b=aXnArhk5+hQCIPYHNbHHoGyEhvznYQoaL5zWkl6JD9KnQnHkCbMgu3m+6Y1CsJL0XB wGoLIyjZephE6Gj5n1RFqgaeRka/+itLTHLOVMU3rKaJb+MsA9pWcKNve6KJFSCj1bYt 7+clvyKt8fWOXwQvomF2HZOmLaAHtdPyI64iHILMCAeuiQ8ORfDMpXcLmx/Smdjkc0Tq q+liTRPgliCIN3f4NeulWs6RSNxwZPxR3EKcDo4HINHPvSCQxbfjD0JBI9BuOFGKUk13 Ru6pGA8emY7lkYq5H4DSG+3bQ2lUItdvdmK8G7GATPEviPATHI/HxM5phitCxSjS/eeQ uW/w==
X-Gm-Message-State: APjAAAUhGTqXmhlCNAMJezOqNaSoz8/aq8s8jZiq7AQdBmG7twPjiiLb OAI2W2Lj7AzfmTMxoGYthjlrRIK7rvc=
X-Google-Smtp-Source: APXvYqzWRLpfAXViKy6Xe5e+tduQyP/1OiD6k1BoMajiN1baIaqdBxbPB01IOgmyL9YXxM1czsgOzg==
X-Received: by 2002:ac8:6982:: with SMTP id o2mr7930065qtq.299.1576775073314;  Thu, 19 Dec 2019 09:04:33 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id s20sm1851101qkg.131.2019.12.19.09.04.32 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2019 09:04:32 -0800 (PST)
To: tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: 
Date: Thu, 19 Dec 2019 12:04:31 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D66A044.3060904@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 17:04:37 -0000

While I think Gorry's comment below is pretty much correct, this is 
direct from RFC 1122's material on TCP.  I'm proposing not to change 
anything about this at the moment, since I don't think any harm is done 
by saying this.

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> Section 3.8.1
> OLD:
>    If a retransmitted packet is identical to the original packet (which
>    implies not only that the data boundaries have not changed, but also
>    that the window and acknowledgment fields of the header have not
>    changed), then the same IP Identification field MAY be used (see
>    Section 3.2.1.5 of RFC 1122) (MAY-4).
> - What is this MAY about? Is it about the IPv4 IPID field and is that 
> really
> important for a TCP spec? 


From nobody Thu Dec 19 09:21:28 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8261120868 for ; Thu, 19 Dec 2019 09:21:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 V0TmLGPH1bIy for ; Thu, 19 Dec 2019 09:21:25 -0800 (PST)
Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (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 198C41207FC for ; Thu, 19 Dec 2019 09:21:25 -0800 (PST)
Received: from davidbormansmbp.americas.cray.com (msp-nat.cray.com [136.162.2.1]) (authenticated bits=0) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id xBJHQjHc015923 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2019 11:26:45 -0600
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: David Borman 
In-Reply-To: 
Date: Thu, 19 Dec 2019 11:21:24 -0600
Cc: tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com>
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> 
To: "Wesley M. Eddy" 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 17:21:27 -0000

This has to do with the fact that the IPID field is used to do =
fragmentation reassembly.  It is ok to reuse the same IPID when =
retransmitting, as long as the retransmitted packet is identical to the =
original packet, not just the TCP data, but also all the TCP headers.  =
If the two packets aren=E2=80=99t identical and they are fragmented, =
then using the same IPID could cause the receiver to not properly =
reassemble the packet.

What this also says is that, if a TCP implementation is such that it =
buffers up previously sent packets for possible retransmission and =
retransmits them verbatim, it doesn=E2=80=99t have to change the IPID =
just because it is a retransmission.  But if there are any differences =
between the original and the retransmitted packet, then the IPID must be =
updated.

			-David Borman

> On Dec 19, 2019, at 11:04 AM, Wesley Eddy  wrote:
>=20
> While I think Gorry's comment below is pretty much correct, this is =
direct from RFC 1122's material on TCP.  I'm proposing not to change =
anything about this at the moment, since I don't think any harm is done =
by saying this.
>=20
> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>> Section 3.8.1
>> OLD:
>>    If a retransmitted packet is identical to the original packet =
(which
>>    implies not only that the data boundaries have not changed, but =
also
>>    that the window and acknowledgment fields of the header have not
>>    changed), then the same IP Identification field MAY be used (see
>>    Section 3.2.1.5 of RFC 1122) (MAY-4).
>> - What is this MAY about? Is it about the IPv4 IPID field and is that =
really
>> important for a TCP spec?=20
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>=20


From nobody Thu Dec 19 09:24:11 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E001207FC for ; Thu, 19 Dec 2019 09:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 74-vWnGBovcR for ; Thu, 19 Dec 2019 09:24:07 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 28C2B1202DD for ; Thu, 19 Dec 2019 09:24:06 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5ACE51B0022B; Thu, 19 Dec 2019 17:24:03 +0000 (GMT)
Message-ID: <5DFBB232.8080602@erg.abdn.ac.uk>
Date: Thu, 19 Dec 2019 17:24:02 +0000
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: Wesley Eddy 
CC: tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <06dc557e-9ec1-abd5-4c81-59d123c33bf2@mti-systems.com>
In-Reply-To: <06dc557e-9ec1-abd5-4c81-59d123c33bf2@mti-systems.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [tcpm] 793bis: variable MTU
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 17:24:10 -0000

On 19/12/2019, 16:53, Wesley Eddy wrote:
> I'm not sure the comment & suggested NEW text below is quite correct.  
> I tracked the text in question down to being from RFC 6691 (and it 
> first appeared in -03 of draft-ietf-tcpm-tcpmss-03, and it looks like 
> it came about from a thread here: 
> https://mailarchive.ietf.org/arch/msg/tcpm/LjfmysjQAKmTudpBgBa2Jp20O3M ).
>
> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>> OLD:
>>    As a result, when the effective MTU of an interface varies, TCP
>>    SHOULD use the smallest effective MTU of the interface to calculate
>>    the value to advertise in the MSS option (SHLD-6).
>> - what does "varies" mean here? The MSS is computed when the SYN is 
>> exchanged
>> is this actually just:
>> NEW:
>>    When multiple IP interfaces have different effective MTUs, TCP
>>    SHOULD use the smallest effective MTU of the interface to calculate
>>    the value to advertise in the MSS option (SHLD-6). 
>
You are indeed correct!

This makes muchmore sense if we refer back to that thread, which was 
about the same interface having maximum packet sizes that vary from 
packet-to-packet, e.g. from  variable-length headers/encapsulations are 
used by the local a link.

An interface SHOULD use the smallest effective MTU that can be used in 
all packets to calculate the value to advertise in the MSS option (SHLD-6).

Gorry

>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Thu Dec 19 09:32:59 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB531202DD for ; Thu, 19 Dec 2019 09:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 QeQFmmGN_yuB for ; Thu, 19 Dec 2019 09:32:55 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7013C120072 for ; Thu, 19 Dec 2019 09:32:55 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 457B31B000A6; Thu, 19 Dec 2019 17:32:51 +0000 (GMT)
Message-ID: <5DFBB442.60001@erg.abdn.ac.uk>
Date: Thu, 19 Dec 2019 17:32:50 +0000
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: David Borman 
CC: "Wesley M. Eddy" , tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>  <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com>
In-Reply-To: <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 17:32:58 -0000

I get this - but if we keep this, I think it should expliclity say *all 
headers have not changed*.

I still think this is a terrible hack to say the transport touches 
something in the network layer - because I have no idea how this sits 
with using TSOpt to disam=biguate retransmissions and extension headers, 
should they be used.

Anyway, this is so very IPv4 centric, I think if we keep this, we should 
call IPv4 out explicitly.

Gorry

On 19/12/2019, 17:21, David Borman wrote:
> This has to do with the fact that the IPID field is used to do fragmentation reassembly.  It is ok to reuse the same IPID when retransmitting, as long as the retransmitted packet is identical to the original packet, not just the TCP data, but also all the TCP headers.  If the two packets aren’t identical and they are fragmented, then using the same IPID could cause the receiver to not properly reassemble the packet.
>
> What this also says is that, if a TCP implementation is such that it buffers up previously sent packets for possible retransmission and retransmits them verbatim, it doesn’t have to change the IPID just because it is a retransmission.  But if there are any differences between the original and the retransmitted packet, then the IPID must be updated.
>
> 			-David Borman
>
>> On Dec 19, 2019, at 11:04 AM, Wesley Eddy  wrote:
>>
>> While I think Gorry's comment below is pretty much correct, this is direct from RFC 1122's material on TCP.  I'm proposing not to change anything about this at the moment, since I don't think any harm is done by saying this.
>>
>> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>>> Section 3.8.1
>>> OLD:
>>>     If a retransmitted packet is identical to the original packet (which
>>>     implies not only that the data boundaries have not changed, but also
>>>     that the window and acknowledgment fields of the header have not
>>>     changed), then the same IP Identification field MAY be used (see
>>>     Section 3.2.1.5 of RFC 1122) (MAY-4).
>>> - What is this MAY about? Is it about the IPv4 IPID field and is that really
>>> important for a TCP spec?
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Thu Dec 19 09:47:32 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E7B12088D for ; Thu, 19 Dec 2019 09:47:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 84rYbzKJvB3x for ; Thu, 19 Dec 2019 09:47:28 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792D61208F4 for ; Thu, 19 Dec 2019 09:47:13 -0800 (PST)
Received: from [IPv6:2a02:8109:1140:c3d:44ee:a88c:58ca:207e] (unknown [IPv6:2a02:8109:1140:c3d:44ee:a88c:58ca:207e]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id E250071E3F909; Thu, 19 Dec 2019 18:47:08 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Michael Tuexen 
In-Reply-To: <5DFBB442.60001@erg.abdn.ac.uk>
Date: Thu, 19 Dec 2019 18:47:08 +0100
Cc: David Borman , tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A3E9FC0-27F2-4BB4-9F43-F3940E5CFC8E@lurchi.franken.de>
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>  <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <5DFBB442.60001@erg.abdn.ac.uk>
To: Gorry Fairhurst 
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 17:47:31 -0000

> On 19. Dec 2019, at 18:32, Gorry Fairhurst  =
wrote:
>=20
> I get this - but if we keep this, I think it should expliclity say =
*all headers have not changed*.
The TCP timestamp option comes up to my mind. For TCP retransmission, =
the TSVal would be different.

Best regards
Michael
>=20
> I still think this is a terrible hack to say the transport touches =
something in the network layer - because I have no idea how this sits =
with using TSOpt to disam=3Dbiguate retransmissions and extension =
headers, should they be used.
>=20
> Anyway, this is so very IPv4 centric, I think if we keep this, we =
should call IPv4 out explicitly.
>=20
> Gorry
>=20
> On 19/12/2019, 17:21, David Borman wrote:
>> This has to do with the fact that the IPID field is used to do =
fragmentation reassembly.  It is ok to reuse the same IPID when =
retransmitting, as long as the retransmitted packet is identical to the =
original packet, not just the TCP data, but also all the TCP headers.  =
If the two packets aren=E2=80=99t identical and they are fragmented, =
then using the same IPID could cause the receiver to not properly =
reassemble the packet.
>>=20
>> What this also says is that, if a TCP implementation is such that it =
buffers up previously sent packets for possible retransmission and =
retransmits them verbatim, it doesn=E2=80=99t have to change the IPID =
just because it is a retransmission.  But if there are any differences =
between the original and the retransmitted packet, then the IPID must be =
updated.
>>=20
>> 			-David Borman
>>=20
>>> On Dec 19, 2019, at 11:04 AM, Wesley Eddy  =
wrote:
>>>=20
>>> While I think Gorry's comment below is pretty much correct, this is =
direct from RFC 1122's material on TCP.  I'm proposing not to change =
anything about this at the moment, since I don't think any harm is done =
by saying this.
>>>=20
>>> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>>>> Section 3.8.1
>>>> OLD:
>>>>    If a retransmitted packet is identical to the original packet =
(which
>>>>    implies not only that the data boundaries have not changed, but =
also
>>>>    that the window and acknowledgment fields of the header have not
>>>>    changed), then the same IP Identification field MAY be used (see
>>>>    Section 3.2.1.5 of RFC 1122) (MAY-4).
>>>> - What is this MAY about? Is it about the IPv4 IPID field and is =
that really
>>>> important for a TCP spec?
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>=20
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Thu Dec 19 10:42:56 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A54120AE1 for ; Thu, 19 Dec 2019 10:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level: 
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QFSKmTqnqqd2 for ; Thu, 19 Dec 2019 10:42:47 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 71E8D120AC5 for ; Thu, 19 Dec 2019 10:42:47 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id z12so5697500iln.11 for ; Thu, 19 Dec 2019 10:42:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FPj4cNHfUmQSXN2CDiTaacpxQ6sD9YhORgM4h01tHPk=; b=anl9iirKRrOZlMnn2lff6uqTKjpSfZ9SVtBa6VXiLrAZpYDCSzpCSpOORxRSWBn8Ub WPZaQ9Kx9uzD6F5laGdSG0u59JkRwjH7TxOd7O90tLizz+fesmft0w/aQC4Sgy3UwM3b OHCV+BJiWFIGNsi6HsJth3ipQrmUpo3TDpfnNySq7+HFvl0rdlkepsVd/7uLuH7zrCUO OKVVuHUOVmG7ngdvfL1FTbRKEJ0kZxaL2pOQQvfEE1uoDJDM9hToQjmF0QUOq4d7jC4d 3LpU7gQF1AL/cuQ9SsAGei6zgo0kljawV36tWO7SzVrxM4F7qsTetEh4tjeophk7mk1T c7Yw==
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=FPj4cNHfUmQSXN2CDiTaacpxQ6sD9YhORgM4h01tHPk=; b=LJPCNUNsynwZSOmjhhfRGoic//IYH6THnToAX3RyiGkcilK1s/5yp0HtHo69Azhr88 R7fAkalzLuF7LRGwPTbiWbH0lxqMln1k5W0ieEK+2dQIZ9fO6wbEv4t1xrVidYOsNfH7 CrGJ8ACNPV1SEI99m4DXzmjbtQuYOJbckyGpVxApIYrWPy5wZumR5/DqbiIRjzsIJz5c UIR6pDKHpAwA/cN6tUTdHIbo38HKv1Et6zZ1CbCA7MgWCDaETBu/8GpqYBIqoCeLu19Q SB5fKPCy8jvIlxyTEC55dY4LmPVz7KUCj3cIC3tIcVy3mQSoveC2kZwaTASTI7P/btGq GK2w==
X-Gm-Message-State: APjAAAW+4lcK9dwQDW4iBzMUkCDSpRQYAaXUU9707ndzWVGxtqc0B65Q gdP+kMyIFA/tYE8WoT36X85uvtshz/OgTWMo3ydRAg==
X-Google-Smtp-Source: APXvYqxLYTrKnA9sLlJuHRg6KLau0yZRg866VsJCgGoLeYvV+5J+rzoDrIi1i68XP3s0rW5uWeO99O33onm1qwajki8=
X-Received: by 2002:a92:ba93:: with SMTP id t19mr8881027ill.0.1576780966459; Thu, 19 Dec 2019 10:42:46 -0800 (PST)
MIME-Version: 1.0
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com>    
In-Reply-To: 
From: Matt Mathis 
Date: Thu, 19 Dec 2019 10:42:33 -0800
Message-ID: 
To: Joe Touch 
Cc: Neal Cardwell , Yuchung Cheng ,  "tcpm@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000065916e059a12ed34"
Archived-At: 
Subject: Re: [tcpm] 793bis: TCP Quiet Time
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 18:42:55 -0000

--00000000000065916e059a12ed34
Content-Type: text/plain; charset="UTF-8"

What Joe said s/effect/opportunities/

Is there standards language anywhere about successive connections sharing
sequence space and timestamps?  If there is, I missed it.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.


On Thu, Dec 19, 2019 at 6:57 AM Joe Touch  wrote:

> This discussion seems to be overlooking the effect of timestamps.
>
> Joe
>
> On Dec 18, 2019, at 9:39 PM, Matt Mathis <
> mattmathis=40google.com@dmarc.ietf.org> wrote:
>
> I am under the impression that web servers do something different:
> Normally the client sends the FIN, and the server holds FIN wait, but often
> discards it before 2MSL to reduce memory pressure, however if the server
> receives a new SYN for the same connection 4tuple (before it is discarded),
> the server has the option to continue in the same sequence space, one byte
> after the FIN.
>
> I haven't looked, but what happens if a connection is in FIN wait, and a
> new SYN arrives?
>
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
> We must not tolerate intolerance;
>        however our response must be carefully measured:
>             too strong would be hypocritical and risks spiraling out of
> control;
>             too weak risks being mistaken for tacit approval.
>
>
> On Wed, Dec 18, 2019 at 8:16 PM Neal Cardwell  40google.com@dmarc.ietf.org> wrote:
>
>> On Wed, Dec 18, 2019 at 8:28 PM Yuchung Cheng
>>  wrote:
>> >
>> > On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy 
>> wrote:
>> > >
>> > > I don't think I noticed anyone responding to Gorry's comment below,
>> and
>> > > I haven't made any alterations in the 793bis draft with regard to this
>> > > (other than fixing some spelling mistakes).  I wanted to pull this
>> into
>> > > its own thread in case other people have thoughts or would like to
>> > > discuss further what the quiet time concept's relevance is in 2020.
>> > I probably am missing something. What's the issue of the text? Linux
>> > to my knowledge does
>> > not implement this quiet time.
>> > But there are other injection attacks or basic checksum issues etc to
>> > corrupt TCP. (Serious) application that solely relying on TCP's
>> > integrity is signing up for troubles already ...
>>
>> I would agree with Yuchung's remarks and the general point that the
>> "TCP Quiet Time Concept" from RFC 793 does not seem to be of practical
>> importance today, from a number of perspectives:
>>
>> o I'm not aware of any major TCP implementation that actually follows
>> the "TCP Quiet Time" approach.
>>
>> o Most production applications AFAIK end up using SO_REUSEADDR,
>> indicating a need to reuse ports quickly and a lack of concern about
>> this kind of issue with old packets ending up mixed into new
>> connections.
>>
>> o Applications that care about this should be using cryptography.
>>
>> o Users today expect to be able to reboot a machine and get back on
>> the network in less than 2 minutes.
>>
>> best,
>> neal
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>

--00000000000065916e059a12ed34
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What Joe said s/effect/opportunities/

I=
s there standards language=C2=A0anywhere=C2=A0about successive connections =
sharing sequence space and timestamps?=C2=A0 If there is, I missed it.

Thanks=
,
--MM--
The best way to predict the future is to create it. =C2=A0=
- Alan Kay

We must not tolerate intolerance;
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be carefully measured:=
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would=
 be hypocritical and risks spiraling out of control;
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mistaken for tacit app=
roval.


On Thu, Dec 19, 2=
019 at 6:57 AM Joe Touch <touch@strayalpha.com> wrote:
This discussion seems to be overlooki=
ng the effect of timestamps.

Joe

On Dec 18, 2019, at 9:39 PM, Matt Mathis <mattmat=
his=3D40google.com@dmarc.ietf.org> wrote:

I am under the impression that web servers do something different:=C2=
=A0 Normally the client sends the FIN, and the server holds FIN wait, but o=
ften discards it before 2MSL to reduce memory pressure, however if the serv=
er receives a new SYN for the same connection 4tuple (before it is discarde=
d), the server has the option to continue in the same sequence space, one b=
yte after the FIN.

I haven't looked, but what happen=
s if a connection is in FIN wait, and a new SYN arrives?

Thanks,
--MM--
The best way to predict the f=
uture is to create it. =C2=A0- Alan Kay

We must not tolerate intoler=
ance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response=
 must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 too strong would be hypocritical and risks spiraling out of c=
ontrol;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks =
being mistaken for tacit approval.


On Wed, Dec 18, 2019 at 8:16 PM Neal Cardwell <ncardwell=3D40google.com=
@dmarc.ietf.org> wrote:
On Wed, Dec 18, 2019 at 8:28 PM Yuchung Cheng

<ycheng=3D40google.com@dmarc.ietf.org> wrote:

>

> On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy <wes@mti-systems.com> wrote:

> >

> > I don't think I noticed anyone responding to Gorry's comm=
ent below, and

> > I haven't made any alterations in the 793bis draft with regar=
d to this

> > (other than fixing some spelling mistakes).=C2=A0 I wanted to pul=
l this into

> > its own thread in case other people have thoughts or would like t=
o

> > discuss further what the quiet time concept's relevance is in=
 2020.

> I probably am missing something. What's the issue of the text? Lin=
ux

> to my knowledge does

> not implement this quiet time.

> But there are other injection attacks or basic checksum issues etc to<=
br>
> corrupt TCP. (Serious) application that solely relying on TCP's
> integrity is signing up for troubles already ...



I would agree with Yuchung's remarks and the general point that the

"TCP Quiet Time Concept" from RFC 793 does not seem to be of prac=
tical

importance today, from a number of perspectives:



o I'm not aware of any major TCP implementation that actually follows
the "TCP Quiet Time" approach.



o Most production applications AFAIK end up using SO_REUSEADDR,

indicating a need to reuse ports quickly and a lack of concern about

this kind of issue with old packets ending up mixed into new

connections.



o Applications that care about this should be using cryptography.



o Users today expect to be able to reboot a machine and get back on

the network in less than 2 minutes.



best,

neal



_______________________________________________

tcpm mailing list

tcpm@ietf.org

https://www.ietf.org/mailman/listinfo/tcpm



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://=
www.ietf.org/mailman/listinfo/tcpm



--00000000000065916e059a12ed34--


From nobody Thu Dec 19 14:01:35 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED59120232 for ; Thu, 19 Dec 2019 14:01:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 pG_htt88yCkd for ; Thu, 19 Dec 2019 14:01:32 -0800 (PST)
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 C0C52120048 for ; Thu, 19 Dec 2019 14:01:32 -0800 (PST)
Received: by mail-qt1-x82b.google.com with SMTP id q20so6397572qtp.3 for ; Thu, 19 Dec 2019 14:01:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=mNR4J5IWqb+1dViIQPu1Oi7PC01GrJdtw4mB9xuAwRY=; b=RZ+/5CuKkCzmNDLMmVQFYU3uGqpAFjlpN7vtHFHmNVbmIYcL/at3KJPRTlW3x8iHnR P+owI/Hc4IsS4v4VD8y2NRiIxsxMn82A8nxjPCPtbzj9iv1B/6TIedcCuAZ347qAEhDl eRpirAMleXvgHwVpNKGBW7o3dKSFdimmiLQ6US6X4YU/Rh3PPoQtGI6hMM+7uZbBdj/Q sm9RcXdDNsVTBtMq1NjshCydevBfPlIHLbWYDnJuRSIdloaKFQreM5D/5PHuQvgfS1Kj yxT3ZnuayLnoUSC6qoPPji/a25pjPgWYooU4M+gnCtkC/Y99sqt/puMfYxh3SKhHILzT c3AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=mNR4J5IWqb+1dViIQPu1Oi7PC01GrJdtw4mB9xuAwRY=; b=XG+7a2+HbznKtQbCicOZC4GBhOnBBpKttbGbhQUGHhhFyleOqChNKZjuXbSQ1RtkvB 8GswAssif69QgwyhOED2GGW8dxs/x8ot2EmgJ7Suv/8Ft9ANeyCmvTs3L/oLQkmPXhlm rTYAWfDOlt9pMUxS0W2Em8J9aZy94ROmW7KjxdfRQYeQQc4GS8bgfpIYwOFWAATeQGfP I+Mh5RwsG6tS0qYkrv+9aRhDVlE65kw0AWe8aZTPLZQVqiE4kvaTNrO8cCsnXDlSr6In 9rP87Q6nd6S+8B0CB+zc3ild9+NvyxZUZ7u8pYIUhTB1HrmBHJr1RtIlIWdJ4J5T0wPm yolQ==
X-Gm-Message-State: APjAAAUVNFCBVUE3kCBA5em9ZBK+se5NvBRRZTgUpzMvHjKrVlheqG5w J9usTj8/SpXcM9dRtJkQ5Mu9qDYaQ3g=
X-Google-Smtp-Source: APXvYqyD3ws7e5FMFGnGEwZDt/BQpy2bb69vCX25jlpvyXSuoA1nZp8eX2zNtIMCeQ+XY8bBaFm+7g==
X-Received: by 2002:ac8:6f75:: with SMTP id u21mr9220422qtv.52.1576792891722;  Thu, 19 Dec 2019 14:01:31 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id i6sm2116400qkk.7.2019.12.19.14.01.31 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2019 14:01:31 -0800 (PST)
To: tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: <58f1b035-94ff-cfa8-c6c6-13d4c3cfae90@mti-systems.com>
Date: Thu, 19 Dec 2019 17:01:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D66A044.3060904@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [tcpm] 793bis: dead gateway detection
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 22:01:35 -0000

Gorry asked a question below about excessive TCP retransmissions 
resulting in triggering of whatever kind of lower-layer "dead gateway" 
detection logic might be available.  This comes from RFC 1122.  I don't 
know the current state of practice, or of any RFCs amending this, so am 
very interested in any feedback from the list on whether some change 
here is needed.

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> Section 3.8.3
> OLD:
>       pass negative advice (see [14]
>       Section 3.3.1.4) to the IP layer, to trigger dead-gateway
>       diagnosis.
> - Is this still best current practice? - If so please explain and cite 
> RFCs. 


From nobody Thu Dec 19 14:06:50 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B17120232 for ; Thu, 19 Dec 2019 14:06:49 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=mti-systems-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 501pcXjSjlxM for ; Thu, 19 Dec 2019 14:06:48 -0800 (PST)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 166BE1200CC for ; Thu, 19 Dec 2019 14:06:48 -0800 (PST)
Received: by mail-qk1-x729.google.com with SMTP id t129so5954503qke.10 for ; Thu, 19 Dec 2019 14:06:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=a3zkjwLUMqPEB7usHO6u9sQl7IE0r9+5M7uwrPb5umc=; b=wOwgA4Zmts94wvetO781X5FIVjsLuWHyskA6ToJA+qM/fuYJAqiOerG64hQhD79PNc jkz5dMXl3Ld/aO9pgwe5+xlO97JRrm6CE5LfzMbpyoKbokNkOBGGE7Lj99cwut2wdbpE wRzSqDRK0D/VcnEZw5isILoapAvdAJJwI9jbhskEgOgsENQOkt5U9ULvrDIyKoWqavLE wBjfr8BbKZSeRhC4mj9SvjbZjaxVuT2B0rt3RYRP2JYBCAFyeN5D/I7/K8wkWAbXwYC+ oSugnmia7o1BQcLeWNRuu99wsMADywzh+NYvJqMuK/r6aqMLixEoMTFD7+IC64AxUBOG DVLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=a3zkjwLUMqPEB7usHO6u9sQl7IE0r9+5M7uwrPb5umc=; b=UpepZqryiIgpbZufF3gPNt2DBlolLKPgUA4Tkj7O6i+1uWGEqxpzo98sfbAynMqkNF 3UdOeQ6yCaPGGTu4idcE1UaYCmJ24GZsnu6mQnqMoL07PS2gyJb0PNGwQc7LIV7ZnOJb voPVO6kEGJdKOwNYqpc2VQ80cqAtSNH/Vdhy8FJJWDrDTACvDZn3zZ/tQVGo+gCM4ZQn pkmzHDIJRQPYqcyHfBzXVOITeeskpSrdeB+choo08AyeTZJeWDk6dZWG8CXtw7IVFMYF ogsK/IFTAjI6lfp76LiGRQGNvOa65qeXmwZUfunGqbwhpHP6Cu6i7qEJ8orbNMYa0deD NZIg==
X-Gm-Message-State: APjAAAWQ+l+zTJE8gvHQ//2LxMXLQXH1ZvLJ75PdN51OQpAAxaSNvRzz z/jLjQkUwvUfB0MixX3VEXyOpp3RH6c=
X-Google-Smtp-Source: APXvYqw2r1ar8ywwB2+rs+Y5dmBTWj7TV13CDGdADBpOoYkzblWcHmI+c8VS/FNmhmtCsnNIaJEubQ==
X-Received: by 2002:a37:488f:: with SMTP id v137mr10187079qka.16.1576793207034;  Thu, 19 Dec 2019 14:06:47 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id 16sm2181441qkj.77.2019.12.19.14.06.45 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2019 14:06:46 -0800 (PST)
To: tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>
From: Wesley Eddy 
Message-ID: <41223eeb-4b18-1abb-1d52-26489d8090e3@mti-systems.com>
Date: Thu, 19 Dec 2019 17:06:43 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D66A044.3060904@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [tcpm] 793bis: delayed ACKs
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 22:06:49 -0000

Regarding Gorry's comment below, I have an alternative suggestion.  I 
think the details are discussed well in 5681 
https://tools.ietf.org/html/rfc5681#section-4.2 and that we can simply 
point to that for expansion.


On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> Section 3.8.6.3 Delayed ACK.
> OLD:
>    and in a stream of full-sized segments there
>    SHOULD be an ACK for at least every second segment (SHLD-19).
> - Delayed ACK is specified in RFC1122 as: "...and in a stream of 
> full-sized segments there SHOULD be an ACK for at least every second 
> segment." Although correct, this does not specify a behaviour when 
> segments are not "full-sized". When asked by people, I have think this 
> should be something like:
> NEW:
> "the receiver SHOULD send an ACK when the data
> needing acknowledgment corresponds to no more than two full-sized 
> (MSS) segments." 


From nobody Thu Dec 19 14:32:05 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA951201DC for ; Thu, 19 Dec 2019 14:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 65WQjT1LBP8y for ; Thu, 19 Dec 2019 14:32:01 -0800 (PST)
Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (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 23B7F1200CC for ; Thu, 19 Dec 2019 14:32:01 -0800 (PST)
Received: from davidbormansmbp.americas.cray.com (msp-nat.cray.com [136.162.2.1]) (authenticated bits=0) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id xBJMam2W031830 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2019 16:36:48 -0600
From: David Borman 
Message-Id: <059F5B35-54F0-4019-A3C3-203A0D735766@weston.borman.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E26A449-B878-489E-8E3A-6555E3BEE2AF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 19 Dec 2019 16:31:28 -0600
In-Reply-To: <0A3E9FC0-27F2-4BB4-9F43-F3940E5CFC8E@lurchi.franken.de>
Cc: Gorry Fairhurst , tcpm@ietf.org
To: Michael Tuexen 
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>  <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <5DFBB442.60001@erg.abdn.ac.uk> <0A3E9FC0-27F2-4BB4-9F43-F3940E5CFC8E@lurchi.franken.de>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2019 22:32:04 -0000

--Apple-Mail=_3E26A449-B878-489E-8E3A-6555E3BEE2AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes, the reality is that I don=E2=80=99t think any full featured TCP =
implementation today would want/be able to take advantage of this.  Some =
things were much simpler when RFC 1122 was published, a lot has changed =
since then.  But with IoT and very small and tiny TCP implementations, =
there may be some places where this makes sense.

I do agree with Gorry, rather than calling out a few example fields that =
also must not have changed, keep it simple:

If a retransmitted packet is identical to the original packet (which =
implies not only that the data boundaries have not changed, but also the =
headers have not changed),

		-David

> On Dec 19, 2019, at 11:47 AM, Michael Tuexen =
 wrote:
>=20
>> On 19. Dec 2019, at 18:32, Gorry Fairhurst  =
wrote:
>>=20
>> I get this - but if we keep this, I think it should expliclity say =
*all headers have not changed*.
> The TCP timestamp option comes up to my mind. For TCP retransmission, =
the TSVal would be different.
>=20
> Best regards
> Michael
>>=20
>> I still think this is a terrible hack to say the transport touches =
something in the network layer - because I have no idea how this sits =
with using TSOpt to disam=3Dbiguate retransmissions and extension =
headers, should they be used.
>>=20
>> Anyway, this is so very IPv4 centric, I think if we keep this, we =
should call IPv4 out explicitly.
>>=20
>> Gorry
>>=20
>> On 19/12/2019, 17:21, David Borman wrote:
>>> This has to do with the fact that the IPID field is used to do =
fragmentation reassembly.  It is ok to reuse the same IPID when =
retransmitting, as long as the retransmitted packet is identical to the =
original packet, not just the TCP data, but also all the TCP headers.  =
If the two packets aren=E2=80=99t identical and they are fragmented, =
then using the same IPID could cause the receiver to not properly =
reassemble the packet.
>>>=20
>>> What this also says is that, if a TCP implementation is such that it =
buffers up previously sent packets for possible retransmission and =
retransmits them verbatim, it doesn=E2=80=99t have to change the IPID =
just because it is a retransmission.  But if there are any differences =
between the original and the retransmitted packet, then the IPID must be =
updated.
>>>=20
>>> 			-David Borman
>>>=20
>>>> On Dec 19, 2019, at 11:04 AM, Wesley Eddy  =
wrote:
>>>>=20
>>>> While I think Gorry's comment below is pretty much correct, this is =
direct from RFC 1122's material on TCP.  I'm proposing not to change =
anything about this at the moment, since I don't think any harm is done =
by saying this.
>>>>=20
>>>> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>>>>> Section 3.8.1
>>>>> OLD:
>>>>>   If a retransmitted packet is identical to the original packet =
(which
>>>>>   implies not only that the data boundaries have not changed, but =
also
>>>>>   that the window and acknowledgment fields of the header have not
>>>>>   changed), then the same IP Identification field MAY be used (see
>>>>>   Section 3.2.1.5 of RFC 1122) (MAY-4).
>>>>> - What is this MAY about? Is it about the IPv4 IPID field and is =
that really
>>>>> important for a TCP spec?
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>=20
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>=20
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>=20


--Apple-Mail=_3E26A449-B878-489E-8E3A-6555E3BEE2AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes, =
the reality is that I don=E2=80=99t think any full featured TCP =
implementation today would want/be able to take advantage of this. =
 Some things were much simpler when RFC 1122 was published, a lot =
has changed since then.  But with IoT and very small and tiny TCP =
implementations, there may be some places where this makes sense.

I do agree with Gorry, =
rather than calling out a few example fields that also must not have =
changed, keep it simple:

If a retransmitted packet is identical to the original packet =
(which implies not only that the data boundaries have not changed, =
but also the headers have not changed),

		-David

On Dec 19, 2019, at 11:47 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

On 19. Dec 2019, at =
18:32, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

I get this - but if we keep this, I think it should =
expliclity say *all headers have not changed*.
The TCP timestamp option comes up to my mind. =
For TCP retransmission, the TSVal would be different.

Best regards
Michael

I still think this is a terrible =
hack to say the transport touches something in the network layer - =
because I have no idea how this sits with using TSOpt to disam=3Dbiguate =
retransmissions and extension headers, should they be used.

Anyway, this is so very IPv4 centric, I think =
if we keep this, we should call IPv4 out explicitly.

Gorry

On 19/12/2019, 17:21, =
David Borman wrote:
This has to do with the fact that the IPID field is used to =
do fragmentation reassembly.  It is ok to reuse the same IPID when =
retransmitting, as long as the retransmitted packet is identical to the =
original packet, not just the TCP data, but also all the TCP headers. =
 If the two packets aren=E2=80=99t identical and they are =
fragmented, then using the same IPID could cause the receiver to not =
properly reassemble the packet.

What this =
also says is that, if a TCP implementation is such that it buffers up =
previously sent packets for possible retransmission and retransmits them =
verbatim, it doesn=E2=80=99t have to change the IPID just because it is =
a retransmission.  But if there are any differences between the =
original and the retransmitted packet, then the IPID must be updated.

			-David Borman

On Dec 19, 2019, at =
11:04 AM, Wesley Eddy<wes@mti-systems.com>  wrote:

While I think Gorry's comment below is pretty much correct, =
this is direct from RFC 1122's material on TCP.  I'm proposing not =
to change anything about this at the moment, since I don't think any =
harm is done by saying this.

On 8/28/2019 =
11:39 AM, Gorry Fairhurst wrote:
Section 3.8.1
OLD:
 =
  If a retransmitted packet is identical to the original =
packet (which
   implies not only that the data =
boundaries have not changed, but also
   that =
the window and acknowledgment fields of the header have not
=
   changed), then the same IP Identification field MAY be used =
(see
   Section 3.2.1.5 of RFC 1122) (MAY-4).
- What is this MAY about? Is it about the IPv4 IPID field and =
is that really
important for a TCP spec?
_______________________________________________tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


=

--Apple-Mail=_3E26A449-B878-489E-8E3A-6555E3BEE2AF--


From nobody Thu Dec 19 18:44:43 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161251207FD for ; Thu, 19 Dec 2019 18:44:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level: 
X-Spam-Status: No, score=-1.22 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 f1OteCFPdF1T for ; Thu, 19 Dec 2019 18:44:40 -0800 (PST)
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 9E40A1200EC for ; Thu, 19 Dec 2019 18:44:40 -0800 (PST)
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=TSe3x/DQXSu0A+wJFW8na1MKYPfqN7PVASHvaFwTT8Q=; b=3h3ni3PhYVSxtFdJ+F2XJGbul DZRJQGKKo6n3S+f2YO5YuHmRSuiujBDost46kJLWHEp4bC3xMjSHKq6eFD7K0wH+1Lw3LWUlQ00uH 5D3dwZNEwgvCtFbFUY9R+PQs/wEkX9FWAREcB07H2z7WqaYpsQQjM+x7PxEU5AzeSK9a/KtFn2h69 pifZxzN+b4vE9hMrqGwWs3DRioPpy5DvVk8pFfxM7qFuCt3x4qqbQGZeN7LYFlx5IoBuIoVfNmjco XXoFfZFZnfmT5cssjd48r5Y5WqOxv+GkRXKQKwDua8y0Y96ctMLPz5Z6ncgj645nSLfbwp0nBPyef Pf9tPgMxA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61497 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ii8HI-00050F-Kz; Thu, 19 Dec 2019 21:44:39 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch 
In-Reply-To: <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com>
Date: Thu, 19 Dec 2019 18:44:33 -0800
Cc: Wes Eddy , tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com>
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>  <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com>
To: David Borman 
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.2
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: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2019 02:44:42 -0000

FWIW, the ID is now supposed to be ignored if fragmentation isn=E2=80=99t =
possible (not source fragmented and not fragmentable).

Perhaps this advice needs revision accordingly, esp. since TCP generally =
tries to run in that mode.

I.e., retransmission should have no bearing on the IPv4 ID unless =
fragmentation occurs or is possible.

Joe

> On Dec 19, 2019, at 9:21 AM, David Borman  =
wrote:
>=20
> This has to do with the fact that the IPID field is used to do =
fragmentation reassembly.  It is ok to reuse the same IPID when =
retransmitting, as long as the retransmitted packet is identical to the =
original packet, not just the TCP data, but also all the TCP headers.  =
If the two packets aren=E2=80=99t identical and they are fragmented, =
then using the same IPID could cause the receiver to not properly =
reassemble the packet.
>=20
> What this also says is that, if a TCP implementation is such that it =
buffers up previously sent packets for possible retransmission and =
retransmits them verbatim, it doesn=E2=80=99t have to change the IPID =
just because it is a retransmission.  But if there are any differences =
between the original and the retransmitted packet, then the IPID must be =
updated.
>=20
> 			-David Borman
>=20
>> On Dec 19, 2019, at 11:04 AM, Wesley Eddy  =
wrote:
>>=20
>> While I think Gorry's comment below is pretty much correct, this is =
direct from RFC 1122's material on TCP.  I'm proposing not to change =
anything about this at the moment, since I don't think any harm is done =
by saying this.
>>=20
>> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>>> Section 3.8.1
>>> OLD:
>>>   If a retransmitted packet is identical to the original packet =
(which
>>>   implies not only that the data boundaries have not changed, but =
also
>>>   that the window and acknowledgment fields of the header have not
>>>   changed), then the same IP Identification field MAY be used (see
>>>   Section 3.2.1.5 of RFC 1122) (MAY-4).
>>> - What is this MAY about? Is it about the IPv4 IPID field and is =
that really
>>> important for a TCP spec?=20
>>=20
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>=20
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Fri Dec 20 07:36:32 2019
Return-Path: 
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22552120639; Fri, 20 Dec 2019 07:36:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tcpm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.113.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <157685619007.4890.11737777369976981147@ietfa.amsl.com>
Date: Fri, 20 Dec 2019 07:36:30 -0800
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-15.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2019 15:36:30 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : Transmission Control Protocol Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-15.txt
	Pages           : 106
	Date            : 2019-12-20

Abstract:
   This document specifies the Internet's Transmission Control Protocol
   (TCP).  TCP is an important transport layer protocol in the Internet
   stack, and has continuously evolved over decades of use and growth of
   the Internet.  Over this time, a number of changes have been made to
   TCP as it was specified in RFC 793, though these have only been
   documented in a piecemeal fashion.  This document collects and brings
   those changes together with the protocol specification from RFC 793.
   This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
   6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
   and should be considered as a replacement for the portions of that
   document dealing with TCP requirements.  It updates RFC 5961 due to a
   small clarification in reset handling while in the SYN-RECEIVED
   state.

   RFC EDITOR NOTE: If approved for publication as an RFC, this should
   be marked additionally as "STD: 7" and replace RFC 793 in that role.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-15
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-15


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 Fri Dec 20 07:45:20 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE721200BA for ; Fri, 20 Dec 2019 07:45:13 -0800 (PST)
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, SPF_HELO_NONE=0.001, 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=mti-systems-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 TlE5P_3Sa3bI for ; Fri, 20 Dec 2019 07:45:11 -0800 (PST)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 D9A671200B8 for ; Fri, 20 Dec 2019 07:45:10 -0800 (PST)
Received: by mail-qv1-xf36.google.com with SMTP id m14so3779274qvl.3 for ; Fri, 20 Dec 2019 07:45:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=mRQjgoqdWdpE5I8U5C5SSt4xobejeG4ee2Q7eMA/U2k=; b=RQPGj6yAwtGp/7ZXZM8e8FZ9+rOsrTfF8IRCgDjcMSPxUpa3ckGdoG3wbKqgoJ+W/y y7vVsjhQgwD4xeTh/rJRHcxaodpXeLnqFMkwRfAZI5NYdHLM6fUUcY01Tyroml9/bBvs /bYRQahlXwzTs4cFRHLH23xU6iX9vgCTVThSvP/ly3L0Jn7Hw5/b6/s3kW8F/PLTfw9m 1l/6OGj+ELc6BXcZGLGBnUV7vCS3sRyw1ruCWz7HTSixUn+W/Vz2XXW9IAcVGnmpYKoT 9lMxbszb1gAzL/kgUe1rvtOmeyv2YY4+04rVDlpMhnvAvDWt1yXoIbUvkR33teJ+gRJc wxGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=mRQjgoqdWdpE5I8U5C5SSt4xobejeG4ee2Q7eMA/U2k=; b=H29vsKPbc/1RtUxb6Xgez93KjmbbUcvOH7SWwnF3bgzUqEatyzzGLgIihth75U+ibb l8JLgi5SP+ktG9aixLON800b8k6x4NiudUYEUtrLCA8mYUtgSl9UOZYIDTrn0aYnKD5g /f80es366tgrqCrwPy9JE7hz9BoSswbTaq/2a1EkfEs29OpeYD8XYlRCQtd9/jxOPrB0 SNNr+Smm4wJacc+bTtvNjjk8mItat9YkA4H6vg/Ypjpjc3aDkrud3zNHv7pSmoDYNPLE yPKh8hTufls1sTUCKc5ZQCELsVZ1ibF1gsRstvx7V0qWa3VycziO38SbOWj1d5Q+BMjN Vwtw==
X-Gm-Message-State: APjAAAVcDb4lhq2RfcjTjcIRZSRzyXjG2omZQ3FAXH+iBrOhIKlh4n5+ P5QfoMJr6iCaB0+8xKxYJZp2BPw8n6I=
X-Google-Smtp-Source: APXvYqym86yDTjrcUPhQDm4ql5/ksOa6MpCAO3i12N+/6Vj1lklL3AMbCOvgS7Nz7EQHv+gQnkKIzg==
X-Received: by 2002:a05:6214:1933:: with SMTP id es19mr12792621qvb.14.1576856709726;  Fri, 20 Dec 2019 07:45:09 -0800 (PST)
Received: from [10.100.1.112] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id q25sm2977370qkq.88.2019.12.20.07.45.08 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Dec 2019 07:45:09 -0800 (PST)
To: tcpm@ietf.org
References: <157685619007.4890.11737777369976981147@ietfa.amsl.com>
From: Wesley Eddy 
Message-ID: <6b90bf1c-0a0d-b8a9-e698-8e8ddc3d1f6e@mti-systems.com>
Date: Fri, 20 Dec 2019 10:45:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <157685619007.4890.11737777369976981147@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------02ACA912F8094CD55569BB4A"
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-15.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2019 15:45:13 -0000

This is a multi-part message in MIME format.
--------------02ACA912F8094CD55569BB4A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

This is an update to get out the bulk of edits from Gorry's review and 
some of the other list discussions, but there are a number of topics 
that I think are still converging on the list, so will need a later 
update to catch the results of.  The ones that I'm still tracking as 
open are:

  * Reserved bits
  * Quiet time
  * R1 and R2 discussion
  * Reset generation
  * Variable MTU and MSS
  * IP ID field on retransmits
  * Dead gateway detection
  * Delayed ACKs w/o full segments
  * Comment on OPEN+LISTEN while same local port in in SYN-RECVD/SENT
  * Comment on process IDs


On 12/20/2019 10:36 AM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>
>          Title           : Transmission Control Protocol Specification
>          Author          : Wesley M. Eddy
> 	Filename        : draft-ietf-tcpm-rfc793bis-15.txt
> 	Pages           : 106
> 	Date            : 2019-12-20
>
> Abstract:
>     This document specifies the Internet's Transmission Control Protocol
>     (TCP).  TCP is an important transport layer protocol in the Internet
>     stack, and has continuously evolved over decades of use and growth of
>     the Internet.  Over this time, a number of changes have been made to
>     TCP as it was specified in RFC 793, though these have only been
>     documented in a piecemeal fashion.  This document collects and brings
>     those changes together with the protocol specification from RFC 793.
>     This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
>     6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
>     and should be considered as a replacement for the portions of that
>     document dealing with TCP requirements.  It updates RFC 5961 due to a
>     small clarification in reset handling while in the SYN-RECEIVED
>     state.
>
>     RFC EDITOR NOTE: If approved for publication as an RFC, this should
>     be marked additionally as "STD: 7" and replace RFC 793 in that role.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-15
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-15
>
>
> 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/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

--------------02ACA912F8094CD55569BB4A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
This is an update to get out the bulk of edits from Gorry's
      review and some of the other list discussions, but there are a
      number of topics that I think are still converging on the list, so
      will need a later update to catch the results of.  The ones that
      I'm still tracking as open are:

    
    
      
  • Reserved bits
    • 
      
  • Quiet time
    • 
      
  • R1 and R2 discussion
    • 
      
  • Reset generation
    • 
      
  • Variable MTU and MSS
    • 
      
  • IP ID field on retransmits
    • 
      
  • Dead gateway detection
    • 
      
  • Delayed ACKs w/o full segments
    • 
      
  • Comment on OPEN+LISTEN while same local port in in
        SYN-RECVD/SENT
    • 
      
  • Comment on process IDs
    
      
    • 
    

    


    

    
On 12/20/2019 10:36 AM,
      internet-drafts@ietf.org wrote:

    

    

      
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : Transmission Control Protocol Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-15.txt
	Pages           : 106
	Date            : 2019-12-20

Abstract:
   This document specifies the Internet's Transmission Control Protocol
   (TCP).  TCP is an important transport layer protocol in the Internet
   stack, and has continuously evolved over decades of use and growth of
   the Internet.  Over this time, a number of changes have been made to
   TCP as it was specified in RFC 793, though these have only been
   documented in a piecemeal fashion.  This document collects and brings
   those changes together with the protocol specification from RFC 793.
   This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
   6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
   and should be considered as a replacement for the portions of that
   document dealing with TCP requirements.  It updates RFC 5961 due to a
   small clarification in reset handling while in the SYN-RECEIVED
   state.

   RFC EDITOR NOTE: If approved for publication as an RFC, this should
   be marked additionally as "STD: 7" and replace RFC 793 in that role.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-15
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-15


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/

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


    

  


--------------02ACA912F8094CD55569BB4A--


From nobody Fri Dec 20 12:37:37 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D5B1209CF for ; Fri, 20 Dec 2019 12:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 PR53_qhJ6Wrf for ; Fri, 20 Dec 2019 12:37:34 -0800 (PST)
Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (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 41C5F120859 for ; Fri, 20 Dec 2019 12:37:34 -0800 (PST)
Received: from davidbormansmbp.americas.cray.com (msp-nat.cray.com [136.162.2.1]) (authenticated bits=0) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id xBKKgoZL025438 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Dec 2019 14:42:50 -0600
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: David Borman 
In-Reply-To: <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com>
Date: Fri, 20 Dec 2019 14:37:31 -0600
Cc: tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>  <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com>
To: Joe Touch 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2019 20:37:37 -0000

Yes, the IPID is only used for doing IP fragment reassembly, so the IPID =
really doesn=E2=80=99t matter on retransmission when IP fragmentation is =
not possible.

So just stating that the IPID must not be reused on retransmission =
unless the packet is identical to the original should be sufficient.  We =
want to avoid having an implementation reuse IPIDs and cause problems, =
and then say =E2=80=9Cbut the RFC didn=E2=80=99t say we couldn=E2=80=99t =
do that=E2=80=9D.
			-David

> On Dec 19, 2019, at 8:44 PM, Joe Touch  wrote:
>=20
> FWIW, the ID is now supposed to be ignored if fragmentation isn=E2=80=99=
t possible (not source fragmented and not fragmentable).
>=20
> Perhaps this advice needs revision accordingly, esp. since TCP =
generally tries to run in that mode.
>=20
> I.e., retransmission should have no bearing on the IPv4 ID unless =
fragmentation occurs or is possible.
>=20
> Joe
>=20
>> On Dec 19, 2019, at 9:21 AM, David Borman  =
wrote:
>>=20
>> This has to do with the fact that the IPID field is used to do =
fragmentation reassembly.  It is ok to reuse the same IPID when =
retransmitting, as long as the retransmitted packet is identical to the =
original packet, not just the TCP data, but also all the TCP headers.  =
If the two packets aren=E2=80=99t identical and they are fragmented, =
then using the same IPID could cause the receiver to not properly =
reassemble the packet.
>>=20
>> What this also says is that, if a TCP implementation is such that it =
buffers up previously sent packets for possible retransmission and =
retransmits them verbatim, it doesn=E2=80=99t have to change the IPID =
just because it is a retransmission.  But if there are any differences =
between the original and the retransmitted packet, then the IPID must be =
updated.
>>=20
>> 			-David Borman
>>=20
>>> On Dec 19, 2019, at 11:04 AM, Wesley Eddy  =
wrote:
>>>=20
>>> While I think Gorry's comment below is pretty much correct, this is =
direct from RFC 1122's material on TCP.  I'm proposing not to change =
anything about this at the moment, since I don't think any harm is done =
by saying this.
>>>=20
>>> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>>>> Section 3.8.1
>>>> OLD:
>>>>  If a retransmitted packet is identical to the original packet =
(which
>>>>  implies not only that the data boundaries have not changed, but =
also
>>>>  that the window and acknowledgment fields of the header have not
>>>>  changed), then the same IP Identification field MAY be used (see
>>>>  Section 3.2.1.5 of RFC 1122) (MAY-4).
>>>> - What is this MAY about? Is it about the IPv4 IPID field and is =
that really
>>>> important for a TCP spec?=20
>>>=20
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>=20
>>=20
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>=20


From nobody Fri Dec 20 14:23:11 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBF21200EF for ; Fri, 20 Dec 2019 14:23:09 -0800 (PST)
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 EBUamUsifw75 for ; Fri, 20 Dec 2019 14:23:08 -0800 (PST)
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 413741200C1 for ; Fri, 20 Dec 2019 14:23:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=TgwlEigsoKQ2qQQmWSP2iDSknK7xvc+Mt3eVJPrSYu0=; b=PkGAavWe9ind9NW4PEG1hcUUY TcPdtV0Xcp9pEDUtfDFzuTvI41BcejvT62Dlg9GD9es37F60T70fwBVT5T4cHmGU1kRwXivlLOMIw g0USYDnMDXmFBz5H2TLsHC5Wu+k2ZIIMaMUL0SweGrGqfxU46L0+JmXq3bKv87vhxmt+dhSr/FZOg Gm4470yF3cJoJ0LyQc/R7qMoP9ljZrLGCas4Fo7H7Hi2bKhhUARbMN4oTJGr90NAvnaphbMRzXwG+ 0r59Svyqzn91PEzrAr0a/FNmAy87IsM1QXP+nxJY9/m0I+y8RhTICDU3TBID5Ca85t7bpLhDCClHx GKQ6rkMWA==;
Received: from [::1] (port=47778 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1iiQfm-002vSK-TE; Fri, 20 Dec 2019 17:23:07 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_07286caa3f85c9bfc977882ef632da44"
Date: Fri, 20 Dec 2019 14:23:02 -0800
From: Joe Touch 
To: David Borman 
Cc: tcpm@ietf.org
In-Reply-To: 
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk>  <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> 
Message-ID: 
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.7
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: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2019 22:23:10 -0000

--=_07286caa3f85c9bfc977882ef632da44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Hi, David, 

On 2019-12-20 12:37, David Borman wrote:

> Yes, the IPID is only used for doing IP fragment reassembly, so the IPID really doesn't matter on retransmission when IP fragmentation is not possible.

Right - it doesn't matter. But that also means it can be reused *even if
the packet contents change*. It should have no impact unless
fragmentation occurs; if it's "atomic" (not source fragmented and DF=0),
then it can be reused *at will* (and already widely is). 

> So just stating that the IPID must not be reused on retransmission unless the packet is identical to the original should be sufficient.

That's overkill. The ID can be (and already is) reused if the packets
are atomic (per above). 

> We want to avoid having an implementation reuse IPIDs and cause problems, and then say "but the RFC didn't say we couldn't do that".

Implementations of TCP need to know that they should not be using IP IDs
for uniqueness, as already indicated in RFC 6864. We should be clear in
supporting that advice here. 

Joe 

> -David
> 
> On Dec 19, 2019, at 8:44 PM, Joe Touch  wrote:
> 
> FWIW, the ID is now supposed to be ignored if fragmentation isn't possible (not source fragmented and not fragmentable).
> 
> Perhaps this advice needs revision accordingly, esp. since TCP generally tries to run in that mode.
> 
> I.e., retransmission should have no bearing on the IPv4 ID unless fragmentation occurs or is possible.
> 
> Joe
> 
> On Dec 19, 2019, at 9:21 AM, David Borman  wrote:
> 
> This has to do with the fact that the IPID field is used to do fragmentation reassembly.  It is ok to reuse the same IPID when retransmitting, as long as the retransmitted packet is identical to the original packet, not just the TCP data, but also all the TCP headers.  If the two packets aren't identical and they are fragmented, then using the same IPID could cause the receiver to not properly reassemble the packet.
> 
> What this also says is that, if a TCP implementation is such that it buffers up previously sent packets for possible retransmission and retransmits them verbatim, it doesn't have to change the IPID just because it is a retransmission.  But if there are any differences between the original and the retransmitted packet, then the IPID must be updated.
> 
> -David Borman
> 
> On Dec 19, 2019, at 11:04 AM, Wesley Eddy  wrote:
> 
> While I think Gorry's comment below is pretty much correct, this is direct from RFC 1122's material on TCP.  I'm proposing not to change anything about this at the moment, since I don't think any harm is done by saying this.
> 
> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote: Section 3.8.1
> OLD:
> If a retransmitted packet is identical to the original packet (which
> implies not only that the data boundaries have not changed, but also
> that the window and acknowledgment fields of the header have not
> changed), then the same IP Identification field MAY be used (see
> Section 3.2.1.5 of RFC 1122) (MAY-4).
> - What is this MAY about? Is it about the IPv4 IPID field and is that really
> important for a TCP spec? 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--=_07286caa3f85c9bfc977882ef632da44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



Hi, David,


On 2019-12-20 12:37, David Borman wrote:




=
Yes, the IPID is only used for doing IP fragment reassembly, so the IPID re=
ally doesn't matter on retransmission when IP fragmentation is not possible=
=2E




=
 


=
Right - it doesn't matter. But that also means it can be reused *even if th=
e packet contents change*. It should have no impact unless fragmentation oc=
curs; if it's "atomic" (not source fragmented and DF=3D0), then it can be r=
eused *at will* (and already widely is).


=
 




=
So just stating that the IPID must not be reused on retransmission unless t=
he packet is identical to the original should be sufficient.




=
 


=
That's overkill. The ID can be (and already is) reused if the packets are a=
tomic (per above).


=
 




=
We want to avoid having an implementation reuse IPIDs and cause problems, a=
nd then say "but the RFC didn't say we couldn't do that".




=
 


=
Implementations of TCP need to know that they should not be using IP IDs fo=
r uniqueness, as already indicated in RFC 6864. We should be clear in suppo=
rting that advice here.


=
 


=
Joe


=
 


=
 




=
 


=

            &n=
bsp;-David



On Dec 19, 2019, at 8:44 PM, Joe Touch <touch@strayalpha.com> wrote:

 FWIW, the ID is now supposed to be ignored if fragmentation isn't possibl=
e (not source fragmented and not fragmentable).

 Perhaps this ad=
vice needs revision accordingly, esp. since TCP generally tries to run in t=
hat mode.

 I.e., retransmission should have no bearing on the IP=
v4 ID unless fragmentation occurs or is possible.

 Joe



On Dec 19, 2019, at 9:21 AM, David Borman <dab@weston.borman.com> wrote:

 This has to do with the fact that the IPID field is used to do frag=
mentation reassembly.  It is ok to reuse the same IPID when retransmit=
ting, as long as the retransmitted packet is identical to the original pack=
et, not just the TCP data, but also all the TCP headers.  If the two p=
ackets aren't identical and they are fragmented, then using the same IPID c=
ould cause the receiver to not properly reassemble the packet.

 =
What this also says is that, if a TCP implementation is such that it buffer=
s up previously sent packets for possible retransmission and retransmits th=
em verbatim, it doesn't have to change the IPID just because it is a retran=
smission.  But if there are any differences between the original and t=
he retransmitted packet, then the IPID must be updated.

  &=
nbsp;          -David Bor=
man



On Dec 19, 2019, at 11:04 AM, Wesley Eddy <wes@mti-systems.com> wrote:
 While I think Gorry's comment below is pretty much correct, this is dir=
ect from RFC 1122's material on TCP.  I'm proposing not to change anyt=
hing about this at the moment, since I don't think any harm is done by sayi=
ng this.

 On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:

Section 3.8.1
 OLD:
  If a retransmitte=
d packet is identical to the original packet (which
  implies not=
 only that the data boundaries have not changed, but also
  that =
the window and acknowledgment fields of the header have not
  cha=
nged), then the same IP Identification field MAY be used (see
  S=
ection 3.2.1.5 of RFC 1122) (MAY-4).
 - What is this MAY about? Is it =
about the IPv4 IPID field and is that really
 important for a TCP spec=
?


 _______________________________________________
 tcpm mailing l=
ist
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

<=
/blockquote>

 _______________________________________________
 tcpm mailing l=
ist
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


 _______________________________________________
 tcpm mailing l=
ist
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

<=
/blockquote>






--=_07286caa3f85c9bfc977882ef632da44--


From nobody Fri Dec 20 17:00:55 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2631A1209EC for ; Fri, 20 Dec 2019 17:00:54 -0800 (PST)
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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 iVPkziaWvsCl for ; Fri, 20 Dec 2019 17:00:52 -0800 (PST)
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 271931209EB for ; Fri, 20 Dec 2019 17:00:52 -0800 (PST)
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-Transfer-Encoding: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=ajkJwa3BCFSc1qbYxzWWaJSk6PLuvzOXq2Cwi6+qPLg=; b=DRxdNDRMkGRc7+Cw1Hl4jMgVN+ +pgJ4Vk1gfcxep2qlgFC2ejx65HaZZ+xv59s59GeyvsP2IHn/49j/HgS9qJ2gN2AFt2eojhwUSJ+7 1fYUX9IvczaKt+Uv+2AyqgSGYHRW9KDjoOECG+tg9o10aBA1mqI/zT5b5TmiXoPoQebcelIYV9VrM +sUu+Wo3XD6J3+eVcMCuoJC3O2YDHI1h+9stsELVnoud1N5v5h/PHTGaB6wItegwlXJGteY2f0Zys oKe4fCvT0nwPS4pQSzrIUXTAaVtGm/X+LvQ4M/yH+tvrU2eZC/GDIUC8f1z8EZrugvbNSfAj+RXC9 MrzzluzA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:65137 helo=[192.168.1.5]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iiT8I-001NI3-IB; Fri, 20 Dec 2019 20:00:43 -0500
Content-Type: multipart/alternative; boundary=Apple-Mail-502C74F0-3CD6-4F4D-9B37-2B128F7D94E1
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Joe Touch 
In-Reply-To: 
Date: Fri, 20 Dec 2019 17:00:38 -0800
Cc: tcpm@ietf.org
Message-Id: <22BCA8B6-473F-4F2C-9A49-065243CCC91A@strayalpha.com>
References: 
To: David Borman 
X-Mailer: iPhone Mail (17C54)
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: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Dec 2019 01:00:54 -0000

--Apple-Mail-502C74F0-3CD6-4F4D-9B37-2B128F7D94E1
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Ps - make that DF=3D1

> On Dec 20, 2019, at 2:23 PM, Joe Touch  wrote:
>=20
> =EF=BB=BF
> Hi, David,
>=20
>> On 2019-12-20 12:37, David Borman wrote:
>>=20
>> Yes, the IPID is only used for doing IP fragment reassembly, so the IPID r=
eally doesn't matter on retransmission when IP fragmentation is not possible=
.
> =20
> Right - it doesn't matter. But that also means it can be reused *even if t=
he packet contents change*. It should have no impact unless fragmentation oc=
curs; if it's "atomic" (not source fragmented and DF=3D0), then it can be re=
used *at will* (and already widely is).
> =20
>> So just stating that the IPID must not be reused on retransmission unless=
 the packet is identical to the original should be sufficient.
> =20
> That's overkill. The ID can be (and already is) reused if the packets are a=
tomic (per above).
> =20
>> We want to avoid having an implementation reuse IPIDs and cause problems,=
 and then say "but the RFC didn't say we couldn't do that".
> =20
> Implementations of TCP need to know that they should not be using IP IDs f=
or uniqueness, as already indicated in RFC 6864. We should be clear in suppo=
rting that advice here.
> =20
> Joe
> =20
> =20
>> =20
>>=20
>>             -David
>>=20
>>> On Dec 19, 2019, at 8:44 PM, Joe Touch  wrote:
>>>=20
>>> FWIW, the ID is now supposed to be ignored if fragmentation isn't possib=
le (not source fragmented and not fragmentable).
>>>=20
>>> Perhaps this advice needs revision accordingly, esp. since TCP generally=
 tries to run in that mode.
>>>=20
>>> I.e., retransmission should have no bearing on the IPv4 ID unless fragme=
ntation occurs or is possible.
>>>=20
>>> Joe
>>>=20
>>>> On Dec 19, 2019, at 9:21 AM, David Borman  wrote=
:
>>>>=20
>>>> This has to do with the fact that the IPID field is used to do fragment=
ation reassembly.  It is ok to reuse the same IPID when retransmitting, as l=
ong as the retransmitted packet is identical to the original packet, not jus=
t the TCP data, but also all the TCP headers.  If the two packets aren't ide=
ntical and they are fragmented, then using the same IPID could cause the rec=
eiver to not properly reassemble the packet.
>>>>=20
>>>> What this also says is that, if a TCP implementation is such that it bu=
ffers up previously sent packets for possible retransmission and retransmits=
 them verbatim, it doesn't have to change the IPID just because it is a retr=
ansmission.  But if there are any differences between the original and the r=
etransmitted packet, then the IPID must be updated.
>>>>=20
>>>>             -David Borman
>>>>=20
>>>>> On Dec 19, 2019, at 11:04 AM, Wesley Eddy  wrote:=

>>>>>=20
>>>>> While I think Gorry's comment below is pretty much correct, this is di=
rect from RFC 1122's material on TCP.  I'm proposing not to change anything a=
bout this at the moment, since I don't think any harm is done by saying this=
.
>>>>>=20
>>>>>> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>>>>>> Section 3.8.1
>>>>>> OLD:
>>>>>>  If a retransmitted packet is identical to the original packet (which=

>>>>>>  implies not only that the data boundaries have not changed, but also=

>>>>>>  that the window and acknowledgment fields of the header have not
>>>>>>  changed), then the same IP Identification field MAY be used (see
>>>>>>  Section 3.2.1.5 of RFC 1122) (MAY-4).
>>>>>> - What is this MAY about? Is it about the IPv4 IPID field and is that=
 really
>>>>>> important for a TCP spec?
>>>>>=20
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> tcpm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>=20
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>=20

--Apple-Mail-502C74F0-3CD6-4F4D-9B37-2B128F7D94E1
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Ps - make that DF=3D1

On Dec 20, 2019, at 2:23 PM,=
 Joe Touch <touch@strayalpha.com> wrote:

=EF=BB=BF

Hi, David,


On 2019-12-20 12:37, David Borman wrote:




Y=
es, the IPID is only used for doing IP fragment reassembly, so the IPID real=
ly doesn't matter on retransmission when IP fragmentation is not possible.



&=
nbsp;


R=
ight - it doesn't matter. But that also means it can be reused *even if the p=
acket contents change*. It should have no impact unless fragmentation occurs=
; if it's "atomic" (not source fragmented and DF=3D0), then it can be reused=
 *at will* (and already widely is).


&=
nbsp;




S=
o just stating that the IPID must not be reused on retransmission unless the=
 packet is identical to the original should be sufficient.




&=
nbsp;


T=
hat's overkill. The ID can be (and already is) reused if the packets are ato=
mic (per above).


&=
nbsp;




W=
e want to avoid having an implementation reuse IPIDs and cause problems, and=
 then say "but the RFC didn't say we couldn't do that".




&=
nbsp;


I=
mplementations of TCP need to know that they should not be using IP IDs for u=
niqueness, as already indicated in RFC 6864. We should be clear in supportin=
g that advice here.


&=
nbsp;


J=
oe


&=
nbsp;


&=
nbsp;




&=
nbsp;


<=
br>             =
-David



On Dec 19, 2019, at 8:44 PM, Joe Touch <touch@strayalpha.com> wrote:

 FWIW,=
 the ID is now supposed to be ignored if fragmentation isn't possible (not s=
ource fragmented and not fragmentable).

 Perhaps this advice needs re=
vision accordingly, esp. since TCP generally tries to run in that mode.
<=
br> I.e., retransmission should have no bearing on the IPv4 ID unless fragme=
ntation occurs or is possible.

 Joe



On Dec 19, 2019, at 9:21 AM, David Borman <dab@weston.borman.com> wrote:

 T=
his has to do with the fact that the IPID field is used to do fragmentation r=
eassembly.  It is ok to reuse the same IPID when retransmitting, as lon=
g as the retransmitted packet is identical to the original packet, not just t=
he TCP data, but also all the TCP headers.  If the two packets aren't i=
dentical and they are fragmented, then using the same IPID could cause the r=
eceiver to not properly reassemble the packet.

 What this also says i=
s that, if a TCP implementation is such that it buffers up previously sent p=
ackets for possible retransmission and retransmits them verbatim, it doesn't=
 have to change the IPID just because it is a retransmission.  But if t=
here are any differences between the original and the retransmitted packet, t=
hen the IPID must be updated.

       &n=
bsp;     -David Borman



On Dec 19, 2019, at 11:04 AM, Wesley Eddy <wes@mti-systems.com> wrote:

 Whil=
e I think Gorry's comment below is pretty much correct, this is direct from R=
FC 1122's material on TCP.  I'm proposing not to change anything about t=
his at the moment, since I don't think any harm is done by saying this.
<=
br> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:

Section 3.8.1
 OLD:
  If a retransmitted pack=
et is identical to the original packet (which
  implies not only tha=
t the data boundaries have not changed, but also
  that the window a=
nd acknowledgment fields of the header have not
  changed), then the=
 same IP Identification field MAY be used (see
  Section 3.2.1.5 of R=
FC 1122) (MAY-4).
 - What is this MAY about? Is it about the IPv4 IPID fi=
eld and is that really
 important for a TCP spec?


 _______________________________________________
 tcpm mailing listtcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm



 _______________________________________________
 tcpm mailing listtcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


 _______________________________________________
 tcpm mailing listtcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm








=

--Apple-Mail-502C74F0-3CD6-4F4D-9B37-2B128F7D94E1--


From nobody Fri Dec 27 11:03:23 2019
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A70120B54 for ; Fri, 27 Dec 2019 11:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 4xxp0-sMLnZi for ; Fri, 27 Dec 2019 11:03:17 -0800 (PST)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2124.outbound.protection.outlook.com [40.107.237.124]) (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 876E21208E0 for ; Fri, 27 Dec 2019 11:03:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zec8xw9m2a5U9Yj/GkjrWvaUeDByLVP0hP1ryOuO7C80IrxuVMj7pzq29vAWAlpXSX7jFKRZH9tMtk1uhyo3bMo8qyzZ2tVb01s0/vp/woTJRRNJKf0pHZTpnR/ya6Vdcf+CO4YBROtPhS32nc2+cHacZSQJKDsZ9HwNLae0+H3CffoBj7LwogtkOFqUETHY6bQ+oHCkK1eJ8i5tb2kV4vbcv/JsqMprPUsRO3F4rbfWZnr+lpOZJHN4GXPwNkDBkRxSEQJDSf7fmiasjiHvypMc2UGjwq6hOCmVsjcbZUQmrJ426iYVfseFuhXPuZsn61trrq6NGA2v4qlO55FXog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7kOzZbBQQNgR45SD+O12rnUg4UPk5rWLHrpGfPoXFTI=; b=EyZqa7rnhMMME9HvdoVIqTGdSOIdNEd4AcKCAv1mFasmDyfO6mRDr3TPN2nfYixXXkyvHkHieXEu/GyozvRnpP8ktOjZ8Be7YegL3yMolVl7tdfPEac0YaZFqdI3e4WUKuHxwEij2eHOj5MEiKivpYHfGgihIZcu16fpOLi8pSRQRPlPKrgbtWpulZ4jM/5Ioh/57yaUfW+yxS7fZlokhOkJeIHLSOWrY1hFB7rN3vd9MqLjOJO/i9K7jaTarSTjN8vB6MbIef1ht78Gm3dkcjKx9ZDHPQwjApCvGaGzWNsNG2pzEwyIwJOnQHKM1v1IqG3RuVuQJTSqRjknv8nBgQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7kOzZbBQQNgR45SD+O12rnUg4UPk5rWLHrpGfPoXFTI=; b=jwzZiiV4i3IKiTa/gGRSBv4reF82sG7VCzkFRFyjNNbOPr1feRRhnN/wRfBlCrgulwA1/3WIMteWPI0lDJUmMzy09B3uiO8eA5R0Ybqd6LUCEZ2fZuHMwluiDOqMmFYu4+0axAIpZMuEalL0cus3tqo2vVAkpl6pMVzLI2b8mmI=
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0940.namprd21.prod.outlook.com (52.132.146.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.6; Fri, 27 Dec 2019 19:03:15 +0000
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c81d:5aa3:e3f5:5ca]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c81d:5aa3:e3f5:5ca%7]) with mapi id 15.20.2602.006; Fri, 27 Dec 2019 19:03:15 +0000
From: Praveen Balasubramanian 
To: Richard Scheffenegger , Jonathan Morton 
CC: Matt Mathis , tcpm IETF list , Mirja Kuehlewind 
Thread-Topic: [EXTERNAL] Re: [tcpm] A possible simplification for AccECN servers
Thread-Index: AQHVo6eBJIGvA2XQT0GosXYhXOFIi6ecFUOAgAACeQCAAAEwgIAAA+WAgABOMwCAClE7AIANjy4AgABsuwCAABepgIAAWBiAgACSyACAAJfHAIAAYgyAgAA5L4CAAAXYAIAXlMWA
Date: Fri, 27 Dec 2019 19:03:14 +0000
Message-ID: 
References:  <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net>  <10B9ACEE-DDA5-45E6-A639-BBB6CD51DDB5@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-12-27T19:03:13.8400929Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=3388b723-8ad7-4201-974a-c3b67483010e; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-originating-ip: [131.107.159.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: a26c0487-e5da-443a-f82a-08d78aff6d3d
x-ms-traffictypediagnostic: MW2PR2101MB0940:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0264FEA5C3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(366004)(396003)(39860400002)(199004)(189003)(13464003)(71200400001)(6506007)(26005)(186003)(53546011)(54906003)(110136005)(66946007)(66476007)(76116006)(316002)(64756008)(66556008)(66446008)(7696005)(8990500004)(2906002)(8936002)(86362001)(81156014)(8676002)(52536014)(81166006)(478600001)(55016002)(9686003)(33656002)(966005)(4326008)(5660300002)(10290500003); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0940; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wFc0Rt9e6fcWYNnhG4HXuKvh6zvTSM1Sx/UqiKZzrSIlczbVEW0OjjeEjPnt4NgdptxljyFj2bw+fLFflirTwdqVv5ccnx7RiOmp6A6HaoOfGV1jtqDhiDLjK+m7NZbMK38udnKcx1ZW1t2TwLtiUxqbLHrAXZndb3iWK3wBUAsVKoyfOcr14I2FJiYBCiK6Is2GNIElJaaGO0tGYXjjluLQYYoGfZQiYwE8N1ougy8fD399nnFiHB5y+pxwy+myftN2KB++aYlxiMZJUOjW1l2eDBgjghPSJ33+qMznGN+afI6a2E9HnZoAf5KXP4/GM+FNH8UHlX5O2d0jFIOg0Yyckimr33dNylQ6tsJWMLNfWUrMJXgLnfp9afg4tCoXztK6bStVfQjOLthEBcv7Ea0DjfTsOFaRDoDJX0gEFfWwOoQx41oT1zUo2bynWad4Wo8c1gOpxy3cOJ3dG7zbLLb3s8RCse/2zOBbwjEhfSAgtGaVQfGNQi2MTkYB7x+qKAJDy3xK3IM/uv5cVFqHgcWSqgltZ04ps3HPQZIuSq0=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a26c0487-e5da-443a-f82a-08d78aff6d3d
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 19:03:14.9086 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: l0km3sUC4MHJyxtzpg37tus7hG7/477Av1gFMl3DcBfBEqr8wcsKVtVSCzLdQupLuzufnS+Qe+NhbT1tHt3I/52At32ugkIBmd+S7D0p3WE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0940
Archived-At: 
Subject: Re: [tcpm] [EXTERNAL] Re: A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Dec 2019 19:03:21 -0000

VG8gY2xhcmlmeSBXaW5kb3dzIFNlcnZlciB3aWxsIGRvIHRoYXQgYnV0IG5vdCBhbnkgb2YgdGhl
IGNsaWVudCBlZGl0aW9ucy4gQW5kIHRoZSBkZWZhdWx0IGZvciBTZXJ2ZXIgaGFzIGFsc28gYmVl
biBmbGlwcGVkIHRvIENVQklDIGluIHRoZSBtb3N0IHJlY2VudCByZWxlYXNlLiANCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRjcG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZz4g
T24gQmVoYWxmIE9mIFJpY2hhcmQgU2NoZWZmZW5lZ2dlcg0KU2VudDogVGh1cnNkYXksIERlY2Vt
YmVyIDEyLCAyMDE5IDEwOjUzIEFNDQpUbzogSm9uYXRoYW4gTW9ydG9uIDxjaHJvbWF0aXg5OUBn
bWFpbC5jb20+DQpDYzogTWF0dCBNYXRoaXMgPG1hdHRtYXRoaXM9NDBnb29nbGUuY29tQGRtYXJj
LmlldGYub3JnPjsgdGNwbSBJRVRGIGxpc3QgPHRjcG1AaWV0Zi5vcmc+OyBNaXJqYSBLdWVobGV3
aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0Pg0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW3RjcG1d
IEEgcG9zc2libGUgc2ltcGxpZmljYXRpb24gZm9yIEFjY0VDTiBzZXJ2ZXJzDQoNCkp1c3QgcmVt
ZW1iZXIgdGhhdCB3aW5kb3dzIHdpbGwgbm93YWRheXMgZ28gd2l0aCBkY3RjcCBpZiB5b3UgdHVy
biBvbiBlY24sIGFuZCB0aGUgc2VydmVyIGlzIGxlc3MgdGhhbiAxMG1zIHJ0dCBhd2F5ICh3aGlj
aCBpcyBwb3NzaWJsZSBpbiBjaXRpZXMgd2hlcmUgYSBjZG4gY29sb2NhdGVzIHdpdGggeW91ciBp
c3AuLi4pDQoNCkp1c3Qgc2F5aW7igJkgOikNCg0KR2VzZW5kZXQgbWl0IGRlciBHTVggTWFpbCBB
cHANCg0KQW0gMTIuMTIuMTkgdW0gMTk6MzIgc2NocmllYiBKb25hdGhhbiBNb3J0b24NCg0KPiA+
IE9uIDEyIERlYywgMjAxOSwgYXQgNTowNyBwbSwgTWF0dCBNYXRoaXMgPG1hdHRtYXRoaXM9NDBn
b29nbGUuY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gPiANCj4gPiBJcyB0aGVyZSBhbnkg
cmVhc29uIHRvIHdhbnQgdG8gaGF2ZSAzMTY4IGFuZCBBY2NFQ04gY29leGlzdGVuY2UgYmV5b25k
IGEgdHJhbnNpdGlvbj8gIFB1dCBhbm90aGVyIHdheSwgaWYgd2UgaW1hZ2luZSBmdWxseSBzdXBw
b3J0aW5nIGJvdGggMzE2OCBhbmQgQWNjRUNOLCBpdCB0aGVyZSBhbnkgcmVhc29uIHRvIGNob29z
ZSAzMTY4IG90aGVyIHRoYW4gZGVwbG95bWVudCBpbmVydGlhPw0KPiANCj4gQmVjYXVzZSB0aGVy
ZSBhcmUgc3RpbGwgcG90ZW50aWFsIHZhbGlkIGV4cGVyaW1lbnRzIHdoaWNoIGJ1aWxkIHVwb24g
UkZDLTMxNjggc2lnbmFsbGluZywgaW5jbHVkaW5nIFNDRSwgd2hpY2ggbWF5IHlldCBwcm92ZSBw
b3B1bGFyLiAgSSB0aGluayBpdCB3b3VsZCBiZSBleGNlZWRpbmdseSBzaG9ydC1zaWdodGVkIHRv
IHByZXZlbnQgc3VjaCBleHBlcmltZW50cyBmcm9tIHN1Y2NlZWRpbmcsIGFuZCBub3QganVzdCBi
ZWNhdXNlIEkgaGFwcGVuIHRvIGJlIGludm9sdmVkIGluIG9uZS4NCj4gDQo+IEFuZCBiZWNhdXNl
IHRoZXJlJ3MgYW4gKmF3ZnVsIGxvdCogb2YgUkZDLTMxNjggY29tcGxpYW50IGVuZHBvaW50cyBv
dXQgdGhlcmUuICBFdmVyeSBjdXJyZW50IEFwcGxlIHByb2R1Y3QgcmVxdWVzdHMgUkZDLTMxNjgg
RUNOIGJ5IGRlZmF1bHQuICBTb21lIG1ham9yIExpbnV4IGRpc3Ryb3MgZG8gYXMgd2VsbCwgYW5k
IGZvciBhbGwgb3RoZXJzIGl0J3MgYSBtZXJlIHN5c2N0bCBhd2F5LiAgRXZlbiBXaW5kb3dzIHVz
ZXJzIGNhbiB0dXJuIGl0IG9uIGp1c3QgYXMgZWFzaWx5LCB0aG91Z2ggaXQgaXMgbm90IG9uIGJ5
IGRlZmF1bHQuDQo+IA0KPiBUaGUgRUNOLWF3YXJlIG1pZGRsZWJveGVzIGludGVuZGVkIGZvciB1
c2Ugb24gbGFzdC1taWxlIGxpbmtzIGFuZCBhcyB3aWZpIEFQcyBhbHNvIHVuaXZlcnNhbGx5IHNp
Z25hbCBpbiB0aGUgUkZDLTMxNjggbWFubmVyIGFuZCBleHBlY3QgYW4gUkZDLTMxNjggKG9yIFJG
Qy04NTExKSBjb21wbGlhbnQgcmVzcG9uc2UuICBJJ3ZlIGZvdW5kIENQRSBhZHZlcnRpc2luZyBz
dXBwb3J0IGZvciBleGFjdGx5IHRoaXMgb24gdGhlIHNoZWxmLiAgVGhlIHJlY2VudCAibWFrZSB3
aWZpIGZhc3QiIG1vZGlmaWNhdGlvbnMgdG8gdGhlIExpbnV4IHdpZmkgc3RhY2sgaW5jbHVkZSBh
IGJ1aWx0LWluIGZxX2NvZGVsIEFRTSBmb3IgdGhlIHZlcnkgY29tbW9uIGF0aDlrLCBhdGgxMGsg
YW5kIG10NzYgaGFyZHdhcmUuDQo+IA0KPiBUaGF0IGRlcGxveW1lbnQgcmVtYWlucyBsb3cgaW4g
dGhlIGNhcnJpZXItZ3JhZGUgbWFya2V0IGlzIGluY3JlYXNpbmdseSBhbm9tYWxvdXMgKGFuZCBt
b3N0bHkgZHVlIHRvIGEgY2hpY2tlbi1hbmQtZWdnIHNpdHVhdGlvbiB3aGVyZWJ5IGNhcnJpZXJz
IGNhbid0IHR1cm4gaXQgb24gYmVjYXVzZSBIVyBkb2Vzbid0IHN1cHBvcnQgaXQsIGFuZCBIVyB2
ZW5kb3JzIGRvbid0IGltcGxlbWVudCBpdCBiZWNhdXNlIHRoZWlyIGN1c3RvbWVycyBkb24ndCBt
YWtlIGEgc3RpbmsgYWJvdXQgaXQpLiAgTmV2ZXJ0aGVsZXNzLCBhdCBsZWFzdCB0d28gbWFqb3Ig
RXVyb3BlYW4gSVNQcyBhcmUga25vd24gdG8gaGF2ZSBkZXBsb3llZCBmcV9jb2RlbCBpbiBib3Ro
IGRpcmVjdGlvbnMsIGluIHRoZSBuYW1lIG9mIGltcHJvdmluZyBjdXN0b21lcnMnIFFvUy4NCj4g
DQo+IFRoaXMgaXMgd2hhdCBJIG1lYW4gYnkgUkZDLTMxNjggZGVwbG95bWVudCAidGFraW5nIG9m
ZiIgaW4gdGhlIHBhc3QgZmV3IHllYXJzLiAgVGhlcmUncyBhIGxvdCBtb3JlIG9mIGl0IG5vdyB0
aGFuIHRoZXJlIHdhcyBmaXZlIHllYXJzIGFnbywgZHVlIGluIGxhcmdlIHBhcnQgdG8gdGhlIHN1
cGVybGF0aXZlIHBlcmZvcm1hbmNlIG9mIENvZGVsIEFRTSAtIHdoaWNoIGlzICpzcGVjaWZpY2Fs
bHkqIGRlc2lnbmVkIGFyb3VuZCBSRkMtMzE2OCByZXNwb25zZSBjaGFyYWN0ZXJpc3RpY3MuICBX
ZSd2ZSBhbHJlYWR5IGRpc2N1c3NlZCB0aGlzIHNvbWV3aGF0IGluIFRTVldHLg0KPiANCj4gIC0g
Sm9uYXRoYW4gTW9ydG9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZw0KaHR0cHM6Ly9uYW0w
Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3
LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0YT0wMiU3QzAxJTdD
cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMjEzN2M4MWFmYTYxNDMyODZjOTMwOGQ3N2YzNDk5OTIl
N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTE3NzM2MjE0
MTgzODM3JmFtcDtzZGF0YT1kOHE4STUzalFVenUwMWZWSSUyRmJHZjk3dFZYSGNTWVNyVXJadk1S
UG8wZ3clM0QmYW1wO3Jlc2VydmVkPTANCg==