From nobody Mon Apr 5 12:37:43 2021 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 2A5E43A24DD; Mon, 5 Apr 2021 12:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 arv57Zi66vdM; Mon, 5 Apr 2021 12:37:36 -0700 (PDT) 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 0D39B3A24DC; Mon, 5 Apr 2021 12:37:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0A5C425A2E; Mon, 5 Apr 2021 21:37:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1617651452; bh=mZ5nTNGxPU/h7l4/lGfS8s4Bb0EZh5Ch6yMKiLRurFo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=b22edJL+ledmveFZks3spZOOuuLogg5xHmsRzgC7iw3WMPxDyC6YFJJwlngMzgON7 FzkDxT4E+gBNQCNsxZ2h9vjtC2VzfqGTwrBhrxbA76gLAqYrTXuK42nB+up2aJPVRO qt1o8bY3gfEvKNWsDnHU7exvpktnJ66Kr9PIEuQY= 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 0-9RDBi1rDyZ; Mon, 5 Apr 2021 21:37:31 +0200 (CEST) Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 5 Apr 2021 21:37:31 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 5 Apr 2021 21:37:30 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.009; Mon, 5 Apr 2021 21:37:30 +0200 From: "Scharf, Michael" To: tcpm IETF list CC: tcpm-chairs Thread-Topic: WG acceptance of draft-touch-tcpm-ao-test-vectors Thread-Index: AdcXUoVwsaN/3P3lS4aR3KKf6cfKYQTAA0Xw Date: Mon, 5 Apr 2021 19:37:30 +0000 Message-ID: <7a23db702b7442ae84d598b357184a3c@hs-esslingen.de> References: <47ebaa639de147f4bb1812982ff67ab8@hs-esslingen.de> In-Reply-To: <47ebaa639de147f4bb1812982ff67ab8@hs-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WG acceptance of draft-touch-tcpm-ao-test-vectors 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, 05 Apr 2021 19:37:41 -0000 SGkgYWxsLA0KDQpUaGVyZSBoYXMgYmVlbiBubyBwdXNoYmFjay4gVGhlcmVmb3JlLCB0aGlzIGRv Y3VtZW50IGlzIGFjY2VwdGVkIGFzIG5ldyBUQ1BNIHdvcmtpbmcgZ3JvdXAgaXRlbS4NCg0KQGF1 dGhvcnM6IFBsZWFzZSByZXN1Ym1pdCB0aGUgSS1EIGFzIGRyYWZ0LWlldGYtdGNwbS1hby10ZXN0 LXZlY3RvcnMuDQoNClRoYW5rcw0KDQpNaWNoYWVsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogU2NoYXJmLCBNaWNoYWVsIDxNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5n ZW4uZGU+DQo+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMTIsIDIwMjEgNDoxNiBQTQ0KPiBUbzogdGNw bSBJRVRGIGxpc3QgPHRjcG1AaWV0Zi5vcmc+DQo+IENjOiB0Y3BtLWNoYWlycyA8dGNwbS1jaGFp cnNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFdHIGFjY2VwdGFuY2Ugb2YgZHJhZnQtdG91Y2gtdGNw bS1hby10ZXN0LXZlY3RvcnMNCj4gDQo+IERlYXIgYWxsLA0KPiANCj4gRHVyaW5nIHRoZSBUQ1BN IG1lZXRpbmcgdG9kYXkgdGhlcmUgd2FzIHBvc2l0aXZlIGZlZWRiYWNrIG9uIHdvcmtpbmcNCj4g Z3JvdXANCj4gYWNjZXB0YW5jZSBvZiBkcmFmdC10b3VjaC10Y3BtLWFvLXRlc3QtdmVjdG9ycy4N Cj4gDQo+IFRoaXMgZS1tYWlsIHNoYWxsIGNvbmZpcm0gYWRkaW5nIGEgbmV3IG1pbGVzdG9uZSBm b3IgYW4gaW5mb3JtYXRpb25hbCBSRkMgb24NCj4gIlRDUC1BTyBUZXN0IFZlY3RvcnMiIHRvIHRo ZSBUQ1BNIGNoYXJ0ZXIuDQo+IA0KPiBBbnkgY29tbWVudHMgd291bGQgYmUgd2VsY29tZS4gSWYg dGhlcmUgYXJlIG5vIG1ham9yIGNvbmNlcm5zIHVudGlsDQo+IE1hcmNoIDI2LA0KPiB0aGUgZG9j dW1lbnQgd2lsbCBiZSBhY2NlcHRlZCBhcyBuZXcgaW5mb3JtYXRpb25hbCBXRyBpdGVtIGluIFRD UE0uDQo+IA0KPiBCZXN0IHJlZ2FyZHMNCj4gDQo+IE1pY2hhZWwgUy4NCj4gDQo+IA0KPiBQUzog VENQLUFPIG1heSBiZSBwYXJ0aWN1bGFybHkgcmVsZXZhbnQgZm9yIFRDUCBpbXBsZW1lbnRhdGlv bnMgb24gbmV0d29yaw0KPiBkZXZpY2VzIChlLmcuLCByb3V0ZXJzKS4gT25lIG1haW4gdXNlIGNh c2UgZm9yIFRDUC1BTyBpcyBzZWN1cmluZyB0aGUgY29udHJvbA0KPiBwbGFuZSBpbnNpZGUgbmV0 d29ya3MgKEJHUCwgTERQLCBldGMuKS4gVENQTSBvd25zIFRDUC1BTy4gVGhlcmUgd2FzIGENCj4g cXVlc3Rpb24NCj4gaW4gdGhlIHJvb20gd2h5IHRoZSBjaGFpcnMgaGF2ZSBub3QgYXNrZWQgdGhl IHF1ZXN0aW9uICJob3cgbWFueQ0KPiBjb250cmlidXRvcnMNCj4gaGF2ZSByZWFkIHRoaXMgZG9j dW1lbnQ/Ii4gV2VsbCwgdGhpcyBkb2N1bWVudCBoYXMgdG8gYmUgcmVsZXZhbnQgYW5kDQo+IHVz ZWZ1bA0KPiB0byB0aG9zZSB3aG8gYWN0dWFsbHkgd29yayBvbiAobmV3KSBUQ1AtQU8gaW1wbGVt ZW50YXRpb25zLiBBbmQgdGhlcmUNCj4gYXJlDQo+IHF1aXRlIGEgbnVtYmVyIG9mIHJlY2VudCBy ZXBvcnRzIG9uIChuZXcpIHJ1bm5pbmcgVENQLUFPIGNvZGUsIGJ1dCBub25lDQo+IG9mDQo+IHRo ZW0gZGVhbHMgd2l0aCBkZXNrdG9wIG9yIHNlcnZlciBvcGVyYXRpbmcgc3lzdGVtcyB0aGF0IGFy ZSBmcmVxdWVudGx5DQo+IGRpc2N1c3NlZCBpbiBUQ1BNLiBBcyBsb25nIGFzIHByb3BlciByZXZp ZXcgb2YgdGhpcyBkb2N1bWVudCBjYW4gYmUNCj4gZW5zdXJlZA0KPiBpbnNpZGUgVENQTSwgaXQg ZG9lcyBub3QgcmVhbGx5IG1hdHRlciB3aGF0IHJlbGF0aXZlIHNoYXJlIG9mIGNvbnRyaWJ1dG9y cw0KPiBhY3R1YWxseSB3b3JrIG9uIFRDUC1BTy4gU28sIHRoYXQgcXVlc3Rpb24gd291bGQgbm90 IGhhdmUgZ2l2ZW4gdXMgbXVjaA0KPiByZWxldmFudCBpbnNpZ2h0Lg0K From nobody Tue Apr 6 00:44:58 2021 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 482E13A13B1 for ; Tue, 6 Apr 2021 00:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=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 p3In4lUfqClQ for ; Tue, 6 Apr 2021 00:44:51 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 F0D443A13B4 for ; Tue, 6 Apr 2021 00:44:45 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id g20so14054022qkk.1 for ; Tue, 06 Apr 2021 00:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UG47y3B3DTVORe9HRSVMW2J9uk/Z7l1izr38764RkNQ=; b=pmxrsrn/iFY9YvkQBbbxbobAKNBH7HfHnv93ss808mX8B5tk9L4n6RpWsDi/L0RmgK FgBzHfJGbx7fE+B1kJBZZxuqRW99Qy4Rv1bvevjffiK0qC++feIR6ShszMZDNw+cPlpS 4swYHa3EXObnERBfBMbT1Ys3TR0kHdjJNrU3kj8O4CIkz4hOooXFgprFgiFxSwv8cf+B keVVYtJAax3Crm18XxT/ZYiLWcDjxHg54wHFMulZ6MVXybEhpuH9yGviXgpTjkdP461U d04Q6BtMVRYhYAzJgOSL9kDwxHS0Bn0GGNzz0L5zoHljwkhjZKlS8yi61A3vRIva+p9h Ef8A== 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=UG47y3B3DTVORe9HRSVMW2J9uk/Z7l1izr38764RkNQ=; b=Ud2ciCiZgzNyO53ItKcPCFnN4aZmHUW4RbJuFHf/o5YFT3KYgs+JF7ga9+GyrinfOC jgz6psGn+r+AB+J2HKZSrGOmioNdlxaTp6Eo1sNSwpIZEZbynOdU7nABVb+RmsIL+kkb wCIszuRRpU+AFKUmYZavyB19wbBHoy4Epp8e4QH/RXoS2AkUMpi2/4ZG+SomMS3nqxcp Q4JDapJbsubjJTXZnAkX8MX+MBtYbcfmNTjrnk10IpjKhzps0iO4+lWRTuLUCAZdQuNZ abkl48j2CT+Yg1gdY5Er5eNQwdiVZyk4LhpDivtOOkBWVTAU1TvPBZ+EVmV9TkjLr61I 2MJQ== X-Gm-Message-State: AOAM531KdTOZhiMEIV0FM0SKsGHb0J7vaiEbmwAz1OA3VeounSXPcYUI D81uH3Eo3E+vqU3UJF7DHzoZgoUAaUc/LNhNLLo= X-Google-Smtp-Source: ABdhPJw4ly+KeROfY7CmS/h5S4ZRA2OgvyluK7agGK19UBR60U3bL0zNLhKijI09mckBE24gwc8pp1ohNjw/fOXeGYA= X-Received: by 2002:a05:620a:15eb:: with SMTP id p11mr27717193qkm.454.1617695084585; Tue, 06 Apr 2021 00:44:44 -0700 (PDT) MIME-Version: 1.0 References: <47df9b8b-515e-d40d-3473-599b0a3e3876@bobbriscoe.net> <6031BE2B-4D33-426F-BA17-DDF15CF821DE@kuehlewind.net> <060c8bd8-d64b-3e46-7874-742e35e6d114@bobbriscoe.net> <221e58f3-ada0-c880-db72-d98af84fedb8@gmx.at> <8151fdef-ae78-80f3-adfc-d40db878ac8e@gmx.at> <48c5910d-5340-acd6-8fd9-fff1b7758310@bobbriscoe.net> <99B71B9A-EC9B-47FD-A149-FBEF9DEEC8DC@kuehlewind.net> In-Reply-To: From: Yoshifumi Nishida Date: Tue, 6 Apr 2021 00:44:33 -0700 Message-ID: To: Praveen Balasubramanian Cc: "rs.ietf@gmx.at" , "ietf@bobbriscoe.net" , "nishida@sfc.wide.ad.jp" , "tcpm@ietf.org" , "ietf@kuehlewind.net" Content-Type: multipart/alternative; boundary="000000000000df26ca05bf48fc4d" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in 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: Tue, 06 Apr 2021 07:44:56 -0000 --000000000000df26ca05bf48fc4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, It seems this is a part of CC although this looks an interesting topic for discussion. I am thinking that the detailed of CC would be outside of this draft. we might need another draft to define this behavior. -- Yoshi On Tue, Mar 30, 2021 at 9:30 AM Praveen Balasubramanian wrote: > How is the sender of the pure ACKs supposed to react upon receiving the > feedback that ACKs themselves are causing congestion? Option B conveys th= is > additional information but how is it supposed to be used? Can a pure > receiver get into such a state and does it need to start throttling ACKs? > > ECN++ draft section 3.3.3 leaves the reaction to the AccECN draft but I a= m > not able to locate the text in the latest AccECN draft. > > -----Original Message----- > From: tcpm On Behalf Of Scheffenegger, Richard > Sent: Tuesday, March 30, 2021 4:13 AM > To: Yoshifumi Nishida ; Bob Briscoe < > ietf@bobbriscoe.net> > Cc: Yoshifumi Nishada ; tcpm IETF list < > tcpm@ietf.org>; Mirja Kuehlewind > Subject: [EXTERNAL] Re: [tcpm] Seeking WG opinions on ACKing ACKs with > good cause (was: Possible error in accurate-ecn) > > > As a co-author and implementor, I would prefer (B). > > While I understand the concerns raised about additional ACKs, formally > these ACKs-for-CE-ACks do convey new information. > > Also, the risk of rare spurious retransmissions (because of a > misclassification, or not considering present SACK / TS information) by t= he > NEW sender is IMHO lower, than the benefit of maintaining good congetion > state in the OLD sender for subsequent transmissions. > > As mentioned earlier, additional heuristics (activating delayed timeout, > eliciting the response for 'n' immediately on receipt of 'n+1' (and > retaining the one pending delta) can further help diminish the ping-pong, > while an 'n' of 3 dramatically dampens the number of ACKs-for-CE-ACKs. > > However, I suspect that the above mentioned changes would not be necessar= y > in non-pathological circumstances at all. > > Best regards, > Richard > > > > > > Am 30.03.2021 um 11:35 schrieb Yoshifumi Nishida: > > Hi Bob, > > > > On Thu, Mar 25, 2021 at 12:03 PM Bob Briscoe > > wrote: > > > > Yoshi, > > > > On 24/03/2021 08:44, Yoshifumi Nishida wrote: > >> Hi Bob, Mirja > >> > >> On Mon, Mar 22, 2021 at 3:08 AM Mirja Kuehlewind > >> > wrote: > >> > >> See inline. > >> > >> > On 19. Mar 2021, at 18:37, Bob Briscoe >> > wrote: > >> > > >> > Yoshi, > >> > > >> > On 17/03/2021 07:22, Yoshifumi Nishida wrote: > >> >> Hi Bob, > >> >> > >> >> On Fri, Mar 12, 2021 at 2:54 AM Bob Briscoe > >> > wrote: > >> >> Yoshi, tcpm list, > >> >> > >> >> As promised we set up a small design team on the single > >> issue of occasionally ACKing pure ACKs if they carry new info > >> (ECN marking at the IP layer). The design team has two > >> solutions and everyone would be prepared to accept either, but > >> preferences differ. So we're seeking wider opinions (more > >> opinions obviously won't narrow the choices, but at least the > >> WG can then make a decision informed by those who care). > >> >> > >> >> To understand the question, you can either read the email > >> below. Or the 3 slides for the tcpm meeting are briefer, and > >> include pictures: > >> >> > >> > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fmeeting%2F110%2Fmaterials%2Fslides-110-tcpm-draft-ietf-tc= pm-accurate-ecn-00%23page%3D6&data=3D04%7C01%7Cpravb%40microsoft.com%7C= 12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV= 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Dt5T6laDBNruH4VDgCE= jhHYI7IpbVAOrktd9iCw1MpKg%3D&reserved=3D0 > >> < > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fmeeting%2F110%2Fmaterials%2Fslides-110-tcpm-draft-ietf-tc= pm-accurate-ecn-00%23page%3D6&data=3D04%7C01%7Cpravb%40microsoft.com%7C= 12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV= 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Dt5T6laDBNruH4VDgCE= jhHYI7IpbVAOrktd9iCw1MpKg%3D&reserved=3D0 > > > >> >> > >> >> Here's the current draft text in question (see here for > >> context > >> > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-ietf-tcpm-accurate-ecn-14%23section-3.2.2.5&da= ta=3D04%7C01%7Cpravb%40microsoft.com%7C12697bf5f0b94211a1a508d8f36cf000%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637526997015192764%7CUnknown%7CTW= FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C3000&sdata=3DFJrrumB1WBtsjRgiDPO5hWlnbveUaUWb8kAF2Qhk2xA%3D&res= erved=3D0 > >> < > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-ietf-tcpm-accurate-ecn-14%23section-3.2.2.5&da= ta=3D04%7C01%7Cpravb%40microsoft.com%7C12697bf5f0b94211a1a508d8f36cf000%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637526997015192764%7CUnknown%7CTW= FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C3000&sdata=3DFJrrumB1WBtsjRgiDPO5hWlnbveUaUWb8kAF2Qhk2xA%3D&res= erved=3D0 > > > >> ): > >> >> 3.2.2.5.1 Data Receiver Safety Procedures > >> >> > >> >> An AccECN Data Receiver: > >> >> > >> >> o SHOULD immediately send an ACK whenever a data packet > >> marked CE > >> >> arrives after the previous packet was not CE. > >> >> > >> >> o MUST immediately send an ACK once 'n' CE marks have > >> arrived since > >> >> the previous ACK, where 'n' SHOULD be 2 and MUST be > >> in the range 2 > >> >> to 6 inclusive. > >> >> > >> >> > >> >> Only the second bullet is in question. Here is the proposed > >> diff for each alternative, then we explain: > >> >> > >> >> Alternative A > >> >> o MUST immediately send an ACK once 'n' CE marks have > >> arrived since > >> >> - the previous ACK, > >> >> + the previous ACK and there is outstanding data to > >> acknowledge, > >> >> where 'n' SHOULD be 2 and MUST be in the range 2 to 6 > >> inclusive. > >> >> > >> >> > >> >> Alternative B > >> >> o MUST immediately send an ACK once 'n' CE marks have > >> arrived since > >> >> - the previous ACK, where 'n' SHOULD be 2 and MUST be > >> in the range 2 > >> >> + the previous ACK, where 'n' SHOULD be 3 and MUST be > >> in the range 3 > >> >> to 6 inclusive. > >> >> > >> >> > >> >> Extra guidance text would be required in each case too (see > >> the end). > >> >> > >> >> Background: > >> >> AccECN is a change to the TCP wire protocol that requires > >> the packet count of congestion feedback to include any > >> congestion experienced (CE) arriving on Pure ACKs (amongst > >> other things). AccECN doesn't require Pure ACKs to be > >> ECN-capable, but allows for them to be. Similarly, AccECN > >> doesn't require any congestion response to CE on pure ACKs, > >> but having the feedback information there allows a response to > >> be added with a one-ended update, if desired/necessary. > >> Basically the data receiver is a 'dumb reflector'. > >> >> > >> >> The above two bullets were designed to ensure that an ACK > >> is triggered a) on the first sign of congestion, and b) > >> frequently enough for the count of CE markings to be fed back > >> using the 3-bit ACE field before it wraps, even if an > >> occasional pure ACK is lost. > >> >> > >> >> We then realized that the wording could require an ACK to > >> be triggered in response to a CE-marked pure ACK. The > >> circumstance when this could occur would be when peer X sends > >> a volley of data to Y then stops, and the path back from Y to > >> X is congested (probably by other flow(s) so that many of the > >> ACKs are CE-marked. The second bullet above under alternative > >> (B) would require X to ACK every 'n-th' CE-marked pure ACK. > >> However, if Y immediately started sending a volley of data to > >> X, Y could misinterpret those ACKs (of ACKs) from X as DupACKs= . > >> >> > >> >> There are two ways to deal with this: > >> >> A) Some of us prefer to completely prevent ACKs on pure > >> ACKs, on the basis that they do not want to risk sometimes > >> generating more ACKs today > >> >> B) Others want to ensure that these rules will cause pure > >> ACKs to be ACKed when the amount of CE on the ACKs merits it. > >> But sparingly and strongly damping any ACK ping-pong. > >> >> > >> >> Hmm. This is not easy.. > >> >> My personal preference is if SACK is negotiated and it 's > >> utilized to distinguish dupacks, then (B) is fine for me. > >> Otherwise, I would prefer (A). > >> >> > >> >> BTW, I am wondering if this could leave it to > >> implementations since both methods have pros and cons. > >> >> I think It's hard to tell one is much better than the order= . > >> > > >> > [BB] The problem is that the decision impacts the complexity > >> of the other end, not just the implementer's own code. > >> > > >> > * If an implementer chooses (A) (doesn't ACK pure ACKs at > >> all), when it finally does send some data, it's CE counter > >> could have built up an (unlimited) store of unreported CE > >> marks, which it will report all at once. So implementations > >> will have to include code that copes with receiving > >> potentially multiple wraps of the ACE field (or just ignore > >> the possibility). > >> > >> You always need to cover this case because it is always > >> possible to lose ACKs and then counter may wrap. However, I > >> don't think you actually need to implement any logic to detect > >> this. It only means the counters on both ends are off by N x 8 > >> but congestion information is only valid that the point when > >> it happens and resyncing on outdated information doesn't help > >> anybody. > >> > >> > >> So, in my understanding, there are two types of choices for > >> implementations on the other end. > >> 1) need to decide whether ignore CE counter wraps or prepare for > >> it (for both A and B) > >> 2) need to decide whether identify ACKs on pure ACKs by accecn or > >> accept possible ack ping-pong (for only B) > >> > >> In this case, > >> For 1) > >> Choosing (A) or (B) doesn't matter because both (A) and (B) > >> have this potential risk. > >> For 2) > >> if we pick A, we don't need this. > >> if we pick B, we need this > >> if we allow both, we need this > >> If I think in this way, choosing (B) is not much different from > >> allowing both? > > > > [BB] Yes,... > > ...but I should make it clear that these pros and cons solely > > describe the implementation complexity of each choice. They don't > > say anything about the benefit of the feedback itself being > > available during that switch-over round trip... > > > > In scenarios where the direction of data switches, option A is > > simpler for one peer, but it denies its peer the benefit of > > continuing to maintain cwnd up to the point it starts sending. So: > > > > If we pick A, no-one gets the benefit but there's not the complexit= y > > of the extra check for B > > If we pick B, everyone gets the benefit and everyone has the > > complexity of the extra check for B > > If we allow both, one peer only gets the benefit if the other peer > > chooses the complexity of the extra check for B. > > > > If we allow both, one peer also has the uncertainty of not knowing > > whether the other peer implements B. An implementater might be able > > to develop a better cwnd validation algorithm if it knows for > > certain whether absence of feedback from the other end is purely > > because it hasn't implemented option B. > > > > > > Yes, It seems that they all have pros and cons. > > It would be good if we can get feedback from implementers here.. > > If there is no strong opinion on this point in the community, I think > > the author will need to pick one at some point. > > -- > > Yoshi > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40microsoft.= com%7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzEm1fZiCGkXd= JIK3RUzItPrKvuRm9WypbyWzRX0D8wA%3D&reserved=3D0 > --000000000000df26ca05bf48fc4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

