From nobody Thu Sep 3 01:27:26 2020 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 C2E033A0BCA for ; Thu, 3 Sep 2020 01:27:24 -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 dojtogJ4tPLY for ; Thu, 3 Sep 2020 01:27:22 -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 678373A0BBB for ; Thu, 3 Sep 2020 01:27:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 492A225A1F; Thu, 3 Sep 2020 10:27:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1599121640; bh=1WbtlcDAxSYf1bGLT7aLcyTI87vZAgC5X5VNWRTUSsk=; h=From:To:Subject:Date:References:In-Reply-To:From; b=NP4/tTl8FaYdIv5Lfg3TVnld3zytqygCAxR1lKObsmRsWjd/tFKajtdTRBl7rGyRs LfGAw0/H8NCT2XXYo3ITFfzhqcawLs4J2B3kaLffHkmdI/YlVD+HyPLSUn4UAYGVAo lRbIZr7/kASq+xO2NapJJzIRrXvnSWMNOU1k3SOo= 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 8eaCPWbPq3UT; Thu, 3 Sep 2020 10:27:16 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 3 Sep 2020 10:27:16 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.74]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 3 Sep 2020 10:27:16 +0200 From: "Scharf, Michael" To: "mohamed.boucadair@orange.com" , "Yoshifumi Nishida" , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 Thread-Index: AQHWaWzLjfgW/VQy5kO/gyv3uqZiX6k8fFwAgA8kGICACySAYA== Date: Thu, 3 Sep 2020 08:27:14 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DD5E5CD@rznt8114.rznt.rzdir.fht-esslingen.de> References: <15680_1598516212_5F476BF4_15680_405_1_787AE7BB302AE849A7480A190F8B9330315259F8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <15680_1598516212_5F476BF4_15680_405_1_787AE7BB302AE849A7480A190F8B9330315259F8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2DD5E5CDrznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 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, 03 Sep 2020 08:27:25 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2DD5E5CDrznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWVkLA0KDQpTdXJlLCB3ZSB3aWxsIGZpeCB0aGUgdHJlZSBkaWFncmFtLg0KDQpUaGFua3Mg YSBsb3QgZm9yIHRoZSBmZWVkYmFjayENCg0KTWljaGFlbA0KDQoNCkZyb206IHRjcG0gPHRjcG0t Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjcsIDIwMjAgMTA6MTcgQU0NClRvOiBZb3NoaWZ1 bWkgTmlzaGlkYSA8bnNkLmlldGZAZ21haWwuY29tPjsgdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25z IDx0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0Y3BtXSBXRyBpdGVtIGFkb3B0aW9uIGZv ciBkcmFmdC1zY2hhcmYtdGNwbS15YW5nLXRjcC0wNg0KDQpIaSBhbGwsDQoNClRoaXMgaXMgYSB1 c2VmdWwgZG9jdW1lbnQuIEkgc3VwcG9ydCBpdC4NCg0KTWljaGFlbCwgcGxlYXNlIHVwZGF0ZSB0 aGUgdHJlZSBkaWFncmFtIHRvIGxpc3QgYWxsIHRoZSBkYXRhIG5vZGVzLiBUaGFua3MuDQoNCkNo ZWVycywNCk1lZA0KDQpEZSA6IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIERl IGxhIHBhcnQgZGUgWW9zaGlmdW1pIE5pc2hpZGENCkVudm95w6kgOiBsdW5kaSAxNyBhb8O7dCAy MDIwIDE5OjA0DQrDgCA6IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+IEV4dGVu c2lvbnMgPHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+Pg0KT2JqZXQgOiBSZTog W3RjcG1dIFdHIGl0ZW0gYWRvcHRpb24gZm9yIGRyYWZ0LXNjaGFyZi10Y3BtLXlhbmctdGNwLTA2 DQoNCkhpIGZvbGtzLA0KV2UgYXBwcmVjaWF0ZSB5b3VyIGZlZWRiYWNrIG9uIHRoaXMuDQotLQ0K dGNwbSBjby1jaGFpcnMNCg0KT24gTW9uLCBBdWcgMywgMjAyMCBhdCAxOjA0IEFNIFlvc2hpZnVt aSBOaXNoaWRhIDxuc2QuaWV0ZkBnbWFpbC5jb208bWFpbHRvOm5zZC5pZXRmQGdtYWlsLmNvbT4+ IHdyb3RlOg0KSGksDQoNClRoZSBjaGFpcnMgaGFzIGJlZW4gZGlzY3Vzc2luZyBob3cgdG8gcHJv Y2VlZCBkcmFmdC1zY2hhcmYtdGNwbS15YW5nLXRjcC0wNiBhZnRlciB0aGUgV0cgbWVldGluZy4N ClRoZSByZXN1bHRzIG9mIHRoZSBodW0gd2VyZSBhIGJpdCB3ZWFrIHRvIHNlZSBjbGVhciBjb25z ZW5zdXMgYWx0aG91Z2ggdGhlcmUgd2FzIHNsaWdodGx5IHN0cm9uZyBodW0gZm9yIGFkb3B0aW9u Lg0KQWxzbywgdGhlcmUgc2VlbXMgdG8gYmUgc29tZSBjb25mdXNpb25zIGR1cmluZyB0aGUgYWRv cHRpb24gY2FsbC4gKEknbSBzb3JyeSBmb3IgdGhlIGNsdW1zaW5lc3Mgb2YgdXNpbmcgdGhlIHRv b2wpDQpJbiBvcmRlciBmb3IgdGhpcywgd2Ugd291bGQgbGlrZSB0byBzZWVrIHRoZSBhZGRpdGlv bmFsIGZlZWRiYWNrIGZyb20gdGhlIGNvbW11bml0eSBvbiB0aGUgZm9sbG93aW5nIHBvaW50cy4N Cg0KMTogSWYgeW91IHdhbnQgdG8gYWRkIHlvdXIgaHVtIHRvIHRoZSBjYWxsIGJlY2F1c2UgeW91 IGRpZG4ndCBhdCB0aGUgbWVldGluZyBmb3Igc29tZSByZWFzb25zIG9yIGlmIHlvdSB3YW50IHRv IGNoYW5nZSB5b3VyIGh1bSwgcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cuDQoyOiBpZiB5b3Ug aHVtbWVkIGZvciBub3QgYWRvcHRpbmcgdGhlIGRyYWZ0LCBwbGVhc2Ugc2hhcmUgeW91ciBvcGlu aW9uLiBUaGlzIHdpbGwgYmUgYSB2ZXJ5IGhlbHBmdWwgaW5wdXQgZm9yIHVzLg0KDQpXZSdsbCBh cHByZWNpYXRlIHlvdXIgY29vcGVyYXRpb24uDQpUaGFua3MsDQotLQ0KWW9zaGkNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2DD5E5CDrznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZv cm1hdGllcnQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRN TFZvcmZvcm1hdGllcnRaY2huDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQg WmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZv cmZvcm1hdGllcnQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRS1NYWlsRm9ybWF0 dm9ybGFnZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBNZWQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TdXJlLCB3ZSB3aWxsIGZpeCB0aGUgdHJlZSBkaWFn cmFtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBhIGxvdCBm b3IgdGhlIGZlZWRiYWNrITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1p Y2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHRjcG0gJmx0O3RjcG0tYm91bmNl c0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDI3LCAyMDIwIDEwOjE3 IEFNPGJyPg0KPGI+VG86PC9iPiBZb3NoaWZ1bWkgTmlzaGlkYSAmbHQ7bnNkLmlldGZAZ21haWwu Y29tJmd0OzsgdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zICZsdDt0Y3BtQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RjcG1dIFdHIGl0ZW0gYWRvcHRpb24gZm9yIGRyYWZ0 LXNjaGFyZi10Y3BtLXlhbmctdGNwLTA2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSBhbGwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+VGhpcyBpcyBhIHVzZWZ1bCBkb2N1bWVudC4gSSBzdXBwb3J0IGl0LiAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWlj aGFlbCwgcGxlYXNlIHVwZGF0ZSB0aGUgdHJlZSBkaWFncmFtIHRvIGxpc3QgYWxsIHRoZSBkYXRh IG5vZGVzLiBUaGFua3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHRjcG0gWzxhIGhyZWY9Im1haWx0bzp0Y3BtLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzp0Y3BtLWJvPHNwYW4gbGFuZz0iRlIiPnVuY2VzQGlldGYu b3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGI+RGUg bGEgcGFydCBkZTwvYj4gWW9zaGlmdW1pIE5pc2hpZGE8YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gbHVuZGkgMTcgYW/Du3QgMjAyMCAxOTowNDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJl Zj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+IEV4dGVuc2lvbnMgJmx0 OzxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbdGNwbV0gV0cgaXRlbSBhZG9wdGlvbiBmb3IgZHJh ZnQtc2NoYXJmLXRjcG0teWFuZy10Y3AtMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRlIiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5XZSBhcHByZWNpYXRlIHlv dXIgZmVlZGJhY2sgb24gdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+LS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG UiI+dGNwbSBjby1jaGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5PbiBN b24sIEF1ZyAzLCAyMDIwIGF0IDE6MDQgQU0gWW9zaGlmdW1pIE5pc2hpZGEgJmx0OzxhIGhyZWY9 Im1haWx0bzpuc2QuaWV0ZkBnbWFpbC5jb20iPm5zZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRlIiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+VGhl IGNoYWlycyBoYXMmbmJzcDtiZWVuIGRpc2N1c3NpbmcgaG93IHRvIHByb2NlZWQgZHJhZnQtc2No YXJmLXRjcG0teWFuZy10Y3AtMDYgYWZ0ZXIgdGhlIFdHIG1lZXRpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RlIiPlRoZSByZXN1bHRzIG9mIHRoZSBodW0gd2VyZSBhIGJpdCB3ZWFrIHRvIHNlZSBjbGVhciBj b25zZW5zdXMgYWx0aG91Z2ggdGhlcmUgd2FzIHNsaWdodGx5IHN0cm9uZyBodW0gZm9yIGFkb3B0 aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5BbHNvLCB0aGVyZSBzZWVtcyB0byBiZSBzb21l IGNvbmZ1c2lvbnMgZHVyaW5nIHRoZSBhZG9wdGlvbiBjYWxsLiAoSSdtIHNvcnJ5IGZvciB0aGUg Y2x1bXNpbmVzcyBvZiB1c2luZyB0aGUgdG9vbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+SW4gb3JkZXIg Zm9yIHRoaXMsIHdlIHdvdWxkIGxpa2UgdG8gc2VlayB0aGUgYWRkaXRpb25hbCZuYnNwO2ZlZWRi YWNrIGZyb20gdGhlIGNvbW11bml0eSBvbiB0aGUgZm9sbG93aW5nIHBvaW50cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj4xOiBJZiB5b3Ugd2FudCB0 byBhZGQgeW91ciBodW0gdG8gdGhlIGNhbGwgYmVjYXVzZSB5b3UgZGlkbid0IGF0IHRoZSBtZWV0 aW5nIGZvciBzb21lIHJlYXNvbnMgb3IgaWYgeW91IHdhbnQgdG8gY2hhbmdlIHlvdXIgaHVtLCBw bGVhc2UgbGV0IHRoZSBjaGFpcnMga25vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+MjogaWYgeW91IGh1 bW1lZCBmb3Igbm90IGFkb3B0aW5nIHRoZSZuYnNwO2RyYWZ0LCBwbGVhc2Ugc2hhcmUgeW91ciBv cGluaW9uLiBUaGlzIHdpbGwgYmUgYSB2ZXJ5IGhlbHBmdWwgaW5wdXQgZm9yIHVzLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5XZSdsbCBh cHByZWNpYXRlIHlvdXIgY29vcGVyYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkZSIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5Zb3NoaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6EC6417807D9754DA64F3087E2E2E03E2DD5E5CDrznt8114rzntrzd_-- From nobody Sun Sep 6 23:36:25 2020 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 93E313A15B8; Sun, 6 Sep 2020 23:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QDHGvp3vgLi; Sun, 6 Sep 2020 23:36:22 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 959373A15B7; Sun, 6 Sep 2020 23:36:21 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0876aJqO057453; Mon, 7 Sep 2020 08:36:19 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 624701D53C1; Mon, 7 Sep 2020 08:36:19 +0200 (CEST) Received: from 79.156.27.47 by webmail.entel.upc.edu with HTTP; Mon, 7 Sep 2020 08:36:19 +0200 Message-ID: Date: Mon, 7 Sep 2020 08:36:19 +0200 From: "Carles Gomez Montenegro" To: lwip@ietf.org, tcpm@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at violet X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Mon, 07 Sep 2020 08:36:19 +0200 (CEST) Archived-At: Subject: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-10.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, 07 Sep 2020 06:36:24 -0000 Dear all, We just submitted revision -10 of the "TCP Usage Guidance in the Internet of Things (IoT)" draft. The main changes in this revision are intended to address: - Erik Kline's comments after his AD review. - A comment from Markku Kojo on advice given in RFC 6691. Thanks to both, Erik and Markku, for your valuable feedback! Cheers, Carles (on behalf of all authors) ---------------------------- Original Message ---------------------------- Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-10.txt From: internet-drafts@ietf.org Date: Mon, September 7, 2020 8:17 am To: i-d-announce@ietf.org Cc: lwip@ietf.org -------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : TCP Usage Guidance in the Internet of Things (IoT) Authors : Carles Gomez Jon Crowcroft Michael Scharf Filename : draft-ietf-lwig-tcp-constrained-node-networks-10.txt Pages : 30 Date : 2020-09-06 Abstract: This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-10 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-10 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/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From nobody Thu Sep 10 00:50:41 2020 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 57C333A1031 for ; Thu, 10 Sep 2020 00:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_LmiwZFWqpr for ; Thu, 10 Sep 2020 00:50:37 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B453A0FF9 for ; Thu, 10 Sep 2020 00:50:36 -0700 (PDT) Received: from mb.fritz.box (ip4d15f5fc.dynamic.kabel-deutschland.de [77.21.245.252]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 66FAB771C96F3 for ; Thu, 10 Sep 2020 09:50:34 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_F2FF09C8-0EBC-427D-8709-CA46D9AF09AB"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <6BFDF7F3-71F0-4544-9F6D-7BE4CD108B51@fh-muenster.de> Date: Thu, 10 Sep 2020 09:50:32 +0200 To: tcpm IETF list X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [tcpm] WGLC for draft-ietf-tcpm-rack-10 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, 10 Sep 2020 07:50:39 -0000 --Apple-Mail=_F2FF09C8-0EBC-427D-8709-CA46D9AF09AB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Dear all, this e-mail starts the working group last call for draft-ietf-tcpm-rack-10. The WGLC runs until Tuesday, September 20th 2020. It is the 2nd WGLC on RACK, since the document improved substantially based on the feedback given during the 1st WGLC. Please send any comments, including indications to support this document, to the TCMP mailing list by then. The ID is available at https://tools.ietf.org/html/draft-ietf-tcpm-rack-10 Best regards Michael --Apple-Mail=_F2FF09C8-0EBC-427D-8709-CA46D9AF09AB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA5 MTAwNzUwMzJaMC8GCSqGSIb3DQEJBDEiBCDXmqmvBA5mrWziwlFt4mQbeToy+W0otIjvoyEVvmay uTCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAq09edEeCkuzzUuJED5WOiX7dIMDd LMLk/c/zbI5BWzJrWXmWQ8JVR4YzNjqkyxW3NCkytbt/GoABQKvbt9uOx9yoi6wwY1euyDyCdGGc U7sKEjLMZDgFBOpi2WAwCNd0/1MAfaFwXJ68M387pV1nyK1nVq9GjOeokluS/BBS37HRWNK69W5o PSE09sorlzwg1Dj1VxIR2kvII1fkgRWSmt1GggL4MZOwgyRiQM24jMgV1FXn+jSoITjbZPnrLe7b TaxD5RRCg3EmYVC+UnbfV6Ro9KAMLOgoqek+a/17KYydikinacGT+9TJVgObuhp5CaYr055Ypn8i 8Ycmfn6r0gAAAAAAAA== --Apple-Mail=_F2FF09C8-0EBC-427D-8709-CA46D9AF09AB-- From nobody Sun Sep 13 19:00:37 2020 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 D0FEA3A0A02 for ; Sun, 13 Sep 2020 19:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMVhWgb8iqnB for ; Sun, 13 Sep 2020 19:00:34 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 3D5843A09FF for ; Sun, 13 Sep 2020 19:00:34 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id x23so9132376wmi.3 for ; Sun, 13 Sep 2020 19:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wDa9ftBvMPj5v3FsPDvitutEHOptD1mHzBCjB54hjzA=; b=gRD4ibuGF2vtoTblYbo9WjOF5vvxECITTikIO27LY6oVVqjjrdDbLf9gdRZnXZwJHD 7bjbqTFaBRG5LR4U3AZidQExCZa3vusclOEvxsE+CGrt397EeZVzbLnGdyfa3U2YbtVs 02d+eXy7cWjBoHEeuGJkfIlYgYNNxuNL3ZZOT1dJTasPPdbiq4Gd+Q2CtKa79iVOPNOz zAgOrYBsnhz1ZVnEOxJ0Z0lrQ5pZyid5LJE2/5m0/E4IKzAuzciUQt4STO8X30gFauQF TqF9Go+NABOsKfKXeNmhNWy8lUK/33hrAwstQDcp1rQlAmlVSa1KxrDby9HC+N3Qhdio kdog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wDa9ftBvMPj5v3FsPDvitutEHOptD1mHzBCjB54hjzA=; b=kU+4DdkLqkKDSklgto/NfPOT8rlD9sXI7FaEEWCLn6LD+LNIIjLzheYXn1zVIrvKKS Z8JOcbMUI5nMcjkLB18AP6/pY58MrkapywB3Z43kXuFA80RuCEGrRfd5Fpz6OSMjmYh8 Yl9EMqiLcXb1yoHsJTzK3P2MwlrD55n9QgG6AGxPjfyMhJ0vcKCVXMXaJL1j5cRjyH3B aZQDKGmy3jgj7IHjWKxQy8rD6UgQ6ATZuVTbK5nXe0QdOaiB4HOtMwWjIEiB0jRTTPGc qr9Z5DJq236yVX8PbPoW8AU/Bcwl2asrULGnUnRpF2M75s3TkmD2X/BLITaci+m0SDL4 L0Rw== X-Gm-Message-State: AOAM531ZOBONBhW84XEw8EjwoiCClNuurbVKCK6dGpwBXk6LkMOqnu+3 Xh0wMv4ItpE3e10MM8qtMyfu5xxM7kyZzc6cChd5++83cVY= X-Google-Smtp-Source: ABdhPJxJ74zlr/kkD3jIlWKy2BPDuXEQ54x8bhIW8GHMfr6LHsbbhc9OW0Co2Di9LIx39GQMZHypZF2z6b+CUEFXl4Y= X-Received: by 2002:a05:600c:2246:: with SMTP id a6mr13244953wmm.38.1600048832216; Sun, 13 Sep 2020 19:00:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Sun, 13 Sep 2020 19:00:21 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000004480bb05af3c66a1" Archived-At: Subject: [tcpm] [Result] WG item adoption for draft-scharf-tcpm-yang-tcp-06 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, 14 Sep 2020 02:00:36 -0000 --0000000000004480bb05af3c66a1 Content-Type: text/plain; charset="UTF-8" Hello, Thanks for providing feedback on WG item adoption for draft-scharf-tcpm-ya ng-tcp-06. After some discussions among the chairs (to be precise: Michael Tuexen and me because Michael Scharf has a conflict of interest), we concluded supporting this draft is our rough consensus. Hence, we decided to adopt it as a WG item. As we have seen some discussions on the doc, we notice this would not be an unanimous opinion in the community. However, we will have plenty of chances for discussions until it's published. If there's any concerns on the doc, it should be clarified and solved by then. We really appreciate your cooperation. -- Yoshi on behalf of tcpm co-chairs On Mon, Aug 3, 2020 at 1:04 AM Yoshifumi Nishida wrote: > Hi, > > The chairs has been discussing how to proceed > draft-scharf-tcpm-yang-tcp-06 after the WG meeting. > The results of the hum were a bit weak to see clear consensus although > there was slightly strong hum for adoption. > Also, there seems to be some confusions during the adoption call. (I'm > sorry for the clumsiness of using the tool) > In order for this, we would like to seek the additional feedback from the > community on the following points. > > 1: If you want to add your hum to the call because you didn't at the > meeting for some reasons or if you want to change your hum, please let the > chairs know. > 2: if you hummed for not adopting the draft, please share your opinion. > This will be a very helpful input for us. > > We'll appreciate your cooperation. > Thanks, > -- > Yoshi > --0000000000004480bb05af3c66a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

Thanks for providing feedback on=C2=A0WG item adoption for draft-sch= arf-tcpm-yang-tcp-06.
After some discussions among the chairs (to be precise: Mich= ael Tuexen and me because Michael Scharf has a conflict of interest),=C2=A0=
we concluded supporti= ng this draft is our rough consensus. Hence, we decided=C2=A0to adopt it as= a WG item.

As we have seen some discus= sions on the=C2=A0doc, we notice this would=C2=A0not be an unanimous opinio= n in the=C2=A0community.
However, we will have=C2=A0plenty of chances for discussio= ns until it's published.=C2=A0
If there's any concerns on= the doc, it should be clarified and solved by then.=C2=A0
<= div>

We really appreciate your cooperation.=C2=A0
--
Yoshi on behalf of tcpm co-chair= s

On Mon, Aug 3, 2020 at 1:04 AM Yoshifumi Nishida <<= a href=3D"mailto:nsd.ietf@gmail.com">nsd.ietf@gmail.com> wrote:
<= /div>
Hi,=