It seems this is a= part of CC although this looks an interesting topic for discussion.=C2=A0<= br>
I am thinking that the detailed of CC would be outside of thi= s draft.
we might need another draft to define this behavior.--
Yoshi

On Tue, Mar 30, 2021 at 9:30 AM Praveen Balasubramanian = <pravb@microsoft.com> wrot= e:
How is the se= nder of the pure ACKs supposed to react upon receiving the feedback that AC= Ks themselves are causing congestion? Option B conveys this additional info= rmation but how is it supposed to be used? Can a pure receiver get into suc= h a state and does it need to start throttling ACKs?

ECN++ draft section 3.3.3 leaves the reaction to the AccECN draft but I am = not able to locate the text in the latest AccECN draft.

-----Original Message-----
From: tcpm <t= cpm-bounces@ietf.org> On Behalf Of Scheffenegger, Richard
Sent: Tuesday, March 30, 2021 4:13 AM
To: Yoshifumi Nishida <nsd.ietf@gmail.com>; Bob Briscoe <ietf@bobbriscoe.net>
Cc: Yoshifumi Nishada <nishida@sfc.wide.ad.jp>; tcpm IETF list <tcpm@ietf.org>; Mirja Kuehlew= ind <ietf@kuehl= ewind.net>
Subject: [EXTERNAL] Re: [tcpm] Seeking WG opinions on ACKing ACKs with good= cause (was: Possible error in accurate-ecn)


As a co-author and implementor, I would prefer (B).

While I understand the concerns raised about additional ACKs, formally thes= e ACKs-for-CE-ACks do convey new information.

Also, the risk of rare spurious retransmissions (because of a misclassifica= tion, or not considering present SACK / TS information) by the NEW sender i= s IMHO lower, than the benefit of maintaining good congetion state in the O= LD sender for subsequent transmissions.

As mentioned earlier, additional heuristics (activating delayed timeout, el= iciting the response for 'n' immediately on receipt of 'n+1'= ; (and retaining the one pending delta) can further help diminish the ping-= pong, while an 'n' of 3 dramatically dampens the number of ACKs-for= -CE-ACKs.

However, I suspect that the above mentioned changes would not be necessary = in non-pathological circumstances at all.

Best regards,
=C2=A0 =C2=A0Richard





Am 30.03.2021 um 11:35 schrieb Yoshifumi Nishida:
> Hi Bob,
>
> On Thu, Mar 25, 2021 at 12:03 PM Bob Briscoe <ietf@bobbriscoe.net
> <mailto:ie= tf@bobbriscoe.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Yoshi,
>
>=C2=A0 =C2=A0 =C2=A0On 24/03/2021 08:44, Yoshifumi Nishida wrote:
>>=C2=A0 =C2=A0 =C2=A0Hi Bob, Mirja
>>
>>=C2=A0 =C2=A0 =C2=A0On Mon, Mar 22, 2021 at 3:08 AM Mirja Kuehlewin= d
>>=C2=A0 =C2=A0 =C2=A0<ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0See inline.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On 19. Mar 2021, at 18:37, B= ob Briscoe <iet= f@bobbriscoe.net
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ietf@bobbriscoe.net>> wrote: >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Yoshi,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On 17/03/2021 07:22, Yoshifu= mi Nishida wrote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Hi Bob,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> On Fri, Mar 12, 2021 at = 2:54 AM Bob Briscoe
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>>= ; wrote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Yoshi, tcpm list,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> As promised we set up a = small design team on the single
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issue of occasionally ACKing pure= ACKs if they carry new info
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(ECN marking at the IP layer). Th= e design team has two
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0solutions and everyone would be p= repared to accept either, but
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0preferences differ. So we're = seeking wider opinions (more
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opinions obviously won't narr= ow the choices, but at least the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WG can then make a decision infor= med by those who care).
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> To understand the questi= on, you can either read the email
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0below. Or the 3 slides for the tc= pm meeting are briefer, and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0include pictures:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracke= r.ietf.org%2Fmeeting%2F110%2Fmaterials%2Fslides-110-tcpm-draft-ietf-tcpm-ac= curate-ecn-00%23page%3D6&amp;data=3D04%7C01%7Cpravb%40microsoft.com%7C1= 2697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%= 7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2= luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3Dt5T6laDBNruH4VD= gCEjhHYI7IpbVAOrktd9iCw1MpKg%3D&amp;reserved=3D0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr= acker.ietf.org%2Fmeeting%2F110%2Fmaterials%2Fslides-110-tcpm-draft-ietf-tcp= m-accurate-ecn-00%23page%3D6&amp;data=3D04%7C01%7Cpravb%40microsoft.com= %7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%= 7C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3Dt5T6laDBNru= H4VDgCEjhHYI7IpbVAOrktd9iCw1MpKg%3D&amp;reserved=3D0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Here's the current d= raft text in question (see here for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0context
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://nam06.safelinks.protection.outl= ook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tcpm-accura= te-ecn-14%23section-3.2.2.5&amp;data=3D04%7C01%7Cpravb%40microsoft.com%= 7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7C1%7= C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DFJrrumB1WBts= jRgiDPO5hWlnbveUaUWb8kAF2Qhk2xA%3D&amp;reserved=3D0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://nam06.safelinks.protection.= outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tcpm-ac= curate-ecn-14%23section-3.2.2.5&amp;data=3D04%7C01%7Cpravb%40microsoft.= com%7C12697bf5f0b94211a1a508d8f36cf000%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C637526997015192764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DFJrrumB1= WBtsjRgiDPO5hWlnbveUaUWb8kAF2Qhk2xA%3D&amp;reserved=3D0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0):
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> 3.2.2.5.1 Data Receiver = Safety Procedures
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 An AccECN D= ata Receiver:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 o=C2=A0 SHO= ULD immediately send an ACK whenever a data packet
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0marked CE
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2= =A0arrives after the previous packet was not CE.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 o=C2=A0 MUS= T immediately send an ACK once 'n' CE marks have
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arrived since
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2= =A0the previous ACK, where 'n' SHOULD be 2 and MUST be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the range 2
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2= =A0to 6 inclusive.
>>=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>> Only the second bullet i= s in question. Here is the proposed
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diff for each alternative, then w= e explain:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Alternative A
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 o=C2=A0 MUS= T immediately send an ACK once 'n' CE marks have
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arrived since
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> -=C2=A0 =C2=A0 =C2=A0the= previous ACK,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> +=C2=A0 =C2=A0 =C2=A0the= previous ACK and there is outstanding data to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledge,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2= =A0where 'n' SHOULD be 2 and MUST be in the range 2 to 6
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inclusive.
>>=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>> Alternative B
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 o=C2=A0 MUS= T immediately send an ACK once 'n' CE marks have
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arrived since
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> -=C2=A0 =C2=A0 =C2=A0the= previous ACK, where 'n' SHOULD be 2 and MUST be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the range 2
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> +=C2=A0 =C2=A0 =C2=A0the= previous ACK, where 'n' SHOULD be 3 and MUST be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the range 3
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2= =A0to 6 inclusive.
>>=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>> Extra guidance text woul= d be required in each case too (see
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the end).
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Background:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> AccECN is a change to th= e TCP wire protocol that requires
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the packet count of congestion fe= edback to include any
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0congestion experienced (CE) arriv= ing on Pure ACKs (amongst
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other things). AccECN doesn't= require Pure ACKs to be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ECN-capable, but allows for them = to be. Similarly, AccECN
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't require any congestio= n response to CE on pure ACKs,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but having the feedback informati= on there allows a response to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be added with a one-ended update,= if desired/necessary.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Basically the data receiver is a = 'dumb reflector'.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> The above two bullets we= re designed to ensure that an ACK
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is triggered a) on the first sign= of congestion, and b)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frequently enough for the count o= f CE markings to be fed back
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using the 3-bit ACE field before = it wraps, even if an
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0occasional pu= re ACK is lost.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> We then realized that th= e wording could require an ACK to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be triggered in response to a CE-= marked pure ACK. The
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0circumstance when this could occu= r would be when peer X sends
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a volley of data to Y then stops,= and the path back from Y to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X is congested (probably by other= flow(s) so that many of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACKs are CE-marked. The second bu= llet above under alternative
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(B) would require X to ACK every = 'n-th' CE-marked pure ACK.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0However, if Y immediately started= sending a volley of data to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X, Y could misinterpret those ACK= s (of ACKs) from X as DupACKs.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> There are two ways to de= al with this:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> A) Some of us prefer to = completely prevent ACKs on pure
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACKs, on the basis that they do n= ot want to risk sometimes
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generating more ACKs today
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> B) Others want to ensure= that these rules will cause pure
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACKs to be ACKed when the amount = of CE on the ACKs merits it.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But sparingly and strongly dampin= g any ACK ping-pong.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Hmm. This is not easy..<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> My personal preference i= s if SACK is negotiated and it 's
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0utilized to distinguish dupacks, = then (B) is fine for me.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Otherwise, I would prefer (A). >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> BTW, I am wondering if t= his could leave it to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementations since both method= s have pros and cons.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> I think It's hard to= tell one is much better than the order.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [BB] The problem is that the= decision impacts the complexity
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the other end, not just the im= plementer's own code.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> * If an implementer chooses = (A) (doesn't ACK pure ACKs at
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0all), when it finally does send s= ome data, it's CE counter
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0could have built up an (unlimited= ) store of unreported CE
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0marks, which it will report all a= t once. So implementations
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will have to include code that co= pes with receiving
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0potentially multiple wraps of the= ACE field (or just ignore
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the possibility).
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0You always need to cover this cas= e because it is always
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0possible to lose ACKs=C2=A0 and t= hen counter may wrap. However, I
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0don't think you actually need= to implement any logic to detect
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this. It only means the counters = on both ends are off by N x 8
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but congestion information is onl= y valid that the point when
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it happens and resyncing on outda= ted information doesn't help
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anybody.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0So, in my understanding, there are two types of= choices for
>>=C2=A0 =C2=A0 =C2=A0implementations on the other end.
>>=C2=A0 =C2=A0 =C2=A01) need to decide whether ignore CE counter wra= ps or prepare for
>>=C2=A0 =C2=A0 =C2=A0it=C2=A0 (for both A and B)
>>=C2=A0 =C2=A0 =C2=A02) need to decide whether identify ACKs on pure= ACKs=C2=A0by accecn=C2=A0or
>>=C2=A0 =C2=A0 =C2=A0accept possible ack ping-pong=C2=A0 (for only B= )
>>
>>=C2=A0 =C2=A0 =C2=A0In this case,
>>=C2=A0 =C2=A0 =C2=A0For 1)
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Choosing (A) or (B) doesn't ma= tter because both (A) and (B)
>>=C2=A0 =C2=A0 =C2=A0have this potential risk.
>>=C2=A0 =C2=A0 =C2=A0For 2)
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0if we pick A, we don't need th= is.
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0if we pick B, we need this
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0if we allow both, we need this
>>=C2=A0 =C2=A0 =C2=A0If I think in this way, choosing (B) is not muc= h different from
>>=C2=A0 =C2=A0 =C2=A0allowing both?
>
>=C2=A0 =C2=A0 =C2=A0[BB] Yes,...
>=C2=A0 =C2=A0 =C2=A0...but I should make it clear that these pros and c= ons solely
>=C2=A0 =C2=A0 =C2=A0describe the implementation complexity of each choi= ce. They don't
>=C2=A0 =C2=A0 =C2=A0say anything about the benefit of the feedback itse= lf being
>=C2=A0 =C2=A0 =C2=A0available during that switch-over round trip...
>
>=C2=A0 =C2=A0 =C2=A0In scenarios where the direction of data switches, = option A is
>=C2=A0 =C2=A0 =C2=A0simpler for one peer, but it denies its peer the be= nefit of
>=C2=A0 =C2=A0 =C2=A0continuing to maintain cwnd up to the point it star= ts sending. So:
>
>=C2=A0 =C2=A0 =C2=A0If we pick A, no-one gets the benefit but there'= ;s not the complexity
>=C2=A0 =C2=A0 =C2=A0of the extra check for B
>=C2=A0 =C2=A0 =C2=A0If we pick B, everyone gets the benefit and everyon= e has the
>=C2=A0 =C2=A0 =C2=A0complexity of the extra check for B
>=C2=A0 =C2=A0 =C2=A0If we allow both, one peer only gets the benefit if= the other peer
>=C2=A0 =C2=A0 =C2=A0chooses the complexity of the extra check for B. >
>=C2=A0 =C2=A0 =C2=A0If we allow both, one peer also has the uncertainty= of not knowing
>=C2=A0 =C2=A0 =C2=A0whether the other peer implements B. An implementat= er might be able
>=C2=A0 =C2=A0 =C2=A0to develop a=C2=A0 better cwnd validation algorithm= if it knows for
>=C2=A0 =C2=A0 =C2=A0certain whether absence of feedback from the other = end is purely
>=C2=A0 =C2=A0 =C2=A0because it hasn't implemented option B.
>
>
> Yes, It seems that they all have pros and cons.
> It would be good if we can get feedback from implementers here..
> If=C2=A0there is no strong opinion on this point in the community, I t= hink
> the author will=C2=A0need to pick one at some point.
> --
> Yoshi
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outl= ook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&a= mp;data=3D04%7C01%7Cpravb%40microsoft.com%7C12697bf5f0b94211a1a508d8f36cf00= 0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637526997015192764%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C3000&amp;sdata=3DzEm1fZiCGkXdJIK3RUzItPrKvuRm9WypbyWzRX0D8wA%3= D&amp;reserved=3D0
--000000000000df26ca05bf48fc4d-- From nobody Wed Apr 7 02:29:47 2021 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 D93473A13BF; Wed, 7 Apr 2021 02:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 jFJ568Qmdesi; Wed, 7 Apr 2021 02:29:41 -0700 (PDT) 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 A793D3A13BE; Wed, 7 Apr 2021 02:29:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1E4EB25B12; Tue, 6 Apr 2021 21:21:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1617736887; bh=5IZm8q9fPXkEhSrG98kZHrFde0D/efEmqffbODJsMYY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bIGsG3LldP9gc07d6O71wJVFVxGF6OPyUe2L4TTAYIz65eHAGWegwFjWr1/8oltaW 8t7h0xgpZbI+AMYU5tf9dJ5GB5gy/YlkI4oM7bOiBE5kRc1RO6bkFNI5VH3JzeDOFr Qe3B+tjzO9O1/ktPYBrkKF9xJcnl2QaSlUygvSd8= 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 1LQv9Gw3ZMtI; Tue, 6 Apr 2021 21:21:26 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 6 Apr 2021 21:21:26 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 6 Apr 2021 21:21:25 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.009; Tue, 6 Apr 2021 21:21:25 +0200 From: "Scharf, Michael" To: Mahesh Jethanandani , "netconf@ietf.org" CC: tcpm IETF list Thread-Topic: [netconf] WGLC for draft-ietf-netconf-tcp-client-server Thread-Index: AQHXIqD5efHe7Em2SUeq9T5051qlEqqn5VqQ Date: Tue, 6 Apr 2021 19:21:25 +0000 Message-ID: <14240f263d0c4834b943353d1e9da314@hs-esslingen.de> References: <7CAA30A6-8E26-4B0F-B0D0-DB376806B922@gmail.com> In-Reply-To: <7CAA30A6-8E26-4B0F-B0D0-DB376806B922@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: multipart/alternative; boundary="_000_14240f263d0c4834b943353d1e9da314hsesslingende_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [netconf] WGLC for draft-ietf-netconf-tcp-client-server 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, 07 Apr 2021 09:29:46 -0000 --_000_14240f263d0c4834b943353d1e9da314hsesslingende_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGFtIGEgY28tYXV0aG9yIG9mIHRoaXMgSS1ELCBzbyBpZiBzb21ldGhpbmcg aXMgbWlzc2luZyBpbiB0aGlzIEktRCwgdGhpcyBpcyBieSBhbmQgbGFyZ2UgbXkgb3duIGZhdWx0 4oCmDQoNCk5vbmV0aGVsZXNzLCBJIHRoaW5rIEkgaGF2ZSBwcm9taXNlZCBsYXN0IHllYXIgdG8g YWRkcmVzcyBhIGNvbW1lbnQgZnJvbSBUb20gUGV0Y2ggcG9zdGVkIG9uIHRoZSBUQ1BNIG1haWxp bmcgbGlzdCAoc2VlDQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3RjcG0v RVF4cWtpREkxMjIyWUNEQ0hvU2NrNDBObUJvLykuIFVuZm9ydHVuYXRlbHksIHRoaXMgZ290IGxv c3Qgb24gbXkgb3duIFRPRE8gbGlzdC4NCg0KSSB0aGluayBUb20gaGFzIGNvcnJlY3RseSBwb2lu dGVkIG91dCB0aGF0IHRoaXMgZG9jdW1lbnQgY291bGQgaGF2ZSBhIGJldHRlciAoaS5lLiwgbG9u Z2VyKSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uIGluIG9yZGVyIHRvIGV4cGxhaW4gdGhlIHB1 cnBvc2UgYW5kIHRoZSBzY29wZSBvZiB0aGUgSS1ELiBUaGVyZSBpcyBhbHJlYWR5IHNvbWUgdXNl ZnVsIHJlbGF0ZWQgdGV4dCBpbiBTZWN0aW9uIDIuMS4xLCBidXQgb25lIG9yIHR3byBhZGRpdGlv bmFsIHNlbnRlbmNlcyBpbiB0aGUgYWJzdHJhY3QgYW5kL29yIGludHJvZHVjdGlvbiB3b3VsZCBw cm9iYWJseSBtYWtlIGl0IGVhc2llciB0byB1bmRlcnN0YW5kIHRoZSBvYmplY3RpdmUgb2YgdGhp cyBZQU5HIG1vZGVsLg0KDQpUaGlzIGlzIG9ubHkgYW4gZWRpdG9yaWFsIGlzc3VlIHRoYXQgbmVp dGhlciBhZmZlY3RzIHRoZSBhY3R1YWwgWUFORyBtb2RlbCBub3IgYW55IG9mIHRoZSBvdGhlciBy ZWxhdGVkIGRvY3VtZW50cy4gSSB0aGluayB0aGlzIGlzc3VlIGNhbiBlYXNpbHkgYmUgZml4ZWQg YnkgdGhlIGF1dGhvcnMgYXMgYSByZXNvbHV0aW9uIG9mIHRoZSBXR0xD4oCmDQoNClNvcnJ5IGZv ciBub3QgaGF2aW5nIGFkZHJlc3NlZCB0aGlzIGVhcmxpZXIhDQoNCk1pY2hhZWwgKGFzIGF1dGhv cikNCg0KDQpQUzogQXMgdGhpcyBpcyBhYm91dCBhIHBhc3QgY29tbWVudCBwb3N0ZWQgb24gdGhl IFRDUE0gbGlzdCwgSSBoYXZlIGFkZGVkIFRDUE0gaW4gQ0MuDQoNCg0KRnJvbTogbmV0Y29uZiA8 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFoZXNoIEpldGhhbmFuZGFu aQ0KU2VudDogRnJpZGF5LCBNYXJjaCAyNiwgMjAyMSAxMTozMSBQTQ0KVG86IG5ldGNvbmZAaWV0 Zi5vcmcNClN1YmplY3Q6IFtuZXRjb25mXSBXR0xDIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtdGNw LWNsaWVudC1zZXJ2ZXINCg0KV2UgYXJlIHN0YXJ0aW5nIGEgMiB3ZWVrIFdHTEMgZm9yIGRyYWZ0 LWlldGYtbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlciB2ZXJzaW9uIDA5Lg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtdGNwLWNsaWVudC1zZXJ2 ZXIvPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1z enRwLWNzci8+DQoNClBsZWFzZSByZXNwb25kIG9uIHRoaXMgdGhyZWFkIGluZGljYXRpbmcgeW91 ciBzdXBwb3J0IG9yIGNvbmNlcm5zIGFib3V0IHdoeSB0aGlzIGRvY3VtZW50IHNob3VsZC9zaG91 bGQgbm90IGJlIGFkb3B0ZWQuDQoNCldlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiBz dGF0ZW1lbnQgb2YgdGhlIGZvcm06DQoNCi0gSSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQg Zm91bmQgbm8gaXNzdWVzLg0KLSBJIGhhdmUgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBmb3VuZCB0 aGUgZm9sbG93aW5nIGlzc3VlcyDigKYNCg0KVGhpcyBXR0xDIHdpbGwgY29uY2x1ZGUgb24gRnJp ZGF5LCBBcHJpbCA5LiBBbiBJUFIgY2FsbCB3aWxsIGJlIGlzc3VlZCBzZXBhcmF0ZWx5Lg0KDQpU aGFuayB5b3UuDQoNCk1haGVzaCAmIEtlbnQgKGFzIGNvLWNoYWlycykNCg0KDQoNCg0KDQo= --_000_14240f263d0c4834b943353d1e9da314hsesslingende_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5I aSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhbSBhIGNvLWF1dGhvciBv ZiB0aGlzIEktRCwgc28gaWYgc29tZXRoaW5nIGlzIG1pc3NpbmcgaW4gdGhpcyBJLUQsIHRoaXMg aXMgYnkgYW5kIGxhcmdlIG15IG93biBmYXVsdOKApg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Tm9uZXRoZWxlc3MsIEkgdGhpbmsgSSBoYXZlIHByb21pc2VkIGxhc3QgeWVhciB0 byBhZGRyZXNzIGEgY29tbWVudCBmcm9tIFRvbSBQZXRjaCBwb3N0ZWQgb24gdGhlIFRDUE0gbWFp bGluZyBsaXN0IChzZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGNwbS9FUXhxa2lESTEyMjJZQ0RDSG9T Y2s0ME5tQm8vIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy90Y3BtL0VReHFraURJMTIyMllDRENIb1NjazQwTm1Cby88L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4pLg0KIFVuZm9ydHVuYXRlbHksIHRoaXMgZ290IGxvc3Qgb24gbXkgb3duIFRPRE8gbGlzdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIFRvbSBoYXMgY29ycmVjdGx5 IHBvaW50ZWQgb3V0IHRoYXQgdGhpcyBkb2N1bWVudCBjb3VsZCBoYXZlIGEgYmV0dGVyIChpLmUu LCBsb25nZXIpIGFic3RyYWN0IGFuZCBpbnRyb2R1Y3Rpb24gaW4gb3JkZXIgdG8gZXhwbGFpbiB0 aGUgcHVycG9zZSBhbmQgdGhlIHNjb3BlIG9mIHRoZSBJLUQuIFRoZXJlDQogaXMgYWxyZWFkeSBz b21lIHVzZWZ1bCByZWxhdGVkIHRleHQgaW4gU2VjdGlvbiAyLjEuMSwgYnV0IG9uZSBvciB0d28g YWRkaXRpb25hbCBzZW50ZW5jZXMgaW4gdGhlIGFic3RyYWN0IGFuZC9vciBpbnRyb2R1Y3Rpb24g d291bGQgcHJvYmFibHkgbWFrZSBpdCBlYXNpZXIgdG8gdW5kZXJzdGFuZCB0aGUgb2JqZWN0aXZl IG9mIHRoaXMgWUFORyBtb2RlbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo aXMgaXMgb25seSBhbiBlZGl0b3JpYWwgaXNzdWUgdGhhdCBuZWl0aGVyIGFmZmVjdHMgdGhlIGFj dHVhbCBZQU5HIG1vZGVsIG5vciBhbnkgb2YgdGhlIG90aGVyIHJlbGF0ZWQgZG9jdW1lbnRzLiBJ IHRoaW5rIHRoaXMgaXNzdWUgY2FuIGVhc2lseSBiZSBmaXhlZCBieSB0aGUgYXV0aG9ycyBhcyBh IHJlc29sdXRpb24NCiBvZiB0aGUgV0dMQ+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlNvcnJ5IGZvciBub3QgaGF2aW5nIGFkZHJlc3NlZCB0aGlzIGVhcmxpZXIhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWljaGFlbCAoYXMgYXV0aG9yKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlBTOiBBcyB0aGlzIGlzIGFib3V0IGEgcGFzdCBjb21tZW50IHBvc3RlZCBvbiB0 aGUgVENQTSBsaXN0LCBJIGhhdmUgYWRkZWQgVENQTSBpbiBDQy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBuZXRjb25mICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5P biBCZWhhbGYgT2YgPC9iPk1haGVzaCBKZXRoYW5hbmRhbmk8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBNYXJjaCAyNiwgMjAyMSAxMTozMSBQTTxicj4NCjxiPlRvOjwvYj4gbmV0Y29uZkBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbmV0Y29uZl0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1u ZXRjb25mLXRjcC1jbGllbnQtc2VydmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+V2UgYXJlIHN0YXJ0aW5nIGEgMiB3ZWVrIFdHTEMgZm9yIGRyYWZ0LWlldGYtbmV0Y29uZi10 Y3AtY2xpZW50LXNlcnZlciB2ZXJzaW9uIDA5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXN6 dHAtY3NyLyI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci88L3NwYW4+PC9hPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlBsZWFzZSByZXNwb25kIG9uIHRoaXMgdGhyZWFkIGluZGljYXRpbmcgeW91ciBzdXBw b3J0IG9yIGNvbmNlcm5zIGFib3V0IHdoeSB0aGlzIGRvY3VtZW50IHNob3VsZC9zaG91bGQgbm90 IGJlIGFkb3B0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5XZSBhcmUgcGFydGljdWxhcmx5IGludGVyZXN0ZWQgaW4gc3RhdGVtZW50IG9mIHRoZSBm b3JtOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBJ IGhhdmUgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBmb3VuZCBubyBpc3N1ZXMuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0gSSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgZm91bmQgdGhl IGZvbGxvd2luZyBpc3N1ZXMg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGlzIFdHTEMgd2lsbCBjb25jbHVkZSBvbiBGcmlkYXksIEFwcmlsIDku IEFuIElQUiBjYWxsIHdpbGwgYmUgaXNzdWVkIHNlcGFyYXRlbHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1haGVzaCAmYW1wOyBLZW50 IChhcyBjby1jaGFpcnMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_14240f263d0c4834b943353d1e9da314hsesslingende_-- From nobody Wed Apr 7 08:04:05 2021 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 7F75B3A1C20; Wed, 7 Apr 2021 08:03:55 -0700 (PDT) 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: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161780783547.23370.7286925299871040473@ietfa.amsl.com> Date: Wed, 07 Apr 2021 08:03:55 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-ao-test-vectors-00.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: Wed, 07 Apr 2021 15:03:56 -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 : TCP-AO Test Vectors Authors : Joe Touch Juhamatti Kuusisaari Filename : draft-ietf-tcpm-ao-test-vectors-00.txt Pages : 26 Date : 2021-04-07 Abstract: This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: one based on SHA-1 and the other on AES-128. The vectors also validate both whole TCP segments as well as segments whose options are excluded for NAT traversal. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-ao-test-vectors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-ao-test-vectors-00 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ao-test-vectors-00 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 Wed Apr 7 15:28:10 2021 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 2663A3A2C53; Wed, 7 Apr 2021 15:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.07 X-Spam-Level: * X-Spam-Status: No, score=1.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.388, RCVD_IN_DNSWL_BLOCKED=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 5ol1o-1K0z8I; Wed, 7 Apr 2021 15:28:00 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 B82CC3A2C51; Wed, 7 Apr 2021 15:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=o9RGQ4i+JmGIqknJjqaBMXddGKicfYUrKp+Ah3WktEU=; b=eL4/e+FIlJejIjhglO5DuYV5u cwemQBTZsORCTUilBNrsx9ZEN4cpC3+n/tEi/vw9RoXad7VeN021MANnsFtZ7MMgVaI0PTDIHKF2M pxagjeG2BUoUqiUPIN7cx+plvyr0xPOk1oOcu3c4gW9NNCaQviuCb7qAAtSW93IN8OtddleLCwQyI JEhYlGk/QM4WdTyBLyRT5m5ZeJutmQ4iTbJE4G0vTH+8LiJcagqZY20MPmBsHSOXUyYLzXBT3Vzcg hyovq1mux4m8enYN3E/FL3NC1UyukgFmJCqLUcT8YSKw2B2UlXK6CdAVDjTx9NYlj2+HBi2RDFe+R r0d32nccw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59698 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lUGeP-000Xfl-Fd; Wed, 07 Apr 2021 18:27:58 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: <161665521569.8906.7182041937114104585@ietfa.amsl.com> Date: Wed, 7 Apr 2021 15:27:51 -0700 Cc: The IESG , tcpm IETF list , draft-ietf-tcpm-2140bis@ietf.org, tcpm-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5CF436C5-67CA-4C17-89E4-2CF65C6FB4E8@strayalpha.com> References: <161665521569.8906.7182041937114104585@ietfa.amsl.com> To: Murray Kucherawy X-Mailer: Apple Mail (2.3654.60.0.2.21) 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] Murray Kucherawy's No Objection on draft-ietf-tcpm-2140bis-10: (with COMMENT) 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, 07 Apr 2021 22:28:04 -0000 FYI - (see 0) is an error; it should read =E2=80=9Csee Appendix A=E2=80=9D= . This is corrected in v-10, currently being completed. > On Mar 24, 2021, at 11:53 PM, Murray Kucherawy via Datatracker = wrote: >=20 > Murray Kucherawy has entered the following ballot position for > draft-ietf-tcpm-2140bis-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In Section 10, to what does "(see 0)" refer? >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Apr 11 17:51:32 2021 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 1F4BC3A262E; Sun, 11 Apr 2021 17:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.069 X-Spam-Level: * X-Spam-Status: No, score=1.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.388, 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 xSTgscPuhTPV; Sun, 11 Apr 2021 17:51:20 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395AD3A262C; Sun, 11 Apr 2021 17:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ebjo8/ah76yf9yz3UjvT6KBVw14AqxGYA8aQl8z4+0E=; b=zEFlkOmd22D/D1vhb/U+7OJiU UdqRpf9xJ4Q8Wtol9wRRSzJGnZkjS6IIDsdIkmrhnHnfiAQ83Vz1erGzLe+hW6wtL0IYsc+YAFUNx SiZfQKgr8n2XYDEukOoTnHpu0ST9K8A08tV6B0jXfMLGIvRmyqUwlpkS+kZtsml2h3ZcgWWBlbbCo veNc9ccotSBd0R0qC+qvpuCmPRSZXIDieh6xK7wKVaT/MDyQ+BV/fE/30ufjTBxWIbyw2DYitrFQ0 8yupnmXSrgwXg98D08Pn27Lk2DhEYW77NZSdByFCEDIwvRnA7XqM7Gb3uxvf2avJhKpusqhRIrhDi dPhTYwgcQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58422 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lVknK-002IWx-Bd; Sun, 11 Apr 2021 20:51:18 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: <161666322074.3399.8841793110004444182@ietfa.amsl.com> Date: Sun, 11 Apr 2021 17:51:09 -0700 Cc: The IESG , draft-ietf-tcpm-2140bis@ietf.org, tcpm-chairs , tcpm IETF list , Michael Scharf Content-Transfer-Encoding: quoted-printable Message-Id: <4C52C95A-367D-4EA9-9707-598FDD5809E4@strayalpha.com> References: <161666322074.3399.8841793110004444182@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3654.60.0.2.21) 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] Benjamin Kaduk's No Objection on draft-ietf-tcpm-2140bis-10: (with COMMENT) 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, 12 Apr 2021 00:51:25 -0000 Hi, Benjamin, Thank you for your feedback. All items below have been incorporated in the upcoming update. Some notes below to assist tracking. Joe > On Mar 25, 2021, at 2:07 AM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-tcpm-2140bis-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks to the shepherd for the very helpful writeup! >=20 > Section 3 >=20 > +RTTVAR - variance of round-trip times of a TCP packet exchange > [RFC6298] >=20 > nit: in RFC 6298 this is "round-trip time variation", which to me is a = more > useful description, since it is not a standard statistical averaged > squared deviation. Agreed. > Section 6.2 >=20 > A forward reference to where the "merge()" operation is discussed = would > be helpful. Added text when this and other table functions are introduced. > During the connection, the associated TCB can be updated based on > particular events, as shown below: >=20 > nit(?): should we s/associated TCB/assoicated TCB cache/? (Likewise = for > =C2=A76.2.) Yes. Clarified in both sec 6 and 7. > Section 9 >=20 > confirmation, etc.) [RFC3124]. By dealing exclusively with > transients, TCB interdependence is more likely to exhibit the same > behavior as unmodified, independent TCP connections. >=20 > Is this the "same behavior" in the steady-state? There seem to be > obvious (intentional) differences in behavior at startup. Yes; clarified. > Section 10 >=20 > The observation that some TCB state is host-pair specific rather > than application-pair dependent is not new and is a common > engineering decision in layered protocol implementations. Although > now deprecated, T/TCP [RFC1644] was the first to propose using > caches in order to maintain TCB states (see 0). >=20 > "see 0" feels like a broken automation for referencing Appendix A. > (Also occurs in Section 11 for the same T/TCP topic.) Fixed. > Section 11 >=20 > (nit) this feels more like a "changes from RFC 2140" section than an > "updates to RFC 2140" section, to me. Yes. > Appendix B >=20 > A reference to the IANA registry might help the reader make sense of > some of these option names. Added. > Appendix C >=20 > Temporal sharing, as described earlier in this document, builds on > the assumption that multiple consecutive connections between the > same host pair are somewhat likely to be exposed to similar > environment characteristics. The stored information can therefore > become invalid over time, and suitable precautions should be taken >=20 > nit: I don't think the preceding sentence justifies the use of > "therefore" here. Fixed. > Appendix C.2 >=20 > environment, can always use a different value. In specific, > information from previous connections, or sets of connections with a > similar path, can already be used as context for such decisions (as > noted in the core of this document). >=20 > nit: it feels like there might be a missing word here, perhaps > "situations" after "specific"? Or perhaps just = s/specific/particular/? The latter seems clearer to me. > Appendix C.3 >=20 > 1. On boot: >=20 > IW =3D MaxIW; # assume this is in bytes, and an even number of = MSS >=20 > nit: is "even number" intended to mean "integral multiple"? Actually both; it=E2=80=99s described later as =E2=80=9Cinteger multiple = of 2 MSS=E2=80=9D to support ACK compression. This is explained here as = well. > A number of additional constraints need to be imposed if this > mechanism is implemented to ensure that it defaults values that >=20 > nit: singular/plural mismatch (maybe "it defaults to values"?) The latter; fixed. > Appendix C.4 >=20 > reasons (e.g., the ISN is used in TCP-AO [RFC5925]). The mechanism > also benefits from persistent state kept across reboots, as would be > other state sharing mechanisms (e.g., TCP Control Block Sharing > [RFC2140]). The mechanism is inspired by RFC 2140's use of > information across connections. >=20 > It feels strange for some reason to reference RFC 2140 here when this > document obsoletes RFC 2140. Agreed. Fixed. From nobody Sun Apr 11 18:53:14 2021 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 675CD3A2826; Sun, 11 Apr 2021 18:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.069 X-Spam-Level: * X-Spam-Status: No, score=1.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.388, 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 LKaHFaI8XfCm; Sun, 11 Apr 2021 18:53:09 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A071B3A2822; Sun, 11 Apr 2021 18:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6JmgEm6oX1kTTl/F84mYB7KCcQkuXxgAHhhJtUf+TiU=; b=RJuaCyhfUWPI4SbeHpAC8/8Ta vc+6pMLJ/gIg94KrdGWbC+6EIo4le1YZikry133MIhyea5FdltRLsEbhekPcbpLzCyOLYMuYJ/g3R hkCmhjCPGWKQnWn2h8sNnRm4acNOUV0pH0/BMw45JH3LqJ432I/41EJunfHZWaz6oGjw/QMRHu0/O WWRynQjSYPscjud3airStYq/cbOkKKOQMhJ6y9RMAnxJFQmfvVHuavABGYitOqEcEi51hYwWrV4Rk OgjMjZjmtC6XLEYi20+53NWnlD5Dx6rmXn2rgXbOhLAmEHbq8u6prUoOCbbtETsVoc0JSACD13GrE +P4oI2DWg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57238 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lVll8-003PbA-TG; Sun, 11 Apr 2021 21:53:07 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: <161667506763.22315.6198477654822795827@ietfa.amsl.com> Date: Sun, 11 Apr 2021 18:52:59 -0700 Cc: The IESG , tcpm IETF list , draft-ietf-tcpm-2140bis@ietf.org, tcpm-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <161667506763.22315.6198477654822795827@ietfa.amsl.com> To: =?utf-8?Q?=C3=89ric_Vyncke?= X-Mailer: Apple Mail (2.3654.60.0.2.21) 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] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tcpm-2140bis-10=3A_=28with_COMMENT=29?= 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, 12 Apr 2021 01:53:14 -0000 Hi, =C3=89ric, Thank you for the feedback.=20 An update will be posted shortly. Some notes below. Joe > On Mar 25, 2021, at 5:24 AM, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-tcpm-2140bis-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for the work put into this document. >=20 > Please find below some non-blocking COMMENT points (but replies would = be > appreciated), and some nits. >=20 > I hope that this helps to improve the document, >=20 > Regards, >=20 > -=C3=A9ric >=20 > =3D=3D COMMENTS =3D=3D >=20 > -- Abstract -- > Nothing critical, but, the abstract is mostly cut & paste of the = introduction. > Could it be made more concise ? Done. > -- Section 1 -- > "as often used in the World-Wide Web", references are really outdated = and we > may expect/hope that H3/QUIC will represent soon the majority of the > connections. This is clarified as applying to some versions of HTTP (more than a few = still use TCP, including automated scripts) and other applications. > "TCP segments having the same host-pair experience the same path = properties" > does this assumption stand in an ECMP world ? A reference to section = 8.1 would > be useful. Done. > -- Section 8.1 -- > "e.g., the connections could be given the same IPv6 flow label" = suggest to add > a reference to RFC 6437 Done. > =3D=3D NITS =3D=3D >=20 > -- Section 2 -- > I am always puzzled by the use of BCP 14 boilerplate for an = informational > document, but, no need to change/reply. The rationale is directly addressed in Sec 2. From nobody Sun Apr 11 22:49:32 2021 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 DAA913A3156; Sun, 11 Apr 2021 22:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZeY0uChP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qpG5VIeX 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 MTbYlh4nUJBm; Sun, 11 Apr 2021 22:49:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8193A3154; Sun, 11 Apr 2021 22:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4102; q=dns/txt; s=iport; t=1618206561; x=1619416161; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PTNIP+vCbfIklKW4EIPGDr6ZCxKVX5K8BaK3om5ug4E=; b=ZeY0uChPpfrkh0PYZH0s7yMUIOiBMymdlpPSOw2GNdYj8gXMhddEjki+ CMt6R0g6yr1AjGRhYBU99aX/4kBQ1CncnnMe5uMrLpvEvKq12VNThy2JH W4jYhRDt7Uyhoapz0F7z4ZN1E2tEX7SVMxquSYdb6MGRny+NYsdiX5rth w=; IronPort-PHdr: =?us-ascii?q?A9a23=3ASt3XNhBt+hxhHNj9mMSNUyQVkhdPi93PFgcI9?= =?us-ascii?q?poqja5Pea2//pPkeVbS/uhpkEShdZ7H8ftVgu7Os6mmUmsFst6Ns3EHJZpLU?= =?us-ascii?q?RJNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8Wau9zcDE?= =?us-ascii?q?xHnNQMzLePwScbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0n?= =?us-ascii?q?xDIuXBPPe9RwDAAGA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Ad833hKkv3UGFOBeWK0DPjdPQ1w7pDfM9jm?= =?us-ascii?q?dD5ilNYBxZY6WkvuiUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZy?= =?us-ascii?q?OjnGezNolt4c/ZwzPmEzDj7eI178ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1a?= =?us-ascii?q?iui/vXwXsFd3AUV4hLxW5Ce2GmO2dxQxRLAod8NLf03LsGmxOLf3MLYsOnQl?= =?us-ascii?q?wMWOber9PG/aiWHyIuLRgh9QWIkHeU87b8CReVxVMzVDlIzLck/wH+4k/Ez4?= =?us-ascii?q?+ktOy2zQKZ6n/L4/1t6Zrc4/ZgJOjJsMgaLT3wlh2lDb4AZ5SutC04ydvfk2?= =?us-ascii?q?oCv8LLp34bTqFOwlPXOlq4uB78nzTnuQxel0PK7X+9rT/drdfiRDQ8YvAxx7?= =?us-ascii?q?5xVhfC8UIvsJVd/ctwrhiknqFaBx/BgyjxjuKgP3oB+ybEwgtBrccpg3NSSo?= =?us-ascii?q?cYYrNKxLZvgX99KosKHy7x9ekcYY9TJfzc//pffBe7aH3UrwBUsaSRd0kzBR?= =?us-ascii?q?uPTww+vNWU2VFt7QlE5nYfrfZv+ksoxdYYcd1p9u7EOqNnmPVlVckNd59wA+?= =?us-ascii?q?8HXI+eFnHNaQikChPWHX3XUIU8f17doZ/+57s4oMuwfoYT8Zc0kJPdFHtFqG?= =?us-ascii?q?8JfV70A8Hm5uwOzjn9BEGGGRj9wMBX4JZ0/pfmQqDwDCGFQFcy1+ytvusYGc?= =?us-ascii?q?+ef/qoIppZD7vCIALVaMF09jy7f6MXBWgVUcUTtNp+cUmJuNj3JorjsfGef+?= =?us-ascii?q?3UILbrDDY4SmLyCnYOR1HIVZx9x3HufkW9rAnaWnvrdEC614l3CrLm8+8az5?= =?us-ascii?q?VINoAkiHlMtX2JouWwbRFSuK0/e0VzZJn9lLmgmGWw9WHUq2FgOh9XCFdJ8K?= =?us-ascii?q?ztOkk6/jMiAgfRS/Iuqt+fcWdd0D+sPRlkVf7bFwZZuhBw4qK4L5uZwCg4EN?= =?us-ascii?q?K5OmeGj38ezUj6Cas0q+mm34PIa5k4BpEpVOhaDgPQDSF4ng5stSNecgMeX1?= =?us-ascii?q?TeETnvkK2hi5QRCIjkBoNBqTbuBfQRhWPUtE2aq81qe2ASWCS2V9WLxSw0QS?= =?us-ascii?q?BPu1F3+6gDobaJlDq1M1EjiOAgPFAkUhXLPJt2SCC+IKRdgPTCZRx5R2biv0?= =?us-ascii?q?3qtzgDPk7Rs3g0qkOkByuOYv3PCkdaoRljo9bX2WIxUH6ccUJ2Ym19qqtnGw?= =?us-ascii?q?39yypO+N7OQLav2G2MbVZH5ecRPFj+EGUvCzIr4cyr3xiInzvHL1Ea/9EFO+?= =?us-ascii?q?zQC6lLScCN5lqkNJCImaYaH/Vd4ZZiM5T0vvUWVP+EEjXlXg/QF/kkwEicqH?= =?us-ascii?q?ojJUBP2QoZuOKt1xv/4Gei2nkjRfLUPVR9XrkeZ8qR9m7+Wp+zodlEpMNwue?= =?us-ascii?q?u7KWPqbNGajanRcj5YMxvWyFTGBd0AuNRRvagosqF0EISeWTzU1Gtf1BF7KM?= =?us-ascii?q?vvjksRTOB657/GU7UfMvA6amZc/lAzks6II1ZuugvqAvUmdVVolmTFJbqykv?= =?us-ascii?q?P1gKtqBlfEqBr7OFGZ/SEY9/DZXzGb3bpfD64rO2xZZEU19XwKxpLMS6TATA?= =?us-ascii?q?GxM+1T9luzNXGwNKVQT6WIAr0cpBd36dPgpZ7dSwPonATL+TdrKKNH9GiqBd?= =?us-ascii?q?6oCAWXAOhS7pi0P0+PjqbC2r/8sB7nDT+gL0IWio1OeRZOMoBNijw+gJY21S?= =?us-ascii?q?b3QKrtuU4hm0Zf5zYillOF4PnQ3E7LWUVddQveidFKWDMWNH6Ch8HM6/KZ23?= =?us-ascii?q?Tw+yIt4+iKKG5AOtVVX8ENRY32JTp0IccevLS077Mi6x4zFCsGHio5knThxO?= =?us-ascii?q?to0reyxeXKV+DjAXnuP0gd+TQtPP8DogU77Wdac8a/6pqhYgIYUu4QasFPk7?= =?us-ascii?q?xrrA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZCACu3nNg/51dJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFSgVNRB3daNjGEQoNIA4U5iC8lA5k7gUKBEQNUCwEBAQ0BASgKAgQ?= =?us-ascii?q?BAYRQAheBYAIlOBMCAwEBDAEBBQEBAQIBBgRxE4VQDYZEAQEBAQIBIxEMAQE?= =?us-ascii?q?3AQsEAgEIEQMBAgECAiYCAgIwFQUDCAIEDgWCcQGCVQMOIQEOoEgCih93gTK?= =?us-ascii?q?BAYIEAQEGgUdBgwIYghMDBoEPKoJ2hAmCPYQRJxyBSUKBEycMEIJfPoJgAgE?= =?us-ascii?q?CgSgBEgEhgxc1giuCFjRkBCIZEAYBAUY5GWlzkFSDNZRhkWEKgwuJY41lhTQ?= =?us-ascii?q?EH4NNiniWLIURkhSJWpJehGECBAIEBQIOAQEGgWsjaVgRB3AVOyoBgj5QFwI?= =?us-ascii?q?Ojh83gzmFFIVFcwI2AgYBCQEBAwkBe4wVAQE?= X-IronPort-AV: E=Sophos;i="5.82,214,1613433600"; d="scan'208";a="869254358" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2021 05:49:20 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 13C5nKHZ018801 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 12 Apr 2021 05:49:20 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 12 Apr 2021 00:49:20 -0500 Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 12 Apr 2021 00:49:19 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 12 Apr 2021 00:49:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SkMhJZe2OuFneiQz5iuAU/nbxQdpGvbFa1jIkkDaCG1wrRRZ+0dQVCyZC5LJ+zigrKYgU29xEDVefb1e9XLi7K4l8FDM2PEP+es4KBepFFa2zeyc0gGwn6OEf4s6pzFY/x4eKr22N4MgG/INXoAluzatgd9xHVA5Vd7UHeN5QdoJgEB8YTQk9XilQ8i9OpI1ICCoGU7Ph+pZ0Nu44Ay/83h1s4Gj+vIRPBcmoBQzpZ64mp1OMlyFKd0gx3TMOr0CNsXMD5gxtScR6LiK6aaBvoBYyvTyhzA5qBzfTca0/ENGXmAY3t44C6f/X51Tz6/xNYS+0GO8L5NRAzLGm7or7Q== 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=PTNIP+vCbfIklKW4EIPGDr6ZCxKVX5K8BaK3om5ug4E=; b=gwg4Lw3QbIZv/O9jEC+zRpYioRtcvWSEhRDCiRZusWpXdPqf6yKv8Tgq+wOHKKXrFyU4d4d/gLBBRD1OKtaZvrNPGGTo/zDcPMKjh2D4FJF5NOmCoA0h/eallGUvlpbmBuZLGXpFG+rUcUwT7+GLJ9jkvL7NWaSrY/TVtfizEgCIroykiiltQ00MBt99efsdcC98su9DrK9KI2QqO8qPwwkvujP8nscX042MJdcLeK8zxH4yHVpjJXQDLuxPHarj54BGvmi4AK2obZLX5XEnjMxsJUMU9L2/daEzcP6XV2xb4OT6CiNbO1Oz9XGHfNMKZDwg/xlFKujBHhIAXx/skg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PTNIP+vCbfIklKW4EIPGDr6ZCxKVX5K8BaK3om5ug4E=; b=qpG5VIeXvB6rc5hGSTDTTuXI9pG6vidncJ6Q5TfS5trT2D1rIgT4J5/ZgrN7D10Csv34UZhP4Behfsua+8SI/mYBQorxyLnNPEkRSxrF5DZ5BX9If4Y7QQ60dHIgKGwh6X9Jdf7DSLfAv6Y4gsymRDUjX2r9+oGreQA3AmDt9cY= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4853.namprd11.prod.outlook.com (2603:10b6:510:40::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Mon, 12 Apr 2021 05:49:18 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4020.022; Mon, 12 Apr 2021 05:49:18 +0000 From: "Eric Vyncke (evyncke)" To: Joseph Touch CC: The IESG , tcpm IETF list , "draft-ietf-tcpm-2140bis@ietf.org" , "tcpm-chairs@ietf.org" Thread-Topic: =?utf-8?B?W3RjcG1dIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p?= =?utf-8?Q?etf-tcpm-2140bis-10:_(with_COMMENT)?= Thread-Index: AQHXLz6e31v+TIzbhECBvKldkBO5yKqwgjCA Date: Mon, 12 Apr 2021 05:49:18 +0000 Message-ID: <591A4997-AB56-42C9-9332-48198B33B39C@cisco.com> References: <161667506763.22315.6198477654822795827@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: strayalpha.com; dkim=none (message not signed) header.d=none;strayalpha.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:559b:6a9d:834f:e682] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 427a1822-0395-4c66-e436-08d8fd76b67b x-ms-traffictypediagnostic: PH0PR11MB4853: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SQGkF0ufU7ih6WvfHlxpav0iF4zsEzX0+H0SXZ6Z4YAb5svMOoWxA1N9k/mq7B+pbl8YWLo+23I9RHZib4D6xHwptZd352dbVa1FOyH7BtP24Qh+BbAz2LGlLbygS8uxtIESX5S4LpLAmqU9UumvOSiuQT25RHTaFH2T8VUvMWXEaIa1QjjYnjRq96jPEZ5MjEHKWTdXsTM7Qv+PNj05iihePHJsSW5176FaL3jLsiiGIvekwiJhWG7SBIYC925GXF0MLhyI50HB5AR+OcflYDzlNHX1hhx1IJpV0Jn/JLr2TkKc9CDw2SGGCHczz9zsjijup6gO8S58zXdmjw9+EEkU8FEXO0UAmT3q45ebqdhhfTex7kYK53IeJPDbard2toNdweW6dei26cpc11wDUWXSsUtSujoIPzpcrHq6vr+upJ2P/7FIYuF6dvFjvm/JWBJB4et5ver2Ej6g+HKThe8gzHdLgL/nQgeth4Za5a/3iOWAQUfSHmX+FMkagFfLskhLjUBzG3KJ4AUYSJUtOdJOguP3F5dc5LwVAz0qDIXSwrOzZf4mNVz+4WwgdorHgaykcrLs1FRAcF9gZi41+MBsHpfGrw7IFbCyqaw3FvsNzWEyU9/8iqM7WxiSwUWexM4TzXKSdK7e2bXpxwAnzw1PIYmEqLDET4uucCeet8T8HF2Xg6U/tSLjhzxr5l93Em7TBaLQMiTJAKbgc4pFORtazUpjyspCwT/j8UbKQlU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(396003)(376002)(136003)(366004)(6916009)(224303003)(8936002)(66446008)(83380400001)(33656002)(54906003)(2906002)(186003)(66556008)(66476007)(66946007)(86362001)(91956017)(316002)(76116006)(5660300002)(2616005)(36756003)(4326008)(6506007)(38100700002)(966005)(478600001)(6486002)(53546011)(71200400001)(6512007)(64756008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Nzc4QkhwQkU1YXRpNnI1YzZQcWtKSTRLOEdRK3IzTWFtWDJudW5TanorT0dK?= =?utf-8?B?WUdGVDlwQmdBY3RxcklYN1llbGI5LzBNMFpyY2Q4OGVXOE9kSnpBM0JhWnUw?= =?utf-8?B?NWZPRnJjb1RrbDBHejk2SXcyMDFNK1pxRXNXaW1lSDhlaldRWCt1ZkE4eXFN?= =?utf-8?B?a1JhOWtvMkN5RkdhMlBUV3pPbWJnMURJakFrbzZSTkVQVHdFNndnL3VMekJw?= =?utf-8?B?cWsrQmhqRFU3VlJtU2R3b2c0MGl1K2hZeEpoR0pMSmRXRlYwblVnUkF2MFJU?= =?utf-8?B?V0RiWlZ0K1hPNVBJcjRFaXBSWWV5Q3lpL2pWdHNNQlZhbFh3aFVQYTkxMkZu?= =?utf-8?B?RmUvZnpBV2tnbFRNdEtPUUtZajJuT3dROTJaekVRaUtJbExoNWlEUTBCa0M0?= =?utf-8?B?YkZPNjBHTTdkU0ZESHFJeGpTZ1pOWEhHbkhmdjFEcmwwTVh1VlovN3BibUdE?= =?utf-8?B?RndTK1hTWGwzZVluVVVsVFJkSFZNRWVjK1V6V0M5V2FaZFZWbzQ4MytDY1Q2?= =?utf-8?B?bkRwb1huallIb3didWlZaTV4ZWxSQ2FGalhLTmdnejBCelFNRExHVmxTV21j?= =?utf-8?B?V2lzdisxQ2EvZjN3RklQeG55dEEwKzA4cHF5Nnl2eHhTOTJ4eWF4TnFrL1Nn?= =?utf-8?B?TjlGK0pwa0dXa1pJNk1DczNFU0F6RW5kd2Vpci9KcE5kWHJEMlF0SFI0dkwz?= =?utf-8?B?eHlCUUhTSXB4citjdlhVT3NTTEZQQzhhRHp1dHFBTTBqdWlJZ0swZVZYRlhE?= =?utf-8?B?OWhHdXR3WHAwMmVoQnBhc1pwTk1Ic0dsSjd4ZG5mOHRVN3I0dWtDR1ZRVnZ6?= =?utf-8?B?a2ZGMkFtMkptYVpUc25EYjh3ZWtranVXQnNPRGZzM01qaFRJbzFSWUhIaW8r?= =?utf-8?B?V0dnTTNoKytScFhSbTlxMXRUVXRNc2UwWVZEa0JMV08vN2hCa1FVWjJwK0xN?= =?utf-8?B?cHBIdkhyNC9qSnNsRkxKaTJFVVgvSGhlS1dmeXA2bkUrcTZaclc4ZUt2ZXVh?= =?utf-8?B?VndYbiswOStBaGFSQ1hINDZUQThrWVZ0ZU1xWmpSVFk2WTlMMkQ1ejlxZWZv?= =?utf-8?B?dkc2eWVnbk80UW5kN25ROENWRFBSSlVxc1NpTmM2T3FWVkdqZjNJNXVyK0Rp?= =?utf-8?B?cmtZUzZYUTlmS1h1aHpUaWg0dW9henVyUCswdnRWQzJuUUo1Q0JBbDVzbU9K?= =?utf-8?B?by94YWNJVStCdEhPUUoxdUtIRkR4cEpwUzd3SUVSVjBOb0tGOC9BOEhtaThl?= =?utf-8?B?aDJNWmQ0aE9kc1lOVmg3S3NMUytoTTFHSklTdXNUYnk3Sm9PSVpzMEpsYytt?= =?utf-8?B?ZjFLdUdZdkVNMUdDSWNzOGNQdEpSWldUanpEOTFmWnFqSUhMaGd2cWRLSGZs?= =?utf-8?B?V2EvVzVPT09ueFBrNlpPWUN6anB0ZDMxUHNTbjhlaGM2UHlIcXphN0lNR1BY?= =?utf-8?B?Q0w3aUEyd2wxMUlTMGhPWXhwWjJqYS9vYW1aMWlaL1paNk1wVFRzOWtCaXJC?= =?utf-8?B?enZuYXhBOVAwYzI3ZTFKS3hidHVRaTVKUEtHc0RJK09uNzIwbjJaRklEZXUy?= =?utf-8?B?cmZpenZubVhMK0F5eXdCaXpGVWljOUhqeklHL1BrZ2NBakFEdnUvS1V6RnQ5?= =?utf-8?B?RTV0SFJyZStGdm5hb2owc1NFeUQ3VXdCbkx4WEpNVDlSeDNocStrVDV2Z0xM?= =?utf-8?B?R2NqVjFsK3lFT1p3dTl0alNGUEc4S3JsWlVyOWY1dSt1N1JYd0JNbGs2ZWIz?= =?utf-8?B?aDlDa1F1WnJGOG9PQzc0WU5iWE8vblRvQkNaWk41dEhzZ1BBWlJLTlFvamxG?= =?utf-8?B?OUg5WnpXQjJscXZlcnc3by9WZnBEZG1rUlplYXZDMUdSVlFhOWsvNXBCTXFr?= =?utf-8?Q?6DIiqbUAJf+8A?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 427a1822-0395-4c66-e436-08d8fd76b67b X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2021 05:49:18.0693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BMIUUUsHYtOF7jXXsFPC+MLAzHJim4XX/+nisd8ueu6hep7BGrlUBglgW7JEnVqNNQj+357yxXE/iPSXT+u8uw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4853 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [tcpm] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tcpm-2140bis-10=3A_=28with_COMMENT=29?= 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, 12 Apr 2021 05:49:27 -0000 VGhhbmsgeW91IEpvZSBmb3IgeW91ciByZXBseSB3aXRoIHRoZSBub3Rlcy4NCg0KUmVnYXJkcw0K DQotw6lyaWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvc2VwaCBU b3VjaCA8dG91Y2hAc3RyYXlhbHBoYS5jb20+DQpEYXRlOiBNb25kYXksIDEyIEFwcmlsIDIwMjEg YXQgMDM6NTMNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+DQpDYzogVGhlIElF U0cgPGllc2dAaWV0Zi5vcmc+LCB0Y3BtIElFVEYgbGlzdCA8dGNwbUBpZXRmLm9yZz4sICJkcmFm dC1pZXRmLXRjcG0tMjE0MGJpc0BpZXRmLm9yZyIgPGRyYWZ0LWlldGYtdGNwbS0yMTQwYmlzQGll dGYub3JnPiwgInRjcG0tY2hhaXJzQGlldGYub3JnIiA8dGNwbS1jaGFpcnNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3RjcG1dIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p ZXRmLXRjcG0tMjE0MGJpcy0xMDogKHdpdGggQ09NTUVOVCkNCg0KICAgIEhpLCDDiXJpYywNCg0K ICAgIFRoYW5rIHlvdSBmb3IgdGhlIGZlZWRiYWNrLiANCg0KICAgIEFuIHVwZGF0ZSB3aWxsIGJl IHBvc3RlZCBzaG9ydGx5LiBTb21lIG5vdGVzIGJlbG93Lg0KDQogICAgSm9lDQoNCiAgICA+IE9u IE1hciAyNSwgMjAyMSwgYXQgNToyNCBBTSwgw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8 bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+IMOJcmljIFZ5bmNrZSBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICA+IGRyYWZ0LWll dGYtdGNwbS0yMTQwYmlzLTEwOiBObyBPYmplY3Rpb24NCiAgICA+IA0KICAgID4gV2hlbiByZXNw b25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8g YWxsDQogICAgPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5l cy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KICAgID4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwg aG93ZXZlci4pDQogICAgPiANCiAgICA+IA0KICAgID4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgID4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCiAgICA+IA0KICAgID4gDQogICAgPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRjcG0tMjE0MGJpcy8NCiAgICA+IA0K ICAgID4gDQogICAgPiANCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IENPTU1FTlQ6DQogICAg PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAgPiANCiAgICA+IFRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgcHV0 IGludG8gdGhpcyBkb2N1bWVudC4NCiAgICA+IA0KICAgID4gUGxlYXNlIGZpbmQgYmVsb3cgc29t ZSBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2ludHMgKGJ1dCByZXBsaWVzIHdvdWxkIGJlDQogICAg PiBhcHByZWNpYXRlZCksIGFuZCBzb21lIG5pdHMuDQogICAgPiANCiAgICA+IEkgaG9wZSB0aGF0 IHRoaXMgaGVscHMgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsDQogICAgPiANCiAgICA+IFJlZ2Fy ZHMsDQogICAgPiANCiAgICA+IC3DqXJpYw0KICAgID4gDQogICAgPiA9PSBDT01NRU5UUyA9PQ0K ICAgID4gDQogICAgPiAtLSBBYnN0cmFjdCAtLQ0KICAgID4gTm90aGluZyBjcml0aWNhbCwgYnV0 LCB0aGUgYWJzdHJhY3QgaXMgbW9zdGx5IGN1dCAmIHBhc3RlIG9mIHRoZSBpbnRyb2R1Y3Rpb24u DQogICAgPiBDb3VsZCBpdCBiZSBtYWRlIG1vcmUgY29uY2lzZSA/DQoNCiAgICBEb25lLg0KDQog ICAgPiAtLSBTZWN0aW9uIDEgLS0NCiAgICA+ICJhcyBvZnRlbiB1c2VkIGluIHRoZSBXb3JsZC1X aWRlIFdlYiIsIHJlZmVyZW5jZXMgYXJlIHJlYWxseSBvdXRkYXRlZCBhbmQgd2UNCiAgICA+IG1h eSBleHBlY3QvaG9wZSB0aGF0IEgzL1FVSUMgd2lsbCByZXByZXNlbnQgc29vbiB0aGUgbWFqb3Jp dHkgb2YgdGhlDQogICAgPiBjb25uZWN0aW9ucy4NCg0KICAgIFRoaXMgaXMgY2xhcmlmaWVkIGFz IGFwcGx5aW5nIHRvIHNvbWUgdmVyc2lvbnMgb2YgSFRUUCAobW9yZSB0aGFuIGEgZmV3IHN0aWxs IHVzZSBUQ1AsIGluY2x1ZGluZyBhdXRvbWF0ZWQgc2NyaXB0cykgYW5kIG90aGVyIGFwcGxpY2F0 aW9ucy4NCg0KICAgID4gIlRDUCBzZWdtZW50cyBoYXZpbmcgdGhlIHNhbWUgaG9zdC1wYWlyIGV4 cGVyaWVuY2UgdGhlIHNhbWUgcGF0aCBwcm9wZXJ0aWVzIg0KICAgID4gZG9lcyB0aGlzIGFzc3Vt cHRpb24gc3RhbmQgaW4gYW4gRUNNUCB3b3JsZCA/IEEgcmVmZXJlbmNlIHRvIHNlY3Rpb24gOC4x IHdvdWxkDQogICAgPiBiZSB1c2VmdWwuDQoNCiAgICBEb25lLg0KDQogICAgPiAtLSBTZWN0aW9u IDguMSAtLQ0KICAgID4gImUuZy4sIHRoZSBjb25uZWN0aW9ucyBjb3VsZCBiZSBnaXZlbiB0aGUg c2FtZSBJUHY2IGZsb3cgbGFiZWwiIHN1Z2dlc3QgdG8gYWRkDQogICAgPiBhIHJlZmVyZW5jZSB0 byBSRkMgNjQzNw0KDQogICAgRG9uZS4NCg0KICAgID4gPT0gTklUUyA9PQ0KICAgID4gDQogICAg PiAtLSBTZWN0aW9uIDIgLS0NCiAgICA+IEkgYW0gYWx3YXlzIHB1enpsZWQgYnkgdGhlIHVzZSBv ZiBCQ1AgMTQgYm9pbGVycGxhdGUgZm9yIGFuIGluZm9ybWF0aW9uYWwNCiAgICA+IGRvY3VtZW50 LCBidXQsIG5vIG5lZWQgdG8gY2hhbmdlL3JlcGx5Lg0KDQogICAgVGhlIHJhdGlvbmFsZSBpcyBk aXJlY3RseSBhZGRyZXNzZWQgaW4gU2VjIDIuDQoNCg== From nobody Mon Apr 12 10:05:03 2021 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 8CDE13A0C35; Mon, 12 Apr 2021 10:04:51 -0700 (PDT) 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: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161824709150.31382.14139820548144315013@ietfa.amsl.com> Date: Mon, 12 Apr 2021 10:04:51 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-11.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, 12 Apr 2021 17:04:57 -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 : TCP Control Block Interdependence Authors : Joe Touch Michael Welzl Safiqul Islam Filename : draft-ietf-tcpm-2140bis-11.txt Pages : 37 Date : 2021-04-12 Abstract: This memo provides guidance to TCP implementers that is intended to help improve connection convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of sharing TCP state, as typically represented in TCP Control Blocks, among similar concurrent or consecutive connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-11 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-11 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 Apr 12 10:17:09 2021 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 34DCA3A0CD2 for ; Mon, 12 Apr 2021 10:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.07 X-Spam-Level: * X-Spam-Status: No, score=1.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.388, HTML_MESSAGE=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 0L39BpVunCax for ; Mon, 12 Apr 2021 10:17:03 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38E23A0E10 for ; Mon, 12 Apr 2021 10:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-Id:To:References:Subject:Date: Mime-Version:Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=n1cTBh/88bOSNHF9aBTUhNPgneluZCbSeZCQdvjxswg=; b=hjsvxTo5kusEBWBkSZGDbNYgk1 5N8qWjclswLvP64gYiwGcQCWN1kFDecv4bEtpWvWFzCSQc2GnVPAsoUPuspZY5psApL5aKGBhjU59 Xmm/iJs9mdTInoOuIMT3gGLLXPOEHN0rMVQ/7ETYW+nDyuSrtwJeHzEHP6iQN+bIxPhfl3mfxrN/Q BH53tF4hOaJD5n9ee2+B8AHqWjJZezBkBgrcwbmYjXHfdimPzNBR4OrzYE5J2U8JOhBpv1mNWph2G qlrYv3KAYNk4S6m1D9Z+R/AqmPBZpEPfTZJJqjTNBOgpQiRZWjaVet4Oz3RbbPRdd0rtrmRTM8YY0 SNKcHf8g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61457 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lW0B7-003ws4-8P; Mon, 12 Apr 2021 13:16:54 -0400 From: Joseph Touch Content-Type: multipart/alternative; boundary="Apple-Mail=_F831469B-643A-4082-8153-B4461321E7A5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 12 Apr 2021 10:16:48 -0700 References: <161824711326.7203.14751237640046380697@ietfa.amsl.com> To: tcpm IETF list Message-Id: X-Mailer: Apple Mail (2.3654.60.0.2.21) 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: [tcpm] Fwd: New Version Notification for draft-touch-sne-00.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: Mon, 12 Apr 2021 17:17:08 -0000 --Apple-Mail=_F831469B-643A-4082-8153-B4461321E7A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, I=E2=80=99ve posted a doc that captures the solution to the sequence = number extension discussion. At this time, I=E2=80=99m anticipating submitting it as an individual = contribution. There=E2=80=99s no real need to force a particular = implementation, so this can just be an informal resource for anyone = using sequence numbers without needing to establish a =E2=80=9Cstandard=E2= =80=9D per se. FYI. Joe > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-touch-sne-00.txt > Date: April 12, 2021 at 10:05:13 AM PDT > To: "Joe Touch" , "Joseph Touch" = >=20 >=20 > A new version of I-D, draft-touch-sne-00.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. >=20 > Name: draft-touch-sne > Revision: 00 > Title: Sequence Number Extension for Windowed Protocols > Document date: 2021-04-12 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/archive/id/draft-touch-sne-00.txt > Status: https://datatracker.ietf.org/doc/draft-touch-sne/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-sne > Htmlized: https://tools.ietf.org/html/draft-touch-sne-00 >=20 >=20 > Abstract: > Sliding window protocols use finite sequence numbers to determine > segment placement and order. These sequence number spaces wrap > around and are reused during the operation of such protocols. This > document describes a way to extend the size of these sequence > numbers at the endpoints to avoid the impact of that wrap and reuse > without transmitting additional information in the packet header. > The resulting extended sequence numbers can be used at the endpoints > in encryption and authentication algorithms to ensure input bit > patterns do not repeat over the lifetime of a connection. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_F831469B-643A-4082-8153-B4461321E7A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all,