The chairs has=C2=A0been discussing how to proceed draft= -scharf-tcpm-yang-tcp-06 after the WG meeting.
The results of the= hum were a bit weak to see clear consensus although there was slightly str= ong hum for adoption.=C2=A0
Also, there seems to be some confusio= ns during the adoption call. (I'm sorry for the clumsiness of using the= tool)
In order for this, we would like to seek the additional=C2= =A0feedback from the community on the following points.

1: If you want to add your hum to the call because you didn'= t at the meeting for some reasons or if you want to change your hum, please= let the chairs know.
2: if you hummed for not adopting the=C2=A0= draft, please share your opinion. This will be a very helpful input for us.= =C2=A0

We'll appreciate your cooperation= .
Thanks,
--
Yoshi
--0000000000004480bb05af3c66a1-- From nobody Thu Sep 17 02:37:01 2020 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 39BD73A0E31; Thu, 17 Sep 2020 02:36:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: martin.h.duke@gmail.com, michael.scharf@hs-esslingen.de, tcpm@ietf.org, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160033541916.308.13230679005084453533@ietfa.amsl.com> Date: Thu, 17 Sep 2020 02:36:59 -0700 Archived-At: Subject: [tcpm] tcpm - New Meeting Session Request for IETF 109 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: Thu, 17 Sep 2020 09:36:59 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Technology Overlap: tsvwg quic taps tsvarea iccrg panrg webtrans masque Key Participant Conflict: netconf People who must be present: Yoshifumi Nishida Michael Tuexen Martin Duke Michael Scharf Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Sep 18 01:53:25 2020 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 2CA113A105D for ; Fri, 18 Sep 2020 01:53:24 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbjA8D5wZodx for ; Fri, 18 Sep 2020 01:53:23 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 CB25F3A105A for ; Fri, 18 Sep 2020 01:53:22 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id e11so6208313wme.0 for ; Fri, 18 Sep 2020 01:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZyYP29h/qdoDjXRFhgP1IvUcWOVCC9SjPPaaW9vMZmc=; b=cR5z0/yq3cWGnFoD3Dx60Ul1CGoV0YTOQUBgr5/wqUHnv6oEMLCnxBr+mo8dG9+wEh gHgoUvQrQshoiWjpBaHyODr7EYeqsf0lo1eVjPZiC7+MiQXVvSfcRIcafdjXd3D7QSHW /pOcXjQkDZ0xBCsMUfAQ8OO13JyC3FxaR6HnjyeZBVg7jx652NWy640pw2OcekVIPrmG jSdFWvslVO5d5DhJIToZd5dd/qZQxRpXB28wnPPE4irW3OpMA2eGm+LXB9GTuuVWvPJ6 Tuv16KLuBSRjUgrhGuMdeMUE/5Ce1LhRykhwDMvzwI/pcJJC08WpQl4F2xInGvRf1E/+ c4gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZyYP29h/qdoDjXRFhgP1IvUcWOVCC9SjPPaaW9vMZmc=; b=dbgNBYAWO7Sp4YMLed2L9AvIwKUSTFchR3roZYE5OeNlmirF0YYkZMfN2dbwvn1JOb yWZenAmGTa8H8He06RcyoueiI73DX6myK/lNNAh019v5aUd9JbgaR4Ft8nzgz/ykww8d tI5UIxOgeOfA65UiLhsCvEFEp8LFxQqC3pqvtrAjUu9xcZmUwUo8mrZfibnqhFYxL9PO u9/rCeGJJauYzp/s/2vrFvdPzKRKRV7v1Ire6s/0q6VZ61QPVynmEmWvcURW4H7IGggM JHHJbHjTr2INUQD2iivhlko+ysYFGMxAhPYAIHQ11SZ0nnL4AgbnTLK4xwPIw9kbyex3 vAMg== X-Gm-Message-State: AOAM5339vprXeZ81oN6KrJtdjeVR+FEEeiGGlhxgG+OaQWQ/x3VJokMN JY0irlIuxsiQV8khX22zV2cuVye2ZpO84RjJcNyo5Fdd82E= X-Google-Smtp-Source: ABdhPJyQb/HYgE35k1diJb53CW+FIPfgPHwUPsS0ZdTOwtcQusecbxeeYzqELImSSYYZtyvQNuxBXaUTXjtI7o+nJrc= X-Received: by 2002:a1c:80cd:: with SMTP id b196mr14510636wmd.104.1600419200571; Fri, 18 Sep 2020 01:53:20 -0700 (PDT) MIME-Version: 1.0 From: Juhamatti Kuusisaari Date: Fri, 18 Sep 2020 11:53:08 +0300 Message-ID: To: tcpm IETF list , "Scharf, Michael" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] Comments for draft-scharf-tcpm-yang-tcp-06 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, 18 Sep 2020 08:53:24 -0000 Hello, I read through draft-scharf-tcpm-yang-tcp-06 and overall it looks fine to me. Nevertheless, there are a couple of items that may need clarifications/improvements. (1) I believe "leaf include-tcp-options" should be "leaf ignore-tcp-options" with a false default as the options are included by default in the RFC 5925. In my opinion, this would better emphasize the fact that options really should be included by default and not including them should be a special case. Change suggestion in detail below: leaf include-tcp-options { type boolean; must "../enable-ao = 'true'"; description "Include TCP options in HMAC calculation."; } => leaf ignore-tcp-options { type boolean; default "false"; must "../enable-ao = 'true'"; description "Ignore TCP options in MAC calculation."; } Please also note the "HMAC"->"MAC" change suggestion. And yes, I do realize that a default could be added to the original "include" leaf. After pondering about this, I do think "ignore" leaf would be a better end result for the reasons I mentioned above. (2) There is now a leaf that says: leaf accept-ao-mismatch { type boolean; must "../enable-ao = 'true'"; description "Accept packets with HMAC mismatch."; } It is true that RFC 5925 allows non-existing MKT connections that should be accepted. Then again, the above configuration and its description looks to me that any mismatch would be accepted. So, maybe a configuration setting better reflecting RFC 5925 would be something on the lines of leaf accept-key-mismatch { type boolean; must "../enable-ao = 'true'"; description "Accept TCP segments with a Master Key Tuple (MKT) that is not configured."; } As this configuration option does not have such a strong default as the former one, I do not see a need to change its logic otherwise nor add a default. I would assume that most security aware users would have "false" there as a setting - especially those users that would use a YANG model to do the configuration. Best regards, -- Juhamatti From nobody Fri Sep 18 05:11:39 2020 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 E69D43A07EC for ; Fri, 18 Sep 2020 05:11:37 -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 ebaPzfgG-X5i for ; Fri, 18 Sep 2020 05:11: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 2D7953A07A7 for ; Fri, 18 Sep 2020 05:11:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id D98E025A49 for ; Fri, 18 Sep 2020 14:11:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1600431093; bh=rtuIx0OWbq3pANTbQqjHSOIUHCc9oCjrOVQO1PDC8Gg=; h=From:To:Subject:Date:From; b=lGjEVIIIuOm0N0W32OxMs2mhhFn9R1YUWFgCQUx4RishTOYoUoxKklbwT78VwsOlP mRcB+CByrEPg7arjnuaxRd3HHRLuNEAt/vzDb2AnsjJ2At7XozUHYQitZzrhLW2+Nr mLxQXNNAFuhGqNXiOSDd9sLadxgXkrbmoX3jMA9g= 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 TzGHwpFqte1n for ; Fri, 18 Sep 2020 14:11:31 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Fri, 18 Sep 2020 14:11:31 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.74]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Fri, 18 Sep 2020 14:11:31 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org Extensions" Thread-Topic: WGLC for 793bis - REVIEW NEEDED Thread-Index: AdaNr7PqnFNNBpXDQaKL+djVtoCPWg== Date: Fri, 18 Sep 2020 12:11:30 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DD8004B@rznt8114.rznt.rzdir.fht-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.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] WGLC for 793bis - REVIEW NEEDED 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, 18 Sep 2020 12:11:38 -0000 Dear TCPM contributors, This e-mail starts a working group last call for draft-ietf-tcpm-rfc793bis-= 18. Information about the document can be found at this link: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ For instance, the current version can be found at https://datatracker.ietf.= org/doc/html/draft-ietf-tcpm-rfc793bis-18. When adopting draft-ietf-tcpm-rfc793bis, the TCPM working group consensus w= as to limit the scope of 793bis to TCP changes that are specified either in= standards-track RFCs or in verified errata. Also, the consensus was to foc= us on the base protocol and exclude mechanisms that can be specified separa= tely (e.g., congestion control). As a result, 793bis should in principle no= t contain anything new. Nonetheless, we all know that TCP is a complex prot= ocol and even small details of the specification matter a lot. Given that 793bis will obsolete RFC 793, which is one of the most important= Internet Standards, this WGLC will run for *four weeks*, i.e., until Octob= er 16. Therefore, *your* help is needed: PLEASE review 793bis in the next weeks! T= he earlier, the better... - Any comments or suggestions are important and highly appreciated. Even if= you don't speak up often on the TCPM mailing list, please let us know if y= ou have any feedback. - Even if you read the document without finding any errors or issue, please= let us know ("+1"). - It is also perfectly fine to look only at a subset of the document, e.g.,= if you are familiar with specific details of TCP. Partial reviews are welc= ome, too. - If you own TCP running code, you definitively should have a very close lo= ok; this document is supposed to be the new base specification of TCP. RFC 793 lays the ground for all work in TCPM, and 793bis is probably one of= the most important deliverables of TCPM. Please help us with completing th= is milestone. Thanks! Michael Scharf Yoshifumi Nishida Michael Tuexen=20 (TCPM chairs) From nobody Sun Sep 20 18:16:32 2020 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 30EDC3A10F7 for ; Sun, 20 Sep 2020 18:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-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 ncKc8hom3AxE for ; Sun, 20 Sep 2020 18:16:29 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650117.outbound.protection.outlook.com [40.107.65.117]) (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 E893A3A102E for ; Sun, 20 Sep 2020 18:16:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tv6FG7GSRK8/eEx/SxOaRDbj/8hDGiv1e/6nUwGlGHde8J+dFtTI7byBih32NaI7+7CrusJnherSJi0KiT4LeOM7PTWr6rppo7HhuzsjGVNmXlETtdYyYgFwya5Kf/qw3CYJTmAffItUqOnyVpEhh3iuTqPmx6By9NFXIg99svZyLP9HiwKofXV/GlygX7mbDn6Wbtq8LnfFwRBisVGbYU12ESUBM24FgIX1JMZQHCc6fQqm02EH76MtRoaVXOwOe++scysXqMWE2PU88GIq818IQFQseuGFteqpJhd4xBj6T2+CT+ZBs6V3xgbHlC5VbQ2QCLceL06JSL3baKrkwA== 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=kg3QEcV7QtXx0/zhX4Cw8yy+5QXVwk76FCCe5UNI3vE=; b=PzR8njhK98+1eW1POq11UPec0S1ZUZa4Ida4ZaYtHcPMjNPdMBTvDBjHxwXcgvr9VmPVtGaGJITs686U2KQmZvkp6+NJZo6zKLXJgmY3C4gROgIfiL+6L+ZTDpKEOwApAuQC3ZLZNRTf/Z626gDAnk5kAIf/D7Q7EaPqcwgisIfPUcdjx+XQYR6p9Mzy5vMUt1eq5yJhi9OaxcL9uxDmnqrEKBxdfA7afcwK8AXvKCILVS1nGVZA1H2Xc5XjCJaGmu9UipPXpy3rMz3SeacPiaNoJj5dispLLNiGF0VKdMIBVxq2NnjlUToangDzXQN/zHpeiJID72hTLWlp0n/jOw== 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=kg3QEcV7QtXx0/zhX4Cw8yy+5QXVwk76FCCe5UNI3vE=; b=N19O1Tvl8ElYKVboY1jdAM8E+ikA1mVkB+kIYuKDrV7ieYwCP8YmUAqS/f5iZj7mwbgnUalsO0ORyHsV9SnlX09a+DC4qP7Q2Ok1EqbN/o4IsGNiEGFAGTUZIk9OCYNpDNodxO+5grw8Wizm/GW355P0Y+QpcXZ1ZS+vV3aQz+k= Received: from (2603:10b6:408:a1::17) by BN3PR00MB0099.namprd00.prod.outlook.com (2a01:111:e400:c5f3::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3434.0; Mon, 21 Sep 2020 01:16:20 +0000 Received: from BN8PR00MB0865.namprd00.prod.outlook.com ([fe80::a035:7b67:a8dc:59ce]) by BN8PR00MB0865.namprd00.prod.outlook.com ([fe80::a035:7b67:a8dc:59ce%8]) with mapi id 15.20.3443.000; Mon, 21 Sep 2020 01:16:20 +0000 From: Yi Huang To: "tcpm@ietf.org" Thread-Topic: A review of draft-ietf-tcpm-rack-10 Thread-Index: AdaPr6OwWgwL5n+GTQqpxYshj1XvWg== Date: Mon, 21 Sep 2020 01:16:20 +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_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-07T21:33:48.7833191Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f25c7c87-c7cc-47e2-ae0d-4b2f4ed88b0d; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic 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:ac89:6da0:638a:f9e5:f1b8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e6716f48-4e45-4dcd-90ec-08d85dcbf2c1 x-ms-traffictypediagnostic: BN3PR00MB0099: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i/K0Li/wt1STCWZobe6/6Dejocr5RTwZdVTdwLhJg4bPOy5e74/XUFrfaOUahP3TRuTHRDDOf8/RfWeY8XwLfjzyODlMuvCzz3RpYUFf0hQEAQxsJi0u3SBCsczUBfei0CMJ6lLgi0lgRugs41ip8bKlg8I8V9MrJxA0xPb5D30z2C6n0pYEDGfTX3PPSuEX5pQv9x8YJQrvWJ4AeE2HwStT5Uq+W0yNGW5X75eqFYzhtXEH/zr9QiUegLWjjFP5y83nt9yninHWO4P9BdcqvX9Oph6BERNkEzh1+8/R7AsESwxQ9GMxHX+n1XH5OEUsZEQI+HuJEdDyodA7Pc0mvA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR00MB0865.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(366004)(39860400002)(136003)(66476007)(66556008)(83380400001)(66946007)(64756008)(8676002)(186003)(107886003)(82950400001)(82960400001)(8990500004)(66446008)(86362001)(52536014)(54906003)(4326008)(76116006)(2906002)(33656002)(6506007)(8936002)(9686003)(71200400001)(5660300002)(6916009)(10290500003)(7696005)(316002)(478600001)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: gDO/6hviM0zEoV9WByrpWP08rrpcFbv1OHfx1lbRiD5IEnQUO+CfJx49xHl9JtygvTQwgWyMVMPDUAgNNFg5hBs5pMxVQ3xJebG7xZNl5kR+mPhgMck8vVrs9/22p5TF10KXrAazkFLnJMwC7/vEhQsqghdiSc7jZV1QQOtVWmKUtHSLmQgpGjbEu735kBpNogH4B+85LQ58nk8LxITu/OBc3Gqk2GC3ZPyMkpGdhZCrr6Gia07WEvTyXBsih+O/rOpX0ceJi9/32Q/z/zyCvBSe4uE1DvvnK0FKitLCBwYm+Jnyjl9VyNl232ganI6RKmlCTVdzx7rduX9meU6L0gqMecBVCGI9g27P7LeDyHjlxbN52rLIYwgOFszf96Dv8RLS0wxV4MCKF+xhSbPYQh7xZ2q8CJyh9PqsOxsgA92nj4yWglEZKmj01VeWoL8xfF+i7zGcb658T2iUacuorfDEBucYPwyrU+G7r/Uw5NlmV0Mf6hIiHfW9XLfwiYFH8iN9l8+yGoDzsys3VGQ6gYy3kyRQe8mn7OrnkHvtomncdK5Ev/PzefAbWKwp3g/msdsFSrbgztrwaqr4tctUPJ5IQreza/EHUHJaHBxygpeZPRj9bUpzywdj1Kjl8lQtOrOJk0pHOHvgjMJpyiqepqqGNX7aTokDk1D1rTnVG7Gql8OvIA0Q1xxbC/xQUn11cq3FQulL3Lrb5vmu2KvXyA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR00MB0865.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e6716f48-4e45-4dcd-90ec-08d85dcbf2c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 01:16:20.4721 (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: FHqFXZwLPLR0KC3hLKaau9SlAyuB7yjtjnbCUdTe1QcGO195WEaf7al147iEC9QiOKCT2GCXbbOvfw+lWpTMgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR00MB0099 Archived-At: Subject: [tcpm] A review of draft-ietf-tcpm-rack-10 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, 21 Sep 2020 01:16:30 -0000 Hi, I reviewed the latest version of RACK-TLP draft and have a few comments/que= stions. 1. In section 5.1, "Segment.retransmitted is true if it was retransmitted i= n the most recent transmission." There are also pseudo-code explaining how retransmitted flag is set. AFAICT= , retransmitted is set if the segment is ever retransmitted since the flag = is never reset. Is this variable supposed to mean ever retransmitted? 2. In section 6.2, p14, " If the sender has not yet observed any reordering based on the previous step, then RACK prioritizes quick loss recovery by using setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds DupThresh, or during loss recovery. Aside from those special conditions, RACK starts with a conservative reordering window of RACK.min_RTT/4. This value was chosen because Linux TCP used the same factor in its implementation to delay Early Retransmit [RFC5827] to reduce spurious loss detections in the presence of reordering, and experience showed this worked reasonably well [DMCG11]." If I understand this correctly, if no reordering observed, TCP should still= enter loss recovery when DupACK >=3D DupThresh (RFC6675). If reordering ha= s been seen, this RFC6675 rule is not honored and TCP only enters loss reco= very when RACK detects loss? I think it would be great to clarify this in t= he spec. 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Window Pro= be (ZWP) timer". Thanks, Yi From nobody Sun Sep 20 20:42:55 2020 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 7188C3A1279 for ; Sun, 20 Sep 2020 20:42:53 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=tenghardt.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 lGAbhRHXrZBK for ; Sun, 20 Sep 2020 20:42:51 -0700 (PDT) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (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 A11AC3A1278 for ; Sun, 20 Sep 2020 20:42:51 -0700 (PDT) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id EE024AA for ; Mon, 21 Sep 2020 05:42:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1600659769; bh=pxpLRu9JUuTADkYZ0TmMHm1gyifuF9snAmYl1dlT9ec=; h=Subject:To:References:From:Date:In-Reply-To:From; b=q+ep31EbM23AfCv8ILHuZWvdkNOwYs0iVwxIsvgwlJyVlv6WTbcCsweq2Jc9zNj+k 6sHVNH5WksloTKmyklvAPAc8cMkp2M5RSEuBxYdcC6xPpbiX91BeU1klgOOndoCwIK sO24TT+aqOD4ZBfRgUpHvHepdBuuUczC/EhPYhLZVwd+Rg1c/1F3DGSOUgjQPKDmC2 S+E52nyfgK+V8XP1Hf+8SNN0IXZFyamorx7mBbju9swRpyZMEfUpgpOpXi2tRFCw12 jtOeiu2Ec9ywtN9M+kFDN7qm7VzOF+m/uaqCPi6eAWWPfia8An96pdkt7UFZdbqYN1 9lUkjU77R90iw== To: tcpm@ietf.org References: <6BFDF7F3-71F0-4544-9F6D-7BE4CD108B51@fh-muenster.de> From: Theresa Enghardt Message-ID: Date: Sun, 20 Sep 2020 20:42:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6BFDF7F3-71F0-4544-9F6D-7BE4CD108B51@fh-muenster.de> Content-Type: multipart/alternative; boundary="------------DC256B52F32E1FD41C3F876E" Content-Language: en-US Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rack-10 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, 21 Sep 2020 03:42:53 -0000 This is a multi-part message in MIME format. --------------DC256B52F32E1FD41C3F876E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Dear TCPM, I just re-read draft-ietf-tcpm-rack-10 (after having provided feedback to -09). The draft has improved substantially and all my comments were addressed. So I'm in favor of publishing this document. One small thing I still found: In Section 7.4.2, the pseudocode uses a variable called ACK.seq. Is this the same as SEG.ACK in the same pseudocode? I think it should be an acknowledgement number, not the sequence number of the received ACK. And small editorial nit: In Section 2.2, the numbered list has two items of "1." Best, Theresa On 10.09.20 00:50, Michael Tuexen wrote: > Dear all, > > this e-mail starts the working group last call for draft-ietf-tcpm-rack-10. > > The WGLC runs until Tuesday, September 20th 2020. > > It is the 2nd WGLC on RACK, since the document improved substantially based > on the feedback given during the 1st WGLC. > > Please send any comments, including indications to support this document, > to the TCMP mailing list by then. > > The ID is available at > https://tools.ietf.org/html/draft-ietf-tcpm-rack-10 > > Best regards > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------DC256B52F32E1FD41C3F876E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Dear TCPM,

I just re-read draft-ietf-tcpm-rack-10 (after having provided feedback to -09).

The draft has improved substantially and all my comments were addressed.

So I'm in favor of publishing this document.

One small thing I still found:

In Section 7.4.2, the pseudocode uses a variable called ACK.seq. Is this the same as SEG.ACK in the same pseudocode? I think it should be an acknowledgement number, not the sequence number of the received ACK.

And small editorial nit:

In Section 2.2, the numbered list has two items of "1."

Best,
Theresa


On 10.09.20 00:50, Michael Tuexen wrote:
Dear all,

this e-mail starts the working group last call for draft-ietf-tcpm-rack-10.

The WGLC runs until Tuesday, September 20th 2020.

It is the 2nd WGLC on RACK, since the document improved substantially based
on the feedback given during the 1st WGLC.

Please send any comments, including indications to support this document,
to the TCMP mailing list by then.

The ID is available at
https://tools.ietf.org/html/draft-ietf-tcpm-rack-10

Best regards
Michael


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


--------------DC256B52F32E1FD41C3F876E-- From nobody Mon Sep 21 09:54:30 2020 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 375913A044E for ; Mon, 21 Sep 2020 09:54:29 -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 YTnsakLLHTv3 for ; Mon, 21 Sep 2020 09:54:27 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 2BAC53A041B for ; Mon, 21 Sep 2020 09:54:27 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id e14so8526523vsa.9 for ; Mon, 21 Sep 2020 09:54:26 -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=qG08qwZ5SPxuwXVlcpY7r5YYDATCUWz+TR99+wnVxRU=; b=QIbNhCv33OAlFUjdTyKBY4G9OzbJDtnV0b/RMU62yvNzCV143adEOM9iPB9YP4FOaJ bi2ly7ac8fM04Cd16MC5CRIGrzcv4BcThgG1F1QyrzUVpZo3qfwzYo6ABdb/qyjuL0q9 Hx60hqh9rUJwW+JO2h1Hq5Y4aGK/WRwNd3FTTNhy27oSkVzKSaZwiG21h08IkKdua2dg KkdV6oD9clXrpzAt4u6m4zp3Ukf3flIBj2Phlhzbyw4P/63vYuslGqas43Bf4u/xhRfR PX07Qrjd4oaTzn3Vw3XPiCdjDSJsRHHrH0eZYpAhZBymeHXC2ivFN/gHueXliYxYeJo+ TPQw== 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=qG08qwZ5SPxuwXVlcpY7r5YYDATCUWz+TR99+wnVxRU=; b=r7F9ShrWWQXCkFgaguHds2bK22Rfz7PMEZofVUQF8IJs+ZkeiDEyqJFVs58WvLm30b gRsHhLIfgywd16RaO0zM1J03ztiqButv6qPsnQCtwCDkDcbD5edC5bIKJlKgxiCbWocb 7Gw365wrb4zxM2LKCMSOKB9s0Vsrb1ZZQTv07uMhzC2n81uOGvo4bOpq1ArobEYWxFzY ILRQMfVl/jINE0ARSRVmj10Evs8w/jQQ1/wFKk7MRPoEED0wZP8Jz7+qKW8EY+NF7IQj 2DcHthakPAwjkiw6G9qNbUimEszfy9rG9q1zHBjAVjGzC+Q2r3aBaZghbpXPEGxUi5n2 kiIA== X-Gm-Message-State: AOAM533QldG/qh6B+QDavlfHEStecwpK9CuT74x+LHzfgi2eifp6MaGI PtI8keihcld0K3fUmkiQ/aAu9f6ypLYSHSJmMMyKzQ+VXIU= X-Google-Smtp-Source: ABdhPJwKlKB5T5Ke6ZgcDdFWHivWDCUA1E4Cuzx0HG32nAQv8KgE+9NKWMOrl2idYW+kegh81Lt0a1ttKZ7UeA0vFjk= X-Received: by 2002:a05:6102:2261:: with SMTP id v1mr799025vsd.28.1600707265851; Mon, 21 Sep 2020 09:54:25 -0700 (PDT) MIME-Version: 1.0 References: <6BFDF7F3-71F0-4544-9F6D-7BE4CD108B51@fh-muenster.de> In-Reply-To: From: Yuchung Cheng Date: Mon, 21 Sep 2020 09:53:49 -0700 Message-ID: To: Theresa Enghardt Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000f8cee105afd5b309" Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rack-10 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, 21 Sep 2020 16:54:29 -0000 --000000000000f8cee105afd5b309 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 20, 2020 at 8:43 PM Theresa Enghardt wrote: > Dear TCPM, > > I just re-read draft-ietf-tcpm-rack-10 (after having provided feedback to > -09). > > The draft has improved substantially and all my comments were addressed. > > So I'm in favor of publishing this document. > > One small thing I still found: > > In Section 7.4.2, the pseudocode uses a variable called ACK.seq. Is this > the same as SEG.ACK in the same pseudocode? I think it should be an > acknowledgement number, not the sequence number of the received ACK. > Thanks for catching that typo. for clarity will replace both ACK.seq & SEQ.ack to the ACK's acknowledgement number > > And small editorial nit: > > In Section 2.2, the numbered list has two items of "1." > wil fix in -11 > > Best, > Theresa > > > On 10.09.20 00:50, Michael Tuexen wrote: > > Dear all, > > this e-mail starts the working group last call for draft-ietf-tcpm-rack-10. > > The WGLC runs until Tuesday, September 20th 2020. > > It is the 2nd WGLC on RACK, since the document improved substantially based > on the feedback given during the 1st WGLC. > > Please send any comments, including indications to support this document, > to the TCMP mailing list by then. > > The ID is available athttps://tools.ietf.org/html/draft-ietf-tcpm-rack-10 > > Best regards > Michael > > > _______________________________________________ > tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000f8cee105afd5b309 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Sep 20, 2020 at 8:43 PM There= sa Enghardt <iet= f@tenghardt.net> wrote:
=20 =20 =20
Dear TCPM,

I just re-read draft-ietf-tcpm-rack-10 (after having provided feedback to -09).

The draft has improved substantially and all my comments were addressed.

So I'm in favor of publishing this document.

One small thing I still found:

In Section 7.4.2, the pseudocode uses a variable called ACK.seq. Is this the same as SEG.ACK in the same pseudocode? I think it should be an acknowledgement number, not the sequence number of the received ACK.
=
Thanks for catching that typo. for clarity will replace both ACK.seq &= amp; SEQ.ack to
the ACK's acknowledgement number
= =C2=A0

And small editorial nit:

In Section 2.2, the numbered list has two items of "1."
wil fix in -= 11=C2=A0

Best,
Theresa


On 10.09.20 00:50, Michael Tuexen wrote:
Dear all,

this e-mail starts the working group last call for draft-ietf-tcpm-rack-10.

The WGLC runs until Tuesday, September 20th 2020.

It is the 2nd WGLC on RACK, since the document improved substantially based
on the feedback given during the 1st WGLC.

Please send any comments, including indications to support this document,
to the TCMP mailing list by then.

The ID is available at
https://tools.ietf.org/html/draft-ietf-tcpm-rack-10

Best regards
Michael


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


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000f8cee105afd5b309-- From nobody Mon Sep 21 10:23:20 2020 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 BA8FA3A09C4 for ; Mon, 21 Sep 2020 10:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdefX7NyvDjf for ; Mon, 21 Sep 2020 10:23:17 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id E30113A09C1 for ; Mon, 21 Sep 2020 10:23:16 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4F32E1B00226; Mon, 21 Sep 2020 18:23:00 +0100 (BST) To: Michael Tuexen , tcpm IETF list References: <6BFDF7F3-71F0-4544-9F6D-7BE4CD108B51@fh-muenster.de> From: Gorry Fairhurst Message-ID: <13ff6f6f-ee78-c9c1-4775-f2d04fd7ba19@erg.abdn.ac.uk> Date: Mon, 21 Sep 2020 18:22:59 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <6BFDF7F3-71F0-4544-9F6D-7BE4CD108B51@fh-muenster.de> Content-Type: multipart/alternative; boundary="------------F76AD25C0F4C2B8039ECE398" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rack-10 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, 21 Sep 2020 17:23:19 -0000 This is a multi-part message in MIME format. --------------F76AD25C0F4C2B8039ECE398 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I reviewed -09, and -10 resolves the issues that I noted. I think this is ready to procceed. Best wishes, Gorry On 10/09/2020 08:50, Michael Tuexen wrote: > Dear all, > > this e-mail starts the working group last call for draft-ietf-tcpm-rack-10. > > The WGLC runs until Tuesday, September 20th 2020. > > It is the 2nd WGLC on RACK, since the document improved substantially based > on the feedback given during the 1st WGLC. > > Please send any comments, including indications to support this document, > to the TCMP mailing list by then. > > The ID is available at > https://tools.ietf.org/html/draft-ietf-tcpm-rack-10 > > Best regards > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------F76AD25C0F4C2B8039ECE398 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

I reviewed -09, and -10 resolves the issues that I noted. I think this is ready to procceed.

Best wishes,

Gorry

On 10/09/2020 08:50, Michael Tuexen wrote:
Dear all,

this e-mail starts the working group last call for draft-ietf-tcpm-rack-10.

The WGLC runs until Tuesday, September 20th 2020.

It is the 2nd WGLC on RACK, since the document improved substantially based
on the feedback given during the 1st WGLC.

Please send any comments, including indications to support this document,
to the TCMP mailing list by then.

The ID is available at
https://tools.ietf.org/html/draft-ietf-tcpm-rack-10

Best regards
Michael


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--------------F76AD25C0F4C2B8039ECE398-- From nobody Mon Sep 21 14:53:36 2020 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 C888F3A0AE7 for ; Mon, 21 Sep 2020 14:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, 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 jAEBtheY8mvl for ; Mon, 21 Sep 2020 14:53:33 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AC13A0AE9 for ; Mon, 21 Sep 2020 14:53:32 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id q26so4813282uaa.12 for ; Mon, 21 Sep 2020 14:53:32 -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:content-transfer-encoding; bh=TB+3L4PbyYkqRz1eKqdBQzzuOnSrqf9bZcdh6cedYLA=; b=flW+4Br1Rfl+IKnJgukLSWdEmMnoNlU7aHfeoAXrq2svEmLLdSqfbHgjMEU6ZacHh7 E/P1Ws+JSyE6ElYFrsUNs60YQGHNC/FHKWBxjdzMDRzHmeLbGX6OwlQMAq+kxhEtVzQS 62svY+8CzrLem3/EVOqCOBhOrHIbvUZPIcv47WIW2W8CifDRn+qhOknHkCzmn3FwUHdS hfg8ogyeYEKdSN8b6N/FRgdfqp/KRaQsOsg5vKG4PkCQ64NShJU5lHOA153NSqJLefYG 48sRDbd+QENRKDA1UyzpyZCKpxTAFX+t1sD16inl0Mphj02s12AHEMcE74BwFKVceBBJ EQbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TB+3L4PbyYkqRz1eKqdBQzzuOnSrqf9bZcdh6cedYLA=; b=hXeOhZBizTE1V3yfc0/S8+rLmTDaJR6Rp7JTFvrYaBx8e936FRujqk7WCBV4dDQK8W rtjs2GSnYguejDoehIlht9VqSNTnaoh7WdBg1jA5Exs4EdcFA/eIFmgCBV3YCtb4NCjt Bc6eljXAqKxPpuo4PVOMf8aT4ecDTIpWAbBdpJQHyluyfWIhqUyVYHCbPL4dkRvYCCQN NwppSt63/xyJvdZPBiXaPsbnEAhXQtXWVZwNPnW15v+oU6iuQWFgREhQPuqG73t8j8b0 za2lcfMVZeDsBNETkbjJK+9bZS86kcK0uroyMuq+pQo48mmrkMdglsKFSbnBzT+77Ngo a6ZA== X-Gm-Message-State: AOAM533Q7mr/XqEXtglAFtO+23hu1K7an4fkXSUaonGNn+2WQDm9Yn+I R3EWwqBpWLoL+Jj0R/rHW77SYT/5y7qarUAQHcn6ikGeqt56mw== X-Google-Smtp-Source: ABdhPJwvWuQVMNUnXpJJCsHZQVHfB8ov7lgqOk9xwJ6fB1UkOkClr1Edw08aR/DDWgJsDx+88S5sUOCk7Mk/T97s+bg= X-Received: by 2002:ab0:145:: with SMTP id 63mr1419026uak.83.1600725211563; Mon, 21 Sep 2020 14:53:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Mon, 21 Sep 2020 14:52:55 -0700 Message-ID: To: Yi Huang Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] A review of draft-ietf-tcpm-rack-10 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, 21 Sep 2020 21:53:35 -0000 On Sun, Sep 20, 2020 at 6:16 PM Yi Huang wrote: > > Hi, > > I reviewed the latest version of RACK-TLP draft and have a few comments/q= uestions. > > 1. In section 5.1, "Segment.retransmitted is true if it was retransmitted= in the most recent transmission." > There are also pseudo-code explaining how retransmitted flag is set. AFAI= CT, retransmitted is set if the segment is ever retransmitted since the fla= g is never reset. Is this variable supposed to mean ever retransmitted? Thanks for catching that. Segment.retransmitted MUST be reset upon a (re)transmission so it does not ever-retransmitted (i.e. it's only meant for the very last transmission) RACK_transmit_data(Segment): Segment.xmit_ts =3D Now() Segment.lost =3D FALSE Segment.retransmitted =3D FALSE RACK_retransmit_data(Segment): RACK_transmit_data(Segment) Segment.retransmitted =3D TRUE > > 2. In section 6.2, p14, > " If the sender has not yet observed any reordering based on the > previous step, then RACK prioritizes quick loss recovery by using > setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds > DupThresh, or during loss recovery. > > Aside from those special conditions, RACK starts with a conservative > reordering window of RACK.min_RTT/4. This value was chosen because > Linux TCP used the same factor in its implementation to delay Early > Retransmit [RFC5827] to reduce spurious loss detections in the > presence of reordering, and experience showed this worked reasonably > well [DMCG11]." > > If I understand this correctly, if no reordering observed, TCP should sti= ll enter loss recovery when DupACK >=3D DupThresh (RFC6675). If reordering = has been seen, this RFC6675 rule is not honored and TCP only enters loss re= covery when RACK detects loss? I think it would be great to clarify this in= the spec. Your understanding is correct. will this text revision improves clarity" "" If no reordering has been observed based on the previous step, the sender enters Fast Recovery when the number of SACKed segments exceeds DupThresh (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon entering and during the loss recovery. Otherwise if some reordering has been observed, RACK does not honor RFC6675 rule and starts with a conservative RACK.reo_wnd of RACK.min_RTT/4. This .... reasonably well [DMCG11]. "" > " If the sender has not yet observed any reordering based on the > previous step, then RACK prioritizes quick loss recovery by using > setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds > DupThresh, or during loss recovery. > > Aside from those special conditions, RACK starts with a conservative > reordering window of RACK.min_RTT/4. This value was chosen because > Linux TCP used the same factor in its implementation to delay Early > Retransmit [RFC5827] to reduce spurious loss detections in the > presence of reordering, and experience showed this worked reasonably > well [DMCG11]." > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Window P= robe (ZWP) timer". will fix thanks > > Thanks, > > Yi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Sep 21 15:18:05 2020 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 0A7143A0BC4 for ; Mon, 21 Sep 2020 15:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=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 o-2VH0hiewr0 for ; Mon, 21 Sep 2020 15:18:03 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650133.outbound.protection.outlook.com [40.107.65.133]) (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 512A23A0BC1 for ; Mon, 21 Sep 2020 15:18:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kIPtm4Fuy/sDaDb/LVfK5Ox2cho4MhxefGcvH6n3vf7Sa4OBcV47Z+SyvKPiK7CVFGqiarstqxGwPOduvkfX56h6fjx2/OErZspFGiHn2sx56/kCuIVDD6cTi1DVpcw8AsugGJA28fJoSHFy63MmRDWy+Jwpp7yWy0oWctdLFgtEL4zEUmkfDTpk1DWxm9QghiK85yy28Aa4F79XIpXLuK5QPi7ttsF9xFi7RXBYgyAnVpFkJ66bru9OaYFEOG3dOkKTS5YC8E3+B+eOOB8ZgXKtq2fK58X3ZNuA3ZUu4v5gJtbTBfpcocg3A040NCduBFBmaHH+K9CICmKAf0AhKw== 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=YFcTwh3M5mMO5heBJoS9v/mn1hGWAZGllfAqU5nDcmk=; b=V8OobSQH8VgZ+BxJt2izZKjOEnAHq+QTTgCAbOZgVcLFIXbHMuQxCzNge/yQJ/1J++qkEub7KOuneblHq5YYPyXuQVgRHzwqI3D7nB7vU+e7UEQZvXHLaTy/lgB/qagMJ3zoFo2RV91LX0+36HGA1R1EYqnVnd5JyqOcZfIQedHDMQxQZU6zEQbji2w4xmoZtxj7djvhx3aMAO3dzTz4bsJTNVOnx27BDeVOyjK6BWnz6IzWOkuKO5M2lOtQFmecKAgExfJ363cz6V69Nx2QiYnqLWwYx+LYiDAReow2v6II1vRrSKiWMqgCdKoJYc+cWX6/djd+N2jDKBzPEmpEjA== 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=YFcTwh3M5mMO5heBJoS9v/mn1hGWAZGllfAqU5nDcmk=; b=BPg1s1ofsCFg6YzqMAPWKJUSuDXjJ+1DnD5pzicrUgBNqG/JLokRPgHsaPM+auz39pMZI3PM/kzkLgQ8XptU8yQrDPt7spolqOxIeuEIDESpTbDPc2iIwucsO4sQkG1ysKqbqtRPM3x9p1MnA0G5V/WeY4OLsCGP4P/pznlGctI= Received: from (2603:10b6:408:a1::17) by BN3PR00MB0066.namprd00.prod.outlook.com (2a01:111:e400:c5f3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3442.0; Mon, 21 Sep 2020 22:18:00 +0000 Received: from BN8PR00MB0865.namprd00.prod.outlook.com ([fe80::e413:e863:934e:7eb2]) by BN8PR00MB0865.namprd00.prod.outlook.com ([fe80::e413:e863:934e:7eb2%6]) with mapi id 15.20.3442.000; Mon, 21 Sep 2020 22:18:00 +0000 From: Yi Huang To: Yuchung Cheng , Yi Huang CC: "tcpm@ietf.org" Thread-Topic: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-10 Thread-Index: AdaPr6OwWgwL5n+GTQqpxYshj1XvWgAsevyAAABE1+A= Date: Mon, 21 Sep 2020 22:18:00 +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=deb7b475-7ce5-410a-88f8-3d03627f0d68; 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=2020-09-21T22:00:37Z; 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:ac89:6c9a:d6c0:4681:a17f] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 80851948-954f-4a9f-e626-08d85e7c3382 x-ms-traffictypediagnostic: BN3PR00MB0066: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Cf8uL8q4ORTQwfFJuYRPXyT6LUueNXEUTtmuiBrq63MkIEC42L+rT5Oj9BZMgflyKd8vBlHQTO7K+VhE2SUUbvaOa3o82vbmhC3aeUB2DMr+E8O/dga5kJsnwdfSK2dHH6pvrxm8S4lPdgawXGlJvCHzKRotEJvlLP++FWxZtUZ8hV7kuK+oycTMsP2y2S6mPG9AEHDwirV1pDtXqGtE+1hYBHD7CbwIw5tspoSvDS02Vhaa6eVLK7i3uDrYWLdaqf6yeEEW3XRWqekFqvS3QNCNChTogZMz2ricVwPyx68+vfkxl3HpkiHmAuBe30bhWV9izE3BFjzCgOESl3YVNwLjK+8q/hgj2Coa0/W3ysop9Q4faZ6MKtvV6iDbwGqsW5EIgZUckHoTht5e7xP7Hg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR00MB0865.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(136003)(396003)(376002)(39860400002)(478600001)(71200400001)(9686003)(8676002)(53546011)(5660300002)(110136005)(316002)(7696005)(55016002)(83380400001)(186003)(6506007)(83080400001)(8936002)(10290500003)(52536014)(966005)(66446008)(76116006)(33656002)(4326008)(64756008)(66556008)(66946007)(66476007)(8990500004)(2906002)(82960400001)(82950400001)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: rwglgf+FM8KBDFK2iTYKUw/+z80b8/w05rV+57GwAhYtL2kLm7m3sn3Llp2IYY87NooQcsXUgGIIiBbLqt2DYFQYd9xd1FQBve1ydxs52RADFgRjolWUTgrddFf5SRHO4anFQtkCIhxa4qKR6VTwzPisZ2mLULCvLPL8D8qEaJOpHhfeJ5p2XkBwCcokjCu0z/H3RrLwyknUOmNm6zNwRbOAHhlQZ59SXS0nas7JwSIvHEWLclrvQ1NDEi/S4lJQJoM/AmLDhXYoRbTeYa+03/QiyY4LMTFBylH78nfUGsbDdfpL+OID5IlN21DCnuGmzoi7aESlyvGIn1IJZbqPMjDNgOQKa7WunJvJq/+JOWilwPsCYpE79kdzvq/T98xjbMBmet2hdUPdlzCNXyUJN4km/5d4aB0jazKuUDp2OykggdZTNBuWzwYx4Y/KFtaamXb9vJaTZLDRPiezOY33T5DzUhqBZLbOTjMNeCoI2UXE6EaDdnrKl+04/KMcaBk9Nau/eDum0rj1MZJ3bYrYdS4/AD2lPjieEClg/YxqWL4f7+UnobzVii55RCAs6IQXPtyJGgW2Xucre20RK8tIJcjC128VdiXV9x/W/ij0t8aZycnnUOMZ5tnEzKZbRgMt7BDGMHC69PqN2iMj4jsqXgKSeToH6UcnDBXMVlMnaoDxNoCXMLTJC+LstAO5pZ6hn0/aESYWH+vjmkx7Tx8Tqg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR00MB0865.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80851948-954f-4a9f-e626-08d85e7c3382 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 22:18:00.5407 (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: /hbwlonKJ39WwG50t3ELK6j0FxhIWcfCfQV0aHsURRtfDxgcm0YdTqx19wSvx5aBhJXnV2CMqE8JUSonbcMx1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR00MB0066 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 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, 21 Sep 2020 22:18:05 -0000 Thanks Yuchung, I responded inline. -----Original Message----- From: tcpm On Behalf Of Yuchung Cheng Sent: Monday, September 21, 2020 2:53 PM To: Yi Huang Cc: tcpm@ietf.org Subject: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-10 On Sun, Sep 20, 2020 at 6:16 PM Yi Huang wrote: >> >> Hi, >> >> I reviewed the latest version of RACK-TLP draft and have a few comments/= questions. >> >> 1. In section 5.1, "Segment.retransmitted is true if it was retransmitte= d in the most recent transmission." >> There are also pseudo-code explaining how retransmitted flag is set. AFA= ICT, retransmitted is set if the segment is ever retransmitted since the fl= ag is never reset. Is this variable supposed to mean ever retransmitted? >Thanks for catching that. Segment.retransmitted MUST be reset upon a (re)t= ransmission so it does not ever-retransmitted (i.e. it's only meant for the= very last transmission) > RACK_transmit_data(Segment): > Segment.xmit_ts =3D Now() > Segment.lost =3D FALSE > Segment.retransmitted =3D FALSE > RACK_retransmit_data(Segment): > RACK_transmit_data(Segment) > Segment.retransmitted =3D TRUE Sorry, I still don't quite get it. RACK_transmit_data is for previously uns= ent data (aka new data) right? If so, it will be only called once for a giv= en segment. Then, RACK_retransmit_data only sets it to TRUE. So where do we= reset it? Looks like we still just initialize it to FALSE and set it to TR= UE upon retransmission. >> >> 2. In section 6.2, p14, >> " If the sender has not yet observed any reordering based on the >> previous step, then RACK prioritizes quick loss recovery by using >> setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds >> DupThresh, or during loss recovery. >> >> Aside from those special conditions, RACK starts with a conservative >> reordering window of RACK.min_RTT/4. This value was chosen because >> Linux TCP used the same factor in its implementation to delay Early >> Retransmit [RFC5827] to reduce spurious loss detections in the >> presence of reordering, and experience showed this worked reasonably >> well [DMCG11]." >> >> If I understand this correctly, if no reordering observed, TCP should st= ill enter loss recovery when DupACK >=3D DupThresh (RFC6675). If reordering= has been seen, this RFC6675 rule is not honored and TCP only enters loss r= ecovery when RACK detects loss? I think it would be great to clarify this i= n the spec. > Your understanding is correct. will this text revision improves clarity" > "" > If no reordering has been observed based on the previous step, the sender= enters Fast Recovery when the number of SACKed segments exceeds DupThresh = (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon entering and d= uring the loss recovery. > Otherwise if some reordering has been observed, RACK does not honor RFC6675 rule and starts with a conservative RACK.reo_wnd of RACK.min_RTT/4.= This .... reasonably well [DMCG11]. > "" Yeah, that's pretty clear now. > " If the sender has not yet observed any reordering based on the > previous step, then RACK prioritizes quick loss recovery by using > setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds > DupThresh, or during loss recovery. > > Aside from those special conditions, RACK starts with a conservative > reordering window of RACK.min_RTT/4. This value was chosen because > Linux TCP used the same factor in its implementation to delay Early > Retransmit [RFC5827] to reduce spurious loss detections in the > presence of reordering, and experience showed this worked reasonably > well [DMCG11]." > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Window P= robe (ZWP) timer". will fix thanks > > Thanks, > > Yi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40micro > soft.com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab2d7c > d011db47%7C1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq8szgH > x43Hsfwlrog%2BZxQwJyiq0%3D&reserved=3D0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40microsoft.c= om%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq8szgHx43Hsfwlrog%2B= ZxQwJyiq0%3D&reserved=3D0 From nobody Mon Sep 21 16:12:41 2020 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 D7A423A0D25 for ; Mon, 21 Sep 2020 16:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eamSENeBTQw5 for ; Mon, 21 Sep 2020 16:12:38 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 21A463A0D29 for ; Mon, 21 Sep 2020 16:12:37 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id v5so4873338uau.10 for ; Mon, 21 Sep 2020 16:12:37 -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:content-transfer-encoding; bh=Bl7fLbLnoOBEFvrV+z5j8hcFAey+L/iytP9CkqC5l8Y=; b=KCc4zsciEdcwtbX7KhpzRhICzqSHwP+GFzpc8ft/9LnUKAi5kJHsyqC68rbGc9khmO 8AzqhtpjfXC9KAXteWvOFZaA1fSqlFEs/ERsojvnmrlpxt5/pTO9BlSo8Q6CphthUHJE jMS+mn9NHqLe06BG9Vpu6Qs/SpcWG/BhgSLUY+9FfIXiCBY94z9DtKzBgSe6eS8CpYwm 9K2Zrnwh1lXRAfZueSCHrnmrptfeizuwTROfUU8vjCGn7SWeLXGAdHZVJiuXdp9GajGV GBUN/5RxzHzT9iqCheFS0Y2PrUhh8t+5P+Ie8+JmQg3vnyb07ZxwA82iRCB9aJMj03J7 bzFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Bl7fLbLnoOBEFvrV+z5j8hcFAey+L/iytP9CkqC5l8Y=; b=ZsrCJdx3wOew/ysB9WNZyx+MbCKR29M819+rBUmE4CLNgkG3TjhXfrfx9qnP/5Ga7K KsELUwAFiLaDCxq74b+IcR53zKmfab8uQ/EbIJONl8hFXfiXaMkdQO4bcJcibYL4863c YZI8fCgOY1eTouDIA3w8k1qz2lTuRWOOtq2OYdadrnAwK7KV98rZLxLSzqPrrMv15ReF OhR0rc77I7hULCnzvLABFOB7wz3PCQsriAPpDeM9Hq0fozpIuLZPHoVhgW8Bjf1YhiZT wIVsormKeHK236C9/LmxAVaPT4Yrpya1CQ1P9B0Ida2xguDvBSeC0EIXOIe4pfPmk3/z bzmg== X-Gm-Message-State: AOAM5305P6cJYoxQ2ZEwj+stFO4S3Ltg6e7NULe9WaqDcyqAtQh3iZVB s1TfsoZ9WzBwGrrzUe+TwQRV9v/nhHmRMTQPpIen+OrH5NQ= X-Google-Smtp-Source: ABdhPJwEeayrbf3UTq0XpwBlDv5S7xHbfMAyxLEvAwhnEtl+fa1pR/wbR8BzneyL2NY1jELsM/1F3Uw9jeVfPABkmYw= X-Received: by 2002:ab0:6d90:: with SMTP id m16mr1686250uah.112.1600729956837; Mon, 21 Sep 2020 16:12:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Mon, 21 Sep 2020 16:12:00 -0700 Message-ID: To: Yi Huang Cc: Yuchung Cheng , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 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, 21 Sep 2020 23:12:40 -0000 On Mon, Sep 21, 2020 at 3:18 PM Yi Huang wrote: > > Thanks Yuchung, I responded inline. > > -----Original Message----- > From: tcpm On Behalf Of Yuchung Cheng > Sent: Monday, September 21, 2020 2:53 PM > To: Yi Huang > Cc: tcpm@ietf.org > Subject: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-10 > > On Sun, Sep 20, 2020 at 6:16 PM Yi Huang wrote: > >> > >> Hi, > >> > >> I reviewed the latest version of RACK-TLP draft and have a few comment= s/questions. > >> > >> 1. In section 5.1, "Segment.retransmitted is true if it was retransmit= ted in the most recent transmission." > >> There are also pseudo-code explaining how retransmitted flag is set. A= FAICT, retransmitted is set if the segment is ever retransmitted since the = flag is never reset. Is this variable supposed to mean ever retransmitted? > >Thanks for catching that. Segment.retransmitted MUST be reset upon a (re= )transmission so it does not ever-retransmitted (i.e. it's only meant for t= he very last transmission) > > > RACK_transmit_data(Segment): > > Segment.xmit_ts =3D Now() > > Segment.lost =3D FALSE > > Segment.retransmitted =3D FALSE > > > RACK_retransmit_data(Segment): > > RACK_transmit_data(Segment) > > Segment.retransmitted =3D TRUE > > Sorry, I still don't quite get it. RACK_transmit_data is for previously u= nsent data (aka new data) right? If so, it will be only called once for a g= iven segment. Then, RACK_retransmit_data only sets it to TRUE. So where do = we reset it? Looks like we still just initialize it to FALSE and set it to = TRUE upon retransmission. Apologize for this confusion. I now see better how the text and code confuse you. Segment.retransmitted is meant to reflect whether the most recent send is a retransmission or not. But since a segment can be (only) retransmitted N times consecutively, the flag is sticky throughout once set. To avoid future confusion, how about having two separate routines. /* Send newly unsent data */ RACK_transmit_new_data(Segment): Segment.xmit_ts =3D Now() Segment.lost =3D FALSE Segment.retransmitted =3D FALSE /* Retransmit previously sent data */ RACK_retransmit_data(Segment) Segment.xmit_ts =3D Now() Segment.lost =3D FALSE Segment.retransmitted =3D TRUE > > >> > >> 2. In section 6.2, p14, > >> " If the sender has not yet observed any reordering based on the > >> previous step, then RACK prioritizes quick loss recovery by using > >> setting RACK.reo_wnd to 0 when the number of SACKed segments exceed= s > >> DupThresh, or during loss recovery. > >> > >> Aside from those special conditions, RACK starts with a conservativ= e > >> reordering window of RACK.min_RTT/4. This value was chosen because > >> Linux TCP used the same factor in its implementation to delay Early > >> Retransmit [RFC5827] to reduce spurious loss detections in the > >> presence of reordering, and experience showed this worked reasonabl= y > >> well [DMCG11]." > >> > >> If I understand this correctly, if no reordering observed, TCP should = still enter loss recovery when DupACK >=3D DupThresh (RFC6675). If reorderi= ng has been seen, this RFC6675 rule is not honored and TCP only enters loss= recovery when RACK detects loss? I think it would be great to clarify this= in the spec. > > > Your understanding is correct. will this text revision improves clarity= " > > "" > > If no reordering has been observed based on the previous step, the send= er enters Fast Recovery when the number of SACKed segments exceeds DupThres= h (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon entering and= during the loss recovery. > > > Otherwise if some reordering has been observed, RACK does not honor > RFC6675 rule and starts with a conservative RACK.reo_wnd of RACK.min_RTT/= 4. This .... reasonably well [DMCG11]. > > "" > > Yeah, that's pretty clear now. > > > " If the sender has not yet observed any reordering based on the > > previous step, then RACK prioritizes quick loss recovery by using > > setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds > > DupThresh, or during loss recovery. > > > > Aside from those special conditions, RACK starts with a conservative > > reordering window of RACK.min_RTT/4. This value was chosen because > > Linux TCP used the same factor in its implementation to delay Early > > Retransmit [RFC5827] to reduce spurious loss detections in the > > presence of reordering, and experience showed this worked reasonably > > well [DMCG11]." > > > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Window= Probe (ZWP) timer". > will fix thanks > > > > Thanks, > > > > Yi > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40micr= o > > soft.com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab2d7c > > d011db47%7C1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq8szg= H > > x43Hsfwlrog%2BZxQwJyiq0%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40microsoft= .com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq8szgHx43Hsfwlrog%= 2BZxQwJyiq0%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Sep 21 16:37:42 2020 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 9F9943A0E84 for ; Mon, 21 Sep 2020 16:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=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 DI3FLWkd7CSH for ; Mon, 21 Sep 2020 16:37:38 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650102.outbound.protection.outlook.com [40.107.65.102]) (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 A57103A0E7F for ; Mon, 21 Sep 2020 16:37:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lquz/9ZuI4vslBTBATmpXcTQrb0FRW3dzsoagrwoXZHWYzV9T48P5sHY4xwvOw1JiXp2qRv/GQGYjF4pSUOUoRf7kO6pQ6CZJnJhTa/yu76DD16S+uewQA1MiSW6vTdPAbmG4/7PfB5r1PvhZ3mZMKOLLykKEEu5CSXB5TFBob3eF1PXka9J30URSmptjeUOjRMb+reNO2StuT0EqSB9jDko5YdB5GE59g8xdF+Hv0tdUv84onfrf5jxNoq+abZG+Xe7aTSee5JaLy27s31OduEVdMcaTeATm+UwBWi+e1yuKorbBnJIz0JkyjZMnZlyVW8XWleF6XSUXNzQVmNGZA== 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=R5r08U4RVarKlnx43GeUW11sdlvYtEkJB+8lRfEp99o=; b=mkeywDmbdl0/6dX2226Ndkngx3ftsl2XcR7QVMKoYnsNVDDXE6KI6l48n4N/sMMoBvMa35NhyCkWrHFeIu9D7baUhDlq1uPr1xgdjhVSq47BOsA6nDldgHc7fxOOWF9S9AP9/f7OmEJVuFTrbds0dztyXkC64gnZDjoEqFsK3kUb/gyH9Gn6N/7qVLcEQa2L//rCxpxFsE+fzxX73uf3Zczb3VdBonRWT6ZPm23S8Rs28YQo12zxEPTqS9lWOPEmxsh4xHZhn5T/p6WpQcPOaOM/37t4mkFABeVGlC4NfJlbGE+CAVdAILEni3NwlxaDAgwoy/043mTlLiZUAVvTxw== 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=R5r08U4RVarKlnx43GeUW11sdlvYtEkJB+8lRfEp99o=; b=e0huHH+cfIXVLou4nAxA265crAY70jNutXP4o5uJRZynhrarsInibg/PJd5J7fU07L6knfEf6n88jDqLBwrachSOMtDU5QFs59au1vqM38DX9ifoUTeMTR8N0qXdFccS9Lkax2hdT4eUEbNco8xV7WX79PALW5tcEn18XCN3jrU= Received: from (2603:10b6:5:21c::21) by DM5PR00MB0953.namprd00.prod.outlook.com (2603:10b6:3:fa::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3424.0; Mon, 21 Sep 2020 23:37:31 +0000 Received: from DM6PR00MB0732.namprd00.prod.outlook.com ([fe80::bca3:a1a3:376a:21f4]) by DM6PR00MB0732.namprd00.prod.outlook.com ([fe80::bca3:a1a3:376a:21f4%9]) with mapi id 15.20.3441.000; Mon, 21 Sep 2020 23:37:31 +0000 From: Praveen Balasubramanian To: Yuchung Cheng , Yi Huang CC: "tcpm@ietf.org" Thread-Topic: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 Thread-Index: AQHWkGy9VQoem/xjLESauVZ2rQvYSqlzvtwA Date: Mon, 21 Sep 2020 23:37:31 +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=8bf5ffff-789f-4c20-a85a-400ebcff5bd4; 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=2020-09-21T23:35:14Z; 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: [2001:4898:80e8:2:95d6:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 89c17b1e-090f-4085-c785-08d85e874f61 x-ms-traffictypediagnostic: DM5PR00MB0953: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Nl56mv/dC21dkYJouWnrvZpWoLFoXpFE5yaZIHyJ/vUTT5UYoR0UeQuh2T9dWcYxHdtcHibTvWbvuU3t7DP34FMrJHXwJqqCicI+BhCuWM1nd5LpwkWs/d9zpjss2wZJraO0QWmXAZkJUGD9I/jKeW90oNeq6tUV2CXVLiWkcYeTRxOPPmXR6lHBZQp/mrIPZLjBqwpy0z8Pc3jCoHAhg0Ht1sFWcw/U3dJsi++oX5vssPHGzpRQirYX+AaecKf7P/griOxnCvztjRZSzwAOExd9ViqeE2YFaxF92/sSDGapiEXOqNmXHhaTVKvYl2qmJ41FuMP46P52OA1Dn1G5tEaNvPzK/LfATEA/0hqFlUFCEqEKnNjtrEBr32x85Q/NcJXKNpOfaon+wju5qdkj0w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0732.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(346002)(136003)(376002)(366004)(66476007)(9686003)(55016002)(86362001)(66446008)(64756008)(7696005)(186003)(66556008)(66946007)(71200400001)(53546011)(6506007)(33656002)(76116006)(2906002)(110136005)(966005)(316002)(4326008)(8990500004)(5660300002)(8676002)(83380400001)(52536014)(82950400001)(82960400001)(8936002)(10290500003)(478600001)(83080400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 05ezmUw8Di3M9lTXccxsztU+0gbZHo5Oy1CoWEw1aqkebWGpogNehAytER0wijm1pi38LyyF9sqjC6Ey8Zmn2gJo26AUqXx7hrxEddp0yYMaTCpAfhXnHdLybfkbRlIl6spm41NXgHYO9EImFyc+7VCufgQzpLmF2WhMaSsehExi5EPzYji7ifGFz5t6Rud+4CBleDM9DJwbGiz/qh3zOjyDfGgPBpoiHw5KK3iBTw9t0+RYg/NQ2mLcEkSpudSGf3IIQ9JGyvkd+xH0Gj7y9P5QrOu5o4vV/SdgBqr6jJCaTTLGOnp/RD/Rqne5NOTUgIE5rxpFocG2jC4A3AutThQ2YmECPSE/KocFiIfSW20z2H6Tlqso0U4ZwQAW29FQRbp1uUm+bHyikGSUwZTaCjc93ow+67+93Ta3exJ5ktzZNLd+bs2ARRt9xQIq3bZCBxA/jO2XGoNk2i45+KiZD8777GSphllCRjNt03pTf5QOISIcXEA0uLAZ2YEXwwvJKKS9bE2eDdmdzANqOhU75rWfLWRSH2ULwGvcAOheODdukHlZqhpbxP/0u/2JVzEYwcWOiGEYogriDml6VpiZjPlmEDLyoxdMGmXW5NMZDqS89pxRvOHRhWFhHCmqVBA2NAYe6TcWCPHnF0APUL92qfMqxEyCVYWr8z4Y51cheWYHFoqGIqdWmUhZY0Q0Af2+b7mfWEUPSBpMeY3PhtiSJQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0732.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89c17b1e-090f-4085-c785-08d85e874f61 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 23:37:31.7104 (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: BVZ8Nx6y6DkFrQXzsCg5LbkqNKERtuf76zINbPe2fl0GbQoYuHmRP4KODk9p+MdGLYgH05yJe91Cn3TMcQBl+hbdwFkTEerIwuXeGPfbZ2U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0953 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 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, 21 Sep 2020 23:37:41 -0000 >> Segment.retransmitted is meant to reflect whether the most recent send i= s a retransmission or not The "most recent send" here is confusing. Why not just state that this refl= ects whether the segment was ever retransmitted? -----Original Message----- From: tcpm On Behalf Of Yuchung Cheng Sent: Monday, September 21, 2020 4:12 PM To: Yi Huang Cc: Yuchung Cheng ; tcpm@ietf.org Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 On Mon, Sep 21, 2020 at 3:18 PM Yi Huang wrote: > > Thanks Yuchung, I responded inline. > > -----Original Message----- > From: tcpm On Behalf Of Yuchung Cheng > Sent: Monday, September 21, 2020 2:53 PM > To: Yi Huang > Cc: tcpm@ietf.org > Subject: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-10 > > On Sun, Sep 20, 2020 at 6:16 PM Yi Huang wrote: > >> > >> Hi, > >> > >> I reviewed the latest version of RACK-TLP draft and have a few comment= s/questions. > >> > >> 1. In section 5.1, "Segment.retransmitted is true if it was retransmit= ted in the most recent transmission." > >> There are also pseudo-code explaining how retransmitted flag is set. A= FAICT, retransmitted is set if the segment is ever retransmitted since the = flag is never reset. Is this variable supposed to mean ever retransmitted? > >Thanks for catching that. Segment.retransmitted MUST be reset upon a=20 > >(re)transmission so it does not ever-retransmitted (i.e. it's only=20 > >meant for the very last transmission) > > > RACK_transmit_data(Segment): > > Segment.xmit_ts =3D Now() > > Segment.lost =3D FALSE > > Segment.retransmitted =3D FALSE > > > RACK_retransmit_data(Segment): > > RACK_transmit_data(Segment) > > Segment.retransmitted =3D TRUE > > Sorry, I still don't quite get it. RACK_transmit_data is for previously u= nsent data (aka new data) right? If so, it will be only called once for a g= iven segment. Then, RACK_retransmit_data only sets it to TRUE. So where do = we reset it? Looks like we still just initialize it to FALSE and set it to = TRUE upon retransmission. Apologize for this confusion. I now see better how the text and code confus= e you. Segment.retransmitted is meant to reflect whether the most recent se= nd is a retransmission or not. But since a segment can be (only) retransmit= ted N times consecutively, the flag is sticky throughout once set. To avoid= future confusion, how about having two separate routines. /* Send newly unsent data */ RACK_transmit_new_data(Segment): Segment.xmit_ts =3D Now() Segment.lost =3D FALSE Segment.retransmitted =3D FALSE /* Retransmit previously sent data */ RACK_retransmit_data(Segment) Segment.xmit_ts =3D Now() Segment.lost =3D FALSE Segment.retransmitted =3D TRUE > > >> > >> 2. In section 6.2, p14, > >> " If the sender has not yet observed any reordering based on the > >> previous step, then RACK prioritizes quick loss recovery by using > >> setting RACK.reo_wnd to 0 when the number of SACKed segments exceed= s > >> DupThresh, or during loss recovery. > >> > >> Aside from those special conditions, RACK starts with a conservativ= e > >> reordering window of RACK.min_RTT/4. This value was chosen because > >> Linux TCP used the same factor in its implementation to delay Early > >> Retransmit [RFC5827] to reduce spurious loss detections in the > >> presence of reordering, and experience showed this worked reasonabl= y > >> well [DMCG11]." > >> > >> If I understand this correctly, if no reordering observed, TCP should = still enter loss recovery when DupACK >=3D DupThresh (RFC6675). If reorderi= ng has been seen, this RFC6675 rule is not honored and TCP only enters loss= recovery when RACK detects loss? I think it would be great to clarify this= in the spec. > > > Your understanding is correct. will this text revision improves clarity= " > > "" > > If no reordering has been observed based on the previous step, the send= er enters Fast Recovery when the number of SACKed segments exceeds DupThres= h (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon entering and= during the loss recovery. > > > Otherwise if some reordering has been observed, RACK does not honor > RFC6675 rule and starts with a conservative RACK.reo_wnd of RACK.min_RTT/= 4. This .... reasonably well [DMCG11]. > > "" > > Yeah, that's pretty clear now. > > > " If the sender has not yet observed any reordering based on the > > previous step, then RACK prioritizes quick loss recovery by using > > setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds > > DupThresh, or during loss recovery. > > > > Aside from those special conditions, RACK starts with a conservative > > reordering window of RACK.min_RTT/4. This value was chosen because > > Linux TCP used the same factor in its implementation to delay Early > > Retransmit [RFC5827] to reduce spurious loss detections in the > > presence of reordering, and experience showed this worked reasonably > > well [DMCG11]." > > > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Window= Probe (ZWP) timer". > will fix thanks > > > > Thanks, > > > > Yi > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40mic > > ro=20 > > soft.com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab2d > > 7c=20 > > d011db47%7C1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq8sz > > gH > > x43Hsfwlrog%2BZxQwJyiq0%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micros > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrDx > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micros > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrDx > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.co= m%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd011db47%7C1= %7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrDxU%2FOrpC7ayXht= ZSuzM%2B2U%3D&reserved=3D0 From nobody Mon Sep 21 16:40:50 2020 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 80B0E3A0E8C for ; Mon, 21 Sep 2020 16:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=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 pJAjYT86JFqw for ; Mon, 21 Sep 2020 16:40:46 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650095.outbound.protection.outlook.com [40.107.65.95]) (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 BFB623A0E8A for ; Mon, 21 Sep 2020 16:40:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PTutwKqaiJ0SthWMkZBBKeoe15OGs8mXtfk7aNJWz9rJlbTRi/xsu3VAVivJ+yljO9X5YP7TdOrZM7eLG114u/ek/Enfo2dcJfQJ7OrazKDs0gn/IRugE/qGtnjX68Tsa/bu28WvBdmwtURmLfOIzca0FD424oUds8QeEQIRso3CCY1fHjN5SBuqvwszG1ueiR7bceR3triHB5lalotLa4zod91qLBIakc1pqyqBu3FUJ5UGupLXvG6m5tKs22V3JKJKCW28d7PmLayA4kos2FbOrp5BPVUY/UXDY5vdHABpFnvYGUmDVEwosgDDSZFEDx7AuzDE/rH+U1WySHwbfw== 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=nG3XQZD1a4Hbjr5U3W8qfmGjVT0Xn4ZCDZTkSaWyRC8=; b=Th8fc4hjQipeynbimJe7BC/Ri5Sl0DwAOgUdJOC/0Mjh8whb+rdRD4jjvyYwMn2exQN/E+dQImL+P7IHwR+uwjG17wkH5+sF0Yv8L61kKX1v9/jhAcznXoimr9siqxH0Jb0GiPakDPjNgMimsdgzQtzfF05wO07sPpAl7wG1ezyfHzw4LAu7V26xnvg0RnzUdekAI4pE21s1dixnA5C2hF/xEb3jrJUddPCtIvyyqSEy2NVsiwn/LzBE8QDGZHOUhhArjzWzT2xQNSIMedJSiwGPc+zuEctArAnRan2ahOfFiBrRNtKDc0TZeDicTNbkKT8IqGtvKDFNuR5uTduRNQ== 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=nG3XQZD1a4Hbjr5U3W8qfmGjVT0Xn4ZCDZTkSaWyRC8=; b=NCMq+YJ5muWFdkAZ6K8doEJa9WnyjsVPsslMw+OMk7tF0WC4iGOwVM0wWjNhWmPKCiDaU6jiOJhEIHuuPFB/5+cgg7CYbWSjP4OwTugTBArpjnu7TQNdLSzIw8fjt/pMPE5GI/anr3JZucs5Ys/MG67baIXIyPBIezykxDMhx/U= Received: from (2603:10b6:408:a1::17) by BN6PR00MB0259.namprd00.prod.outlook.com (2603:10b6:404:4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3431.0; Mon, 21 Sep 2020 23:40:35 +0000 Received: from BN8PR00MB0865.namprd00.prod.outlook.com ([fe80::e413:e863:934e:7eb2]) by BN8PR00MB0865.namprd00.prod.outlook.com ([fe80::e413:e863:934e:7eb2%6]) with mapi id 15.20.3442.000; Mon, 21 Sep 2020 23:40:35 +0000 From: Yi Huang To: Praveen Balasubramanian , Yuchung Cheng CC: "tcpm@ietf.org" Thread-Topic: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 Thread-Index: AQHWkGy2QE5uqNZZ5kWIKfV0G0hE7Klzv3+AgAAAbEA= Date: Mon, 21 Sep 2020 23:40:34 +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=8bf5ffff-789f-4c20-a85a-400ebcff5bd4; 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=2020-09-21T23:35:14Z; 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:ac89:6c9a:d6c0:4681:a17f] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 66366830-9aae-4bf3-3f17-08d85e87bcac x-ms-traffictypediagnostic: BN6PR00MB0259: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: t401hB/mDs7d81vHe237U3SqsNVrUrGPinBzcZIVN7rAfdRADG9sxmbFs41XcOB2MkgQcQ/+7DSngGmXRbDAeit6nDryiqCwOJrNpm1wVrMXBur6YxFyo7IqUkxUyql2N52vWp9Ar56cQ6NAkOy8RTNHwnB7YNfmGQpLqgPt7m8TRObKJYMdsec6ahAehl4sDSvpqh4KKWdW6k2cB3xxS81kKylN4+r5JDEIgyktgovQWG3/AWjxiu1bFxGONaFAPHiKSPpgxXJzqz60MuafwFS0t9lwuVpJFL2tRzdtfsvuLAB6tJbHit5P+4sZnSd3gwaWJmknsrM+o10a2EmIQPvQjlky5467zukpZl01DzmdnRsMof8NDZe4GXSlmb9n8Ve5jW7XEYyioU+e3azzeQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR00MB0865.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(366004)(136003)(376002)(346002)(86362001)(316002)(186003)(8990500004)(2906002)(53546011)(6506007)(55016002)(5660300002)(76116006)(66476007)(966005)(66556008)(66946007)(83380400001)(110136005)(4326008)(33656002)(64756008)(66446008)(52536014)(8676002)(82960400001)(10290500003)(82950400001)(83080400001)(478600001)(9686003)(71200400001)(7696005)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: cTTNgKxXSjKuDPYMQNgS+OXN2nVmRg1KMWpjC0G5Hl11N73CZ3Ke+lZA3oJVYND/RtrM11/HoBEW+aqxUkXoZwp7nqkQNWK71zouRPDFM1If+a20cGUY8kiydG/YaFqIWt2pDVMdO38KgVlv9ye5kvvDW/AV+oxEwFXtdJ2OwWXsWrDKDUyTpGXK2gWFdfXeiTFv6jEZx/NYO5li4k15KHDxcytRg47Ct7YujbNiw2GXxyM8/2/tgbyP5JKurSdZwD6LDqmC4KQ7DJ4zAqnUFhsd8OGoESAfL6rvkZ6APsCXta1PI+ubS/uwElmgWAkD8/rdVWf5J7HtsOl1c/NzTqgkrr9gttMYKbXI5rxFu+eEPYQxm81Oyw++KQ+Srv2bboVoxcxq+fR5gMUFPEG6eStYuIjn2zkaiMo+m9HjTxWiSyaDbXUECXhOkdrrl4L4N/bT7YWaHSssv7U7hcyhzcFhlkOEj92vHmvZJfybj3LXCstOqYWK779kbW0T6R2z4hNcctxaEseCGobp1V3CPB7W/8fgWMoIr4KsiMC4VzNDEYQ/OU/18IJD/tahN1YFv7p4v6uRpL/n2n7DZXK9EfhGg6+mpNTtH+3CZCZp8RTNv9VNFu88pm1Sj4cDmsRILsnFcid0A5n4WYxg0egzl5gg1eoQr6rs/H4Hq3N8QLSxMzQEnA9tPgx3i4oclrhVbmzIoZ2mPFPOgi8q/p1rJA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR00MB0865.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66366830-9aae-4bf3-3f17-08d85e87bcac X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 23:40:35.0197 (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: 8SxyrN8tw55kmjCngAhBB3sZEsbt1a1R0ex2ULv3HJgq6OrSnFsEG2OHY0GneoxwGqVihdlWCvhtfPCyH9sykQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR00MB0259 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 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, 21 Sep 2020 23:40:49 -0000 The new pseudocode looks great and Praveen already asked what I wanted to a= sk. It seems to be more accurate to call it ever retransmitted. -----Original Message----- From: Praveen Balasubramanian =20 Sent: Monday, September 21, 2020 4:38 PM To: Yuchung Cheng ; Yi Huang Cc: tcpm@ietf.org Subject: RE: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 >> Segment.retransmitted is meant to reflect whether the most recent=20 >> send is a retransmission or not The "most recent send" here is confusing. Why not just state that this refl= ects whether the segment was ever retransmitted? -----Original Message----- From: tcpm On Behalf Of Yuchung Cheng Sent: Monday, September 21, 2020 4:12 PM To: Yi Huang Cc: Yuchung Cheng ; tcpm@ietf.org Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 On Mon, Sep 21, 2020 at 3:18 PM Yi Huang wrote: > > Thanks Yuchung, I responded inline. > > -----Original Message----- > From: tcpm On Behalf Of Yuchung Cheng > Sent: Monday, September 21, 2020 2:53 PM > To: Yi Huang > Cc: tcpm@ietf.org > Subject: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-10 > > On Sun, Sep 20, 2020 at 6:16 PM Yi Huang wrote: > >> > >> Hi, > >> > >> I reviewed the latest version of RACK-TLP draft and have a few comment= s/questions. > >> > >> 1. In section 5.1, "Segment.retransmitted is true if it was retransmit= ted in the most recent transmission." > >> There are also pseudo-code explaining how retransmitted flag is set. A= FAICT, retransmitted is set if the segment is ever retransmitted since the = flag is never reset. Is this variable supposed to mean ever retransmitted? > >Thanks for catching that. Segment.retransmitted MUST be reset upon a=20 > >(re)transmission so it does not ever-retransmitted (i.e. it's only=20 > >meant for the very last transmission) > > > RACK_transmit_data(Segment): > > Segment.xmit_ts =3D Now() > > Segment.lost =3D FALSE > > Segment.retransmitted =3D FALSE > > > RACK_retransmit_data(Segment): > > RACK_transmit_data(Segment) > > Segment.retransmitted =3D TRUE > > Sorry, I still don't quite get it. RACK_transmit_data is for previously u= nsent data (aka new data) right? If so, it will be only called once for a g= iven segment. Then, RACK_retransmit_data only sets it to TRUE. So where do = we reset it? Looks like we still just initialize it to FALSE and set it to = TRUE upon retransmission. Apologize for this confusion. I now see better how the text and code confus= e you. Segment.retransmitted is meant to reflect whether the most recent se= nd is a retransmission or not. But since a segment can be (only) retransmit= ted N times consecutively, the flag is sticky throughout once set. To avoid= future confusion, how about having two separate routines. /* Send newly unsent data */ RACK_transmit_new_data(Segment): Segment.xmit_ts =3D Now() Segment.lost =3D FALSE Segment.retransmitted =3D FALSE /* Retransmit previously sent data */ RACK_retransmit_data(Segment) Segment.xmit_ts =3D Now() Segment.lost =3D FALSE Segment.retransmitted =3D TRUE > > >> > >> 2. In section 6.2, p14, > >> " If the sender has not yet observed any reordering based on the > >> previous step, then RACK prioritizes quick loss recovery by using > >> setting RACK.reo_wnd to 0 when the number of SACKed segments exceed= s > >> DupThresh, or during loss recovery. > >> > >> Aside from those special conditions, RACK starts with a conservativ= e > >> reordering window of RACK.min_RTT/4. This value was chosen because > >> Linux TCP used the same factor in its implementation to delay Early > >> Retransmit [RFC5827] to reduce spurious loss detections in the > >> presence of reordering, and experience showed this worked reasonabl= y > >> well [DMCG11]." > >> > >> If I understand this correctly, if no reordering observed, TCP should = still enter loss recovery when DupACK >=3D DupThresh (RFC6675). If reorderi= ng has been seen, this RFC6675 rule is not honored and TCP only enters loss= recovery when RACK detects loss? I think it would be great to clarify this= in the spec. > > > Your understanding is correct. will this text revision improves clarity= " > > "" > > If no reordering has been observed based on the previous step, the send= er enters Fast Recovery when the number of SACKed segments exceeds DupThres= h (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon entering and= during the loss recovery. > > > Otherwise if some reordering has been observed, RACK does not honor > RFC6675 rule and starts with a conservative RACK.reo_wnd of RACK.min_RTT/= 4. This .... reasonably well [DMCG11]. > > "" > > Yeah, that's pretty clear now. > > > " If the sender has not yet observed any reordering based on the > > previous step, then RACK prioritizes quick loss recovery by using > > setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds > > DupThresh, or during loss recovery. > > > > Aside from those special conditions, RACK starts with a conservative > > reordering window of RACK.min_RTT/4. This value was chosen because > > Linux TCP used the same factor in its implementation to delay Early > > Retransmit [RFC5827] to reduce spurious loss detections in the > > presence of reordering, and experience showed this worked reasonably > > well [DMCG11]." > > > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Window= Probe (ZWP) timer". > will fix thanks > > > > Thanks, > > > > Yi > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40mic > > ro > > soft.com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab2d > > 7c > > d011db47%7C1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq8sz > > gH > > x43Hsfwlrog%2BZxQwJyiq0%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micros > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrDx > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micros > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrDx > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40microsoft.c= om%7Cd3da167125f14f08fc9f08d85e875607%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C637363282644029020&sdata=3DmsvNOdkbMtyFfB5pep34eo%2BMdKiDh73hVF= GX503kgjA%3D&reserved=3D0 From nobody Tue Sep 22 17:36:56 2020 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 BCD4C3A0906 for ; Tue, 22 Sep 2020 17:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm1CF-FFNxiG for ; Tue, 22 Sep 2020 17:36:51 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 637123A0128 for ; Tue, 22 Sep 2020 17:36:51 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id 5so11416941vsu.5 for ; Tue, 22 Sep 2020 17:36:51 -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:content-transfer-encoding; bh=Z8sVggekdklMbg1N0MKxaZEBSxfO+jPkHZ+m/s5R07k=; b=DrvfJ6I52t8CAtMkehbSrK2BU/48hFsdsx6Kaq4Sae139qO5lnyFj0rwKjMI/yZKBS S0vQaqpDcFneEG8er0Sl3CE1uz1WzsNCK72PoPqkgEjGR9YiMKO+7okdFyV0wO7Q17ia jvwR3L6ZqE29ymuiyC1gaNSbIK7ag1l734qvXHEFa70Zl+rKMkKsvcdD47t4GacdCiR8 tqJfOS1JZHhtcRLFGYMLmWAO5iBUcegrPTf8xcBn6SM/uWWVmUDGa7lcrdu/Mef90KrW defbvIkOz/xX7ssV0VmKEtOTigA4HWCFL5yVwS0p3PwvgJbuYmoCQoywr5rwUTUJk2o5 +bUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Z8sVggekdklMbg1N0MKxaZEBSxfO+jPkHZ+m/s5R07k=; b=N68VtJwfehHYl+E1WgCrJuJ+KrvoGKytOPfCCgH3TMXNXMWqvC5+DMbepXDgkWDaen QE1XfHhNsZLWvyM8bKItS1AjNAIVq2s4Ami+gScVll8lAtJE91NzQNK+9VF5kRV4Msrm nscJDmYZq7VBSf9to65K3BBc2LPpmoAzyYGtF3Dhv6dsvwethHi7Aemf6aMVAw7IvsX/ yUEMykiheummY+Ak3mKYl73IDivCb27k3VM6/wm3cg+VlkuEOtdP+Jp+cdJmosPv2IRI OqvbyfgEGoFd+X2erLNVVplUhRXMecmR1b22mchlSJFKvlNWkQkWOU+CmiAb7swfm+0m XLxQ== X-Gm-Message-State: AOAM5332X8ZjCGBYTZkDetZjnjDFhUY/3sC7v0nQrGE2raMJA325D6uu ahfj7rP43FMhmXK1gMxD1WoglyOzeTnUjEj1pHaBUw== X-Google-Smtp-Source: ABdhPJzGAVk55M1tVSYYBxgSzkc5zre7LKUTeUA42xZkG+SNZtZKRWCIQi9iVFZ0z6SvIbQ3/9HIN75tWHKlcF/4OTg= X-Received: by 2002:a67:d00a:: with SMTP id r10mr5649164vsi.12.1600821409984; Tue, 22 Sep 2020 17:36:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Tue, 22 Sep 2020 17:36:13 -0700 Message-ID: To: Yi Huang Cc: Praveen Balasubramanian , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 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, 23 Sep 2020 00:36:55 -0000 Hi Yi and Praveen, Neal and I are auditing the algorithm in full on this state variable change. Will get back in a day or two. On Mon, Sep 21, 2020 at 4:40 PM Yi Huang wrote: > > The new pseudocode looks great and Praveen already asked what I wanted to= ask. It seems to be more accurate to call it ever retransmitted. > > -----Original Message----- > From: Praveen Balasubramanian > Sent: Monday, September 21, 2020 4:38 PM > To: Yuchung Cheng ; Yi Huang > Cc: tcpm@ietf.org > Subject: RE: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 > > >> Segment.retransmitted is meant to reflect whether the most recent > >> send is a retransmission or not > The "most recent send" here is confusing. Why not just state that this re= flects whether the segment was ever retransmitted? > > -----Original Message----- > From: tcpm On Behalf Of Yuchung Cheng > Sent: Monday, September 21, 2020 4:12 PM > To: Yi Huang > Cc: Yuchung Cheng ; tcpm@ietf.org > Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 > > On Mon, Sep 21, 2020 at 3:18 PM Yi Huang wrote: > > > > Thanks Yuchung, I responded inline. > > > > -----Original Message----- > > From: tcpm On Behalf Of Yuchung Cheng > > Sent: Monday, September 21, 2020 2:53 PM > > To: Yi Huang > > Cc: tcpm@ietf.org > > Subject: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-10 > > > > On Sun, Sep 20, 2020 at 6:16 PM Yi Huang wrote: > > >> > > >> Hi, > > >> > > >> I reviewed the latest version of RACK-TLP draft and have a few comme= nts/questions. > > >> > > >> 1. In section 5.1, "Segment.retransmitted is true if it was retransm= itted in the most recent transmission." > > >> There are also pseudo-code explaining how retransmitted flag is set.= AFAICT, retransmitted is set if the segment is ever retransmitted since th= e flag is never reset. Is this variable supposed to mean ever retransmitted= ? > > >Thanks for catching that. Segment.retransmitted MUST be reset upon a > > >(re)transmission so it does not ever-retransmitted (i.e. it's only > > >meant for the very last transmission) > > > > > RACK_transmit_data(Segment): > > > Segment.xmit_ts =3D Now() > > > Segment.lost =3D FALSE > > > Segment.retransmitted =3D FALSE > > > > > RACK_retransmit_data(Segment): > > > RACK_transmit_data(Segment) > > > Segment.retransmitted =3D TRUE > > > > Sorry, I still don't quite get it. RACK_transmit_data is for previously= unsent data (aka new data) right? If so, it will be only called once for a= given segment. Then, RACK_retransmit_data only sets it to TRUE. So where d= o we reset it? Looks like we still just initialize it to FALSE and set it t= o TRUE upon retransmission. > > Apologize for this confusion. I now see better how the text and code conf= use you. Segment.retransmitted is meant to reflect whether the most recent = send is a retransmission or not. But since a segment can be (only) retransm= itted N times consecutively, the flag is sticky throughout once set. To avo= id future confusion, how about having two separate routines. > > /* Send newly unsent data */ > RACK_transmit_new_data(Segment): > Segment.xmit_ts =3D Now() > Segment.lost =3D FALSE > Segment.retransmitted =3D FALSE > > /* Retransmit previously sent data */ > RACK_retransmit_data(Segment) > Segment.xmit_ts =3D Now() > Segment.lost =3D FALSE > Segment.retransmitted =3D TRUE > > > > > > >> > > >> 2. In section 6.2, p14, > > >> " If the sender has not yet observed any reordering based on the > > >> previous step, then RACK prioritizes quick loss recovery by using > > >> setting RACK.reo_wnd to 0 when the number of SACKed segments exce= eds > > >> DupThresh, or during loss recovery. > > >> > > >> Aside from those special conditions, RACK starts with a conservat= ive > > >> reordering window of RACK.min_RTT/4. This value was chosen becau= se > > >> Linux TCP used the same factor in its implementation to delay Ear= ly > > >> Retransmit [RFC5827] to reduce spurious loss detections in the > > >> presence of reordering, and experience showed this worked reasona= bly > > >> well [DMCG11]." > > >> > > >> If I understand this correctly, if no reordering observed, TCP shoul= d still enter loss recovery when DupACK >=3D DupThresh (RFC6675). If reorde= ring has been seen, this RFC6675 rule is not honored and TCP only enters lo= ss recovery when RACK detects loss? I think it would be great to clarify th= is in the spec. > > > > > Your understanding is correct. will this text revision improves clari= ty" > > > "" > > > If no reordering has been observed based on the previous step, the se= nder enters Fast Recovery when the number of SACKed segments exceeds DupThr= esh (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon entering a= nd during the loss recovery. > > > > > Otherwise if some reordering has been observed, RACK does not honor > > RFC6675 rule and starts with a conservative RACK.reo_wnd of RACK.min_RT= T/4. This .... reasonably well [DMCG11]. > > > "" > > > > Yeah, that's pretty clear now. > > > > > " If the sender has not yet observed any reordering based on the > > > previous step, then RACK prioritizes quick loss recovery by using > > > setting RACK.reo_wnd to 0 when the number of SACKed segments excee= ds > > > DupThresh, or during loss recovery. > > > > > > Aside from those special conditions, RACK starts with a conservati= ve > > > reordering window of RACK.min_RTT/4. This value was chosen becaus= e > > > Linux TCP used the same factor in its implementation to delay Earl= y > > > Retransmit [RFC5827] to reduce spurious loss detections in the > > > presence of reordering, and experience showed this worked reasonab= ly > > > well [DMCG11]." > > > > > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Wind= ow Probe (ZWP) timer". > > will fix thanks > > > > > > Thanks, > > > > > > Yi > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40mi= c > > > ro > > > soft.com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab2d > > > 7c > > > d011db47%7C1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq8s= z > > > gH > > > x43Hsfwlrog%2BZxQwJyiq0%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro= s > > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrD= x > > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro= s > > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrD= x > > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40microsoft= .com%7Cd3da167125f14f08fc9f08d85e875607%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C637363282644029020&sdata=3DmsvNOdkbMtyFfB5pep34eo%2BMdKiDh73h= VFGX503kgjA%3D&reserved=3D0 From nobody Thu Sep 24 09:31:02 2020 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 C98253A105B for ; Thu, 24 Sep 2020 09:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, 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 Z100PpFtCfzT for ; Thu, 24 Sep 2020 09:30:58 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 AC5173A1002 for ; Thu, 24 Sep 2020 09:30:58 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id z193so1500311vsz.10 for ; Thu, 24 Sep 2020 09:30:58 -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:content-transfer-encoding; bh=7s+fYaCuPKoq7+G26S8cdYsyT1WnlMODEsocCSTTVvE=; b=pxQPWHAAB8E89jnGJK7l8edBb2Uad4LOlby/TbENugrfmb+pEy4W9exeT+maLhVXOp FIK38dKfJPUszyV32ac0MlRCsKW1wUdoJo3XhREVWi7/k6uHrImSy1HS1lUURtObJW6q YbwQmEiVelvNV6niwNsMvbsINU6j3BUPVeES/Y9Q+WCrvIQ0T0BXhzG0iZQ3vJF3s5B4 3WcWBo5Wp06SezM19J/8e+kXPQ6RdTg6T1PPZdP5Uz6zWJIJikL9mZEghO4RP4tMsQrW 1tgeynQbLemyraxQwB3OcTtA5H6uFUxTGqZgS8AJSv0Jco/qUAl1iIJ7O95TxYZQNWi6 gaYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7s+fYaCuPKoq7+G26S8cdYsyT1WnlMODEsocCSTTVvE=; b=OKXXSgiV+klyq5R6nZ1W3DXXdrpp2nUNrT8zjvtD60umlRqvz3iH3/35gvgYEx5lSO DAG+F9gbnleCfnb+em/FLq41Q9YU+oKeLhTryZm05xEmJLUmgIuUqy7f+yy5AhmGyyiQ L8s5rEQ39JPLVk5lb1qm/TCqKh1A2J7Pawc+mJf3A7805p7HG/qefnNMoczIEybjOPR+ hBKLsb8ew83okHF4/JCjkSkTDlw13symytpYXQcuiS0kctSTCO2daRasOdn5yLpDBo+c aKMFqnGWoYvc/k7lf6a4EQmBZLnrC5bm/wncVjVHl8tzZPJWBfHn6GYBRIEbCAujjXNC 9r9A== X-Gm-Message-State: AOAM532fi/TsQoprDqZnwCH5qvRPCFOay2vPoum7O2LkiblIwgWSTJyK t4ABOMnQYYNIjG1tqUsQKPDlqzf+fM43Vo7u6sGTzw== X-Google-Smtp-Source: ABdhPJxTFzYFmj01vLTeGubvD1AvT8Q/nnLFEHRFl4MIYcDSqAl5ApbRzFTjlGsd8YJM+vtDCGz0Ujd2nskCaH6tJMc= X-Received: by 2002:a67:fe81:: with SMTP id b1mr5266316vsr.5.1600965057322; Thu, 24 Sep 2020 09:30:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Thu, 24 Sep 2020 09:30:20 -0700 Message-ID: To: Praveen Balasubramanian Cc: Yi Huang , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 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, 24 Sep 2020 16:31:01 -0000 On Mon, Sep 21, 2020 at 4:37 PM Praveen Balasubramanian wrote: > > >> Segment.retransmitted is meant to reflect whether the most recent send= is a retransmission or not > The "most recent send" here is confusing. Why not just state that this re= flects whether the segment was ever retransmitted? We'll make the change based on your suggestions: =E2=80=9CSegment.retransmitted=E2=80=9D is true if the segment has ever bee= n retransmitted. False otherwise. Also RACK_detect_loss() can be further simplified by removing the checks of Segment.retransmitted, as long as Segment.xmit_ts is invalidated upon loss. =E2=80=9CSegment.xmit_ts=E2=80=9D is the time of the last transmiss= ion of a data segment, including retransmissions, if any, with a clock granularity specified in the Requirements section. A maximum value INFINITE_TS indicates an invalid timestamp that represents that the Segment is not currently in flight. New RACK_detect_lost(): timeout =3D 0 RACK.reo_wnd =3D RACK_update_reo_wnd() For each segment, Segment, not acknowledged yet: // removed the old lines to check Segment.retransmitted // If RACK_sent_after(RACK.xmit_ts, RACK.end_seq, Segment.xmit_ts, Segment.end_seq): remaining =3D Segment.xmit_ts + RACK.rtt + RACK.reo_wnd - Now() If remaining <=3D 0: Segment.lost =3D TRUE Segment.xmit_ts =3D INFINITE_TS //<--- new line Else: timeout =3D max(remaining, timeout) Return timeout So it's more clear and simpler :-) > > -----Original Message----- > From: tcpm On Behalf Of Yuchung Cheng > Sent: Monday, September 21, 2020 4:12 PM > To: Yi Huang > Cc: Yuchung Cheng ; tcpm@ietf.org > Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 > > On Mon, Sep 21, 2020 at 3:18 PM Yi Huang wrote: > > > > Thanks Yuchung, I responded inline. > > > > -----Original Message----- > > From: tcpm On Behalf Of Yuchung Cheng > > Sent: Monday, September 21, 2020 2:53 PM > > To: Yi Huang > > Cc: tcpm@ietf.org > > Subject: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-10 > > > > On Sun, Sep 20, 2020 at 6:16 PM Yi Huang wrote: > > >> > > >> Hi, > > >> > > >> I reviewed the latest version of RACK-TLP draft and have a few comme= nts/questions. > > >> > > >> 1. In section 5.1, "Segment.retransmitted is true if it was retransm= itted in the most recent transmission." > > >> There are also pseudo-code explaining how retransmitted flag is set.= AFAICT, retransmitted is set if the segment is ever retransmitted since th= e flag is never reset. Is this variable supposed to mean ever retransmitted= ? > > >Thanks for catching that. Segment.retransmitted MUST be reset upon a > > >(re)transmission so it does not ever-retransmitted (i.e. it's only > > >meant for the very last transmission) > > > > > RACK_transmit_data(Segment): > > > Segment.xmit_ts =3D Now() > > > Segment.lost =3D FALSE > > > Segment.retransmitted =3D FALSE > > > > > RACK_retransmit_data(Segment): > > > RACK_transmit_data(Segment) > > > Segment.retransmitted =3D TRUE > > > > Sorry, I still don't quite get it. RACK_transmit_data is for previously= unsent data (aka new data) right? If so, it will be only called once for a= given segment. Then, RACK_retransmit_data only sets it to TRUE. So where d= o we reset it? Looks like we still just initialize it to FALSE and set it t= o TRUE upon retransmission. > > Apologize for this confusion. I now see better how the text and code conf= use you. Segment.retransmitted is meant to reflect whether the most recent = send is a retransmission or not. But since a segment can be (only) retransm= itted N times consecutively, the flag is sticky throughout once set. To avo= id future confusion, how about having two separate routines. > > /* Send newly unsent data */ > RACK_transmit_new_data(Segment): > Segment.xmit_ts =3D Now() > Segment.lost =3D FALSE > Segment.retransmitted =3D FALSE > > /* Retransmit previously sent data */ > RACK_retransmit_data(Segment) > Segment.xmit_ts =3D Now() > Segment.lost =3D FALSE > Segment.retransmitted =3D TRUE > > > > > > >> > > >> 2. In section 6.2, p14, > > >> " If the sender has not yet observed any reordering based on the > > >> previous step, then RACK prioritizes quick loss recovery by using > > >> setting RACK.reo_wnd to 0 when the number of SACKed segments exce= eds > > >> DupThresh, or during loss recovery. > > >> > > >> Aside from those special conditions, RACK starts with a conservat= ive > > >> reordering window of RACK.min_RTT/4. This value was chosen becau= se > > >> Linux TCP used the same factor in its implementation to delay Ear= ly > > >> Retransmit [RFC5827] to reduce spurious loss detections in the > > >> presence of reordering, and experience showed this worked reasona= bly > > >> well [DMCG11]." > > >> > > >> If I understand this correctly, if no reordering observed, TCP shoul= d still enter loss recovery when DupACK >=3D DupThresh (RFC6675). If reorde= ring has been seen, this RFC6675 rule is not honored and TCP only enters lo= ss recovery when RACK detects loss? I think it would be great to clarify th= is in the spec. > > > > > Your understanding is correct. will this text revision improves clari= ty" > > > "" > > > If no reordering has been observed based on the previous step, the se= nder enters Fast Recovery when the number of SACKed segments exceeds DupThr= esh (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon entering a= nd during the loss recovery. > > > > > Otherwise if some reordering has been observed, RACK does not honor > > RFC6675 rule and starts with a conservative RACK.reo_wnd of RACK.min_RT= T/4. This .... reasonably well [DMCG11]. > > > "" > > > > Yeah, that's pretty clear now. > > > > > " If the sender has not yet observed any reordering based on the > > > previous step, then RACK prioritizes quick loss recovery by using > > > setting RACK.reo_wnd to 0 when the number of SACKed segments excee= ds > > > DupThresh, or during loss recovery. > > > > > > Aside from those special conditions, RACK starts with a conservati= ve > > > reordering window of RACK.min_RTT/4. This value was chosen becaus= e > > > Linux TCP used the same factor in its implementation to delay Earl= y > > > Retransmit [RFC5827] to reduce spurious loss detections in the > > > presence of reordering, and experience showed this worked reasonab= ly > > > well [DMCG11]." > > > > > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Wind= ow Probe (ZWP) timer". > > will fix thanks > > > > > > Thanks, > > > > > > Yi > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40mi= c > > > ro > > > soft.com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab2d > > > 7c > > > d011db47%7C1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq8s= z > > > gH > > > x43Hsfwlrog%2BZxQwJyiq0%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro= s > > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrD= x > > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro= s > > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrD= x > > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.= com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOTrDxU%2FOrpC7ayX= htZSuzM%2B2U%3D&reserved=3D0 From nobody Thu Sep 24 13:15:05 2020 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 009EA3A125D for ; Thu, 24 Sep 2020 13:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=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 G_LbbLbYKmDy for ; Thu, 24 Sep 2020 13:15:00 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650113.outbound.protection.outlook.com [40.107.65.113]) (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 121843A123D for ; Thu, 24 Sep 2020 13:14:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mW1doleHCvxGbusqRlaFZviuXV8DUEyypTxfddvZirgaJ51X2BwkQ1kiQ68T/ojDVcK3cXuGv/ISlL0yTL7l5RYcJRZE/K6AdHKUwNaKykXjpurQbjz/viuHIJDD1SRnqNVE14qUQIUE0rMJCMRxURpVtVo7UoZ+N6dYOSdklEjASL1vCpph4t46hcnG3H0sW/fjfAtzHjkwev7kBQh5FCMYfiaYtEhb9aBaZi1wYqGmKK4bEC1LlLKdvjlIkRtDFUq0DKKKYwewBWi8/Fd+BY+5azhOy+8B+GmrRuUGFhubbdYSR25TZWZ69lN+Yd7mFpLSuBdb+KXdl1VKFS51kQ== 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=kXnCJYlCTfhgZ4od3GgfhYwmhKd+rOOmEd7+6XkROvs=; b=XADqoihyC2roTpbhFOtlBsa8PnmNoAXsI/lBLmARCYM0dvyA4hqc3875UbbHFFfr9G0n2DRQWvRBOdGFyDAnmM1M01Wb3AGynmpUGmC57wIplAa9LPzKgPk6kXcnxOsd9cDyQvV1NCd3Kx8vX18yVlLYlyhtYBTrz4KannI3uiwoTOUYp0cSgS0bzCp2Q0ENjVF59W+XKvva/rK/wKhkCR+r8oBugsnViMGdzLxyLZm594xS97YUUSblxr2A7cYKpGSs/RMJBJI7fw9+EqVSEW5vJTQIRo1T6C5x5JZzChcNelwL4FVR+ukmxXQQuEOe7E1l7lhPIbvSBSIITmkHlw== 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=kXnCJYlCTfhgZ4od3GgfhYwmhKd+rOOmEd7+6XkROvs=; b=FkdoUkdXWayP4KIV/tbnPmXru2csDsFi+lfevxW+bL8lwKnwSSxsA+yz/n6kiRVgphVyZvfmFyOobnw0pRg+Y87XiQ+i2weJp0GVLUIxme0pgLQG28Kf2PKb3XmKZj3EQwnZ/qlGeg39vILcl94Yfo7+XSjT7fYUMGj/8ZXRKvU= Received: from BYAPR00MB0870.namprd00.prod.outlook.com (2603:10b6:a03:108::23) by BYAPR00MB0456.namprd00.prod.outlook.com (2603:10b6:a03:d5::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3451.0; Thu, 24 Sep 2020 20:14:56 +0000 Received: from BYAPR00MB0870.namprd00.prod.outlook.com ([fe80::5c10:da9:b3d9:8d44]) by BYAPR00MB0870.namprd00.prod.outlook.com ([fe80::5c10:da9:b3d9:8d44%6]) with mapi id 15.20.3450.000; Thu, 24 Sep 2020 20:14:56 +0000 From: Yi Huang To: Yuchung Cheng , Praveen Balasubramanian CC: "tcpm@ietf.org" Thread-Topic: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 Thread-Index: AQHWkGy2QE5uqNZZ5kWIKfV0G0hE7Klzv3+AgAQ/pACAADsm0A== Date: Thu, 24 Sep 2020 20:14:56 +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=5ba6e397-aa07-4315-ac45-456979c3359a; 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=2020-09-24T20:02:02Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:877f:ac89:1402:7118:d6f6:42a1] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4b316931-7dce-41ca-9f79-08d860c6815a x-ms-traffictypediagnostic: BYAPR00MB0456: 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: lOZKr1/eZH7OgrlRSvGnkcwfr9Wj8I4ujX077u7KqXMW8HYXVdXfoopwCkFGXEdNUVduU+R0/ikmW80OnYGsa0JnGHOXL8zuSYQI2+zsnxgVX4I/QHc3bhUfl5832kHKl2vALErKlja/NnCrUIIn+jnNJe3YC34z1nQNp2WDuotwZWy/zKygXlINZq5bMcEY9MSVlCHeQ1qDAdIQ3TOohV80la1sgl2HME8i8/ZtFNIGbWDuQJ1XCwQilkAPod/QQUSOjBGK+ARgzUwLJTeUzT094ejmtq0huySrTFExMk7MTms9zHa8981u6JtxQ5Qjb0iXT8dD5D1PHctl0qrlcJfSGqITrQlCMHRdrtfCqoQZKYiREuzWDzXNqVS8MyIORvVytmd5lSm4q3fte6Z9cg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR00MB0870.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(376002)(136003)(396003)(52536014)(478600001)(66946007)(76116006)(71200400001)(64756008)(66556008)(66476007)(66446008)(83380400001)(8676002)(8990500004)(83080400001)(5660300002)(4326008)(10290500003)(186003)(2906002)(82960400001)(82950400001)(8936002)(33656002)(7696005)(86362001)(110136005)(9686003)(966005)(6506007)(316002)(53546011)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: SMcJiyRm3uwjPJq6wt+wINz/r+jftpBF5KkMluGQpgBsQSkmz5zNVHGlxw9QUV2YqSH1NTWmPEBbBJNVO+9dtG1fYzRfs9BYHcZvH5w0JYtm5+74MBdfKGUenK1b79m1pFddEmLPsGawZMlmDtoD+H//N5YDci2/svFvQHDbbBytiAHfBCrMMTyf8etXYrcr/iWO4ERMP/AgJQ8jxuFJnibKIwlCDMqkexhzJYdeP3JDIBkuFlS+BN5cj5vhMRm4/MeOaW8CWZNML0cfkx/8H15tWf0DEkNakpHNcn1Doayz5PIeVndYz/UA7djgHgluK14xtXBlJ1x5coHTfnziGCvV/GxtFd+sp0MSMtAK1mYZ/TnFj8XTum9C/OvC1sMzUEb0+UHYwvfYhMhshlDZJld+2rrvpNFBkn211LhaRfDPYhOFy+a02p8e5KDBbkhXblE95mkVNyPWVFT2omMAwsb3W8JNTuWTXUkxyDPJgAO+zmW0Kj0WG5//bQGtDISAPTPlyeTTN9XzyyOzjbsaQ2oPn6gkTSywEHPS+cOAuqK3nIjmnYr5FPePrCzhbNtE7c9BAKdFVPcyBRKtE69AOhE9i/LfxmsiGFS4qOvG70aJG9fIf4ym/bGrrxaLtpAF5Oqq92fyIUHzIjz0RF2DBj7GETAyXbn4YTSXOd7xqrKn/ucPWinpAN98nclfPmXoljyAYv7SmJ1AargmqlEvkQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR00MB0870.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b316931-7dce-41ca-9f79-08d860c6815a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2020 20:14:56.2286 (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: Xae7aQzArOGgM6pE4mSInM/JIjMtTqqfAXzCf7gCMElbUV6DBrasdEf9IaGuZ7fMFm3ufDG/4WpuZ9q8K8TXzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0456 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 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, 24 Sep 2020 20:15:03 -0000 WWVzLCB0aGlzIGlzIG11Y2ggYmV0dGVyLiBZb3UgY291bGQgYWxzbyBjaGFuZ2UgdGhlIGxvb3Ag Y29uZGl0aW9uIHRvICJGb3IgZWFjaCB1bmFja25vd2xlZGdlZCBhbmQgbm90IGxvc3Qgc2VnbWVu dCwgU2VnbWVudDoiIGFuZCB5b3Ugd291bGRuJ3QgbmVlZCBJTkZJTklURV9UUywgd2hpY2ggc291 bmRzIGEgYml0IG1vcmUgaW50dWl0aXZlIHRvIG1lLiBPciBldmVuIHNpbXBsZXIgIkZvciBlYWNo IHNlZ21lbnQsIFNlZ21lbnQsIG5vdCBsb3N0IHlldCIgc2luY2UgaXQgaXMgdXN1YWxseSBhc3N1 bWVkIHRoYXQgY3VtdWxhdGl2ZWx5IEFDS2VkIHNlZ21lbnRzIGFyZSBubyBsb25nZXIgYmVpbmcg dHJhY2tlZC4gQW55d2F5LCB0aGUgbmV3IHBzZXVkb2NvZGUgYW5kIHRleHQgbG9vayBwcmV0dHkg Z29vZC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFl1Y2h1bmcgQ2hlbmcg PHljaGVuZ0Bnb29nbGUuY29tPiANClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMjAg OTozMCBBTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5j b21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogWWkgSHVhbmcgPGh1YW55aUBtaWNyb3NvZnQuY29tPjsg dGNwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0Y3BtXSBbRVhURVJOQUxdIFJlOiBBIHJldmll dyBvZiBkcmFmdC1pZXRmLXRjcG0tcmFjay0xMA0KDQpPbiBNb24sIFNlcCAyMSwgMjAyMCBhdCA0 OjM3IFBNIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmc+IHdyb3RlOg0KPg0KPiA+PiBTZWdtZW50LnJldHJhbnNtaXR0ZWQgaXMgbWVh bnQgdG8gcmVmbGVjdCB3aGV0aGVyIHRoZSBtb3N0IHJlY2VudCANCj4gPj4gc2VuZCBpcyBhIHJl dHJhbnNtaXNzaW9uIG9yIG5vdA0KPiBUaGUgIm1vc3QgcmVjZW50IHNlbmQiIGhlcmUgaXMgY29u ZnVzaW5nLiBXaHkgbm90IGp1c3Qgc3RhdGUgdGhhdCB0aGlzIHJlZmxlY3RzIHdoZXRoZXIgdGhl IHNlZ21lbnQgd2FzIGV2ZXIgcmV0cmFuc21pdHRlZD8NCldlJ2xsIG1ha2UgdGhlIGNoYW5nZSBi YXNlZCBvbiB5b3VyIHN1Z2dlc3Rpb25zOg0KDQrigJxTZWdtZW50LnJldHJhbnNtaXR0ZWTigJ0g aXMgdHJ1ZSBpZiB0aGUgc2VnbWVudCBoYXMgZXZlciBiZWVuIHJldHJhbnNtaXR0ZWQuIEZhbHNl IG90aGVyd2lzZS4NCg0KQWxzbyBSQUNLX2RldGVjdF9sb3NzKCkgY2FuIGJlIGZ1cnRoZXIgc2lt cGxpZmllZCBieSByZW1vdmluZyB0aGUgY2hlY2tzIG9mIFNlZ21lbnQucmV0cmFuc21pdHRlZCwg YXMgbG9uZyBhcyBTZWdtZW50LnhtaXRfdHMgaXMgaW52YWxpZGF0ZWQgdXBvbiBsb3NzLg0KDQog ICAgICAgIOKAnFNlZ21lbnQueG1pdF90c+KAnSBpcyB0aGUgdGltZSBvZiB0aGUgbGFzdCB0cmFu c21pc3Npb24gb2YgYSBkYXRhIHNlZ21lbnQsIGluY2x1ZGluZyByZXRyYW5zbWlzc2lvbnMsIGlm IGFueSwgd2l0aCBhIGNsb2NrIGdyYW51bGFyaXR5IHNwZWNpZmllZCBpbiB0aGUgUmVxdWlyZW1l bnRzIHNlY3Rpb24uIEEgbWF4aW11bSB2YWx1ZSBJTkZJTklURV9UUyBpbmRpY2F0ZXMgYW4gaW52 YWxpZCB0aW1lc3RhbXAgdGhhdCByZXByZXNlbnRzIHRoYXQgdGhlIFNlZ21lbnQgaXMgbm90IGN1 cnJlbnRseSBpbiBmbGlnaHQuDQoNCk5ldyBSQUNLX2RldGVjdF9sb3N0KCk6DQogICAgdGltZW91 dCA9IDANCiAgICBSQUNLLnJlb193bmQgPSBSQUNLX3VwZGF0ZV9yZW9fd25kKCkNCg0KICAgIEZv ciBlYWNoIHNlZ21lbnQsIFNlZ21lbnQsIG5vdCBhY2tub3dsZWRnZWQgeWV0Og0KICAgICAgICAv LyByZW1vdmVkIHRoZSBvbGQgbGluZXMgdG8gY2hlY2sgU2VnbWVudC5yZXRyYW5zbWl0dGVkDQog ICAgICAgIC8vDQogICAgICAgIElmIFJBQ0tfc2VudF9hZnRlcihSQUNLLnhtaXRfdHMsIFJBQ0su ZW5kX3NlcSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlZ21lbnQueG1pdF90cywgU2Vn bWVudC5lbmRfc2VxKToNCiAgICAgICAgICAgIHJlbWFpbmluZyA9IFNlZ21lbnQueG1pdF90cyAr IFJBQ0sucnR0ICsNCiAgICAgICAgICAgICAgICAgICAgICAgIFJBQ0sucmVvX3duZCAtIE5vdygp DQogICAgICAgICAgICBJZiByZW1haW5pbmcgPD0gMDoNCiAgICAgICAgICAgICAgICBTZWdtZW50 Lmxvc3QgPSBUUlVFDQogICAgICAgICAgICAgICAgU2VnbWVudC54bWl0X3RzID0gSU5GSU5JVEVf VFMgLy88LS0tIG5ldyBsaW5lDQogICAgICAgICAgICBFbHNlOg0KICAgICAgICAgICAgICAgIHRp bWVvdXQgPSBtYXgocmVtYWluaW5nLCB0aW1lb3V0KQ0KICAgIFJldHVybiB0aW1lb3V0DQoNClNv IGl0J3MgbW9yZSBjbGVhciBhbmQgc2ltcGxlciA6LSkNCg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBZdWNodW5nIENoZW5nDQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIxLCAyMDIwIDQ6 MTIgUE0NCj4gVG86IFlpIEh1YW5nIDxodWFueWk9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnPg0KPiBDYzogWXVjaHVuZyBDaGVuZyA8eWNoZW5nPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZz47IHRjcG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0Y3BtXSBbRVhURVJOQUxdIFJl OiBBIHJldmlldyBvZiBkcmFmdC1pZXRmLXRjcG0tcmFjay0xMA0KPg0KPiBPbiBNb24sIFNlcCAy MSwgMjAyMCBhdCAzOjE4IFBNIFlpIEh1YW5nIDxodWFueWk9NDBtaWNyb3NvZnQuY29tQGRtYXJj LmlldGYub3JnPiB3cm90ZToNCj4gPg0KPiA+IFRoYW5rcyBZdWNodW5nLCBJIHJlc3BvbmRlZCBp bmxpbmUuDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHRj cG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFl1Y2h1bmcgQ2hlbmcNCj4g PiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMSwgMjAyMCAyOjUzIFBNDQo+ID4gVG86IFlpIEh1 YW5nIDxodWFueWk9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPg0KPiA+IENjOiB0Y3Bt QGlldGYub3JnDQo+ID4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW3RjcG1dIEEgcmV2aWV3IG9m IGRyYWZ0LWlldGYtdGNwbS1yYWNrLTEwDQo+ID4NCj4gPiBPbiBTdW4sIFNlcCAyMCwgMjAyMCBh dCA2OjE2IFBNIFlpIEh1YW5nIDxodWFueWk9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn PiB3cm90ZToNCj4gPiA+Pg0KPiA+ID4+IEhpLA0KPiA+ID4+DQo+ID4gPj4gSSByZXZpZXdlZCB0 aGUgbGF0ZXN0IHZlcnNpb24gb2YgUkFDSy1UTFAgZHJhZnQgYW5kIGhhdmUgYSBmZXcgY29tbWVu dHMvcXVlc3Rpb25zLg0KPiA+ID4+DQo+ID4gPj4gMS4gSW4gc2VjdGlvbiA1LjEsICJTZWdtZW50 LnJldHJhbnNtaXR0ZWQgaXMgdHJ1ZSBpZiBpdCB3YXMgcmV0cmFuc21pdHRlZCBpbiB0aGUgbW9z dCByZWNlbnQgdHJhbnNtaXNzaW9uLiINCj4gPiA+PiBUaGVyZSBhcmUgYWxzbyBwc2V1ZG8tY29k ZSBleHBsYWluaW5nIGhvdyByZXRyYW5zbWl0dGVkIGZsYWcgaXMgc2V0LiBBRkFJQ1QsIHJldHJh bnNtaXR0ZWQgaXMgc2V0IGlmIHRoZSBzZWdtZW50IGlzIGV2ZXIgcmV0cmFuc21pdHRlZCBzaW5j ZSB0aGUgZmxhZyBpcyBuZXZlciByZXNldC4gSXMgdGhpcyB2YXJpYWJsZSBzdXBwb3NlZCB0byBt ZWFuIGV2ZXIgcmV0cmFuc21pdHRlZD8NCj4gPiA+VGhhbmtzIGZvciBjYXRjaGluZyB0aGF0LiBT ZWdtZW50LnJldHJhbnNtaXR0ZWQgTVVTVCBiZSByZXNldCB1cG9uIA0KPiA+ID5hIChyZSl0cmFu c21pc3Npb24gc28gaXQgZG9lcyBub3QgZXZlci1yZXRyYW5zbWl0dGVkIChpLmUuIGl0J3MgDQo+ ID4gPm9ubHkgbWVhbnQgZm9yIHRoZSB2ZXJ5IGxhc3QgdHJhbnNtaXNzaW9uKQ0KPiA+DQo+ID4g PiBSQUNLX3RyYW5zbWl0X2RhdGEoU2VnbWVudCk6DQo+ID4gPiAgICAgICAgICAgU2VnbWVudC54 bWl0X3RzID0gTm93KCkNCj4gPiA+ICAgICAgICAgICBTZWdtZW50Lmxvc3QgPSBGQUxTRQ0KPiA+ ID4gICAgICAgICAgIFNlZ21lbnQucmV0cmFuc21pdHRlZCA9IEZBTFNFDQo+ID4NCj4gPiA+ICAg UkFDS19yZXRyYW5zbWl0X2RhdGEoU2VnbWVudCk6DQo+ID4gPiAgICAgICAgICAgUkFDS190cmFu c21pdF9kYXRhKFNlZ21lbnQpDQo+ID4gPiAgICAgICAgICAgU2VnbWVudC5yZXRyYW5zbWl0dGVk ID0gVFJVRQ0KPiA+DQo+ID4gU29ycnksIEkgc3RpbGwgZG9uJ3QgcXVpdGUgZ2V0IGl0LiBSQUNL X3RyYW5zbWl0X2RhdGEgaXMgZm9yIHByZXZpb3VzbHkgdW5zZW50IGRhdGEgKGFrYSBuZXcgZGF0 YSkgcmlnaHQ/IElmIHNvLCBpdCB3aWxsIGJlIG9ubHkgY2FsbGVkIG9uY2UgZm9yIGEgZ2l2ZW4g c2VnbWVudC4gVGhlbiwgUkFDS19yZXRyYW5zbWl0X2RhdGEgb25seSBzZXRzIGl0IHRvIFRSVUUu IFNvIHdoZXJlIGRvIHdlIHJlc2V0IGl0PyBMb29rcyBsaWtlIHdlIHN0aWxsIGp1c3QgaW5pdGlh bGl6ZSBpdCB0byBGQUxTRSBhbmQgc2V0IGl0IHRvIFRSVUUgdXBvbiByZXRyYW5zbWlzc2lvbi4N Cj4NCj4gQXBvbG9naXplIGZvciB0aGlzIGNvbmZ1c2lvbi4gSSBub3cgc2VlIGJldHRlciBob3cg dGhlIHRleHQgYW5kIGNvZGUgY29uZnVzZSB5b3UuIFNlZ21lbnQucmV0cmFuc21pdHRlZCBpcyBt ZWFudCB0byByZWZsZWN0IHdoZXRoZXIgdGhlIG1vc3QgcmVjZW50IHNlbmQgaXMgYSByZXRyYW5z bWlzc2lvbiBvciBub3QuIEJ1dCBzaW5jZSBhIHNlZ21lbnQgY2FuIGJlIChvbmx5KSByZXRyYW5z bWl0dGVkIE4gdGltZXMgY29uc2VjdXRpdmVseSwgdGhlIGZsYWcgaXMgc3RpY2t5IHRocm91Z2hv dXQgb25jZSBzZXQuIFRvIGF2b2lkIGZ1dHVyZSBjb25mdXNpb24sIGhvdyBhYm91dCBoYXZpbmcg dHdvIHNlcGFyYXRlIHJvdXRpbmVzLg0KPg0KPiAvKiBTZW5kIG5ld2x5IHVuc2VudCBkYXRhICov DQo+IFJBQ0tfdHJhbnNtaXRfbmV3X2RhdGEoU2VnbWVudCk6DQo+ICAgICAgICAgICAgU2VnbWVu dC54bWl0X3RzID0gTm93KCkNCj4gICAgICAgICAgICBTZWdtZW50Lmxvc3QgPSBGQUxTRQ0KPiAg ICAgICAgICAgIFNlZ21lbnQucmV0cmFuc21pdHRlZCA9IEZBTFNFDQo+DQo+IC8qIFJldHJhbnNt aXQgcHJldmlvdXNseSBzZW50IGRhdGEgKi8NCj4gUkFDS19yZXRyYW5zbWl0X2RhdGEoU2VnbWVu dCkNCj4gICAgICAgICAgIFNlZ21lbnQueG1pdF90cyA9IE5vdygpDQo+ICAgICAgICAgICBTZWdt ZW50Lmxvc3QgPSBGQUxTRQ0KPiAgICAgICAgICAgU2VnbWVudC5yZXRyYW5zbWl0dGVkID0gVFJV RQ0KPg0KPg0KPiA+DQo+ID4gPj4NCj4gPiA+PiAyLiBJbiBzZWN0aW9uIDYuMiwgcDE0LA0KPiA+ ID4+ICIgICBJZiB0aGUgc2VuZGVyIGhhcyBub3QgeWV0IG9ic2VydmVkIGFueSByZW9yZGVyaW5n IGJhc2VkIG9uIHRoZQ0KPiA+ID4+ICAgIHByZXZpb3VzIHN0ZXAsIHRoZW4gUkFDSyBwcmlvcml0 aXplcyBxdWljayBsb3NzIHJlY292ZXJ5IGJ5IHVzaW5nDQo+ID4gPj4gICAgc2V0dGluZyBSQUNL LnJlb193bmQgdG8gMCB3aGVuIHRoZSBudW1iZXIgb2YgU0FDS2VkIHNlZ21lbnRzIGV4Y2VlZHMN Cj4gPiA+PiAgICBEdXBUaHJlc2gsIG9yIGR1cmluZyBsb3NzIHJlY292ZXJ5Lg0KPiA+ID4+DQo+ ID4gPj4gICAgQXNpZGUgZnJvbSB0aG9zZSBzcGVjaWFsIGNvbmRpdGlvbnMsIFJBQ0sgc3RhcnRz IHdpdGggYSBjb25zZXJ2YXRpdmUNCj4gPiA+PiAgICByZW9yZGVyaW5nIHdpbmRvdyBvZiBSQUNL Lm1pbl9SVFQvNC4gIFRoaXMgdmFsdWUgd2FzIGNob3NlbiBiZWNhdXNlDQo+ID4gPj4gICAgTGlu dXggVENQIHVzZWQgdGhlIHNhbWUgZmFjdG9yIGluIGl0cyBpbXBsZW1lbnRhdGlvbiB0byBkZWxh eSBFYXJseQ0KPiA+ID4+ICAgIFJldHJhbnNtaXQgW1JGQzU4MjddIHRvIHJlZHVjZSBzcHVyaW91 cyBsb3NzIGRldGVjdGlvbnMgaW4gdGhlDQo+ID4gPj4gICAgcHJlc2VuY2Ugb2YgcmVvcmRlcmlu ZywgYW5kIGV4cGVyaWVuY2Ugc2hvd2VkIHRoaXMgd29ya2VkIHJlYXNvbmFibHkNCj4gPiA+PiAg ICB3ZWxsIFtETUNHMTFdLiINCj4gPiA+Pg0KPiA+ID4+IElmIEkgdW5kZXJzdGFuZCB0aGlzIGNv cnJlY3RseSwgaWYgbm8gcmVvcmRlcmluZyBvYnNlcnZlZCwgVENQIHNob3VsZCBzdGlsbCBlbnRl ciBsb3NzIHJlY292ZXJ5IHdoZW4gRHVwQUNLID49IER1cFRocmVzaCAoUkZDNjY3NSkuIElmIHJl b3JkZXJpbmcgaGFzIGJlZW4gc2VlbiwgdGhpcyBSRkM2Njc1IHJ1bGUgaXMgbm90IGhvbm9yZWQg YW5kIFRDUCBvbmx5IGVudGVycyBsb3NzIHJlY292ZXJ5IHdoZW4gUkFDSyBkZXRlY3RzIGxvc3M/ IEkgdGhpbmsgaXQgd291bGQgYmUgZ3JlYXQgdG8gY2xhcmlmeSB0aGlzIGluIHRoZSBzcGVjLg0K PiA+DQo+ID4gPiBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4gd2lsbCB0aGlzIHRleHQg cmV2aXNpb24gaW1wcm92ZXMgY2xhcml0eSINCj4gPiA+ICIiDQo+ID4gPiBJZiBubyByZW9yZGVy aW5nIGhhcyBiZWVuIG9ic2VydmVkIGJhc2VkIG9uIHRoZSBwcmV2aW91cyBzdGVwLCB0aGUgc2Vu ZGVyIGVudGVycyBGYXN0IFJlY292ZXJ5IHdoZW4gdGhlIG51bWJlciBvZiBTQUNLZWQgc2VnbWVu dHMgZXhjZWVkcyBEdXBUaHJlc2ggKHNpbWlsYXIgdG8gUkZDNjY3NSkuIFRoZSBSQUNLLnJlb193 bmQgaXMgc2V0IHRvIDAgYm90aCB1cG9uIGVudGVyaW5nIGFuZCBkdXJpbmcgdGhlIGxvc3MgcmVj b3ZlcnkuDQo+ID4NCj4gPiA+IE90aGVyd2lzZSBpZiBzb21lIHJlb3JkZXJpbmcgaGFzIGJlZW4g b2JzZXJ2ZWQsIFJBQ0sgZG9lcyBub3QgDQo+ID4gPiBob25vcg0KPiA+IFJGQzY2NzUgcnVsZSBh bmQgc3RhcnRzIHdpdGggYSBjb25zZXJ2YXRpdmUgUkFDSy5yZW9fd25kIG9mIFJBQ0subWluX1JU VC80LiBUaGlzIC4uLi4gcmVhc29uYWJseSB3ZWxsIFtETUNHMTFdLg0KPiA+ID4gIiINCj4gPg0K PiA+IFllYWgsIHRoYXQncyBwcmV0dHkgY2xlYXIgbm93Lg0KPiA+DQo+ID4gPiAiICAgSWYgdGhl IHNlbmRlciBoYXMgbm90IHlldCBvYnNlcnZlZCBhbnkgcmVvcmRlcmluZyBiYXNlZCBvbiB0aGUN Cj4gPiA+ICAgIHByZXZpb3VzIHN0ZXAsIHRoZW4gUkFDSyBwcmlvcml0aXplcyBxdWljayBsb3Nz IHJlY292ZXJ5IGJ5IHVzaW5nDQo+ID4gPiAgICBzZXR0aW5nIFJBQ0sucmVvX3duZCB0byAwIHdo ZW4gdGhlIG51bWJlciBvZiBTQUNLZWQgc2VnbWVudHMgZXhjZWVkcw0KPiA+ID4gICAgRHVwVGhy ZXNoLCBvciBkdXJpbmcgbG9zcyByZWNvdmVyeS4NCj4gPiA+DQo+ID4gPiAgICBBc2lkZSBmcm9t IHRob3NlIHNwZWNpYWwgY29uZGl0aW9ucywgUkFDSyBzdGFydHMgd2l0aCBhIGNvbnNlcnZhdGl2 ZQ0KPiA+ID4gICAgcmVvcmRlcmluZyB3aW5kb3cgb2YgUkFDSy5taW5fUlRULzQuICBUaGlzIHZh bHVlIHdhcyBjaG9zZW4gYmVjYXVzZQ0KPiA+ID4gICAgTGludXggVENQIHVzZWQgdGhlIHNhbWUg ZmFjdG9yIGluIGl0cyBpbXBsZW1lbnRhdGlvbiB0byBkZWxheSBFYXJseQ0KPiA+ID4gICAgUmV0 cmFuc21pdCBbUkZDNTgyN10gdG8gcmVkdWNlIHNwdXJpb3VzIGxvc3MgZGV0ZWN0aW9ucyBpbiB0 aGUNCj4gPiA+ICAgIHByZXNlbmNlIG9mIHJlb3JkZXJpbmcsIGFuZCBleHBlcmllbmNlIHNob3dl ZCB0aGlzIHdvcmtlZCByZWFzb25hYmx5DQo+ID4gPiAgICB3ZWxsIFtETUNHMTFdLiINCj4gPiA+ DQo+ID4gPiAzLiBbTklUXSBJbiBzZWN0aW9uIDgsICIgWmVybyB3aW5kb3cgcHJvYmUgKFpXUCkg dGltZXIiIC0+ICJaZXJvIFdpbmRvdyBQcm9iZSAoWldQKSB0aW1lciIuDQo+ID4gd2lsbCBmaXgg dGhhbmtzDQo+ID4gPg0KPiA+ID4gVGhhbmtzLA0KPiA+ID4NCj4gPiA+IFlpDQo+ID4gPg0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4gPiB0Y3BtQGlldGYub3JnDQo+ID4gPiBodHRwczovL25h bTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3 d3cuDQo+ID4gPiBpZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9 MDIlN0MwMSU3Q2h1YW55aSU0MG0NCj4gPiA+IGljDQo+ID4gPiBybw0KPiA+ID4gc29mdC5jb20l N0M3MTc0OGFmM2I5YWU0MjMyMzQ2MDA4ZDg1ZTc4ZDA2MyU3QzcyZjk4OGJmODZmMTQxYWY5MWFi DQo+ID4gPiAyZA0KPiA+ID4gN2MNCj4gPiA+IGQwMTFkYjQ3JTdDMSU3QzAlN0M2MzczNjMyMjAy OTc4Mjg0NzcmYW1wO3NkYXRhPWVIWWgwRlhSR05TOFQyTEZxOA0KPiA+ID4gc3oNCj4gPiA+IGdI DQo+ID4gPiB4NDNIc2Z3bHJvZyUyQlp4UXdKeWlxMCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0 Y3BtIG1haWxpbmcgbGlzdA0KPiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiBodHRwczovL25hbTA2LnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+ ID4gaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdDMDEl N0NwcmF2YiU0MG1pY3INCj4gPiBvcyANCj4gPiBvZnQuY29tJTdDNGNjMGFkYjU1OGE2NGZlZGNm YWMwOGQ4NWU4M2RjYTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkNw0KPiA+IGNkIA0KPiA+IDAx MWRiNDclN0MxJTdDMCU3QzYzNzM2MzI2Nzc0NTExOTQ1NSZhbXA7c2RhdGE9R2RYcnR3bllhdmZM cFZJWXFyT1RyDQo+ID4gRHgNCj4gPiBVJTJGT3JwQzdheVhodFpTdXpNJTJCMlUlM0QmYW1wO3Jl c2VydmVkPTANCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPiB0Y3BtQGlldGYub3JnDQo+ID4g aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3Lg0KPiA+IGlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZh bXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyDQo+ID4gb3MgDQo+ID4gb2Z0LmNvbSU3QzRj YzBhZGI1NThhNjRmZWRjZmFjMDhkODVlODNkY2E5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDcN Cj4gPiBjZCANCj4gPiAwMTFkYjQ3JTdDMSU3QzAlN0M2MzczNjMyNjc3NDUxMTk0NTUmYW1wO3Nk YXRhPUdkWHJ0d25ZYXZmTHBWSVlxck9Ucg0KPiA+IER4DQo+ID4gVSUyRk9ycEM3YXlYaHRaU3V6 TSUyQjJVJTNEJmFtcDtyZXNlcnZlZD0wDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5v cmcNCj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3Lg0KPiBpZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRj cG0mYW1wO2RhdGE9MDIlN0MwMSU3Q2h1YW55aSU0MG1pY3JvDQo+IHNvZnQuY29tJTdDNWVhNmEz OGMzYzBiNGZiNTE4YTkwOGQ4NjBhNzM3OWIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2MNCj4g ZDAxMWRiNDclN0MxJTdDMCU3QzYzNzM2NTYxOTAzMTc4Mjg4NSZhbXA7c2RhdGE9QlpSTFRIdXhj azlHU3lLdkMlMkJTQQ0KPiBQSVBiY0VVVTNNUzBvQzclMkJkMDhJZGdjJTNEJmFtcDtyZXNlcnZl ZD0wDQo= From nobody Thu Sep 24 13:27:41 2020 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 C46033A129F for ; Thu, 24 Sep 2020 13:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgNDXh8KBsSC for ; Thu, 24 Sep 2020 13:27:37 -0700 (PDT) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 3E2FE3A129D for ; Thu, 24 Sep 2020 13:27:37 -0700 (PDT) Received: by mail-vk1-xa29.google.com with SMTP id m8so105508vka.6 for ; Thu, 24 Sep 2020 13:27:36 -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=ayzAc5mGY9MSG4+5inrPTFf7XJkG6N1Sv4yQ/MVawX0=; b=iW8JQ3WljEqlhbbe+J7XRzNoOk4sUW59kPRF/SxmKB/JXuFDW9tQ3Zt8UZML4qkkZO w103y14x5APdzvXRYNxTpGSpRHrVrDZfRpmfkwC6FOLv0L3GeXqj7BLtPs3rIVBQjW2Y XltAVeAjAKIVaA1yktJOQN8jKg2hdVeTUNZrUwbGKsowCL6YulFKF+g7Oy3ppmVxxlh0 Pij2A8xYtvBkmubOGld3357YqyUEoavagXT/nDrbFGEWuvwi2zHg2x0iZKHwn3kUBoWH Ntsfu2LmvNzSbCUON30boHJ/Y5ijsaPTTw8zzuWGpr6RoNxGt7GF8C44+Ri1YS2xaNah l/ng== 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=ayzAc5mGY9MSG4+5inrPTFf7XJkG6N1Sv4yQ/MVawX0=; b=IJqk4tiC/sEPKp0NrdASrjjzGb5tuI+1oai/eifBpPcNIeeKhz2W52+IeKe7k53JSu n39DAHySPI0dcuz7nuSrqgUjVoCtsj6CbPcsB32oAC43cDQWvtCWsJM9ZHpkS9AIon8Z xm3pdwTsZJ9PwLSiouQpFMwQjcn55lN3fsxYCEAvJtZHbszDTdenBOahKvNwEKB5Daui dSHxo4TI7q8ecSOtNHHG3owcjjFGQKAU7qAukDkArWViel1GuXkmfXgp8EkmIFwVaRw5 JQUmysCfxN6xvXoxlpqYQudhLuyC3zo0tUsMtv1+K7ZfHM7EBBLvi8pYIM6RsX21GVkK SoyQ== X-Gm-Message-State: AOAM533685HCSsHYhwzp+j9+9qo/3Ojd19CWSoSMxk0kcgX0nEN/OM6c yKAEIwkZ3xZGXqsH6dxSefX/VLanUzst67hqIuiDO/a2PUt10w== X-Google-Smtp-Source: ABdhPJy24Iq/v162H91wDim//PCLbYseuov+uwomf6KtMrxK2p8fri2cFTkoECEzBbl2EqkfHlrRMAL/8wyR8/XjYFE= X-Received: by 2002:a1f:9c04:: with SMTP id f4mr973082vke.14.1600979255813; Thu, 24 Sep 2020 13:27:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Thu, 24 Sep 2020 16:27:19 -0400 Message-ID: To: Yi Huang Cc: Yuchung Cheng , Praveen Balasubramanian , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d6603805b0150704" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 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, 24 Sep 2020 20:27:40 -0000 --000000000000d6603805b0150704 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 24, 2020 at 4:15 PM Yi Huang wrote: > Yes, this is much better. You could also change the loop condition to "Fo= r > each unacknowledged and not lost segment, Segment:" and you wouldn't need > INFINITE_TS, which sounds a bit more intuitive to me. Or even simpler "Fo= r > each segment, Segment, not lost yet" since it is usually assumed that > cumulatively ACKed segments are no longer being tracked. Anyway, the new > pseudocode and text look pretty good. > Expressing this as "For each unacknowledged and not lost segment, Segment:" or "For each segment, Segment, not lost yet" might be a little unclear or ambiguous. The issue is that we do want to consider in this loop the segments that were marked lost but then later retransmitted. The way Yuchung expressed the loop condition avoids that issue. best, neal > > -----Original Message----- > From: Yuchung Cheng > Sent: Thursday, September 24, 2020 9:30 AM > To: Praveen Balasubramanian > Cc: Yi Huang ; tcpm@ietf.org > Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 > > On Mon, Sep 21, 2020 at 4:37 PM Praveen Balasubramanian 40microsoft.com@dmarc.ietf.org> wrote: > > > > >> Segment.retransmitted is meant to reflect whether the most recent > > >> send is a retransmission or not > > The "most recent send" here is confusing. Why not just state that this > reflects whether the segment was ever retransmitted? > We'll make the change based on your suggestions: > > =E2=80=9CSegment.retransmitted=E2=80=9D is true if the segment has ever b= een > retransmitted. False otherwise. > > Also RACK_detect_loss() can be further simplified by removing the checks > of Segment.retransmitted, as long as Segment.xmit_ts is invalidated upon > loss. > > =E2=80=9CSegment.xmit_ts=E2=80=9D is the time of the last transmi= ssion of a data > segment, including retransmissions, if any, with a clock granularity > specified in the Requirements section. A maximum value INFINITE_TS > indicates an invalid timestamp that represents that the Segment is not > currently in flight. > > New RACK_detect_lost(): > timeout =3D 0 > RACK.reo_wnd =3D RACK_update_reo_wnd() > > For each segment, Segment, not acknowledged yet: > // removed the old lines to check Segment.retransmitted > // > If RACK_sent_after(RACK.xmit_ts, RACK.end_seq, > Segment.xmit_ts, Segment.end_seq): > remaining =3D Segment.xmit_ts + RACK.rtt + > RACK.reo_wnd - Now() > If remaining <=3D 0: > Segment.lost =3D TRUE > Segment.xmit_ts =3D INFINITE_TS //<--- new line > Else: > timeout =3D max(remaining, timeout) > Return timeout > > So it's more clear and simpler :-) > > > > > -----Original Message----- > > From: tcpm On Behalf Of Yuchung Cheng > > Sent: Monday, September 21, 2020 4:12 PM > > To: Yi Huang > > Cc: Yuchung Cheng ; tcpm@ietf.org > > Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10 > > > > On Mon, Sep 21, 2020 at 3:18 PM Yi Huang 40microsoft.com@dmarc.ietf.org> wrote: > > > > > > Thanks Yuchung, I responded inline. > > > > > > -----Original Message----- > > > From: tcpm On Behalf Of Yuchung Cheng > > > Sent: Monday, September 21, 2020 2:53 PM > > > To: Yi Huang > > > Cc: tcpm@ietf.org > > > Subject: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-10 > > > > > > On Sun, Sep 20, 2020 at 6:16 PM Yi Huang 40microsoft.com@dmarc.ietf.org> wrote: > > > >> > > > >> Hi, > > > >> > > > >> I reviewed the latest version of RACK-TLP draft and have a few > comments/questions. > > > >> > > > >> 1. In section 5.1, "Segment.retransmitted is true if it was > retransmitted in the most recent transmission." > > > >> There are also pseudo-code explaining how retransmitted flag is > set. AFAICT, retransmitted is set if the segment is ever retransmitted > since the flag is never reset. Is this variable supposed to mean ever > retransmitted? > > > >Thanks for catching that. Segment.retransmitted MUST be reset upon > > > >a (re)transmission so it does not ever-retransmitted (i.e. it's > > > >only meant for the very last transmission) > > > > > > > RACK_transmit_data(Segment): > > > > Segment.xmit_ts =3D Now() > > > > Segment.lost =3D FALSE > > > > Segment.retransmitted =3D FALSE > > > > > > > RACK_retransmit_data(Segment): > > > > RACK_transmit_data(Segment) > > > > Segment.retransmitted =3D TRUE > > > > > > Sorry, I still don't quite get it. RACK_transmit_data is for > previously unsent data (aka new data) right? If so, it will be only calle= d > once for a given segment. Then, RACK_retransmit_data only sets it to TRUE= . > So where do we reset it? Looks like we still just initialize it to FALSE > and set it to TRUE upon retransmission. > > > > Apologize for this confusion. I now see better how the text and code > confuse you. Segment.retransmitted is meant to reflect whether the most > recent send is a retransmission or not. But since a segment can be (only) > retransmitted N times consecutively, the flag is sticky throughout once > set. To avoid future confusion, how about having two separate routines. > > > > /* Send newly unsent data */ > > RACK_transmit_new_data(Segment): > > Segment.xmit_ts =3D Now() > > Segment.lost =3D FALSE > > Segment.retransmitted =3D FALSE > > > > /* Retransmit previously sent data */ > > RACK_retransmit_data(Segment) > > Segment.xmit_ts =3D Now() > > Segment.lost =3D FALSE > > Segment.retransmitted =3D TRUE > > > > > > > > > > >> > > > >> 2. In section 6.2, p14, > > > >> " If the sender has not yet observed any reordering based on the > > > >> previous step, then RACK prioritizes quick loss recovery by usi= ng > > > >> setting RACK.reo_wnd to 0 when the number of SACKed segments > exceeds > > > >> DupThresh, or during loss recovery. > > > >> > > > >> Aside from those special conditions, RACK starts with a > conservative > > > >> reordering window of RACK.min_RTT/4. This value was chosen > because > > > >> Linux TCP used the same factor in its implementation to delay > Early > > > >> Retransmit [RFC5827] to reduce spurious loss detections in the > > > >> presence of reordering, and experience showed this worked > reasonably > > > >> well [DMCG11]." > > > >> > > > >> If I understand this correctly, if no reordering observed, TCP > should still enter loss recovery when DupACK >=3D DupThresh (RFC6675). If > reordering has been seen, this RFC6675 rule is not honored and TCP only > enters loss recovery when RACK detects loss? I think it would be great to > clarify this in the spec. > > > > > > > Your understanding is correct. will this text revision improves > clarity" > > > > "" > > > > If no reordering has been observed based on the previous step, the > sender enters Fast Recovery when the number of SACKed segments exceeds > DupThresh (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon > entering and during the loss recovery. > > > > > > > Otherwise if some reordering has been observed, RACK does not > > > > honor > > > RFC6675 rule and starts with a conservative RACK.reo_wnd of > RACK.min_RTT/4. This .... reasonably well [DMCG11]. > > > > "" > > > > > > Yeah, that's pretty clear now. > > > > > > > " If the sender has not yet observed any reordering based on the > > > > previous step, then RACK prioritizes quick loss recovery by usin= g > > > > setting RACK.reo_wnd to 0 when the number of SACKed segments > exceeds > > > > DupThresh, or during loss recovery. > > > > > > > > Aside from those special conditions, RACK starts with a > conservative > > > > reordering window of RACK.min_RTT/4. This value was chosen > because > > > > Linux TCP used the same factor in its implementation to delay > Early > > > > Retransmit [RFC5827] to reduce spurious loss detections in the > > > > presence of reordering, and experience showed this worked > reasonably > > > > well [DMCG11]." > > > > > > > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero > Window Probe (ZWP) timer". > > > will fix thanks > > > > > > > > Thanks, > > > > > > > > Yi > > > > > > > > _______________________________________________ > > > > tcpm mailing list > > > > tcpm@ietf.org > > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40= m > > > > ic > > > > ro > > > > soft.com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab > > > > 2d > > > > 7c > > > > d011db47%7C1%7C0%7C637363220297828477&sdata=3DeHYh0FXRGNS8T2LFq= 8 > > > > sz > > > > gH > > > > x43Hsfwlrog%2BZxQwJyiq0%3D&reserved=3D0 > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40mic= r > > > os > > > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7 > > > cd > > > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOT= r > > > Dx > > > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40mic= r > > > os > > > oft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7 > > > cd > > > 011db47%7C1%7C0%7C637363267745119455&sdata=3DGdXrtwnYavfLpVIYqrOT= r > > > Dx > > > U%2FOrpC7ayXhtZSuzM%2B2U%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Chuanyi%40micr= o > > soft.com%7C5ea6a38c3c0b4fb518a908d860a7379b%7C72f988bf86f141af91ab2d7c > > d011db47%7C1%7C0%7C637365619031782885&sdata=3DBZRLTHuxck9GSyKvC%2BS= A > > PIPbcEUU3MS0oC7%2Bd08Idgc%3D&reserved=3D0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000d6603805b0150704 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 24, 2020 at 4:15 PM Yi Huang = <huanyi=3D40microsoft.= com@dmarc.ietf.org> wrote:
Yes, this is much better. You = could also change the loop condition to "For each unacknowledged and n= ot lost segment, Segment:" and you wouldn't need INFINITE_TS, whic= h sounds a bit more intuitive to me. Or even simpler "For each segment= , Segment, not lost yet" since it is usually assumed that cumulatively= ACKed segments are no longer being tracked. Anyway, the new pseudocode and= text look pretty good.

Expressing this= as=C2=A0"For each unacknowledged and not lost segment, Segment:"= or "For each segment, Segment, not lost yet" might be a little u= nclear or ambiguous. The issue is that we do want to consider in this loop = the segments that were marked lost but then later retransmitted.=C2=A0 The = way Yuchung expressed the loop condition avoids that issue.

<= /div>
best,
neal

=C2=A0

-----Original Message-----
From: Yuchung Cheng <ycheng@google.com>
Sent: Thursday, September 24, 2020 9:30 AM
To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>
Cc: Yi Huang <= huanyi@microsoft.com>; tcpm@ietf.org
Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10

On Mon, Sep 21, 2020 at 4:37 PM Praveen Balasubramanian <pravb=3D40microsoft.co= m@dmarc.ietf.org> wrote:
>
> >> Segment.retransmitted is meant to reflect whether the most re= cent
> >> send is a retransmission or not
> The "most recent send" here is confusing. Why not just state= that this reflects whether the segment was ever retransmitted?
We'll make the change based on your suggestions:

=E2=80=9CSegment.retransmitted=E2=80=9D is true if the segment has ever bee= n retransmitted. False otherwise.

Also RACK_detect_loss() can be further simplified by removing the checks of= Segment.retransmitted, as long as Segment.xmit_ts is invalidated upon loss= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9CSegment.xmit_ts=E2=80=9D is the time o= f the last transmission of a data segment, including retransmissions, if an= y, with a clock granularity specified in the Requirements section. A maximu= m value INFINITE_TS indicates an invalid timestamp that represents that the= Segment is not currently in flight.

New RACK_detect_lost():
=C2=A0 =C2=A0 timeout =3D 0
=C2=A0 =C2=A0 RACK.reo_wnd =3D RACK_update_reo_wnd()

=C2=A0 =C2=A0 For each segment, Segment, not acknowledged yet:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // removed the old lines to check Segment.retra= nsmitted
=C2=A0 =C2=A0 =C2=A0 =C2=A0 //
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If RACK_sent_after(RACK.xmit_ts, RACK.end_seq,<= br> =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=A0Segment.xmit_ts, Segment.end_seq):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 remaining =3D Segment.xmit_ts + R= ACK.rtt +
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 RACK.reo_wnd - Now()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If remaining <=3D 0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Segment.lost =3D TR= UE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Segment.xmit_ts =3D= INFINITE_TS //<--- new line
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Else:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 timeout =3D max(rem= aining, timeout)
=C2=A0 =C2=A0 Return timeout

So it's more clear and simpler :-)

>
> -----Original Message-----
> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
> Sent: Monday, September 21, 2020 4:12 PM
> To: Yi Huang <huanyi=3D40microsoft.com@dmarc.ietf.org>
> Cc: Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org>; tcpm@ietf.org
> Subject: Re: [tcpm] [EXTERNAL] Re: A review of draft-ietf-tcpm-rack-10=
>
> On Mon, Sep 21, 2020 at 3:18 PM Yi Huang <huanyi=3D40microsoft.com@dmarc.i= etf.org> wrote:
> >
> > Thanks Yuchung, I responded inline.
> >
> > -----Original Message-----
> > From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
> > Sent: Monday, September 21, 2020 2:53 PM
> > To: Yi Huang <huanyi=3D40microsoft.com@dmarc.ietf.org>
> > Cc: tcpm@ietf.= org
> > Subject: [EXTERNAL] Re: [tcpm] A review of draft-ietf-tcpm-rack-1= 0
> >
> > On Sun, Sep 20, 2020 at 6:16 PM Yi Huang <huanyi=3D40microsoft.com@dm= arc.ietf.org> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I reviewed the latest version of RACK-TLP draft and have= a few comments/questions.
> > >>
> > >> 1. In section 5.1, "Segment.retransmitted is true i= f it was retransmitted in the most recent transmission."
> > >> There are also pseudo-code explaining how retransmitted = flag is set. AFAICT, retransmitted is set if the segment is ever retransmit= ted since the flag is never reset. Is this variable supposed to mean ever r= etransmitted?
> > >Thanks for catching that. Segment.retransmitted MUST be reset= upon
> > >a (re)transmission so it does not ever-retransmitted (i.e. it= 's
> > >only meant for the very last transmission)
> >
> > > RACK_transmit_data(Segment):
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment.xmit_ts =3D = Now()
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment.lost =3D FAL= SE
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment.retransmitte= d =3D FALSE
> >
> > >=C2=A0 =C2=A0RACK_retransmit_data(Segment):
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RACK_transmit_data(S= egment)
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment.retransmitte= d =3D TRUE
> >
> > Sorry, I still don't quite get it. RACK_transmit_data is for = previously unsent data (aka new data) right? If so, it will be only called = once for a given segment. Then, RACK_retransmit_data only sets it to TRUE. = So where do we reset it? Looks like we still just initialize it to FALSE an= d set it to TRUE upon retransmission.
>
> Apologize for this confusion. I now see better how the text and code c= onfuse you. Segment.retransmitted is meant to reflect whether the most rece= nt send is a retransmission or not. But since a segment can be (only) retra= nsmitted N times consecutively, the flag is sticky throughout once set. To = avoid future confusion, how about having two separate routines.
>
> /* Send newly unsent data */
> RACK_transmit_new_data(Segment):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Segment.xmit_ts =3D Now()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Segment.lost =3D FALSE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Segment.retransmitted =3D FAL= SE
>
> /* Retransmit previously sent data */
> RACK_retransmit_data(Segment)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment.xmit_ts =3D Now()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment.lost =3D FALSE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment.retransmitted =3D TRUE=
>
>
> >
> > >>
> > >> 2. In section 6.2, p14,
> > >> "=C2=A0 =C2=A0If the sender has not yet observed an= y reordering based on the
> > >>=C2=A0 =C2=A0 previous step, then RACK prioritizes quick = loss recovery by using
> > >>=C2=A0 =C2=A0 setting RACK.reo_wnd to 0 when the number o= f SACKed segments exceeds
> > >>=C2=A0 =C2=A0 DupThresh, or during loss recovery.
> > >>
> > >>=C2=A0 =C2=A0 Aside from those special conditions, RACK s= tarts with a conservative
> > >>=C2=A0 =C2=A0 reordering window of RACK.min_RTT/4.=C2=A0 = This value was chosen because
> > >>=C2=A0 =C2=A0 Linux TCP used the same factor in its imple= mentation to delay Early
> > >>=C2=A0 =C2=A0 Retransmit [RFC5827] to reduce spurious los= s detections in the
> > >>=C2=A0 =C2=A0 presence of reordering, and experience show= ed this worked reasonably
> > >>=C2=A0 =C2=A0 well [DMCG11]."
> > >>
> > >> If I understand this correctly, if no reordering observe= d, TCP should still enter loss recovery when DupACK >=3D DupThresh (RFC6= 675). If reordering has been seen, this RFC6675 rule is not honored and TCP= only enters loss recovery when RACK detects loss? I think it would be grea= t to clarify this in the spec.
> >
> > > Your understanding is correct. will this text revision impro= ves clarity"
> > > ""
> > > If no reordering has been observed based on the previous ste= p, the sender enters Fast Recovery when the number of SACKed segments excee= ds DupThresh (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon e= ntering and during the loss recovery.
> >
> > > Otherwise if some reordering has been observed, RACK does no= t
> > > honor
> > RFC6675 rule and starts with a conservative RACK.reo_wnd of RACK.= min_RTT/4. This .... reasonably well [DMCG11].
> > > ""
> >
> > Yeah, that's pretty clear now.
> >
> > > "=C2=A0 =C2=A0If the sender has not yet observed any re= ordering based on the
> > >=C2=A0 =C2=A0 previous step, then RACK prioritizes quick loss= recovery by using
> > >=C2=A0 =C2=A0 setting RACK.reo_wnd to 0 when the number of SA= CKed segments exceeds
> > >=C2=A0 =C2=A0 DupThresh, or during loss recovery.
> > >
> > >=C2=A0 =C2=A0 Aside from those special conditions, RACK start= s with a conservative
> > >=C2=A0 =C2=A0 reordering window of RACK.min_RTT/4.=C2=A0 This= value was chosen because
> > >=C2=A0 =C2=A0 Linux TCP used the same factor in its implement= ation to delay Early
> > >=C2=A0 =C2=A0 Retransmit [RFC5827] to reduce spurious loss de= tections in the
> > >=C2=A0 =C2=A0 presence of reordering, and experience showed t= his worked reasonably
> > >=C2=A0 =C2=A0 well [DMCG11]."
> > >
> > > 3. [NIT] In section 8, " Zero window probe (ZWP) timer&= quot; -> "Zero Window Probe (ZWP) timer".
> > will fix thanks
> > >
> > > Thanks,
> > >
> > > Yi
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > tcpm@ietf= .org
> > > https://nam06.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Chuan= yi%40m
> > > ic
> > > ro
> > > soft.com%7C71748af3b9ae4232346008d85e78d063%7C72f988bf86f141af91ab=
> > > 2d
> > > 7c
> > > d011db47%7C1%7C0%7C637363220297828477&amp;sdata=3DeHYh0F= XRGNS8T2LFq8
> > > sz
> > > gH
> > > x43Hsfwlrog%2BZxQwJyiq0%3D&amp;reserved=3D0
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org<= /a>
> > https://nam06.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> > = ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40m= icr
> > os
> > o= ft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7
> > cd
> > 011db47%7C1%7C0%7C637363267745119455&amp;sdata=3DGdXrtwnYavfL= pVIYqrOTr
> > Dx
> > U%2FOrpC7ayXhtZSuzM%2B2U%3D&amp;reserved=3D0
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org<= /a>
> > https://nam06.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> > = ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40m= icr
> > os
> > o= ft.com%7C4cc0adb558a64fedcfac08d85e83dca9%7C72f988bf86f141af91ab2d7
> > cd
> > 011db47%7C1%7C0%7C637363267745119455&amp;sdata=3DGdXrtwnYavfL= pVIYqrOTr
> > Dx
> > U%2FOrpC7ayXhtZSuzM%2B2U%3D&amp;reserved=3D0
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://nam06.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> ietf.= org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Chuanyi%40micro=
> soft.= com%7C5ea6a38c3c0b4fb518a908d860a7379b%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C637365619031782885&amp;sdata=3DBZRLTHuxck9GSyKv= C%2BSA
> PIPbcEUU3MS0oC7%2Bd08Idgc%3D&amp;reserved=3D0
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000d6603805b0150704-- From nobody Fri Sep 25 06:52:21 2020 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 A22D83A0E25 for ; Fri, 25 Sep 2020 06:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 iPe1r5tySQ9M for ; Fri, 25 Sep 2020 06:52:18 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10C83A0E23 for ; Fri, 25 Sep 2020 06:52:17 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4ByYJ00rF7z8tr4; Fri, 25 Sep 2020 15:52:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601041936; bh=amehv7uYiVYmMps877vWql9lLQ1upzTlGaO+LeKB438=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=sbTGH9I3OhJRMTW4hyNGxVg0sSVbXunQv7rWYq0BHmTpmvbwD86nYkIjsBVAuaiHS lqDKDhvrv593jKXGJD/wz9T9j68E4H/cVg8O7DM8OK46RyvxF9cbros1YSAyMlNsDn tcgxoUNhquxfLph/jvKq75228pABX2UAuZNJAK28wML74E4sMm5NEU4cmTsLulIkOl uJpkFyJijx0LaNApiQCZ4nMtsQV1C+QPNp30cDPYM6gRVyspg+YraeVDx0lJElJJLD tMa8Eq7eaL7UGVcOzz44NwD2mr7AeDgCAGzI03QxGmwAXBtB8x3bo7jEOQoGv0frmn bGjD5vD6UTvfg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4ByYHz70gwzCqkd; Fri, 25 Sep 2020 15:52:15 +0200 (CEST) From: To: "Scharf, Michael" , "tcpm@ietf.org Extensions" Thread-Topic: WGLC for 793bis - REVIEW NEEDED Thread-Index: AdaNr7PqnFNNBpXDQaKL+djVtoCPWgFkrhdg Date: Fri, 25 Sep 2020 13:52:15 +0000 Message-ID: <25639_1601041936_5F6DF610_25639_379_1_787AE7BB302AE849A7480A190F8B933031546B9F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2DD8004B@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DD8004B@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for 793bis - REVIEW NEEDED 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, 25 Sep 2020 13:52:20 -0000 Hi all,=20 Wes already addressed my comments in previous versions of the spec. Please find some edits/nits/comments: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-i= etf-tcpm-rfc793bis-18-rev%20Med.pdf=20 * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ie= tf-tcpm-rfc793bis-18-rev%20Med.docx=20 The document is almost ready to move forward. Many thanks to Wes for carrying this important work.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, > Michael > Envoy=E9=A0: vendredi 18 septembre 2020 14:12 > =C0=A0: tcpm@ietf.org Extensions > Objet=A0: [tcpm] WGLC for 793bis - REVIEW NEEDED >=20 > Dear TCPM contributors, >=20 > This e-mail starts a working group last call for draft-ietf-tcpm- > rfc793bis-18. Information about the document can be found at this > link: >=20 > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ >=20 > For instance, the current version can be found at > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-18. >=20 > When adopting draft-ietf-tcpm-rfc793bis, the TCPM working group > consensus was to limit the scope of 793bis to TCP changes that are > specified either in standards-track RFCs or in verified errata. > Also, the consensus was to focus on the base protocol and exclude > mechanisms that can be specified separately (e.g., congestion > control). As a result, 793bis should in principle not contain > anything new. Nonetheless, we all know that TCP is a complex > protocol and even small details of the specification matter a lot. >=20 > Given that 793bis will obsolete RFC 793, which is one of the most > important Internet Standards, this WGLC will run for *four weeks*, > i.e., until October 16. >=20 > Therefore, *your* help is needed: PLEASE review 793bis in the next > weeks! The earlier, the better... >=20 > - Any comments or suggestions are important and highly appreciated. > Even if you don't speak up often on the TCPM mailing list, please > let us know if you have any feedback. >=20 > - Even if you read the document without finding any errors or issue, > please let us know ("+1"). >=20 > - It is also perfectly fine to look only at a subset of the > document, e.g., if you are familiar with specific details of TCP. > Partial reviews are welcome, too. >=20 > - If you own TCP running code, you definitively should have a very > close look; this document is supposed to be the new base > specification of TCP. >=20 > RFC 793 lays the ground for all work in TCPM, and 793bis is probably > one of the most important deliverables of TCPM. Please help us with > completing this milestone. >=20 > Thanks! >=20 > Michael Scharf > Yoshifumi Nishida > Michael Tuexen > (TCPM chairs) >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 30 14:44:28 2020 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 C77233A0BC0; Wed, 30 Sep 2020 14:44:26 -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.17.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <160150226674.15636.3838107625700718158@ietfa.amsl.com> Date: Wed, 30 Sep 2020 14:44:26 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-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: Wed, 30 Sep 2020 21:44:27 -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 : The RACK-TLP loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Priyaranjan Jha Filename : draft-ietf-tcpm-rack-11.txt Pages : 31 Date : 2020-09-30 Abstract: This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgements (SACK) [RFC2018] and has two parts: RACK ("Recent ACKnowledgment") starts fast recovery quickly using time-based inferences derived from ACK feedback. TLP ("Tail Loss Probe") leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used DUPACK threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DUPACK threshold approach in [RFC5681][RFC6675]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-11 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-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 Wed Sep 30 14:50:41 2020 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 3D9703A0C20 for ; Wed, 30 Sep 2020 14:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 H3UtZVn8s-fB for ; Wed, 30 Sep 2020 14:50:38 -0700 (PDT) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 137543A0C1D for ; Wed, 30 Sep 2020 14:50:38 -0700 (PDT) Received: by mail-vk1-xa2c.google.com with SMTP id m8so672382vka.6 for ; Wed, 30 Sep 2020 14:50:38 -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; bh=xk0v4m+SepKkKbvJqboQIu3/JS5NdSaQtQzNhxtWD9E=; b=iRuLSJz2lYlAyFPXW9Co179NZcCSPBvGGpfV7zwZMHcyfWmDol3ubXmSrxcdaXNWnd COsqXRWOcTzh2XMMCpXxY6upH1HZdYDQsfUE4a0YAbGPlv62225hWlPxGt2WkC0Mc+in 9SMA0Gs2teXghEOkDb4LjZ/y8koz27DrxP317S2zP37QClkUJ3EtmMPZ0BZKzUYkAZ8I 4nISlL/IhQVStviAsi1vwl4EVMa7PJ6IghWBavSTMrT78YmYPSkLbqSN8LoAyN1QfI17 dI4fzSiCEM5s60j1kGBY0xJ1zn/VzVzlgpwV6d8ZaHk0RZys29lp9pm4tVUg4hb7BE+g k+0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xk0v4m+SepKkKbvJqboQIu3/JS5NdSaQtQzNhxtWD9E=; b=P5AOTPyPhZumQC3ZqPEeJYaUT06AkC0cKSicDKA4LGcP/N/oibxiU6HFmwRpBDkQtF W9lnjUwIawalatGolzH9DsrnxRtBtzcddSLvbr4uhdaF2aTplFeVPlH4m7De51sLdNiu PwtRN62/XSbHW0wwBhXBr9IZfcJGdqqNtb/08H108p/T+XtsbTVWAUVUhW/wev655rlx GWkOoWFNPG1a9QuGciIIqHteRizqa4yGzOx5xgKT+sNW2p2mvqjrBjtdbVHiO5wAE7Fg M6Fbmzdk7jV1XwwXBgNwDKM9XA4FDBlKI+dG9tEnfcaJFoVievMg+WyZRd241MQstabh zZgQ== X-Gm-Message-State: AOAM533RHTJ3LJ/jyucbyLsL2Yxt0ueeD5CbYGBKQx1D3U6+grOQ0nDD cZfDugDVtBsPhxcRIv0sONekGznYKVIJ1ijImdVMcLH90MM= X-Google-Smtp-Source: ABdhPJx8CFMntyKNBkyHNG98OpyKZmWZcADFoX3Ghl8I2xB5S7/1LYEAd+MlfS0YyvrDvnueVU/ZcHWgZ2h3YanJ0pc= X-Received: by 2002:ac5:c842:: with SMTP id g2mr2970375vkm.19.1601502636727; Wed, 30 Sep 2020 14:50:36 -0700 (PDT) MIME-Version: 1.0 References: <160150226674.15636.3838107625700718158@ietfa.amsl.com> In-Reply-To: <160150226674.15636.3838107625700718158@ietfa.amsl.com> From: Yuchung Cheng Date: Wed, 30 Sep 2020 14:50:00 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000c532a805b08ee337" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rack-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: Wed, 30 Sep 2020 21:50:39 -0000 --000000000000c532a805b08ee337 Content-Type: text/plain; charset="UTF-8" Hi This latest RACK revision includes the changes to address the WGLC reviews discussed in the list. The core algorithm remains but the pseudo code is slightly simplified with the suggested clarifications on Segment.retransmitted definition (please see the diff). Thanks for all the reviews again! Yuchung --000000000000c532a805b08ee337 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

This latest RACK revision includes t= he changes to address the WGLC reviews discussed in the list. The core algo= rithm remains but the pseudo code is slightly simplified with the suggested= clarifications on Segment.retransmitted definition (please see the diff). = Thanks for all the reviews again!

Yuchung

--000000000000c532a805b08ee337--