I=E2=80=99ve = posted a doc that captures the solution to the sequence number extension = discussion.

At = this time, I=E2=80=99m anticipating submitting it as an individual = contribution. There=E2=80=99s no real need to force a particular = implementation, so this can just be an informal resource for anyone = using sequence numbers without needing to establish a =E2=80=9Cstandard=E2= =80=9D per se.

FYI.

Joe

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-touch-sne-00.txt
Date: = April 12, 2021 at 10:05:13 AM = PDT
To: = "Joe Touch" <touch@strayalpha.com>, "Joseph Touch" <touch@strayalpha.com>


A new version = of I-D, draft-touch-sne-00.txt
has been successfully = submitted by Joe Touch and posted to the
IETF = repository.

Name: = draft-touch-sne
Revision: 00
Title:= = Sequence Number Extension for Windowed Protocols
Document date: 2021-04-12
Group:= = Individual Submission
Pages: 10
URL: =            https://www.ietf.org/archive/id/draft-touch-sne-00.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-sne/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-sne
Htmlized:       https://tools.ietf.org/html/draft-touch-sne-00


Abstract:
=   Sliding window protocols use finite sequence numbers to = determine
  segment placement and order. These = sequence number spaces wrap
  around and are = reused during the operation of such protocols. This
=   document describes a way to extend the size of these = sequence
  numbers at the endpoints to avoid = the impact of that wrap and reuse
  without = transmitting additional information in the packet header.
=   The resulting extended sequence numbers can be used at the = endpoints
  in encryption and authentication = algorithms to ensure input bit
  patterns do = not repeat over the lifetime of a connection.




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.

The IETF Secretariat



= --Apple-Mail=_F831469B-643A-4082-8153-B4461321E7A5-- From nobody Mon Apr 12 10:17:39 2021 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 177E43A0CD5; Mon, 12 Apr 2021 10:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.069 X-Spam-Level: * X-Spam-Status: No, score=1.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.388, 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 RHyyUCBgnACT; Mon, 12 Apr 2021 10:17:35 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276A83A0CCD; Mon, 12 Apr 2021 10:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8uDqualKAhGk82AsJqNHFjhR7EcCDmGMQR5El8L5XO0=; b=YyfyHKi/ptWJp5+7QxixnA6gY 5OUKvkLSFVD1N7mSfJqK0cfyla7z8E6jcKz+aFIaBAIaWIgKI19rwvmlSbRkaLlJGNFcmW2/t3S8Q wf0XAcjOzHDJEDf/27I8tkXxd2fJZB0eYryTJtnRINUw8k4FXe2Bv+1Q6Zo7SLpKJk1PKAwc57V8U kOR7VmQUTQfXqnGnuizVMtsI7+RDiruAXmdAEBLs+GhnAB4V7BUGx8IPHL8uE/7dgdYGT4AtuBj5A MyN0Rh4wO2RcMJ1+q0Sb6ZitIJdPttqIkL1++JOmoUIpUU2IHfQSqN6x5O8JZhk9+DxImhJ641zRv HRIx3jY8Q==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61457 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lW0Bm-003ws4-3g; Mon, 12 Apr 2021 13:17:34 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: <161824709150.31382.14139820548144315013@ietfa.amsl.com> Date: Mon, 12 Apr 2021 10:17:29 -0700 Cc: i-d-announce@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <161824709150.31382.14139820548144315013@ietfa.amsl.com> To: tcpm IETF list X-Mailer: Apple Mail (2.3654.60.0.2.21) 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] I-D Action: draft-ietf-tcpm-2140bis-11.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: Mon, 12 Apr 2021 17:17:38 -0000 Hi, all, This update captures all the IESG and area review feedback received and = should be ready for the next stage of the process. Joe > On Apr 12, 2021, at 10:04 AM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : TCP Control Block Interdependence > Authors : Joe Touch > Michael Welzl > Safiqul Islam > Filename : draft-ietf-tcpm-2140bis-11.txt > Pages : 37 > Date : 2021-04-12 >=20 > Abstract: > This memo provides guidance to TCP implementers that is intended to > help improve connection convergence to steady-state operation > without affecting interoperability. It updates and replaces RFC > 2140's description of sharing TCP state, as typically represented in > TCP Control Blocks, among similar concurrent or consecutive > connections. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-11 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-2140bis-11 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Apr 15 03:26:56 2021 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 6654F3A1A06 for ; Thu, 15 Apr 2021 03:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cs.helsinki.fi 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 bORkh4jolq5L for ; Thu, 15 Apr 2021 03:26:49 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167B83A19ED for ; Thu, 15 Apr 2021 03:26:48 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 15 Apr 2021 13:26:23 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:message-id:mime-version:content-type; s=dkim20130528; bh=jJiKAJ95M6nD9sqNILnztL9SYLu/Qo2JpLNWBSIFVzU=; b= c2WBA0tbMQyC14PR8s4hfO20smaDXAVGphuwWf7gipJQVJE6fdTrzqrU6N+9P8Fr UNbMY5N69EfLsuxvxJUKFDFxbvQdHZFwKt6nXqJyXlHGDE2OtBhofDXiqfBVyYOg 6qE1dxlixIfLEzWe9/67PfEkmD/klnJtEn0tQA9r4BA= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Thu, 15 Apr 2021 13:26:23 +0300 id 00000000005A1C6E.00000000607814CF.0000530F Date: Thu, 15 Apr 2021 13:26:23 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Bob Briscoe cc: tcpm@ietf.org Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: [tcpm] Feedback on draft-ietf-tcpm-accurate-ecn-14 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, 15 Apr 2021 10:26:54 -0000 Hi, I read through the changes since -09. Some recommendations/notes: - "The server MAY include a test to avoid this case." I'd say: "The server MAY implement a filter in ESTABLISHED state for ACKs with handshake encoding." The problem with the original wording is that "this case" is not that obvious (in fact, the previous sentence talked exactly opposite thing, that is, interpreting the ACE field normally). - "For each field, it takes the least significant 24 bits of its associated local counter (s.ceb, s.e0b or s.e1b) and subtracts them from the counter in the associated field of the incoming AccECN Option (respectively ECEB, EE0B, EE1B), to work out the minimum positive increment it could apply to s.ceb, s.e0b or s.e1b (assuming the field in the option only wrapped at most once).". When using a heuristic to update the byte counters, "the minimum positive increment" is too restricting as the byte counters may have to be backtracked after heuristic misguessed which of them to increment. Also in appendix, there's the now the same assumption that the byte counter difference will always be non-negative. - Paragraph seems to appear twice (only 2 words differ in them): "Even though the first bullet is stated as a "SHOULD", it is important for a transition to immediately trigger an ACK if at all possible, ..." - Compatibility with TCP Experiments and Common TCP Options Should re-state (again) here how SYN and SYN/ACK data is to be treated wrt. the byte counters. -- i. From nobody Fri Apr 16 12:08:43 2021 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 79AB13A3177 for ; Fri, 16 Apr 2021 12:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] autolearn=ham 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 A9LZc--FIQ6H for ; Fri, 16 Apr 2021 12:08:38 -0700 (PDT) Received: from outbound.mail.eo.outlook.com (mail-oln040093008002.outbound.protection.outlook.com [40.93.8.2]) (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 58AB13A3175 for ; Fri, 16 Apr 2021 12:08:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AMqb9eqlk08Do/F9wgjkcrYMVqKT3VKjNQVWHrf8CI+PcOL/mjKHiULors2PDeSEupKY1Cg0asM5fPrxKTCCek3cbbx+mWVSm+zIxBxDIbaq7WaRdWCEAvq8uVCTDYTZgSFWdx/Lb9hXGe6aFvTDw74TjN20tjkUeN4BOuwDr1Cll24Jd9Km5i+ZDAdcdgbb3ZBCAdFLogQSY+SxKv28PBtdisnLeGBxQGPpK5Aok8aUnzep77OgDxdA3KdY5J2dCtfFRWgt1fMD7ppS2BkGtkZtK7qO8+Tjd8E5slOuXLKk6yDoQhDmmaJApDCF7RPZ4mb60NtPKF0EVf8OdxFYKA== 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=h5PSNzJZVlJRejFpjTsCo8upBrCkTfW0ojy/4JHgM7g=; b=TISHzDG8ZRbZf5m3qN+qcceAPFYWNuXIv41Solf5hrmhOks6P+tEdewfdyh8xNSNfxdD9u3xT5/CpYomR5DLeOGDeHEu3+rSc+aFxNmLMXcgL4xSeoSUY5DxSBIGHN2JabYSJqZRqBFQr73YYw3R2nmJ5FYhCXMoKE9/3/H06QNIzCqeXdefYkVTJENYvlgMxs+oWWFyI2Dtli89NK6EbozoAsi8zZgicLOAr0RbY4nKYtRp/2SQBpB2P7puEglIlO5cLbsYZmY2AJJfYMXhA+iP967iX1dUKx1pdZhSgxARKUlS0xyGrhoZxltvVCXDZohcZHAnj6BpdZa85XCMMg== 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=h5PSNzJZVlJRejFpjTsCo8upBrCkTfW0ojy/4JHgM7g=; b=X8Ps4ztyJnMVGK2SjobHPsO9YlJZ1rOGYavI1yeN5kp3u4Mh4OEcYMVOfO9N2C8z7iWodCC/6qnVt5ts1aHM9PPY5r53x2ywbEDmUAgdG/ART5d9akJsV8SsqHiJtq5d3eJ4ExYKMsgu2SQe6ld5AsnyP6QOC2/E+eJiMVlTC5M= Received: from MN2PR00MB0877.namprd00.prod.outlook.com (2603:10b6:208:38::30) by MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4082.0; Fri, 16 Apr 2021 19:08:28 +0000 Received: from MN2PR00MB0877.namprd00.prod.outlook.com ([fe80::f819:d628:d896:83ef]) by MN2PR00MB0877.namprd00.prod.outlook.com ([fe80::f819:d628:d896:83ef%7]) with mapi id 15.20.4091.000; Fri, 16 Apr 2021 19:08:28 +0000 From: Yi Huang To: "tcpm@ietf.org" Thread-Topic: A question about PRR/loss recovery Thread-Index: Adcy6s+WHt48g0ZnTJOXGzLVsKusRw== Date: Fri, 16 Apr 2021 19:08:28 +0000 Message-ID: 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_ActionId=29a29e9e-4d94-4cf0-a123-23cad435af94; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-16T17:56:56Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:877f:acd0:c15:52dd:59ce:bd40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b20e826c-ca6f-46d8-e5a8-08d9010b04c1 x-ms-traffictypediagnostic: MN2PR00MB0686: x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PK5S9saBdQzhAMM35IbNkLoe4UtVCPMo3Hra42GArEPJLLsuCRdlz+7tlDzKPQ/eb2A1VDt8i/2R2hz/zSupWeaP4lynats+ekDoaRDLhPMfsEseH5wwfTLJIGVfIzsXVOWCFKR9eMXCqjppb8XfOqSNL25PccKyYRRtWS3O7RpdThREBaM0VV2vLnkOMDDjmgZC/of1+5nrKlQyq4+Ude4T6ItO7IPcNYcgyT9D6aGQMX14qaskPNTpSMbMlpL6IZR2lgWAYRcE1XcjvhDIbLeGGPhHItkSHz6olGqBCcetAuym3odB0bSiFOv8T1h9tpK9TR4KvsE2Ug0Gu7rzVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0877.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33656002)(4326008)(7696005)(82960400001)(71200400001)(66476007)(82950400001)(66556008)(64756008)(83380400001)(107886003)(8676002)(8990500004)(76116006)(66946007)(66446008)(6506007)(38100700002)(9686003)(478600001)(122000001)(2906002)(8936002)(10290500003)(86362001)(54906003)(6916009)(55016002)(316002)(5660300002)(52536014)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?w2UwDVeywGcXXMJMZvowwsyI5IKUUksX4RI4iIMgNJB0XQOOHqiLX3/YmSfx?= =?us-ascii?Q?XxsarQUyKPtBdHtZL+f37BCGZSXoVesRmVniyFvoEiVJOXKspPFoLJOIR5Iq?= =?us-ascii?Q?5nMYBGqe9HGAM1DeKZvDSUjHn/Ae3be6vj9s5FZ2ZJMhxSInHWVim8FDDH+g?= =?us-ascii?Q?so23Wd+FJN8gAUA0hOo89WHg9TBe6gPa3gZz6EXXw7+bzSZJs3j6kGtUTiTI?= =?us-ascii?Q?OAT8qHD67ILgfnpuS/X3zAWw7B+DKtfOOGOX6E3Eot4V8EAzInSl8KC14HMg?= =?us-ascii?Q?LL0Ak/Jk7G1Qv16HhZ6J6+FQgOQqZdL6pl75jJ46urnRPdYxaa22PMdBDvFe?= =?us-ascii?Q?wymMcdkzkgOC1wHsd7bQhRfSs628Hl1XxjH4mkL/56LtN8Fy2PvvBXC5Hv+q?= =?us-ascii?Q?m3bq9mn84eXKcLPHhzgymJ5cdbsqYB0jgGoI0jrakFvTgN5CRv81z3tjy2DY?= =?us-ascii?Q?Dmwpk8EMf/1aBST6O5GIbfrqWfGSoyEHcs1YA94/DCqjfmfAcQurOU0SLzmC?= =?us-ascii?Q?RPA+fOHjcTDGN36fP7wWEpa8vfHkfGd3PQyZ914ab0k4TOp+xm1G1drvreg0?= =?us-ascii?Q?OE9txiZvxU5kjNxtJgIvPDdpN8DW9d2rtRZj1IIvTAy9VlJFNZxynsxTjFzw?= =?us-ascii?Q?BBBVpdVpoGAw+ZCN+mPyg78lzy9J0Q1W7seohLclrUWSRtiIyitY71psFjPc?= =?us-ascii?Q?hVqBo2hNBcWS5H26v825T1lpF8+beRx0hLjG9j81j7Gu1tRMWCgtFrM00Unr?= =?us-ascii?Q?yS1DGticgCO+CP5OC9HRNTE0YjkbQWSRNw8x3tf6zF1jLZqY20h6x4YuqcBv?= =?us-ascii?Q?j50B0YKE2OvDEFz412R6q5zN7qUPcqL2Y8EhT84xQJTvn09Y599+HrsnF9XB?= =?us-ascii?Q?D7CPuqHnSMsSBU6aB/mK2Gy17itKQvmvD+7J2hGSkK+S5Z2fRl9zfiJaJXlu?= =?us-ascii?Q?7ZQGYAFh+6E+LO+KHuzkC8L8l7CWrAabr0wCvTa/17yWGUC6P9D5FsgHMkpV?= =?us-ascii?Q?RdMYmvIrDwwPBfC5vYm7Ip4CYfrSeRwY7gtheV6OqXJ/G1iPZVhM3eXRSIGH?= =?us-ascii?Q?nO8L9emgXM1ziLuWRAHtDhWaNrI4KorHadp9m63BLFUw+Wzw1GzSwAm5zWRn?= =?us-ascii?Q?LtA7ERSLNmS6H5yc3/e0yzcUt844NJ594xkccI6o/U6LK/AaoYHQInHTJ/es?= =?us-ascii?Q?l3bztohSJZkiBRJKTyle/yTOH/hIR0JP1qfK5jI2xF6tW8PB/9it33RveRBL?= =?us-ascii?Q?PbkpZZ0NMPSnw1UF1xMxX5Vv9jcyjYuYYvTRcWF1lZ3H4eG5UPT80ICh0YZ1?= =?us-ascii?Q?m8oTjrIv50rSt9JE3LzcuGyyxxb2lTsZFGNO2X+HD0UVhqKErezr6qd1aKPy?= =?us-ascii?Q?mTsnDUfrl88puPVNpOwXNCApnppG?= Content-Type: multipart/alternative; boundary="_000_MN2PR00MB08779B864962711A2F35F2F4C34C9MN2PR00MB0877namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0877.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b20e826c-ca6f-46d8-e5a8-08d9010b04c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 19:08:28.4170 (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: aC6jgGh1gHOi+hTkP/B5cw53xgT6e23nn7LJcVesM/tjI3Va8GlV42FLuwgxzlW/nYXWqyWwjb6pCgFWXCSq0g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0686 Archived-At: Subject: [tcpm] A question about PRR/loss recovery 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, 16 Apr 2021 19:08:43 -0000 --_000_MN2PR00MB08779B864962711A2F35F2F4C34C9MN2PR00MB0877namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi tcpm and PRR authors, We are revisiting PRR implementation in Windows and I noticed there might b= e a problem in our implementation (and it is actually not specific to PRR). PRR algorithm computes a sndcnt on each ACK during loss recovery and thus u= se it to accurately regulate bytes in-flight. In the RFC (6937 or bis), I see this statement and note "local" and "respon= se to each ACK". We introduce a local variable "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. In Windows' TCP implementation, new data can be also sent out inline during= loss recovery from app send context (app calling send()) and they are not = regulated by sndcnt/PRR. Instead, we just check if CWND allows us to send i= n this case. So, effectively, we use two variables controlling the number o= f bytes in flight during loss recovery, i.e. sndcnt and CWND. It apparently= seems a bad behavior because it ignores PRR's sendcnt but I just want to d= ouble check with the PRR authors and the community. Thanks, Yi --_000_MN2PR00MB08779B864962711A2F35F2F4C34C9MN2PR00MB0877namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi tcpm and PRR authors,

 

We are revisiting PRR implementation in Windows and = I noticed there might be a problem in our implementation (and it is actuall= y not specific to PRR).

 

PRR algorithm computes a sndcnt on each ACK during l= oss recovery and thus use it to accurately regulate bytes in-flight.

 

In the RFC (6937 or bis), I see this statement and n= ote “local” and “response to each ACK”.<= /p>

   We introduce a local variable "snd= cnt", which indicates exactly how

   many bytes should be sent in response t= o each ACK.

 

In Windows’ TCP implementation, new data can b= e also sent out inline during loss recovery from app send context (app call= ing send()) and they are not regulated by sndcnt/PRR. Instead, we just chec= k if CWND allows us to send in this case. So, effectively, we use two variables controlling the number of bytes in f= light during loss recovery, i.e. sndcnt and CWND. It apparently seems a bad= behavior because it ignores PRR’s sendcnt but I just want to double = check with the PRR authors and the community.

 

Thanks,

Yi

--_000_MN2PR00MB08779B864962711A2F35F2F4C34C9MN2PR00MB0877namp_-- From nobody Fri Apr 16 12:44:23 2021 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 942A13A32A1 for ; Fri, 16 Apr 2021 12:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 GePhgmh8aa-N for ; Fri, 16 Apr 2021 12:44:18 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 D213F3A329C for ; Fri, 16 Apr 2021 12:44:17 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id p9so1087185vkf.10 for ; Fri, 16 Apr 2021 12:44:17 -0700 (PDT) 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=ffbA7EEy0jm4TCwjUl4uQyhLllVI6WQ5wfqB9XLMz0k=; b=ZziPZVrxGj6uBB9bvZ0My5/vD8P0f0DImlvSTfaAY9lTGj9LE8rliAN2CLckUQAJJy sR8VpTRMN7gw3GxUsxC9Jan8+BGtOYpXVwCIBzvNnJNQe641SpXDvKPsuHWfwG5lmzfu +6VRBOWQ/JlalfaxFdp0gRy2Jjw5Hk+Q5yGnyQ2zsl5fYgZTb0maIwJLt29FWeDTwdOS D8X1xvvDkJjMr5aWedHjWZCzhvGs91SIzlSilwSLxGuDDqZR4g8EB6Um/12v2XZexGso uTW973ZEWagG4j9IY8NzGAtAxD0p83Xg7YHxZeL5erdx5vwrhV4IJ9SclgFNkVg74INR 1ybA== 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=ffbA7EEy0jm4TCwjUl4uQyhLllVI6WQ5wfqB9XLMz0k=; b=QjbfiayyUpOFDnJkay1LIPEDAAg/l1yPaAJ8FZYUMgBZRrKA84B+vT86YfrjksAwZh /qjb1gDU1j2zNCqIgqoQk5I4IFig0of8x642MN3EPx00gta6crRa6YLZaD9u3RnAl1+c 4LHL/wN2XE5xCg0IyESMwrcAvzkP9DdEMSmTO+E5Aa3lZFgiS/L4wyEChnsE2AbiZsEA rS9nz73hLE6iKFF8PLz8IqMppTAxwAP0oijjAxGHXKMIofzOvDsCxhjGwmXcbyDwlLei bqzqEVJYqyhse704fXgCSMu2Jkuwz4CG7JInmE1yUP9DI51w27Lbbb74NfrweIMxRfsR x+uA== X-Gm-Message-State: AOAM532ccWbxwXSxK5BvWNh1/yCclShzQi6k4WgXDquNHym17AiqgWMz lw9WfXEnv0Gqquaa8t/eRtwG4bOj+o6W3pI8Vkkavg== X-Google-Smtp-Source: ABdhPJyV53VcajHbwgGRQCweOi2v0Fo7CiqfnRoTnBwESTBiTobb14tQs9m49RsviAi+2++7ZhfFRGwFZdb1o/DdcOU= X-Received: by 2002:a1f:1fcc:: with SMTP id f195mr8759200vkf.17.1618602254922; Fri, 16 Apr 2021 12:44:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Fri, 16 Apr 2021 15:43:58 -0400 Message-ID: To: Yi Huang Cc: "tcpm@ietf.org" , Yuchung Cheng , Matt Mathis , Nandita Dukkipati Content-Type: multipart/alternative; boundary="00000000000070929e05c01c34b9" Archived-At: Subject: Re: [tcpm] A question about PRR/loss recovery 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, 16 Apr 2021 19:44:23 -0000 --00000000000070929e05c01c34b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 16, 2021 at 3:08 PM Yi Huang wrote: > Hi tcpm and PRR authors, > > > > We are revisiting PRR implementation in Windows and I noticed there might > be a problem in our implementation (and it is actually not specific to PR= R). > > > > PRR algorithm computes a sndcnt on each ACK during loss recovery and thus > use it to accurately regulate bytes in-flight. > > > > In the RFC (6937 or bis), I see this statement and note =E2=80=9Clocal=E2= =80=9D and > =E2=80=9Cresponse to each ACK=E2=80=9D. > > We introduce a local variable "sndcnt", which indicates exactly how > > many bytes should be sent in response to each ACK. > > > > In Windows=E2=80=99 TCP implementation, new data can be also sent out inl= ine > during loss recovery from app send context (app calling send()) and they > are not regulated by sndcnt/PRR. Instead, we just check if CWND allows us > to send in this case. So, effectively, we use two variables controlling t= he > number of bytes in flight during loss recovery, i.e. sndcnt and CWND. It > apparently seems a bad behavior because it ignores PRR=E2=80=99s sendcnt = but I just > want to double check with the PRR authors and the community. > > Thanks for the note. I believe that approach runs contrary to the intent of the PRR spec/algorithm. Implicit in the end of the algorithm in https://tools.ietf.org/html/rfc6937#section-3 is the following line (in pseudocode): cwnd =3D pipe + sndcnt That is what the Linux TCP implementation of the PRR algorithm does. That way there is only one variable (cwnd) controlling the number of bytes in flight during loss recovery. Effectively, this allows the PRR algorithm decision to persist, in case there is no data available to send at the instant the ACK arrives. Perhaps the update to the PRR RFC can make this explicit? best, neal --00000000000070929e05c01c34b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 16, 2021 at 3:08 PM Yi Hu= ang <huanyi=3D40micros= oft.com@dmarc.ietf.org> wrote:

Hi tcpm and PRR authors,

=C2=A0

We are revisiting PRR implementation in Windows and = I noticed there might be a problem in our implementation (and it is actuall= y not specific to PRR).

=C2=A0

PRR algorithm computes a sndcnt on each ACK during l= oss recovery and thus use it to accurately regulate bytes in-flight.

=C2=A0

In the RFC (6937 or bis), I see this statement and n= ote =E2=80=9Clocal=E2=80=9D and =E2=80=9Cresponse to each ACK=E2=80=9D.<= /u>

=C2=A0=C2=A0 We introduce a local variable "snd= cnt", which indicates exactly how

=C2=A0=C2=A0 many bytes should be sent in response t= o each ACK.

=C2=A0

In Windows=E2=80=99 TCP implementation, new data can= be also sent out inline during loss recovery from app send context (app ca= lling send()) and they are not regulated by sndcnt/PRR. Instead, we just ch= eck if CWND allows us to send in this case. So, effectively, we use two variables controlling the number of bytes in f= light during loss recovery, i.e. sndcnt and CWND. It apparently seems a bad= behavior because it ignores PRR=E2=80=99s sendcnt but I just want to doubl= e check with the PRR authors and the community.


<= div>Thanks for the note.

I believe that approach r= uns contrary to the intent of the PRR spec/algorithm.

<= div>Implicit in the end of the algorithm in=C2=A0https://tools.ietf.org/html/rfc6937#section= -3 is the following line (in pseudocode):

=C2= =A0 cwnd =3D pipe + sndcnt

That is what the Li= nux TCP implementation of the PRR algorithm does. That way there is only on= e variable (cwnd) controlling the number of bytes in flight during loss rec= overy. Effectively, this allows the PRR algorithm decision to persist, in c= ase there is no data available to send at the instant the ACK arrives.

Perhaps the update to the PRR RFC can make this explic= it?

best,
neal

--00000000000070929e05c01c34b9-- From nobody Sat Apr 17 13:23:40 2021 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 346483A3153 for ; Sat, 17 Apr 2021 13:23:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161869101920.16150.5653470711715403147@ietfa.amsl.com> Date: Sat, 17 Apr 2021 13:23:39 -0700 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: Sat, 17 Apr 2021 20:23:39 -0000 Changed milestone "Submit RFC8312bis document to the IESG for publication as a Proposed Standard RFC", set state to active from review, accepting new milestone. Changed milestone "Submit document on YANG model for TCP configuration as a Proposed Standard RFC", set state to active from review, accepting new milestone. Changed milestone "Submit documents on TCP-AO Test Vectors as an Informational RFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Mon Apr 19 09:56:00 2021 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 9AF0C3A3AB6 for ; Mon, 19 Apr 2021 09:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.698 X-Spam-Level: X-Spam-Status: No, score=-15.698 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 vlacd1bRwB6b for ; Mon, 19 Apr 2021 09:55:56 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 AD0FA3A3AAE for ; Mon, 19 Apr 2021 09:55:56 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id w4so31057304wrt.5 for ; Mon, 19 Apr 2021 09:55:56 -0700 (PDT) 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=AVoCEQ+8QsLuG+IHb66xnfHUWGXcIIq3yuLSoSg4s8c=; b=YFJH4iywIktdjZRv8Jfgtwm8yd7y6ify1e6037Gb4LzPgBvz4L5/iB8O7TvFlUdPKt W+Xln19Kj1TJDxpn3eux9pZ5oFhiZ2Qq+ZyuIjS1f44R+cUCv5mm6qWdPhKQ7rEI0KGp +la1jNFLPrFjZph9KA9ZpkVJ2vYycQwxahYybcLIV8Vtm4hC5n/HN5pnlxO/zG0sCMa+ 3gmh+UElEfs4v4qaGdbESUaOmxdRMa1Ml3DgliuKb+M5Ub5a3bzOlayY8QDP6F6+IALW HfMdxYUGzZ8t5rntyvQlrUDEElcSPATIBzwjt2JJz1IuOYW7Y45SLTgmHJ5lacdHC6mz q4Mg== 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=AVoCEQ+8QsLuG+IHb66xnfHUWGXcIIq3yuLSoSg4s8c=; b=Otb3/qipNGbu9XJbnS5qMbo5hDyVNgwckgSyJmdvpCbzWl4xyfwoSFGL72Va0mwqaQ zr1zry4IKa7qJVLjPgrlFkq2/5MOL537qTUjYdJaOeA2YZ+ISyxPnbOhG2p5jGaj2kQJ tRiCwWmXMasOw10c+SmeWqwAs/Syhf87gFOhNggFXsXFgWVZbjDiFWdjAdpAfbLbwdve RIWh2LcWHiEU3iE8K0TBDjUz8PbWIrE5CCRKKQl6RAY7Hb4FjVxd5y162oBZD4/yEHgR arBODB4969VvrCtLUPkIm6lj32zMqvLxQA6xr4/fA6/Dvy3+8Xhuv4Ixla3mS+/r2gqC 6FFw== X-Gm-Message-State: AOAM5322U9ixkER1e4jPk8+HcfkSBX3tLBLbiuvLhj1DTuyD9H6MhLCp rGnzuBJ0SmqwZVr9sDQy/q6DVv900oubFqIn+8jX4R1Qhqo= X-Google-Smtp-Source: ABdhPJzAodU9bvqkrPiYWRH114PZqyeuyEuZrg2fnq+zUKyLyQylcY7YxR4VH4J9V1YDzHJyaIuy8HGacssF/wyY70E= X-Received: by 2002:a5d:4f82:: with SMTP id d2mr15901968wru.228.1618851353639; Mon, 19 Apr 2021 09:55:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Mon, 19 Apr 2021 09:55:16 -0700 Message-ID: To: Neal Cardwell Cc: Yi Huang , "tcpm@ietf.org" , Matt Mathis , Nandita Dukkipati Content-Type: multipart/alternative; boundary="000000000000e1085d05c05633fc" Archived-At: Subject: Re: [tcpm] A question about PRR/loss recovery 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, 19 Apr 2021 16:56:00 -0000 --000000000000e1085d05c05633fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the current PRR RFC is fairly clear about cwnd computation and it should be used for both retransmits and new data (so both implicitly use sndcnt). Having limited-transmit (i.e. new-data) only follow the (unmodified) cwnd would break PRR substantially -- the packet conservation principle is not really implemented. I suppose it's easy to fix Windows code? On Fri, Apr 16, 2021 at 12:44 PM Neal Cardwell wrote= : > > > On Fri, Apr 16, 2021 at 3:08 PM Yi Huang 40microsoft.com@dmarc.ietf.org> wrote: > >> Hi tcpm and PRR authors, >> >> >> >> We are revisiting PRR implementation in Windows and I noticed there migh= t >> be a problem in our implementation (and it is actually not specific to P= RR). >> >> >> >> PRR algorithm computes a sndcnt on each ACK during loss recovery and thu= s >> use it to accurately regulate bytes in-flight. >> >> >> >> In the RFC (6937 or bis), I see this statement and note =E2=80=9Clocal= =E2=80=9D and >> =E2=80=9Cresponse to each ACK=E2=80=9D. >> >> We introduce a local variable "sndcnt", which indicates exactly how >> >> many bytes should be sent in response to each ACK. >> >> >> >> In Windows=E2=80=99 TCP implementation, new data can be also sent out in= line >> during loss recovery from app send context (app calling send()) and they >> are not regulated by sndcnt/PRR. Instead, we just check if CWND allows u= s >> to send in this case. So, effectively, we use two variables controlling = the >> number of bytes in flight during loss recovery, i.e. sndcnt and CWND. It >> apparently seems a bad behavior because it ignores PRR=E2=80=99s sendcnt= but I just >> want to double check with the PRR authors and the community. >> >> > Thanks for the note. > > I believe that approach runs contrary to the intent of the PRR > spec/algorithm. > > Implicit in the end of the algorithm in > https://tools.ietf.org/html/rfc6937#section-3 is the following line (in > pseudocode): > > cwnd =3D pipe + sndcnt > > That is what the Linux TCP implementation of the PRR algorithm does. That > way there is only one variable (cwnd) controlling the number of bytes in > flight during loss recovery. Effectively, this allows the PRR algorithm > decision to persist, in case there is no data available to send at the > instant the ACK arrives. > > Perhaps the update to the PRR RFC can make this explicit? > > best, > neal > > --000000000000e1085d05c05633fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the current PRR RFC is fairly clear about cwnd com= putation and it should be used for both retransmits and new data (so both i= mplicitly use sndcnt). Having limited-transmit (i.e. new-data) only follow = the (unmodified) cwnd would break PRR substantially -- the packet conservat= ion principle is not really implemented. I suppose it's easy to fix Win= dows code?

On Fri, Apr 16, 2021 at 12:44 PM Neal Cardwell <ncardwell@google.com> wrote:


On Fri, Apr 16, 2021 at 3:08 PM Yi Huang <huanyi=3D40microsoft.com@dma= rc.ietf.org> wrote:

Hi tcpm and PRR authors,

=C2=A0

We are revisiting PRR implementation in Windows and = I noticed there might be a problem in our implementation (and it is actuall= y not specific to PRR).

=C2=A0

PRR algorithm computes a sndcnt on each ACK during l= oss recovery and thus use it to accurately regulate bytes in-flight.

=C2=A0

In the RFC (6937 or bis), I see this statement and n= ote =E2=80=9Clocal=E2=80=9D and =E2=80=9Cresponse to each ACK=E2=80=9D.<= /u>

=C2=A0=C2=A0 We introduce a local variable "snd= cnt", which indicates exactly how

=C2=A0=C2=A0 many bytes should be sent in response t= o each ACK.

=C2=A0

In Windows=E2=80=99 TCP implementation, new data can= be also sent out inline during loss recovery from app send context (app ca= lling send()) and they are not regulated by sndcnt/PRR. Instead, we just ch= eck if CWND allows us to send in this case. So, effectively, we use two variables controlling the number of bytes in f= light during loss recovery, i.e. sndcnt and CWND. It apparently seems a bad= behavior because it ignores PRR=E2=80=99s sendcnt but I just want to doubl= e check with the PRR authors and the community.


<= div>Thanks for the note.

I believe that approach r= uns contrary to the intent of the PRR spec/algorithm.

<= div>Implicit in the end of the algorithm in=C2=A0https://tools.ietf.org/ht= ml/rfc6937#section-3 is the following line (in pseudocode):
<= br>
=C2=A0 cwnd =3D pipe + sndcnt

Th= at is what the Linux TCP implementation of the PRR algorithm does. That way= there is only one variable (cwnd) controlling the number of bytes in fligh= t during loss recovery. Effectively, this allows the PRR algorithm decision= to persist, in case there is no data available to send at the instant the = ACK arrives.

Perhaps the update to the PRR RFC can= make this explicit?

best,
neal

--000000000000e1085d05c05633fc-- From nobody Mon Apr 19 11:21:26 2021 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 BF1493A3D9F for ; Mon, 19 Apr 2021 11:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=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 dBHZtL_9yDIg for ; Mon, 19 Apr 2021 11:21:19 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650096.outbound.protection.outlook.com [40.107.65.96]) (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 AC1063A3D9D for ; Mon, 19 Apr 2021 11:21:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YzRPgqBQKP4m06MxG5dybOxmvj2hX/VNwrrHmZI77OkyblN+Mg/ulRRVoxcTtffE1yoZztNc5J0yuLvxVWBJ5j8hTjvTX0au9OSKCb/NAgwzDkuCMPSLlDAsKPd3aki4UO+hpRKqBKTOwtIG00uy+KE9XH+SjPo0a92cnI+IGZHtlPOpGoC40uPaSgZMFmaQYJnmNoUXfBR8/I/Ff0XJnMH44HXXH22QbaB6LY36oy1J39HqGAsINqcJjyCblARUFE8zQLDsTWuMoiE4Mue3Tmg8GC9OqHqVOd3JrkT3DlQNG63Jita512sgYPteoZ4x2NrDisUUnce9HjSq1/HX6w== 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=vS5vN6miuHqxpP9eLJs3KQ6lwq+WcZWr8xjsvjqC6jQ=; b=leoNy1hw2bciNSHZP+IDPHYmk1G37GVqM9SyPiIJMJ4cKSZLJL6tXyCu4mfppP8/9029osePrCdbg78nW9WoozkgpVPTsKQ3k7KROn7ia72wu8nt4bvUIFAFQ6VDJpYzZUO3qsYQMca1fZvLTLNRqzTjAL2VVP+SGPXxnttLxN8uogPYewUgl0rmB1wugtxnsrLfOCRILITDXQjtG3ou8Ejkxh6GP7fD5RrwvE1BHhZ3Bz+tgQdsD+T29jL9BAWfqyLFd9NUEDFK1wvd5qMozz2yrGhsI7MWZaPWiViqiB2SspAspOhUE9ln6muoyeFYHbSy64g81FjKfUiv/n/Arw== 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=vS5vN6miuHqxpP9eLJs3KQ6lwq+WcZWr8xjsvjqC6jQ=; b=b1orC2rUapvvcCJvnWdlV8Rl7RC9LuMTKwACY8+vU/10Wzh6Yetd4U4udlTzEv2nUQt/ko144BfF3th70HxtFxedxOZyMsl8YgVLP7t6JgCtUhyPUc1i0AG2j/h6SqMMFwUNZCCptkfml8+xzU0Hk/m1R9ErlDPiHDdEQyfQJ1k= Received: from DM6PR00MB0875.namprd00.prod.outlook.com (2603:10b6:5:163::14) by DM5PR00MB0357.namprd00.prod.outlook.com (2603:10b6:4:9f::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4100.0; Mon, 19 Apr 2021 18:21:11 +0000 Received: from DM6PR00MB0875.namprd00.prod.outlook.com ([fe80::7498:94d7:2c0c:5ef1]) by DM6PR00MB0875.namprd00.prod.outlook.com ([fe80::7498:94d7:2c0c:5ef1%6]) with mapi id 15.20.4100.000; Mon, 19 Apr 2021 18:21:11 +0000 From: Yi Huang To: "ycheng=40google.com@dmarc.ietf.org" , "ncardwell@google.com" CC: "tcpm@ietf.org" , "mattmathis@google.com" , "huanyi=40microsoft.com@dmarc.ietf.org" Thread-Topic: [EXTERNAL] Re: [tcpm] A question about PRR/loss recovery Thread-Index: Adcy6s+WHt48g0ZnTJOXGzLVsKusRwADgfwAAJD7hAAAAsBsgA== Date: Mon, 19 Apr 2021 18:21:11 +0000 Message-ID: References: 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_ActionId=54d1904e-fd4f-4f85-8a74-da7237310284; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-19T18:14:03Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:877f:acd0:18:7a8:250a:ee7a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa886e26-ed5b-4664-a15a-08d9035fe8c8 x-ms-traffictypediagnostic: DM5PR00MB0357: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8/uzziLxhZ80KMNLvLuJMi5QvperXVGxpxAJAYrL3Mfow4XdLkga53dmjuVB9+ArV8LvJLZ31GjH4OsSl8O7ac0pkMq/LTl37Ezbq1MCGWJKcMpMd8zAW8UesX7eeSS9mifwM0rwZLBE59BNh+GW66m3F1Pv+j8EgY0a4OG6wtvu+pHPq1E/rsr26qp0mLGY4eMI8efm2V3eVNPG4c8xGSWcP1u7g3li74IkfV9RFi2lb2TJ2bmbj61cQUPHIS8brOnFf0PIdL7jnHzeeUGRxZUBs7oknXABgzKsyF/EsfYgdHF2B21DkUaGma8ROX5Un2zCLz8ztOX4+Te5GcsGAw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0875.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(82950400001)(82960400001)(83380400001)(52536014)(9686003)(7696005)(478600001)(166002)(71200400001)(8676002)(4326008)(316002)(110136005)(54906003)(10290500003)(55016002)(8936002)(122000001)(8990500004)(38100700002)(5660300002)(186003)(86362001)(53546011)(6506007)(66946007)(2906002)(966005)(66446008)(76116006)(66476007)(33656002)(64756008)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Isvfehaz1f2fu4FDbNQEGp1PEwGoO6OYLb6k/uGSJzA0+JGmSBQi/FmdPQk4?= =?us-ascii?Q?R5igB44wgkghguocCjdPCLQztqrvPARfkpDJwPpWIM3qIDDOeD5X8N4t4iKv?= =?us-ascii?Q?TUNNDH82MrTP2aQm9xrb3RKT7fJ4yHQQn/77/c0Lsp3tJ1KOg5cExeg45WY3?= =?us-ascii?Q?W+GHoWTleHVHtcGuo3/iwj5sx248ec4RJtaczMyUN2aOeTMcecEDUCRP+kiQ?= =?us-ascii?Q?Bvf5ngMxCM6P2jtZT/8P8QBiiAaPPG/HqBHkclRTIBGa6n0jNBSyvIGiDcbC?= =?us-ascii?Q?SzD11scPjwI4LSs3G4zV8XGNp4G/xt/nz4y08LSqv/53evZNILvTEiwUwi5c?= =?us-ascii?Q?2yxDPXWjc63HlQSE7aeZdxwUsAxD59qCd23EmSR7FWBeu3T55FYL0f6NXa4x?= =?us-ascii?Q?dbAltenKHAAxTVttdRMpzi7xUM2ewbGOPOI7jZnlEHcUSSOCoYlU7SIMuEHl?= =?us-ascii?Q?/YjBczvjEwmQ9EPt66kqbI3ckxbZfeLjlvjsHILwRe53ugFiQjPszIeRR9Gi?= =?us-ascii?Q?bWqXBgeaBF62qqePxJVNLreANkshCMsxDydWwZZzvD5hsVzVNtbiVR6UptUT?= =?us-ascii?Q?jh8U4He7hi/GIzvMHV7Rp14EzCkBfRlxUH+MtfqVj2Vbcz+brB16Ms+hM72k?= =?us-ascii?Q?Ov0EuMZpGFx+mg0Qip9Z31XbzjWTNkV9u2LS+PJko6kxu/24gJtO4BqWa898?= =?us-ascii?Q?ACiYkNOGMdgaWpkhcZLyN4si7jO3pfBrzB/iTog6VX6rx5FFOXPupIE+siCy?= =?us-ascii?Q?gRZx+K7ppS/mB+wp7fJAZlf9y1il3nJhRlsg9Ps2xl5Sz+3eeVxErrb7d5iR?= =?us-ascii?Q?TDmEFTRgZAzalA8Mzemspjw/E5es8e3KUFQZGb2fZBmQNT5GvmTBxPxb+Ilc?= =?us-ascii?Q?Pl2bDrWeXW0QeH57EtF/oY35EAzKmV2+R8TCKCiG5fUgkrl1amebzIN3iRhY?= =?us-ascii?Q?zftYUkGkJITroEuGkTn0nQTG56R/ON9mjZnXxOKMaU9/0Gk5rqVQBQ+6btxO?= =?us-ascii?Q?3CWhoy9fqmi6xPZumg44wxPxsHH1h4LiHk1A45Z6dHuGA/goUyuaO0VKzCIr?= =?us-ascii?Q?1aR0le11k02TENrvqCmomsP9jSKqtM773d5hy7nfBPQPhtbb6W9WSEC1po2E?= =?us-ascii?Q?B+RnO22FgVdH51lUOWuzaifSoqZeKoIvYUivwJaNK3tSUkyJiukaUN3jWUR4?= =?us-ascii?Q?RLRLF9UwbOskE+zm63qOjek4pfi+j4k3O7kRqIPoyyMC9VbESNszqDWUXouv?= =?us-ascii?Q?lPnrffVUVByhwWpRDgUKu8BeyfudoHJtno+eeoLsmoJdYfT+FR8r17YEKSe0?= =?us-ascii?Q?6XlWN+r+0BvVUtzggoep56DVITNC7qmyNnsRTSWo0rotuHPiEhKdKFrNXKw5?= =?us-ascii?Q?c9TXNv8=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0875DB2DDBF799E89FFAF4CBC3499DM6PR00MB0875namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0875.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa886e26-ed5b-4664-a15a-08d9035fe8c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2021 18:21:11.1235 (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: Zr2D62smLZWyh+JMsgk2u46UhsSJzhlay+6VJ+OiXGrznFnOsixnaQavzS/9U2tbc+DDPM3Dg2hVaxohD6CAjg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0357 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A question about PRR/loss recovery 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, 19 Apr 2021 18:21:25 -0000 --_000_DM6PR00MB0875DB2DDBF799E89FFAF4CBC3499DM6PR00MB0875namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Neal and Yuchung, the RFC is clear enough to me. Just wanted to doub= le check. We will fix that this problem. From: tcpm On Behalf Of Yuchung Cheng Sent: Monday, April 19, 2021 9:55 AM To: Neal Cardwell Cc: tcpm@ietf.org; Matt Mathis ; Yi Huang Subject: [EXTERNAL] Re: [tcpm] A question about PRR/loss recovery I think the current PRR RFC is fairly clear about cwnd computation and it s= hould be used for both retransmits and new data (so both implicitly use snd= cnt). Having limited-transmit (i.e. new-data) only follow the (unmodified) = cwnd would break PRR substantially -- the packet conservation principle is = not really implemented. I suppose it's easy to fix Windows code? On Fri, Apr 16, 2021 at 12:44 PM Neal Cardwell > wrote: On Fri, Apr 16, 2021 at 3:08 PM Yi Huang > wrote: Hi tcpm and PRR authors, We are revisiting PRR implementation in Windows and I noticed there might b= e a problem in our implementation (and it is actually not specific to PRR). PRR algorithm computes a sndcnt on each ACK during loss recovery and thus u= se it to accurately regulate bytes in-flight. In the RFC (6937 or bis), I see this statement and note "local" and "respon= se to each ACK". We introduce a local variable "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. In Windows' TCP implementation, new data can be also sent out inline during= loss recovery from app send context (app calling send()) and they are not = regulated by sndcnt/PRR. Instead, we just check if CWND allows us to send i= n this case. So, effectively, we use two variables controlling the number o= f bytes in flight during loss recovery, i.e. sndcnt and CWND. It apparently= seems a bad behavior because it ignores PRR's sendcnt but I just want to d= ouble check with the PRR authors and the community. Thanks for the note. I believe that approach runs contrary to the intent of the PRR spec/algorit= hm. Implicit in the end of the algorithm in https://tools.ietf.org/html/rfc6937= #section-3 is the following line= (in pseudocode): cwnd =3D pipe + sndcnt That is what the Linux TCP implementation of the PRR algorithm does. That w= ay there is only one variable (cwnd) controlling the number of bytes in fli= ght during loss recovery. Effectively, this allows the PRR algorithm decisi= on to persist, in case there is no data available to send at the instant th= e ACK arrives. Perhaps the update to the PRR RFC can make this explicit? best, neal --_000_DM6PR00MB0875DB2DDBF799E89FFAF4CBC3499DM6PR00MB0875namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Neal and Yuchung, the RFC is clear enough to = me. Just wanted to double check. We will fix that this problem.<= /p>

 

From: tcpm <tcpm-bounces@ietf.org> O= n Behalf Of Yuchung Cheng
Sent: Monday, April 19, 2021 9:55 AM
To: Neal Cardwell <ncardwell@google.com>
Cc: tcpm@ietf.org; Matt Mathis <mattmathis@google.com>; Yi Hua= ng <huanyi=3D40microsoft.com@dmarc.ietf.org>
Subject: [EXTERNAL] Re: [tcpm] A question about PRR/loss recovery

 

I think the current PRR RFC is fairly clear about cw= nd computation and it should be used for both retransmits and new data (so = both implicitly use sndcnt). Having limited-transmit (i.e. new-data) only f= ollow the (unmodified) cwnd would break PRR substantially -- the packet conservation principle is not really= implemented. I suppose it's easy to fix Windows code?

 

On Fri, Apr 16, 2021 at 12:44 PM Neal Cardwell <<= a href=3D"mailto:ncardwell@google.com">ncardwell@google.com> wrote:<= o:p>

 

 

On Fri, Apr 16, 2021 at 3:08 PM Yi Huang <huanyi= =3D40mi= crosoft.com@dmarc.ietf.org> wrote:

Hi tcpm and PRR authors,

 

We are revisiting PRR implementation in Windows and I noticed ther= e might be a problem in our implementation (and it is actually not specific= to PRR).

 

PRR algorithm computes a sndcnt on each ACK during loss recovery a= nd thus use it to accurately regulate bytes in-flight.

 

In the RFC (6937 or bis), I see this statement and note “loc= al” and “response to each ACK”.

   We introduce a local variable "sndcnt", whi= ch indicates exactly how

   many bytes should be sent in response to each ACK.

 

In Windows’ TCP implementation, new data can be also sent ou= t inline during loss recovery from app send context (app calling send()) an= d they are not regulated by sndcnt/PRR. Instead, we just check if CWND allows us to send in this case. So, effectively, we = use two variables controlling the number of bytes in flight during loss rec= overy, i.e. sndcnt and CWND. It apparently seems a bad behavior because it = ignores PRR’s sendcnt but I just want to double check with the PRR authors and the community.

 

Thanks for the note.

 

I believe that approach runs contrary to the intent = of the PRR spec/algorithm.

 

Implicit in the end of the algorithm in https://tools.ietf.org/html/rfc6937#section-3 is the following line (in pseudocode):

 

  cwnd =3D pipe + sndcnt

 

That is what the Linux TCP implementation of the PRR= algorithm does. That way there is only one variable (cwnd) controlling the= number of bytes in flight during loss recovery. Effectively, this allows t= he PRR algorithm decision to persist, in case there is no data available to send at the instant the ACK arrives.=

 

Perhaps the update to the PRR RFC can make this expl= icit?

 

best,

neal

 

--_000_DM6PR00MB0875DB2DDBF799E89FFAF4CBC3499DM6PR00MB0875namp_-- From nobody Tue Apr 20 11:43:18 2021 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 B466E3A097E; Tue, 20 Apr 2021 11:43:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Michael Scharf , The IESG , draft-ietf-tcpm-2140bis@ietf.org, martin.h.duke@gmail.com, michael.scharf@hs-esslingen.de, rfc-editor@rfc-editor.org, tcpm-chairs@ietf.org, tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161894419371.29931.11560563684320783811@ietfa.amsl.com> Date: Tue, 20 Apr 2021 11:43:13 -0700 Archived-At: Subject: [tcpm] Document Action: 'TCP Control Block Interdependence' to Informational RFC (draft-ietf-tcpm-2140bis-11.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: Tue, 20 Apr 2021 18:43:14 -0000 The IESG has approved the following document: - 'TCP Control Block Interdependence' (draft-ietf-tcpm-2140bis-11.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ Technical Summary This informational document describes TCP Control Block Interdependence, i.e. sharing of a part of TCP state among similar concurrent or consecutive connections. Many TCP implementations use such sharing to help improve convergence to steady-state operation. The memo documents known caching mechanisms and provides guidance to TCP implementers. 2140bis updates and replaces RFC 2140's description of interdependent TCP control blocks. The document describes local heuristics inside a TCP endpoint that do not affect interoperability between different TCP implementations. As described in the document, different TCP/IP stacks internally cache different TCP parameters, and there is no known best approach. As a result, 2140bis is submitted as informational document, like RFC 2140. Working Group Summary The document is an outcome of the TCPM working group and has been discussed in TCPM for a long time. There is strong consensus in the TCPM working group that an up-to-date description of TCP Control Block Interdependence is useful - instead of the outdated content of RFC 2140. Section 11 describes the updates compared to RFC 2140. Various TCP implementers provided feedback about actually implemented mechanisms and contributed e.g. to the summary in Section 10. Before adoption in TCPM there were discussions about the target status of this document, most notably about the question whether to publish 2140bis as BCP. However, many implementers pushed back against a BCP in this space, given that there is no known "best" caching heuristic and different operating systems have successfully used different strategies for a long time. As different choices by implementers do not result in interoperability issues, there is no apparent need for normative IETF guidance. As a result, the TCPM consensus is to update and replace the informational RFC 2140 by an informational document. A small number of TCPM contributors has performed comprehensive reviews of the document, both before and during WGLC. Given the informational status, parts of the working group may not care much about the content of the document. Nonetheless, the shepherd believes that there is strong consensus in the TCPM working group to publish the main body of the document as informational RFC, as it contains valuable information on how to efficiently implement TCP. A notable exception is appendix C, which is based on text from an expired individual Internet-Draft (draft-touch-tcpm-automatic-iw), for which there is no known implementation at the time of publication. During and after WGLC, some TCPM contributors expressed concerns about appendix C and in particular about its length. While everybody agrees that it makes sense to discuss sharing of the TCP initial window in this document, small parts of the TCPM working group believe that a link to the expired draft and some summary discussion would be sufficient instead of a full specification of the algorithm. Some improvements in the appendix were made to address these WGLC comments, but the authors prefer to keep a full description of an algorithm in appendix C instead of a summary only. All in all, this discussion was between a small number of TCPM contributors only. The vast majority in the TCPM working group stays silent on that question. The TCPM consensus whether to include a full description of an example algorithm in appendix C is rough, and, as a result, appendix C has no strong backing inside the TCPM working group. Nonetheless, the example in appendix C is only a minor part of the overall document. Document Quality TCP control block interdependence is widely deployed, and this memo attempts to update the Informational RFC to reflect modern practices. Personnel The document shepherd is Michael Scharf . The responsible Area Director is Martin Duke . From nobody Wed Apr 21 04:15:04 2021 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 2C3E93A20FE; Wed, 21 Apr 2021 04:14:58 -0700 (PDT) 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: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161900369811.32481.884979008893654014@ietfa.amsl.com> Date: Wed, 21 Apr 2021 04:14:58 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc8312bis-01.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: Wed, 21 Apr 2021 11:14:58 -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 : CUBIC for Fast and Long-Distance Networks Authors : Lisong Xu Sangtae Ha Injong Rhee Vidhi Goel Lars Eggert Filename : draft-ietf-tcpm-rfc8312bis-01.txt Pages : 28 Date : 2021-04-21 Abstract: CUBIC is an extension to the traditional TCP standards. It differs from the traditional TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of the linear window increase function of the traditional TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks. This document updates the specification of CUBIC to include algorithmic improvements based on these implementations and recent academic work. Based on the extensive deployment experience with CUBIC, it also moves the specification to the Standards Track, obsoleting [RFC8312]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-01 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 Wed Apr 21 04:17:51 2021 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 07AA53A211B for ; Wed, 21 Apr 2021 04:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=eggert.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 PimtKXgnO4nl for ; Wed, 21 Apr 2021 04:17:42 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 795133A2116 for ; Wed, 21 Apr 2021 04:17:42 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:11a5:f928:3c42:44d9] (unknown [IPv6:2a00:ac00:4000:400:11a5:f928:3c42:44d9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 8DE2960033C for ; Wed, 21 Apr 2021 14:17:33 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1619003853; bh=7t3rJ4cMbBdrWTgkCi8tV2WHJc5I6g172/TYFiC1UJA=; h=From:Subject:Date:References:To:In-Reply-To; b=yoExa0lwqdRCpVNR8QteFQs/yr7GZdCVuhUbA6cYbJjIxm9GIsJ5N4Eu+KGnDD/Ky In7dodEJ90f96vnJVvYyk3NoMyde+4JMHK3FLNh9XxVc1JVLR95zEncYimtH8sWAxi QarcurmopAkRZWgy6c/OG2YEWARukpqC6Wnn8/uU= From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_B64663AA-753F-4142-9D6C-78B5422DC144"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 21 Apr 2021 14:17:33 +0300 References: <161900369811.32481.884979008893654014@ietfa.amsl.com> To: tcpm@ietf.org In-Reply-To: <161900369811.32481.884979008893654014@ietfa.amsl.com> Message-Id: <188CB4A3-C25C-4E54-A082-9E8998ACDA82@eggert.org> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-MailScanner-ID: 8DE2960033C.A2AE9 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: [tcpm] Ready for WGLC? (Re: I-D Action: draft-ietf-tcpm-rfc8312bis-01.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, 21 Apr 2021 11:17:50 -0000 --Apple-Mail=_B64663AA-753F-4142-9D6C-78B5422DC144 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, this revision rolls in all the changes the authors wanted to make to = CUBIC. In other words, we believe this could be ready for a WGLC. Thanks, Lars On 2021-4-21, at 14:14, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : CUBIC for Fast and Long-Distance Networks > Authors : Lisong Xu > Sangtae Ha > Injong Rhee > Vidhi Goel > Lars Eggert > Filename : draft-ietf-tcpm-rfc8312bis-01.txt > Pages : 28 > Date : 2021-04-21 >=20 > Abstract: > CUBIC is an extension to the traditional TCP standards. It differs > from the traditional TCP standards only in the congestion control > algorithm on the sender side. In particular, it uses a cubic > function instead of the linear window increase function of the > traditional TCP standards to improve scalability and stability under > fast and long-distance networks. CUBIC has been adopted as the > default TCP congestion control algorithm by the Linux, Windows, and > Apple stacks. >=20 > This document updates the specification of CUBIC to include > algorithmic improvements based on these implementations and recent > academic work. Based on the extensive deployment experience with > CUBIC, it also moves the specification to the Standards Track, > obsoleting [RFC8312]. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-01.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc8312bis-01 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_B64663AA-753F-4142-9D6C-78B5422DC144 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCACc0ACgkQVLXDCb9w wVfl6hAAsYkxOc/fO6Fc1pjA4T5Xqw9SgbVhfgGjglOH77lul8Q27lbNXVNxb4Ph fPisS7O5CQCqQwxAh8wjFzmVmhYOoMGx35Ju2DPjshNYKdr10QeKbN3R4bIk00Dk sd/btldkrQ8kXeCbhtOOlsim7oCaUk7ZZzF1jz14ixZ451dc/NK4vIAu4TxUdele qha1UY8Vyp+B7X+0fFBRh9y7r6MbNG8gGOvaZ9w5hejBM8bpjczOlGNHph7s5P4G Y89qLFd3PKGOtTJpJfjbdxXjnYsXZff5itTJhm2tEmswYDaRW5xL65+r6e/Yq260 mAQBdrIs51+9ch7r/MbWrPfSI7pjYEnLgfusbhH6A4GeXMZjAdemjybTUHJYNhOm zawt6mCkxv57/3pOntRvHwvvaxFAr/6LUQiCKRTwyUMYRQdtHJEQeGXVCnSkO3aB iiQZx9fJKamjJZzAtjMOe/QoeMyp0ftitzeNoBXUWnI83NoS4XzLoGsA+X0mUf4p 7biJUJa2fcIbZXMpAyYnhyt7D8GHWS9HdVtt3g/dYCEY/Wb8fR2WdNlH0Za0yt5t p9k+3jYXmXWUBMlBcfnzAb+ypJgPaxncCHw+BZFHvU6HT4hfN+RG5/XXkn7CeTc2 /IxMoT1LoHvIkkEphPJP6FoHHcsjE4nyM30gEp5VRKpIGD+k71c= =cBrq -----END PGP SIGNATURE----- --Apple-Mail=_B64663AA-753F-4142-9D6C-78B5422DC144-- From nobody Wed Apr 21 10:41:50 2021 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 5A56C3A30D0 for ; Wed, 21 Apr 2021 10:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 sIpEgkcM27bq for ; Wed, 21 Apr 2021 10:41:44 -0700 (PDT) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.85.90]) (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 96F953A30CE for ; Wed, 21 Apr 2021 10:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MeLB9ccB+rJ4E6FvDK5HXimQcl7JBE1oyf/4RNlUob8=; b=JdPz0GiW09vap34aWrOK2ro9i 20AZ1sO/pG2/sr6S1xGHnjhYKQ0l46qzZYVQOxpnYY9wucDuryReqKmp+IZL8sIQqSVj7b+3xvqd9 pSJooPQIprSVp62WGXugbOhVYIHn4Ml/xv1FTqMmdWdu4HR8ybEe/gvndwIhx+ujONj6ZQpDOceBE 0QIEQA8Ch2+EcXsVh5fRZpp8+eWlCYG3nZBiOxe8/JXegBikE3gWd2xikFZ6j/cGOU/DM2zOiAW8Y aum8iCRcka0sI3hm/z2cOGZBoTp7MdpSe3ywHlSfMEtsRhqAdRYjAYIH2ErSaxH6DPldQ+m4mRBJA CwLsupblw==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:35300 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1lZGr8-0003EP-JZ; Wed, 21 Apr 2021 18:41:43 +0100 To: =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= Cc: tcpm@ietf.org References: From: Bob Briscoe Message-ID: Date: Wed, 21 Apr 2021 18:41:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EEF723515D7D466D898C7F61" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk 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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] Feedback on draft-ietf-tcpm-accurate-ecn-14 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, 21 Apr 2021 17:41:49 -0000 This is a multi-part message in MIME format. --------------EEF723515D7D466D898C7F61 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ilpo, Thanks. I've updated the editor's copy as described below. On 15/04/2021 11:26, Ilpo Järvinen wrote: > Hi, > > I read through the changes since -09. Some recommendations/notes: > > - "The server MAY include a test to avoid this case." > I'd say: "The server MAY implement a filter in ESTABLISHED state > for ACKs with handshake encoding." > The problem with the original wording is that "this case" is not > that obvious (in fact, the previous sentence talked exactly > opposite thing, that is, interpreting the ACE field normally). [BB] I see the problems. I've reordered and rewritten this with a 'Reasoning' paragraph afterwards, like the other rules: Once the TCP server transitions to ESTABLISHED state, it might later receive other pure ACK(s) with the handshake encoding in the ACE field. A server MAY implement a test for such a case, but it is not required. Therefore, once in the ESTABLISHED state, it will be sufficient for the server to consider the ACE field to be encoded as the normal ACE counter on all packets with SYN=0. Reasoning: Such ACKs will be quite unusual, e.g. a SYN/ACK (or ACK of the SYN/ACK) that is delayed for longer than the server's retransmission timeout; or packet duplication by the network. And the impact of any error in the feedback on such ACKs will only be temporary. Clearer? > > - "For each field, it takes the least significant 24 bits of its > associated local counter (s.ceb, s.e0b or s.e1b) and subtracts > them from the counter in the associated field of the incoming > AccECN Option (respectively ECEB, EE0B, EE1B), to work out the > minimum positive increment it could apply to s.ceb, s.e0b or > s.e1b (assuming the field in the option only wrapped at most > once).". > When using a heuristic to update the byte counters, "the minimum > positive increment" is too restricting as the byte counters may > have to be backtracked after heuristic misguessed which of them > to increment. > Also in appendix, there's the now the same assumption that the > byte counter difference will always be non-negative. [BB] To avoid having to introduce the idea of heuristics at this early stage, I've replaced 'MUST decode' with 'normally decodes' (the 'MUST' isn't appropriate anyway): If the ACK has not been superseded, the Data Sender normally decodes the fields in the AccECN Option as follows. Then I added the following to the end of Appendix A.1 that gives a decoding example: In practice an implementation might use heuristics to guess the feedback in missing ACKs, then when it subsequently receives feedback it might find that it needs to correct its earlier heuristics as part of the decoding process. The above decoding process does not include any such heuristics. Is that good enough? > > - Paragraph seems to appear twice (only 2 words differ in them): > "Even though the first bullet is stated as a "SHOULD", it is important > for a transition to immediately trigger an ACK if at all possible, ..." [BB] I've replaced the first occurrence just under the 'SHOULD' with a pointer to the second occurrence, which I've described as the only valid exception to the SHOULD. Thanks for pointing this out. I also rationalized all the text around the rules on when to trigger immediate sending of ACKs and AccECN Options. I've separated out: a) a name for each rule so it can be referred to unambiguously; b) the rule itself; c) rationale for the rule; c) exception to the rule. > > - Compatibility with TCP Experiments and Common TCP Options > Should re-state (again) here how SYN and SYN/ACK data is to be > treated wrt. the byte counters. > Done. Thank you again. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------EEF723515D7D466D898C7F61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ilpo,

Thanks. I've updated the editor's copy as described below.

On 15/04/2021 11:26, Ilpo Järvinen wrote:
Hi,

I read through the changes since -09. Some recommendations/notes:

- "The server MAY include a test to avoid this case."
  I'd say: "The server MAY implement a filter in ESTABLISHED state
  for ACKs with handshake encoding."
  The problem with the original wording is that "this case" is not
  that obvious (in fact, the previous sentence talked exactly
  opposite thing, that is, interpreting the ACE field normally).

[BB] I see the problems. I've reordered and rewritten this with a 'Reasoning' paragraph afterwards, like the other rules:

      Once the TCP server transitions to ESTABLISHED state, it might
      later receive other pure ACK(s) with the handshake encoding in the
      ACE field.  A server MAY implement a test for such a case, but it
      is not required.  Therefore, once in the ESTABLISHED state, it
      will be sufficient for the server to consider the ACE field to be
      encoded as the normal ACE counter on all packets with SYN=0.

      Reasoning: Such ACKs will be quite unusual, e.g. a SYN/ACK (or ACK
      of the SYN/ACK) that is delayed for longer than the server's
      retransmission timeout; or packet duplication by the network.  And
      the impact of any error in the feedback on such ACKs will only be
      temporary.
Clearer?



- "For each field, it takes the least significant 24 bits of its
  associated local counter (s.ceb, s.e0b or s.e1b) and subtracts
  them from the counter in the associated field of the incoming
  AccECN Option (respectively ECEB, EE0B, EE1B), to work out the
  minimum positive increment it could apply to s.ceb, s.e0b or
  s.e1b (assuming the field in the option only wrapped at most
  once).".
  When using a heuristic to update the byte counters, "the minimum
  positive increment" is too restricting as the byte counters may
  have to be backtracked after heuristic misguessed which of them
  to increment.
  Also in appendix, there's the now the same assumption that the
  byte counter difference will always be non-negative.

[BB] To avoid having to introduce the idea of heuristics at this early stage, I've replaced 'MUST decode' with 'normally decodes' (the 'MUST' isn't appropriate anyway):
   If the ACK has not
   been superseded, the Data Sender normally decodes the fields in the
   AccECN Option as follows.

Then I added the following to the end of Appendix A.1 that gives a decoding example:
   In practice an implementation might use heuristics to guess the
   feedback in missing ACKs, then when it subsequently receives feedback
   it might find that it needs to correct its earlier heuristics as part
   of the decoding process.  The above decoding process does not include
   any such heuristics.

Is that good enough?


- Paragraph seems to appear twice (only 2 words differ in them):
  "Even though the first bullet is stated as a "SHOULD", it is important
   for a transition to immediately trigger an ACK if at all possible, ..."

[BB] I've replaced the first occurrence just under the 'SHOULD' with a pointer to the second occurrence, which I've described as the only valid exception to the SHOULD.

Thanks for pointing this out. I also rationalized all the text around the rules on when to trigger immediate sending of ACKs and AccECN Options. I've separated out:
a) a name for each rule so it can be referred to unambiguously;
b) the rule itself;
c) rationale for the rule;
c) exception to the rule.


- Compatibility with TCP Experiments and Common TCP Options
  Should re-state (again) here how SYN and SYN/ACK data is to be
  treated wrt. the byte counters.

Done.

Thank you again.


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------EEF723515D7D466D898C7F61-- From nobody Tue Apr 27 07:20:31 2021 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 B423A3A0B9E for ; Tue, 27 Apr 2021 07:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 wFpUvCy2aoh1 for ; Tue, 27 Apr 2021 07:20:24 -0700 (PDT) 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 117B33A0BC1 for ; Tue, 27 Apr 2021 07:20:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id F3A4225A1F; Tue, 27 Apr 2021 16:20:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1619533222; bh=r3+bYxO0pkA90+UnKIOrUBmdTxwe1tjRPH39CTtZUGE=; h=From:To:Subject:Date:References:In-Reply-To:From; b=XbEUoFnV13Sc3bSIO9498nFBMvRAMb80r/lWc102jwEnWz2mSiPYrpbDMlzn66FVD HsyLdqYVzA7UXfxMIFwCH5z+BNSZskq1kp3ggyU0eSXkvarMCRmutcCQVRCJbAo8QZ Vn7JIla/qc0E4Dy+Cm8EmWAmlOH/poWO9gdT7CLE= 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 oHSfC0fAbwRe; Tue, 27 Apr 2021 16:20:20 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 27 Apr 2021 16:20:20 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 27 Apr 2021 16:20:20 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.012; Tue, 27 Apr 2021 16:20:20 +0200 From: "Scharf, Michael" To: Lars Eggert , "tcpm@ietf.org" Thread-Topic: [tcpm] Ready for WGLC? (Re: I-D Action: draft-ietf-tcpm-rfc8312bis-01.txt) Thread-Index: AQHXNqABhoTnud0RjUi9I+y6WyOlO6rIZJ2g Date: Tue, 27 Apr 2021 14:20:20 +0000 Message-ID: References: <161900369811.32481.884979008893654014@ietfa.amsl.com> <188CB4A3-C25C-4E54-A082-9E8998ACDA82@eggert.org> In-Reply-To: <188CB4A3-C25C-4E54-A082-9E8998ACDA82@eggert.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Ready for WGLC? (Re: I-D Action: draft-ietf-tcpm-rfc8312bis-01.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: Tue, 27 Apr 2021 14:20:29 -0000 Hi Lars, all, I have read -01, which looks pretty good to me. Yet, I wonder about one editorial aspect: In the current version, the abstract, introduction and some later non-norma= tive sections are by and large copied from RFC 8312. While that is perfectl= y reasonable for a -bis document, I believe the document could be a bit mor= e explicit regarding the new status as PS, even if this would imply some ed= itorial changes as compared to RFC 8312. As of today, 8312bis is probably one of the most important and most widely = deployed TCP standards. But the text is not necessarily written that way, g= iven its origins. Here are some examples of what comes into my mind: 1/ Abstract: "CUBIC is an extension to the traditional TCP standards. It differs from th= e traditional TCP standards only in the congestion control algorithm on the= sender side." IMHO one could also start here with something much more explicit along the = lines of "CUBIC is a standard TCP congestion control algorithm [...]". Personally, I don't like the term "traditional standards" in this context. = In fact, after 8312bis will be published as PS, CUBIC may actually become p= art of what one could consider as "traditional standards". Maybe it would b= e better to avoid that term altogether? At least, I believe it could be avo= ided by rewording the abstract. 2/ Introduction:=20 The key sentence "It is therefore to be regarded as the current standard fo= r TCP congestion control" comes at the end after a lot of text on the histo= rical background. An alternative would be to start in the introduction with what CUBIC is as = according to this document and why CUBIC is relevant. Obviously, the histor= ical context _is_ important and must be explained in the document. But I am= less sure whether the history needs to be at the beginning of the introduc= tion. At least newcomers to congestion control may more care about the cont= ent of this Proposed Standard and less about research that resulted in RFC = 8312. 3/ Section 5.4: "CUBIC has been extensively studied by using both NS-2 simulation and testb= ed experiments, covering a wide range of network environments. More informa= tion can be found in [HKLRX06]. Additionally, there is decade-long deployme= nt experience with CUBIC on the Internet." This is another example where the most important message as of 2021 comes s= omewhere at the end. Given the experience with CUBIC, one could just start = with the last sentence "There is decade-long deployment experience..." and = then state something along the lines of "The original CUBIC design has been= studied extensively by using both NS-2 simulation and testbed experiments.= ..". Just as a thought. Probably the existing text in -01 also works in all these cases and this is= just about editorial style. But I think we could at least discuss whether = some alternative wordings would make sense given the new PS status, in part= icular for newcomers who may not have read RFC 8312 and don't know its hist= ory (and probably never have to once this PS is published). My 2 cents Michael (with no hat) > -----Original Message----- > From: tcpm On Behalf Of Lars Eggert > Sent: Wednesday, April 21, 2021 1:18 PM > To: tcpm@ietf.org > Subject: [tcpm] Ready for WGLC? (Re: I-D Action: draft-ietf-tcpm-rfc8312b= is- > 01.txt) >=20 > Hi, >=20 > this revision rolls in all the changes the authors wanted to make to CUBI= C. In > other words, we believe this could be ready for a WGLC. >=20 > Thanks, > Lars >=20 > On 2021-4-21, at 14:14, 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 W= G > of the IETF. > > > > Title : CUBIC for Fast and Long-Distance Networks > > Authors : Lisong Xu > > Sangtae Ha > > Injong Rhee > > Vidhi Goel > > Lars Eggert > > Filename : draft-ietf-tcpm-rfc8312bis-01.txt > > Pages : 28 > > Date : 2021-04-21 > > > > Abstract: > > CUBIC is an extension to the traditional TCP standards. It differs > > from the traditional TCP standards only in the congestion control > > algorithm on the sender side. In particular, it uses a cubic > > function instead of the linear window increase function of the > > traditional TCP standards to improve scalability and stability under > > fast and long-distance networks. CUBIC has been adopted as the > > default TCP congestion control algorithm by the Linux, Windows, and > > Apple stacks. > > > > This document updates the specification of CUBIC to include > > algorithmic improvements based on these implementations and recent > > academic work. Based on the extensive deployment experience with > > CUBIC, it also moves the specification to the Standards Track, > > obsoleting [RFC8312]. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/ > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-01.html > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc8312bis-01 > > > > > > 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 From nobody Tue Apr 27 07:41:42 2021 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 989493A0D42 for ; Tue, 27 Apr 2021 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=eggert.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 2ElZ-wr7hQ5t for ; Tue, 27 Apr 2021 07:41:39 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 21CAD3A0D3E for ; Tue, 27 Apr 2021 07:41:39 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:c939:a873:31cd:f47c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 85D7460031D; Tue, 27 Apr 2021 17:41:16 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1619534476; bh=sbch/7QOFQtWW9sUitBtMVA+qHvGsHeCEbyPTkq1jb8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=A9AfEoav6ueZ9YTJY+oyHTG/VfIkTfgkByniVf+OmEYbBzTC88e7pQyEKOGkaqO4f 3BOUXYMXEfJ4K7CocmS5XfOzMBVEFAnvThhvrIBtb8XDOHG8D7CQf8ECfu8B4jPkRu VTA60l5SpfX3VsCszg9ZSl8D4oVo+eJcpg+CDu+c= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9802493D-0E31-498A-9D80-19606A5F88E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 27 Apr 2021 17:41:13 +0300 In-Reply-To: Cc: "tcpm@ietf.org" To: "Scharf, Michael" References: <161900369811.32481.884979008893654014@ietfa.amsl.com> <188CB4A3-C25C-4E54-A082-9E8998ACDA82@eggert.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-MailScanner-ID: 85D7460031D.A1F24 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] Ready for WGLC? (Re: I-D Action: draft-ietf-tcpm-rfc8312bis-01.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: Tue, 27 Apr 2021 14:41:41 -0000 --Apple-Mail=_9802493D-0E31-498A-9D80-19606A5F88E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-4-27, at 17:20, Scharf, Michael = wrote: > I have read -01, which looks pretty good to me. > Yet, I wonder about one editorial aspect: thank you, I have opened https://github.com/NTAP/rfc8312bis/issues/59 = for this. Lars --Apple-Mail=_9802493D-0E31-498A-9D80-19606A5F88E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCIIokACgkQVLXDCb9w wVfERA/+Ib+JCKdYUbBKQS6QogSVSzRxBaUwI4AGGLQl+KmuGQwVkBaLZqLbSXF0 FOWvO88AyNX8QZ8TzjcWwFrOAo2eMTi4p6ncjFdPshE3jWHjBLx88rFmJ9UEe486 1P4n20+gKN8llG54dQKDGakZadLCGKQKkBVTZYl1wrx5CFqrHVLx5JdMBpOxUCOl Q7YEKeq3DP5LMpQR6HMewK2ahcT1yT+TcHoch5wOsb05vvmEAEhiI79ylXLefGhF Y09GA144SK7X1n4MYMkuwGb7eThQhQGyg7IZvXx3HLS8YGhWslSG5+B9ToV9HXBF ZDx0u89rSlbDtFKLK1uRS8yvqf25OE0fKJQGetBYe7nSWwS19XBKClcS/FT1CkeE Cmr9tPBHgNnmkHb/QGXgfOW8zJxtcNqwCSHGgJhWaETIx3O0DvTBsWJ0uerxpTWl Sg0x56BsEXVE4NpWuRqmVJ2dko7Qm30XOB2JjpjBHz56DbSgtPZG9uaw/qGBa2F5 0RH9I9RIYWPLjPYZMfnuAesIq3q8P8/plBgK/iZvEaB/VQT2NXLl23Dfpp5jpvSX 7hf7peph0yehbymZ1D6JW+nEvPnHpv3ffB9PAqq1ie2g91AaAec6snm3Jw3E49Zi QM5lsAr3yTfFOBGVHP7WHGoBolXid+LhwIMWBjyKV8LpV/SURmE= =vqWw -----END PGP SIGNATURE----- --Apple-Mail=_9802493D-0E31-498A-9D80-19606A5F88E4--