From nobody Fri Sep 2 08:08:06 2016 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 C9DEA12D0AF for ; Fri, 2 Sep 2016 02:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCBtWPyInxh4 for ; Fri, 2 Sep 2016 02:11:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 02E8B12D129 for ; Fri, 2 Sep 2016 02:11:43 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-b7-57c9424e328c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 51.7B.04209.E4249C75; Fri, 2 Sep 2016 11:11:42 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 2 Sep 2016 11:11:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jgj3TA8hMn+UGpC73a/uzXJhbDxbbUxgNLQwAYkBTTU=; b=crszNDbgaAOQEGpY4TcgownFBAVeAZnsqJIdViLd4xpB46cG40R49Gja2oL3z3BB82kOAOAXonUfKZGwGVgDjPA1uzFxNHIr+8BYTjpiooumCgvxA7hLi3BGdCeHpduEstJNuDZEryBrf42xFE1NipeMSIlIMOKZOaWzRBQeLGE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15; Fri, 2 Sep 2016 09:11:39 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0587.018; Fri, 2 Sep 2016 09:11:39 +0000 From: Ingemar Johansson S To: Neal Cardwell Thread-Topic: [tcpm] [e2e] TCP HyStart patch deployment Thread-Index: AdCXp+zNDAZ7zydkTra0wALqZYyJLQH+JqqAA0qsYsAOCTWagAADKaaAABZGAgAAAuJsAABGVozQ///TRACAAB/3AIAAKj8AgAEIjoCAABVIgP//hZhA/9ZLHXD/q+ph8P9XvOWw/q9KtpD9XnrA8Pq87vsQ9Xnw1wDq7PsqANXZxFgAq6D0qADXJ4+XAK5OzT0A2sVIJmC1ihllAOsP0S4A Date: Fri, 2 Sep 2016 09:11:39 +0000 Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34B2E666@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E64B65@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E65133@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E676EF@XCHSRV01.main.orange.md> <1441314842.8932.222.camel@edumazet-glaptop2.roam.corp.google.com> <1441385297.17208.6.camel@edumazet-glaptop2.roam.corp.google.com> <7DBBB686E19D2049ADAACD210B474BB10166E856CA@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD84BC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E859FB@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD86EC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E85C4E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD880B@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E8BDBA@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10167E64F3E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB08A1@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10167E8DC6E@XCHSRV01.main.orange.md> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-office365-filtering-correlation-id: 2a1fb41f-7230-4a83-4abf-08d3d3112606 x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 6:7F4kqq5qwQl0Z2EGu6MIgDQe2BebJPU2euXlkThopmCAMNqUpczqJQ0vtDBg1cKDpM7dZ6LBui+6lPBTz5SV3TCccYk5+piD52es/uCkF5T0kLxwPcSwDjZQ7ShRso+5/v942gsq6q2oW04H8E2NlI1Ie7ZCPd+6rLP3m7GdHffpI9Ge3RFAhs3bAbPqXKijCnnbSQoyWTLvnXnbukkJDgHKS3q0Uq9HuhL87Fowp1tfuIxcYp68SRWyPxsMXV1JnO6nYnya3aKCSQPikuIITCiRSc859Wftm80T71eCI/A=; 5:lUyJ67LjFXv3F1o4BuWDCnPvA2O/nckpUZZ5i5Z2qs0nEFZ5f06BkEwPGYUdkZMU4VwTkUZRncwBREXFZc6Rb5ZNcoMnURAqqgdf6q0pzFawhEZzsYCCqAqNSqz20phtuppmlXBGpy6xDw2vrSLweg==; 24:/RpEaD0eL7k6a06AtCqDU0HASfaOmjJ+TsBmJrDx0wJXLWHcsR9M+BiklVcHLDclZpX+17NKTYVuqXTm2WQOCR3cuygwBK/FMS2PI3m20e0=; 7:2+Ie3lG8dm1bv6gr6acpo2vuUnZVoMpTtjuX7LzbnJcr7Vo97E78vU932mLArir2yxsNzOH2MJyPNbLz472QwlZlznNoMQJ4tIKRhB8c23bD2co6dQmYNzcyDp/11/yUHLlS33xPTBm1Zazqv5jaz/zOSMJ2x9EPdEJVpxaKyUB4ZhC+JokFgGUh6A4teLWz64FPmAZHuKxD7q31EC9bSfCikxwdFvW5i4xX3xiQjZ6QRL0UdJlmLEx/gH6RQoa1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB346; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(6029001)(7916002)(11905935001)(189002)(199003)(377454003)(24454002)(13464003)(51914003)(101416001)(2906002)(122556002)(86362001)(7696003)(81156014)(15975445007)(7736002)(74316002)(93886004)(345774005)(76176999)(81166006)(102836003)(68736007)(3660700001)(6116002)(106356001)(54356999)(305945005)(66066001)(3846002)(4001430100002)(19580395003)(7846002)(3280700002)(11100500001)(105586002)(10400500002)(19580405001)(5002640100001)(8676002)(189998001)(5660300001)(50986999)(76576001)(110136002)(4326007)(92566002)(97736004)(586003)(77096005)(2900100001)(9686002)(87936001)(107886002)(33656002)(8936002)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2016 09:11:39.2879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+XYuOw5XX0vbi4rVKihLzRo1SCKtYBRlWrQQspYe5vDKjkYF lRjlLaNWRtrFFmOVZNYQr1NzpDazu4makzJneB1dyCS7eHYM+u/53uf3XvkYQmal/Bh9agZr SNUmK2gJWbyvenXwzkiHZvXFz3KVq3VArKp/XkSqGt3PaFVuX8OMunIBqR53tiJVlaNUpHL/ eUhsYtS1JU6x+qY1U202T4nUZosLqXPbHhC7qFhJeAKbrD/MGkI3HpQkXmmvodIHko7Yvhnp LJSlz0deDGAlNN4fJPKRhJHhCgSPuspo3pDhNgRGix9vkLiQgKnOZrFAGUXwtboECY8WBLm9 30k+hcbhcNc+iXjtg5eD89Z7D0TgqwTU1X2jeGM+Xge92ROEAK0H49MznuY+eAiBq/6UJ5vE S+HqhXFRPmIYKY6FojxS6OaaA6byETHPeOFouHXxvIdHeAFMtt8T8ZrAcugdLBUJ22Ew214Q gvaF4Y+/KYGPhy89hZQQXwTTrwdoQe+Ae4UVnoEAj9NwpyuXFIyt8MtUPVtUD9YfJoIfDvB2 yHMtEfgqBN3N5bPNAqDjbBYSDDMNo8WjpHBWFm6Xn0bCKfzA2ZmHzqOgkv8GL5mpS+AVUFEX KoQXw6WCD2JeS/E8cBQPkjcRWYZ8OZY7lKJbszaENejjOS4tNSSVzbCimZ/UXPlzWQ16MxZh R5hBCm/pQeUTjYzSHuaOptgRMITCRzo3wqGRSRO0R4+xhrQDhsxklrMjf4ZUyKVRw4s1MqzT ZrBJLJvOGv65IsbLLwtllrrVOi4psmaq8u3xlKhxWLT5S1F0ILmDDgmv6nvVn/Fyw8IjW4Li LHKiw36s3/96hLdO7cy2KJtqrwUUTDTX2VZoum/Yjr9z28R7VzblVI4E1jh2jzS1BMebVjmj T4z1jFOHqp4rT14uskx/bczZ9ikmLGaP/7mk/XGuoQaJW0FyidqwIMLAaf8CUJdu5UUDAAA= Archived-At: X-Mailman-Approved-At: Fri, 02 Sep 2016 08:08:03 -0700 Cc: Kristofer Sandlund , "tcpm@ietf.org" , Piers O'Hanlon , Sangtae Ha , Ingemar Johansson S , Eric Dumazet , "end2end-interest@postel.org" Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 02 Sep 2016 09:11:47 -0000 SGkNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuIA0KV2hhdCB3ZSBzZWUgaXMgdGhhdCBBQ0tz IHRoYXQgYXJlIGRlbGF5ZWQgY2FuIGdpdmUgb2NjYXNpb25hbCBSVFQgc3Bpa2VzIHRoYXQgZWFz aWx5IGNhdXNlIHNsb3cgc3RhcnQgdG8gZXhpdCwgd2l0aCBsb3cgdGhyb3VnaHB1dCBhcyBhIHJl c3VsdC4gDQpXaGF0IGNhbiBpbXByb3ZlIHRoaW5ncyBoZXJlIGlzIHNvbWUgYW1vdW50IG9mIHN0 YXRpc3RpY2FsIGZpbHRlcmluZyB0aGF0IHJlbW92ZXMgb2NjYXNpb25hbCBkZWxheSBzcGlrZXMs IHBlcmhhcHMgaXQgaXMgYXMgc2ltcGxlIGFzIHRoYXQgdGhlIGFsZ29yaXRobSByZXF1aXJlcyB0 aGF0IHRoZSB0aHJlc2hvbGQgaXMgZXhjZWVkZWQgTiB0aW1lcyBiZWZvcmUgc2xvd3N0YXJ0IGV4 aXRzLg0KUXVlc3Rpb24gOiBIYXMgc29tZWJvZHkgbG9va2VkIHRoZSBwb3NzaWJpbGl0eSB0byB1 c2UgdGhlIHJlY2VpdmUgdGltZXN0YW1wcyBhcyBhIG1lYW5zIHRvIHJlbW92ZSBSVFQgb3V0bGll cnMgdGhhdCBhcmUgY2F1c2VkIGJ5IGRlbGF5ZWQgQUNLcyA/DQpUaGUgZGVsYXlfbWluLzggaXMg YWxzbyBvbmUgdGhpbmcgd29ydGggbG9va2luZyBhdCwgaXQgc2VlbXMgbGlrZSB0aGlzIG1heSBi ZSBhIGJpdCB0b28gbG93LCBlc3BlY2lhbGx5IGZvciB0aGUgY2FzZXMgd2hlcmUgUlRUbWluIGlz IHZlcnkgbG93IGFscmVhZHkgZHVlIHRvIHNob3J0IGRpc3RhbmNlIHRvIHRoZSBzZXJ2ZXIuDQpB bHNvIEkgdW5kZXJzdGFuZCB0aGF0IEhZU1RBUlRfTUlOX1NBTVBMRVMgYW5kIGh5c3RhcnRfbG93 X3dpbmRvdyBhcmUgZGV2aXNlZCB3aGVuIHRoZSBpbml0aWFsIGNvbmdlc3Rpb24gd2luZG93IHdh cyAzTVNTLCB0b2RheSBpdCBzZWVtcyBsaWtlIHRoZSBub3JtIGlzIDEwTVNTLCBwZXJoYXBzIHRo ZXNlIHZhbHVlcyBzaG91bGQgYmUgaW5jcmVhc2VkID8NCg0KL0luZ2VtYXINCg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5lYWwgQ2FyZHdlbGwgW21haWx0bzpuY2Fy ZHdlbGxAZ29vZ2xlLmNvbV0NCj4gU2VudDogZGVuIDMwIGF1Z3VzdGkgMjAxNiAxNjowMA0KPiBU bzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+ DQo+IENjOiBWZWFjZXNsYXYgUk9NQU4gPFZlYWNlc2xhdi5Sb21hbkBvcmFuZ2UubWQ+OyBFcmlj IER1bWF6ZXQNCj4gPGVkdW1hemV0QGdvb2dsZS5jb20+OyBFcmljIER1bWF6ZXQgPGVyaWMuZHVt YXpldEBnbWFpbC5jb20+Ow0KPiB0Y3BtQGlldGYub3JnOyBQaWVycyBPJ0hhbmxvbiA8cC5vaGFu bG9uQGdtYWlsLmNvbT47IFNhbmd0YWUgSGENCj4gPHNhbmd0YWUuaGFAZ21haWwuY29tPjsgZW5k MmVuZC1pbnRlcmVzdEBwb3N0ZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gW2UyZV0gVENQ IEh5U3RhcnQgcGF0Y2ggZGVwbG95bWVudA0KPiANCj4gSGksDQo+IA0KPiBBcyBvbmUgZGF0YSBw b2ludCwgYXQgR29vZ2xlIHRoZSBnb29nbGUuY29tIGFuZCBZb3VUdWJlIFRDUCBzdGFja3MgdXNl IEVyaWMNCj4gRHVtYXpldCdzIGZxIHBhY2luZyBxZGlzYzoNCj4gICBodHRwczovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy84OC9zbGlkZXMvc2xpZGVzLTg4LXRjcG0tOS5wZGYNCj4gICBodHRw czovL2x3bi5uZXQvQXJ0aWNsZXMvNTY0OTc4Lw0KPiBFcmljIGRpc2NvdmVyZWQgdGhhdCB0aGUg SHlzdGFydCBBY2sgVHJhaW4gbWVjaGFuaXNtIGRvZXMgbm90IHdvcmsgd2VsbCB3aXRoDQo+IHBh Y2luZywgc28gZm9yIFRDUCBhdCBHb29nbGUgd2UgaGF2ZSBsb25nIGFnbyBkaXNhYmxlZCB0aGUg SHlzdGFydCBBY2sgVHJhaW4NCj4gbWVjaGFuaXNtLCBhbmQganVzdCB1c2UgdGhlIGRlbGF5IG1l Y2hhbmlzbS4NCj4gDQo+IEl0IGlzIGFsc28gb3VyIGV4cGVyaWVuY2UgdGhhdCB0aGUgSHlzdGFy dCBkZWxheSBtZWNoYW5pc20gb2Z0ZW4gdHJpZ2dlcnMNCj4gc3B1cmlvdXNseSBmb3IgY2VsbHVs YXIgYW5kIHdpZmkgbGlua3MsIGFuZCBpcyBkaWZmaWN1bHQgdG8gdHVuZSBpbiBhIHdheSB0aGF0 IHdvcmtzDQo+IHdlbGwgZ2VuZXJhbGx5LiBJdCBtYXkgYmUgdXNlZnVsIGZvciBzb21lb25lIGlu IHRoZSBjb21tdW5pdHkgdG8gZG8gYSBicm9hZA0KPiBpbnZlc3RpZ2F0aW9uIHRvIHNlZSBpZiB0 aGVyZSBhcmUgSFlTVEFSVF9ERUxBWV9NSU4sDQo+IEhZU1RBUlRfREVMQVlfTUFYLCBhbmQgdGhy ZXNob2xkIHJhdGlvIHZhbHVlcyB0aGF0IHdvcmsgYmV0dGVyIHRoYW4gdGhlDQo+IGN1cnJlbnQg dmFsdWVzIGFjcm9zcyBhIHZhcmlldHkgb2YgaW1wb3J0YW50IGxhc3QtbWlsZSB0ZWNobm9sb2dp ZXMgKGNlbGx1bGFyLA0KPiBjYWJsZSwgRFNMLCB3aWZpLC4uLikuDQo+IA0KPiBuZWFsDQo+IA0K PiBPbiBUdWUsIEF1ZyAzMCwgMjAxNiBhdCAzOjAyIEFNLCBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+ IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ID4gSGkNCj4gPg0K PiA+IEFuIG9sZCB0aHJlYWQgcmVzdW1lZCBmcm9tIG91ciBzaWRlIGFzIHdlIHNlZSBpc3N1ZXMg d2l0aCB0aGUgSHlTdGFydA0KPiBhbGdvcml0aG0gaW4gQ3ViaWMgd2hlbiB3ZSBldmFsdWF0ZSBz b21lIG5ldyBMVEUgYW5kIDVHIGFjY2VzcyBjb25jZXB0cy4NCj4gPiBPbmUgcHJvYmxlbSBpcyB0 aGUgcGFja2V0IHRyYWluIGFsZ29yaXRobSA6IEkgdW5kZXJzdGFuZCB0aGF0IGl0IGRvZXMgbm90 DQo+IHdvcmsgd2VsbCB3aXRoIHBhY2tldCBwYWNpbmcgYW5kIGlzIHRoZXJlZm9yZSBkaXNhYmxl ZCBpbiBRVUlDLiBJcyB0aGUgcGFja2V0DQo+IHRyYWluIGFsZ29yaXRobSB1c2VkIGluIGdlbmVy YWwsIEkgZ3Vlc3Mgbm90IGluIHRoZSBjYXNlcyB3aGVuIHBhY2tldCBwYWNpbmcgaXMNCj4gZW5h YmxlZCBvciA/DQo+ID4NCj4gPiBUaGUgb3RoZXIgcHJvYmxlbSBpcyB0aGUgZGVsYXkgYWxnb3Jp dGhtLCBteSBpbXByZXNzaW9uIGJhc2VkIG9uDQo+ID4gbGltaXRlZCBzaW11bGF0aW9uIGV4cGVy aW1lbnRzIGlzIHRoYXQgdGhlIEhZU1RBUlRfREVMQVlfTUlOIG5lZWRzIHRvDQo+ID4gYmUgc2V0 IHRvIH4xNm1zIHRvIGF2b2lkIHRoYXQgSHlTdGFydCBleGl0cyBwcmVtYXR1cmVseS4gVGhlIHF1 ZXN0aW9uDQo+ID4gaXMgaWYgdGhpcyBjYXVzZXMgcHJvYmxlbSB3aXRoIG90aGVyIGFjY2VzcyB0 eXBlcyAoRFNMID8pDQo+ID4NCj4gPiBDb21tZW50cyB3ZWxjb21lDQo+ID4gL0luZ2VtYXINCj4g Pg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFZlYWNl c2xhdiBST01BTiBbbWFpbHRvOlZlYWNlc2xhdi5Sb21hbkBvcmFuZ2UubWRdDQo+ID4+IFNlbnQ6 IGRlbiAzIG5vdmVtYmVyIDIwMTUgMjA6MDYNCj4gPj4gVG86IEluZ2VtYXIgSm9oYW5zc29uIFMg PGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPjsgTmVhbA0KPiA+PiBDYXJkd2VsbCA8 bmNhcmR3ZWxsQGdvb2dsZS5jb20+DQo+ID4+IENjOiBFcmljIER1bWF6ZXQgPGVkdW1hemV0QGdv b2dsZS5jb20+OyBFcmljIER1bWF6ZXQNCj4gPj4gPGVyaWMuZHVtYXpldEBnbWFpbC5jb20+OyB0 Y3BtQGlldGYub3JnOyBQaWVycyBPJ0hhbmxvbg0KPiA+PiA8cC5vaGFubG9uQGdtYWlsLmNvbT47 IFNhbmd0YWUgSGEgPHNhbmd0YWUuaGFAZ21haWwuY29tPjsNCj4gZW5kMmVuZC0NCj4gPj4gaW50 ZXJlc3RAcG9zdGVsLm9yZw0KPiA+PiBTdWJqZWN0OiBSRTogW3RjcG1dIFtlMmVdIFRDUCBIeVN0 YXJ0IHBhdGNoIGRlcGxveW1lbnQNCj4gPj4NCj4gPj4gWW91IGFyZSByaWdodCwgaXQgd2Fzbid0 IG1vZGlmaWVkIGFuZCBzdGF5ZWQgYXQgMTYuIFRoYW5rIHlvdSBmb3INCj4gc3VnZ2VzdGlvbi4N Cj4gPj4gQ3VycmVudGx5IHdlIGFyZSB0cnlpbmcgdG8gbWFrZSBhbiBleHBlcmltZW50YWwgdmVy c2lvbiB3ZXJlIHRoaXMNCj4gPj4gd291bGQgYmUgcG9zc2libGUgdG8gbWFrZSB0aGVzZSBwYXJh bWV0ZXJzIGFuZCBmZXcgb3RoZXIgdGhpbmdzDQo+IGV4dGVybmFsbHkgc2V0dGFibGUuDQo+ID4+ DQo+ID4+IEJ1dCwgaG9uZXN0bHksIHRoZSBmdXJ0aGVyIHdlIGRpZyBpbiB0aGUgY29kZSBhbmQg dHJhY2VzIHRoZSBtb3JlIHRoZQ0KPiA+PiBjb25mdXNpb24gYW5kIG1vcmUgcXVlc3Rpb25zIGFy aXNlcy4NCj4gPj4gICAgICAgSHlzdGFydCByZWx5IG9uIGNvcnJlY3QgaWRlbnRpZmljYXRpb24g b2Ygcm91bmQgYm9yZGVycy4gRm9yDQo+ID4+IHRoaXMgaHlzdGFydF9yZXNldCBzZXRzIHRoZSBi b3JkZXIgYXQgc25kX254dC4NCj4gPj4gQnV0LCBpZiBzZXZlcmFsIEFDSyBhcnJpdmUgYXQgaGln aCBzcGVlZCB3aGVuIHRoZSBjdXJyZW50IHJvdW5kDQo+ID4+IGJvcmRlciBpcyBjcm9zc2VkIGFu ZCB0aGUgc2VuZGVyIGhhcyBub3QgdGltZSB0byB0cmFuc21pdCB0d28gcGFja2V0cw0KPiA+PiBp bW1lZGlhdGVseSBhZnRlciBBQ0ssIHRoZW4gdGhlIHNuZF9ueHQgZG9lcyBub3QgcHJvZ3Jlc3Mg YW5kDQo+ID4+IGh5c3RhcnRfcmVzZXQgc2V0cyB0aGUgcm91bmQgb2YgdGhlIGJvcmRlciB0byBh IHByZXR0eSByYW5kb20gdmFsdWUNCj4gPj4gYW5kIHRoZW4gaW4gdGhlIG5leHQgcm91bmQgdGhl IGh5c3RhcnQgbWVhc3VyZSBwaWVjZXMgb2YgdHdvIHJvdW5kcy4NCj4gPj4gICAgICAgQWxzbywg dGhlIGNvZGUgaXMgY2FsbGluZyBoeXN0YXJ0X3VwZGF0ZSBvbiBlYWNoIEFDSyBiZWZvcmUgdGhl DQo+ID4+IGh5c3RhcnRfcmVzZXQsIGFzIGEgcmVzdWx0IGF0IHRoZSBib3JkZXIgb2Ygcm91bmRz IHRoZSBoZWFkIG9mIGxpbmUNCj4gPj4gKEhPTCkgQUNLIGRlbGF5IG9mIHJvdW5kIE4rMSBpcyBh Y2NvdW50ZWQgaW4gdGhlIHJvdW5kIE4gYW5kLA0KPiA+PiBiZWNhdXNlLCB0aGUgSE9MIHVzdWFs bHkgaGFzIGxlc3MgZGVsYXksIGl0IGlzIGZyZXF1ZW50bHkgYmVjb21lDQo+ID4+IGRlbGF5X21p biBidXQgbm90IGluIHJvdW5kDQo+ID4+IE4rMSBhbmQsIGFzIGEgcmVzdWx0IGVhcmx5IGV4aXQg aW4gcm91bmQgTisxIGFmdGVyIGNvdW50aW5nIGRlbGF5cyBvZg0KPiA+PiBOK3BhY2tldHMgMg0K PiA+PiB0aHJvdWdoIDkuDQo+ID4+ICAgICAgIFRoaXMgc2hvdWxkIGFsc28gYWZmZWN0IHRyYWlu IGRldGVjdCBhcywgd2hlbiBjcm9zc2luZyB0aGUNCj4gPj4gcm91bmQgYm9yZGVyLCBpbnN0ZWFk IG9mIHN1YnRyYWN0aW5nIHRoZSB0aW1lIG9mIHRoZSBmaXJzdCBhbmQgdGhlDQo+ID4+IGxhc3Qg QUNLIG9mIHRoZSB0cmFpbiBOIHRoZXJlIHdpbGwgYmUgc3VidHJhY3RlZCB0aW1lcyBvZiBmaXJz dCBBQ0sNCj4gPj4gb2YgdHJhaW4gTiBhbmQgZmlyc3QgQUNLIG9mIHRoZSB0cmFpbiBOKzEgd2hp Y2ggd2lsbCBiZSBhcHByb3hpbWF0ZWx5DQo+ID4+IGVxdWFsIHRvIFJUVCBhbmQgZGVmaW5pdGVs eSBiaWdnZXIgdGhhbiBSVFQvMiBhcyBwZXIgZXhwZWN0ZWQNCj4gPj4gYWxnb3JpdGhtLiBUaGlz IHNoYWxsIHR5cGljYWxseSBsZWFkIHRvIGFsd2F5cyBleGl0IGluIHRyYWluIDIuIFRoaXMNCj4g Pj4gd2lsbCBhZmZlY3QgaGlnaCBzcGVlZCBuZXR3b3JrcyB3aXRoIFJUVCBsZXNzIHRoYW4gaHlz dGFydF9hY2tfZGVsdGENCj4gKDJtcykuDQo+ID4+ICAgICAgICAgICAgICBUaGVuIGNhbGwgb2Yg aHlzdGFydF9yZXNldCBpcyBzdWJqZWN0IG9mIGNoZWNrIG9mDQo+ID4+IHNldmVyYWwgY29uZGl0 aW9ucyBsaWtlIG1heV9yaXNlX2N3bmQgb3IgaXNfY3duZF9saW1pdGVkLCB3aGlsZSBpdA0KPiA+ PiBkb2Vzbid0IGxvb2sgdGhhdCBoeXN0YXJ0X3VwZGF0ZSBpcywgc28gdGhhdCBpdCBtYXkgYmVj b21lIHRvdGFsbHkNCj4gPj4gb3V0IG9mIHN5bmMgd2l0aCByb3VuZCBib3JkZXIuDQo+ID4+DQo+ ID4+ICAgICAgIFdlIGFyZSBzdGlsbCBkb2luZyBlZmZvcnRzIHRvIHRyeSB0byBmaW5kIHBhcmFt ZXRlcnMgd2hpY2gNCj4gPj4gd291bGQgbWFrZSBoeXN0YXJ0IGJldHRlciwgYnV0IGFuYWx5c2lz IG9mIG1hbnkgdHJhY2VzIG1ha2UgbXVjaA0KPiA+PiBpbXByZXNzaW9uIG9mIHJhbmRvbW5lc3Mg b2YgZXhpdCBhbmQgbm90IHN1cmUgd2hldGhlciBwYXJhbWV0ZXJzIG1heQ0KPiBoZWxwLg0KPiA+ Pg0KPiA+PiBWZWFjZXNsYXYgUm9tYW4NCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogSW5nZW1hciBKb2hhbnNzb24gUyBbbWFpbHRvOmluZ2VtYXIucy5q b2hhbnNzb25AZXJpY3Nzb24uY29tXQ0KPiA+PiBTZW50OiBUdWVzZGF5LCAwMyBOb3ZlbWJlciAy MDE1IDE1OjE5DQo+ID4+IFRvOiBWZWFjZXNsYXYgUk9NQU47IE5lYWwgQ2FyZHdlbGwNCj4gPj4g Q2M6IEVyaWMgRHVtYXpldDsgRXJpYyBEdW1hemV0OyB0Y3BtQGlldGYub3JnOyBQaWVycyBPJ0hh bmxvbjsNCj4gPj4gU2FuZ3RhZSBIYTsgZW5kMmVuZC1pbnRlcmVzdEBwb3N0ZWwub3JnOyBJbmdl bWFyIEpvaGFuc3NvbiBTDQo+ID4+IFN1YmplY3Q6IFJFOiBbdGNwbV0gW2UyZV0gVENQIEh5U3Rh cnQgcGF0Y2ggZGVwbG95bWVudA0KPiA+Pg0KPiA+PiBIaQ0KPiA+Pg0KPiA+PiBUaGFua3MgZm9y IGRvaW5nIHRoZSBleHBlcmltZW50cy4NCj4gPj4gSXQgbWF5IGJlIHBvc3NpYmxlIHRoYXQgSHlT dGFydCBtYXkgbmVlZCBtb3JlIGV4dGVuc2l2ZSBtb2RpZmljYXRpb25zLg0KPiA+PiBOZWVkIHRv IGFzayB0aGUgZHVtYiBxdWVzdGlvbiBmaXJzdCB0aG91Z2guIElzIEhZU1RBUlRfREVMQVlfTUFY DQo+ID4+IG1vZGlmaWVkIGluIHlvdXIgZXhwZXJpbWVudCBvciBpcyBpdCBzdGlsbCAxNm1zID8N Cj4gPj4gSSBndWVzcyBIWVNUQVJUX0RFTEFZX01BWCBtYXkgbmVlZCB0byBiZSBzZXQgdG8NCj4g Pj4gICAgIEhZU1RBUlRfREVMQVlfTUFYID0gTUFYKDE2bXMsIEhZU1RBUlRfREVMQVlfTUlOKjIp IE9yDQo+IHNvbWV0aGluZw0KPiA+PiBzaW1pbGFyLCBvbmUgY2FuIGFsd2F5cyBhcmd1ZSBhcm91 bmQgdGhlIGZhY3RvciAyIGFib3ZlLg0KPiA+Pg0KPiA+PiAvSW5nZW1hcg0KPiA+Pg0KPiA+PiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4gRnJvbTogVmVhY2VzbGF2IFJPTUFO IFttYWlsdG86VmVhY2VzbGF2LlJvbWFuQG9yYW5nZS5tZF0NCj4gPj4gPiBTZW50OiBkZW4gMTcg b2t0b2JlciAyMDE1IDIyOjQ4DQo+ID4+ID4gVG86IE5lYWwgQ2FyZHdlbGwNCj4gPj4gPiBDYzog RXJpYyBEdW1hemV0OyBJbmdlbWFyIEpvaGFuc3NvbiBTOyBFcmljIER1bWF6ZXQ7IHRjcG1AaWV0 Zi5vcmc7DQo+ID4+ID4gUGllcnMgTydIYW5sb247IFNhbmd0YWUgSGE7IGVuZDJlbmQtaW50ZXJl c3RAcG9zdGVsLm9yZw0KPiA+PiA+IFN1YmplY3Q6IFJFOiBbdGNwbV0gW2UyZV0gVENQIEh5U3Rh cnQgcGF0Y2ggZGVwbG95bWVudA0KPiA+PiA+DQo+ID4+ID4gSGksDQo+ID4+ID4gUmVjb21waWxl ZCBrZXJuZWwgdG8gSFlTVEFSVF9ERUxBWV9NSU4gIDIwIG1zOg0KPiA+PiA+DQo+ID4+ID4gICBE b3dubG9hZCAxME1CLCBIaWdoIEJhbmR3aWR0aHMsIEhZU1RBUlRfREVMQVlfTUlOICAyMCBtczoN Cj4gPj4gPiAgICAgICAgICAgIEh5c3RhcnQgYXZlcmFnZSBkb3dubG9hZCB0aW1lOiAxLjE4IHMN Cj4gPj4gPiAgICAgICAgICAgIE5vSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDEuMDAg IHMNCj4gPj4gPg0KPiA+PiA+IE5vIHNpZ25pZmljYW50IGltcHJvdmVtZW50IGFnYWluc3QgdGhl IGNhc2Ugd2l0aCBIWVNUQVJUX0RFTEFZX01JTg0KPiA+PiA+IDEwIG1zLg0KPiA+PiA+DQo+ID4+ ID4gU2lsbCBIeXN0YXJ0IGVhcmx5IGV4aXQgaXMgdmlzaWJsZS4NCj4gPj4gPg0KPiA+PiA+IE90 aGVyIHRlc3RzIHdpdGggSFlTVEFSVF9ERUxBWV9NSU4gIDIwIG1zIGFuZCBmaWxlcyBvZiAzTUIu DQo+ID4+ID4NCj4gPj4gPiAgIERvd25sb2FkIDNNQiwgSGlnaCBCYW5kd2lkdGhzLCBIWVNUQVJU X0RFTEFZX01JTiAgMjAgbXM6DQo+ID4+ID4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93 bmxvYWQgdGltZTogMC40NyBzDQo+ID4+ID4gICAgICAgICAgICBOb0h5c3RhcnQgYXZlcmFnZSBk b3dubG9hZCB0aW1lOiAwLjM5ICBzDQo+ID4+ID4NCj4gPj4gPiBjb21wYXJlIHdpdGggNCBtcw0K PiA+PiA+DQo+ID4+ID4gICBEb3dubG9hZCAzTUIsIEhpZ2ggQmFuZHdpZHRocywgSFlTVEFSVF9E RUxBWV9NSU4gIDQgbXM6DQo+ID4+ID4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93bmxv YWQgdGltZTogMC42NSBzDQo+ID4+ID4gICAgICAgICAgICBOb0h5c3RhcnQgYXZlcmFnZSBkb3du bG9hZCB0aW1lOiAwLjM3ICBzDQo+ID4+ID4NCj4gPj4gPiBGZXcgbW9yZSBjb21tZW50OiBIaWdo IEJhbmR3aWR0aCBpcyB0eXBpY2FsbHkgYWJvdmUgMzAtNDAgTWJwcy4NCj4gPj4gPiBGb3IgTG93 IEJhbmR3aWR0aCwgd2hlbiByYWRpbyBkbyBub3QgcGVybWl0IGFib3ZlIDQwIE1icHMgSHlzdGFy dA0KPiA+PiA+IGVhcmx5IGV4aXQgZG9lcyBub3QgaGF2ZSBhIHNpZ25pZmljYW50IGltcGFjdC4g SSBkbyBleHBsYWluIGl0IHdpdGgNCj4gPj4gPiB0aGUgZmFjdCB0aGF0IHRoZSBtaW5pbXVtIGV4 aXQgQ1dORCBmb3IgSHlzc3RhcnQgaXMgMjkgd2hpY2gsIGZvcg0KPiA+PiA+IFJUVCBvZiB+MTVt cyAobWluaW11bSBwb3NzaWJsZSBpbiBMVEUgYW5kIHZpc2libGUgaW4gbWFqb3JpdHkgb2YNCj4g Pj4gPiB0cmFjZXMpIGxlYWRzIHRvIH4yNSBNYnBzLCBzbyBIeXN0YXJ0IGV4aXQsIGF0IGxlYXN0 LCBhdCAyNSBNYnBzDQo+ID4+ID4gYW5kIHRoZW4gaXQgdGFrZXMgbm90IHRvbyBsb25nIHRvIGN1 YmljIHRvIHJlYWNoIDMwLTQwIE1icHMuDQo+ID4+ID4NCj4gPj4gPiBWZWFjZXNsYXYgUm9tYW4N Cj4gPj4gPg0KPiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4gRnJvbTog TmVhbCBDYXJkd2VsbCBbbWFpbHRvOm5jYXJkd2VsbEBnb29nbGUuY29tXQ0KPiA+PiA+IFNlbnQ6 IFR1ZXNkYXksIDA2IE9jdG9iZXIgMjAxNSAwNDowNg0KPiA+PiA+IFRvOiBWZWFjZXNsYXYgUk9N QU4NCj4gPj4gPiBDYzogRXJpYyBEdW1hemV0OyBJbmdlbWFyIEpvaGFuc3NvbiBTOyBFcmljIER1 bWF6ZXQ7IHRjcG1AaWV0Zi5vcmc7DQo+ID4+ID4gUGllcnMgTydIYW5sb247IFNhbmd0YWUgSGE7 IGVuZDJlbmQtaW50ZXJlc3RAcG9zdGVsLm9yZw0KPiA+PiA+IFN1YmplY3Q6IFJlOiBbdGNwbV0g W2UyZV0gVENQIEh5U3RhcnQgcGF0Y2ggZGVwbG95bWVudA0KPiA+PiA+DQo+ID4+ID4gT24gTW9u LCBPY3QgNSwgMjAxNSBhdCA2OjA3IFBNLCBWZWFjZXNsYXYgUk9NQU4NCj4gPj4gPiA8VmVhY2Vz bGF2LlJvbWFuQG9yYW5nZS5tZD4gd3JvdGU6DQo+ID4+ID4gPiBXZSd2ZSBtYW5hZ2VkIHRvIHJl Y29tcGlsZSB0aGUga2VybmVsIDQuMSB3aXRoIHRjcF9jdWJpYw0KPiA+PiA+IEhZU1RBUlRfREVM QVlfTUlOICAoMTBVPDwzKSAsIDEwbXMuDQo+ID4+ID4gPiBXZWxsLCB3ZSBoYWQgdGltZSBvbmx5 IGZvciBvbmUgdGVzdCBjeWNsZSwgYnV0IHJlc3VsdHMgYXJlIHZlcnkNCj4gcHJvbWlzaW5nOg0K PiA+PiA+ID4NCj4gPj4gPiA+IERvd25sb2FkIDEwTUIsIEhpZ2ggQmFuZHdpZHRocywgSFlTVEFS VF9ERUxBWV9NSU4gIDEwIG1zOg0KPiA+PiA+ID4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2Ug ZG93bmxvYWQgdGltZTogMS4xNiBzDQo+ID4+ID4gPiAgICAgICAgICAgIE5vSHlzdGFydCBhdmVy YWdlIGRvd25sb2FkIHRpbWU6IDAuOTMgIHMNCj4gPj4gPiAuLi4NCj4gPj4gPiA+ICBEb3dubG9h ZCAxME1CLCBIaWdoIEJhbmR3aWR0aHMsIEhZU1RBUlRfREVMQVlfTUlOICA0IG1zOg0KPiA+PiA+ ID4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93bmxvYWQgdGltZTogMS40MiBzDQo+ID4+ ID4gPiAgICAgICAgICAgIE5vSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDAuODkgIHMN Cj4gPj4gPg0KPiA+PiA+IFRoYW5rcyEgVGhhdCBpcyB2ZXJ5IHVzZWZ1bCBhbmQgaW50ZXJlc3Rp bmcgZGF0YS4gV291bGQgeW91IGJlIGFibGUNCj4gPj4gPiB0byB0cnkgYSBmZXcgb3RoZXIgdmFs dWVzLCBsaWtlIDE1bXMgYW5kIDIwbXM/DQo+ID4+ID4NCj4gPj4gPiBuZWFsDQo= From nobody Sun Sep 4 03:54:03 2016 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 0708112B12B for ; Sun, 4 Sep 2016 03:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 d7pybchGUu6p for ; Sun, 4 Sep 2016 03:54:00 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BA612B0CD for ; Sun, 4 Sep 2016 03:53:58 -0700 (PDT) Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com [209.85.213.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 808E527844C for ; Sun, 4 Sep 2016 19:53:56 +0900 (JST) Received: by mail-vk0-f50.google.com with SMTP id v189so57852317vkv.1 for ; Sun, 04 Sep 2016 03:53:56 -0700 (PDT) X-Gm-Message-State: AE9vXwPg/FJeDCqiVCnJCqc1FpbB5BBtjIebRvGN5elyt0U7v9oDzsWpkd+n2IkuT9nXvwWbM1pQ1VwxoZ+GyQ== X-Received: by 10.31.252.207 with SMTP id a198mr1263181vki.51.1472986434964; Sun, 04 Sep 2016 03:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.194 with HTTP; Sun, 4 Sep 2016 03:53:54 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Sun, 4 Sep 2016 03:53:54 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Sanjeev Ranot Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] (ref. RFC 7323) Increase of shift count from 14 to 15. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 10:54:02 -0000 Hi Sanjeev, I think there might be some useful cases if we can change shift count in the middle of the session. However, one tricky thing for this is you'll need to send new shift count reliably. Because when an end node sends a new shift count, it will be problematic if the peer cannot receive it. But, TCP doesn't have a good mechanism to send TCP options reliably during data transfer. So, in order to build this feature, we'll need to think about how to solve it. That's the reason I think it'll be a rather broad topic. Thanks, -- Yoshi On Tue, Aug 30, 2016 at 9:02 PM, Sanjeev Ranot wrote: > Hi Yoshi, > > Yes, using shf.cnt of 15 in connection establishment phase is sufficient > enough, but while thinking from migration and interoperability this > suggestion of changing shf.cnt during Data Transfer Phase came to mind. > > Present behavior is that if window limit is reached then we cannot > transfer no matter how big cwnd is. This limits the rate of growth of > congestion window if not growth completely. Now with high speed interfaces > it will not always be the case that we increase size of MTU (as for jumbo > frames) to get the bandwidth with support of bundling (etherChannels). > > Generally when shf.cnt is chosen it defines the size of SND.WND > within range from 0 to max SND.WND. SND.WND proves to be a > constraint in situation discussed below. > > Note: With PAWS we need to make sure that it is sufficiently large > enough to provide ample monotonically non-decreasing numbers so that > they can be differentiated or make its use in such a way so that > its always sufficient to distinguish at-least between 2 successive > windows. RFC 7323 defines such a way by putting same TSval for all > segments belonging to the same window. > > Before citing situation for the need of dynamic exchange of shf.cnt we > need to discuss why sequence number of greater than 32 bit is not needed > because of PAWS and PAWS timestamp Interface transfer speed and window > size are related > > With PAWS, each wrap of timestamp must be >= 2*MSL. This MSL is based > on transfer rate. Assuming 1 timestamp tick is 1 ms, hence if we > transfer 2^30 bytes of data in each window i.e. with shf.cnt = 14 then > maximum transfer rate which we need to get this big a window is of > 1 Tera bytes (TbE) with PAWS in place > > 1000 ms (1s) = 1000 Gb (1TbE) > 1ms = 1 Gb ~ 2^30 > > Therefore with PAWS timestamp tick of 1ms allows 1 Gb of window size that > we can transmit safely without data corruption due to duplicate data or > ACK segments. This minimum timestamp click needed for PAWS safety is > provided with a base consideration of sequence number of 32 bits in size. > It takes 49.6 days for a 32 bit sequence number to wrap again when > timestamp tick is 1ms. If in future we were to increase sequence numbers > to 64 bits, then this timestamp tick can be reduced or we MAY never need > PAWS again thereafter if 64 bit sequence number is used and we can never > increase bandwidth speed no matter how much we bundle cables. > > The situation discussed assume that we are never going to increase the > sequence number size and we are good with PAWS to provide us safety from > duplicate data and ACK segment or of old packets from previous incarnations > of the same TCP connection. > > Another example with shf.cnt = 15 : > With shf.cnt = 15 > 1000ms = 2000 Gb (2TbE) > 1ms = 2000000000 bits = 2 Gb ~ 2^31 > Therefore with a speed of 2Tbps and 1 ms timestamp tick for PAWS we can > get a window size of 2 Gb. > > Migration Notes: > This means that when we introduce a shf.cnt of 15, then we MAY either let > PAWS timestamp tick to remain same as used for 1 Gb of window size with > shf.cnt of 14 if its sufficient enough or we may think to readjust if we > want to gain more speed by lowering the previous PAWS timestamp. > > Similary with a speed of 4Tbps and 1 ms timestamp tick for PAWS we can > get a window size of 4 Gb. > > Situation: > TCP connection is going on for days using same shf.cnt which was > exchanged on day 1 when this TCP connection was established. Suppose > due to incredible high transfer rate of the inter-continent link > cwnd == SND.WND was already reached at end of day 1 and now the > transfer rate is limited by SND.WND (decided by shf.cnt) when only > very small fraction of link speed is utilized. Now suppose a very > huge surplus of memory is made available by hot-swappable memory > card inserted on both ends while TCP connection is running its > Data Transfer Phase. Shf.cnt was already decided in beginning of > this TCP connection and it was decided on the basis of amount on > total memory available at that time to be allocated to its RCV.BUF. > It required restarting this ongoing connection to have a new shf.cnt > that will now consider this new additional memory surplus (i.e. > increase RCV.BUF) and start all over again from start or further > from the last index received is area of improvement. > > My proposal is that (this is separate from the on going work on shf.cnt = > 15) : > If TCP stack have support of exchanging shf.cnt in data transfer phase > when large amount of memory is available dynamically then we can achieve > significant high transfer rates without ever having to restart the > connection. > > This feature comes in heading "Dynamically adjustable TCP window" and > shf.cnt_interoperability.pdf mentions one of the possible mechanisms > for implementing this introducing 7 new state variables and 1 TCP flag. > > Also, just to reiterate regarding migration purposes please look into > PAWS and discuss with stake holders if they are ok with existing > timestamp for new shf.cnt of 15. > > > Thanks & Regards, > Sanjeev Ranot > > > > On 29 August 2016 at 13:02, Yoshifumi Nishida > wrote: >> >> Hi Sanjeev, >> >> On Sun, Aug 28, 2016 at 1:55 AM, Sanjeev Ranot >> wrote: >> > Hi Yoshi, >> > >> > thanks for replying. I have done some work in these couple of days on >> > how exchange and interoperability of shift count 15 or greater will >> > work. >> > >> > Basically my idea is for the new TCP stack (which will support shf.cnt >> > >= >> > 15) >> > to exchange shf.cnt even in Data Transfer Phase and not only in >> > connection >> > establishment. I have presented this exchange work in the document >> > enclosed. >> > >> > Please have a look at the document and let me know for any info or >> > clarification >> >> Thanks for the doc. >> I personally think you might want to clarify why we want to change >> shift count in data transfer phase a bit more. >> This is because even if we use shift count=15, I think we can specify >> rather small window size by using a small number for the timestamp >> value. So, if the stack supports shift count=15, I think it can just >> use it from the beginning of the data transfer in most cases. >> >> If your focus is to have a feature to update shift count during data >> transfer phase in general, I think it can be a separate proposal from >> increasing max shift count. Because it looks a more broad topic to me. >> >> Thanks, >> -- >> Yoshi > > From nobody Sun Sep 4 03:55:13 2016 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 BE44F12B12C for ; Sun, 4 Sep 2016 03:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 L34LvmqulNRn for ; Sun, 4 Sep 2016 03:55:09 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353B412B0CD for ; Sun, 4 Sep 2016 03:55:09 -0700 (PDT) Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C48E127844C for ; Sun, 4 Sep 2016 19:55:07 +0900 (JST) Received: by mail-ua0-f180.google.com with SMTP id 31so7023346uao.0 for ; Sun, 04 Sep 2016 03:55:07 -0700 (PDT) X-Gm-Message-State: AE9vXwNyy+NZk2ZsUK+kA3ZJlPibPT+JzIvDrwm9zYpDw/J1UU6QPiqzkrGzQYRGvPgJD71mZ1C/uZ2wOK54cA== X-Received: by 10.159.32.2 with SMTP id 2mr19089016uam.74.1472986506271; Sun, 04 Sep 2016 03:55:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.194 with HTTP; Sun, 4 Sep 2016 03:55:05 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Sun, 4 Sep 2016 03:55:05 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Cui, Cheng" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] question about if a recent Linux patch is compliant with RFC7323 on window scaling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 10:55:12 -0000 Hi Cheng, On Tue, Aug 30, 2016 at 7:16 AM, Cui, Cheng wrote: > Six days have passed and no response yet. Can anyone in this board make a comment? > > Thanks, > --Cheng Cui > NetApp Scale Out Networking > > > On 8/24/16, 5:06 PM, "Cui, Cheng" wrote: > > Hello David, > > I hope this email could reach you well, because I found related > discussions about this topic on window scaling and the case of window > shrinking (or retraction or loss of precision). And I try to make this > question simple. > > There is a recent Linux patch at receiver side to round-up advertised > window due to precision loss of window scaling. It reaches my attention > because the same problem could also happen between a pair of Linux and > FreeBSD nodes, and I am not aware of any similar patch in FreeBSD yet. > > The Linux patch is this: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6 > 07bfbf2d55dd1cfe5368b41c2a81a8c9ccf4723 > > And I quote some description of the Linux patch below: > > If the sender uses up the entire window before it is shrunk, this can > >have > > chaotic effects on the connection. When sending ACKs, > >tcp_acceptable_seq() > > will notice that the window has been shrunk since tcp_wnd_end() is before > > tp->snd_nxt, which makes it choose tcp_wnd_end() as sequence number. > > This will fail the receivers checks in tcp_sequence() however since it > > is before it's tp->rcv_wup, making it respond with a dupack. > > > If the Linux sender?s behavior is right ("ACK-only packets should be sent > with the largest in-window sequence number that has ever been sent." ref: > https://www.ietf.org/mail-archive/web/tcpm/current/msg10512.html), it > actually chooses "tp->snd_una+tp->snd_wnd" (tcp_wnd_end()) instead of > tp->snd_nxt, as it thought tp->snd_nxt is out of window, in case of > precision loss which made the receiver?s advertise-window smaller. > However, the RFC7323 explicitly specifies the receiver should right shift > the exact scale factor, without mentioning any further round-up: > > https://tools.ietf.org/html/rfc7323#page-9 > > o The window field (SEG.WND) of every outgoing segment, with the > > exception of segments, MUST be right-shifted by > > Rcv.Wind.Shift bits: > > > > SEG.WND = RCV.WND >> Rcv.Wind.Shift > > And also if I am understanding correctly, RFC7323 page 10 (2.4. Addressing > Window Retraction) specifies it is the sender?s responsibility to handle > the sequence number out of window: > https://tools.ietf.org/html/rfc7323#page-10 > > 4) On first retransmission, or if the sequence number is out of > > window by less than 2^Rcv.Wind.Shift, then do normal > > retransmission(s) without regard to the receiver window as long > > as the original segment was in window when it was sent. > > > > 5) Subsequent retransmissions MAY only be sent if they are within > > the window announced by the most recent . > > In your discussion of the link below, if I am understanding correctly, you > were also in favor of "Yes. It is ok to have more receive buffer space > available than you advertise in the window, but not ok to advertise a > larger window than you are willing to accept." So I think you were not in > favor of rounding-up the advertise-window. > > https://www.ietf.org/mail-archive/web/tsvwg/current/msg06475.html > > > So my question is: Is the Linux patch (on receiver side to round-up the > advertise-window) RFC compliant? Or is it just the right thing (vendor > specific) and other systems like FreeBSD have to follow up, so that their > talks can have no problem? I think the Linux patch at least follows the following principle in RFC793. The mechanisms provided allow a TCP to advertise a large window and to subsequently advertise a much smaller window without having accepted that much data. This, so called "shrinking the window," is strongly discouraged. The robustness principle dictates that TCPs will not shrink the window themselves, but will be prepared for such behavior on the part of other TCPs. I personally think a real question would be how FreeBSD prepares for shrinking window. Linux chose one way for it, but I guess all implementations don't need to follow the same way. -- Yoshi From nobody Mon Sep 5 08:01:46 2016 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 3B08812B131 for ; Sun, 4 Sep 2016 21:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uSGqwcbs0G34 for ; Sun, 4 Sep 2016 21:18:13 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 AB43012B119 for ; Sun, 4 Sep 2016 21:18:12 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id v189so68271202vkv.1 for ; Sun, 04 Sep 2016 21:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xRGrWZa0b/7+kxVP+56DHHaiEF3yjekhP1+P93tQXi8=; b=fsxclaqth9zXoSwkvQ6NAcugeEgwrWxb4SozVSeQ7a5zflq5ilZmVSREyh2DF5eq8o JXSe/2z+VkFQHXrQ5qJubM8furw4jbcYFWD4PXts0kFE4QvPIJDqxPPVFFDxUmeFKC60 l0pyrRpyqSxyy+GHjwEboPFAQ4sUbY0N6/rlZkL+q97+t144SbA+jOhk5kMNFF4j4hsF 0iZq67WCAqXOZ490KZTdRL8D/3n6h5ipF7BtKA8K+w7aIcrYKGHNrWvqEn/riR9oU83z m+TNe0ShtyF3pO3bMMIkV3MFVkWxYxr7F7UGFRbflSm/zsZSE3XktldxAg4Ay0nNWv4+ cAjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xRGrWZa0b/7+kxVP+56DHHaiEF3yjekhP1+P93tQXi8=; b=Dp8Z5FW9hUX2JMyEtMeJ3wl3EjmHIQO1sSYThx98Oe156i0U7stIRsIqz+a634WD0q /7lHIQTG1oiTHpq33Uvh396pireKHYlO6GkYF0c0QrGQE4qvgTKJO2k/8J8pFsQ08xzl ykx5vpJrEbwzBheGtXV2dOORIab7d/+la8Ddch8HlWpdf/ZWHMjY8AkS5z5QNG2vC71L 2ELJRbu6KvLPdlt6HurYFXciM1jtnwoqPJNjlVao8HWYnEqi71It/YsjmZ1K49RQJ0X1 ILjajZxEk/W27Q+b8vtxX4kxtQaygmOJUwSEHZLDYKzauJAekWytxrt0tqW/Xu1ojSP/ nJVQ== X-Gm-Message-State: AE9vXwODcYbqePUqKoRl6yM9uZAhTdX684vcO+WY8xLPZRSoZoJxAzzuG/RsaeVYys/UdW/m2QsGEPS6PDB+7Q== X-Received: by 10.31.162.137 with SMTP id l131mr21811303vke.69.1473049091681; Sun, 04 Sep 2016 21:18:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.199 with HTTP; Sun, 4 Sep 2016 21:18:11 -0700 (PDT) In-Reply-To: References: From: Sanjeev Ranot Date: Mon, 5 Sep 2016 09:48:11 +0530 Message-ID: To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=001a11439ef2d8b65b053bbaf71f Archived-At: X-Mailman-Approved-At: Mon, 05 Sep 2016 08:01:45 -0700 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] (ref. RFC 7323) Increase of shift count from 14 to 15. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 04:18:15 -0000 --001a11439ef2d8b65b053bbaf71f Content-Type: text/plain; charset=UTF-8 Hi Yoshi, thanks for the reply. I really want you and team to take forward this idea of dynamically changing the shift count whenever in future you start work on this. I will be glad if it gets implemented. At present its out of my capacity to take it forward because I'm looking to relocate permanently abroad by getting some job and so is trying to meet the ends meet. As per your concerns, I too had similar concerns of reliably communicating this information to the peer therefore in the document which contains implementation of the idea i.e. *"shf.cnt_interoperability.pdf"* has a note: *"The condition is that these shf.cnt update will be transmitted only reliablyon data segment or on non-empty ack segment (NOT using empty acksegment or pure ack)"* Thanks again for your and team's valuable time and input. Thanks & Regards, Sanjeev Ranot On 4 September 2016 at 16:23, Yoshifumi Nishida wrote: > Hi Sanjeev, > > I think there might be some useful cases if we can change shift count > in the middle of the session. > However, one tricky thing for this is you'll need to send new shift > count reliably. Because when an end node sends a new shift count, it > will be problematic if the peer cannot receive it. > But, TCP doesn't have a good mechanism to send TCP options reliably > during data transfer. So, in order to build this feature, we'll need > to think about how to solve it. That's the reason I think it'll be a > rather broad topic. > > Thanks, > -- > Yoshi > > > > On Tue, Aug 30, 2016 at 9:02 PM, Sanjeev Ranot > wrote: > > Hi Yoshi, > > > > Yes, using shf.cnt of 15 in connection establishment phase is sufficient > > enough, but while thinking from migration and interoperability this > > suggestion of changing shf.cnt during Data Transfer Phase came to mind. > > > > Present behavior is that if window limit is reached then we cannot > > transfer no matter how big cwnd is. This limits the rate of growth of > > congestion window if not growth completely. Now with high speed > interfaces > > it will not always be the case that we increase size of MTU (as for jumbo > > frames) to get the bandwidth with support of bundling (etherChannels). > > > > Generally when shf.cnt is chosen it defines the size of SND.WND > > within range from 0 to max SND.WND. SND.WND proves to be a > > constraint in situation discussed below. > > > > Note: With PAWS we need to make sure that it is sufficiently large > > enough to provide ample monotonically non-decreasing numbers so that > > they can be differentiated or make its use in such a way so that > > its always sufficient to distinguish at-least between 2 successive > > windows. RFC 7323 defines such a way by putting same TSval for all > > segments belonging to the same window. > > > > Before citing situation for the need of dynamic exchange of shf.cnt we > > need to discuss why sequence number of greater than 32 bit is not needed > > because of PAWS and PAWS timestamp Interface transfer speed and window > > size are related > > > > With PAWS, each wrap of timestamp must be >= 2*MSL. This MSL is based > > on transfer rate. Assuming 1 timestamp tick is 1 ms, hence if we > > transfer 2^30 bytes of data in each window i.e. with shf.cnt = 14 then > > maximum transfer rate which we need to get this big a window is of > > 1 Tera bytes (TbE) with PAWS in place > > > > 1000 ms (1s) = 1000 Gb (1TbE) > > 1ms = 1 Gb ~ 2^30 > > > > Therefore with PAWS timestamp tick of 1ms allows 1 Gb of window size that > > we can transmit safely without data corruption due to duplicate data or > > ACK segments. This minimum timestamp click needed for PAWS safety is > > provided with a base consideration of sequence number of 32 bits in size. > > It takes 49.6 days for a 32 bit sequence number to wrap again when > > timestamp tick is 1ms. If in future we were to increase sequence numbers > > to 64 bits, then this timestamp tick can be reduced or we MAY never need > > PAWS again thereafter if 64 bit sequence number is used and we can never > > increase bandwidth speed no matter how much we bundle cables. > > > > The situation discussed assume that we are never going to increase the > > sequence number size and we are good with PAWS to provide us safety from > > duplicate data and ACK segment or of old packets from previous > incarnations > > of the same TCP connection. > > > > Another example with shf.cnt = 15 : > > With shf.cnt = 15 > > 1000ms = 2000 Gb (2TbE) > > 1ms = 2000000000 bits = 2 Gb ~ 2^31 > > Therefore with a speed of 2Tbps and 1 ms timestamp tick for PAWS we can > > get a window size of 2 Gb. > > > > Migration Notes: > > This means that when we introduce a shf.cnt of 15, then we MAY either let > > PAWS timestamp tick to remain same as used for 1 Gb of window size with > > shf.cnt of 14 if its sufficient enough or we may think to readjust if we > > want to gain more speed by lowering the previous PAWS timestamp. > > > > Similary with a speed of 4Tbps and 1 ms timestamp tick for PAWS we can > > get a window size of 4 Gb. > > > > Situation: > > TCP connection is going on for days using same shf.cnt which was > > exchanged on day 1 when this TCP connection was established. Suppose > > due to incredible high transfer rate of the inter-continent link > > cwnd == SND.WND was already reached at end of day 1 and now the > > transfer rate is limited by SND.WND (decided by shf.cnt) when only > > very small fraction of link speed is utilized. Now suppose a very > > huge surplus of memory is made available by hot-swappable memory > > card inserted on both ends while TCP connection is running its > > Data Transfer Phase. Shf.cnt was already decided in beginning of > > this TCP connection and it was decided on the basis of amount on > > total memory available at that time to be allocated to its RCV.BUF. > > It required restarting this ongoing connection to have a new shf.cnt > > that will now consider this new additional memory surplus (i.e. > > increase RCV.BUF) and start all over again from start or further > > from the last index received is area of improvement. > > > > My proposal is that (this is separate from the on going work on shf.cnt = > > 15) : > > If TCP stack have support of exchanging shf.cnt in data transfer phase > > when large amount of memory is available dynamically then we can achieve > > significant high transfer rates without ever having to restart the > > connection. > > > > This feature comes in heading "Dynamically adjustable TCP window" and > > shf.cnt_interoperability.pdf mentions one of the possible mechanisms > > for implementing this introducing 7 new state variables and 1 TCP flag. > > > > Also, just to reiterate regarding migration purposes please look into > > PAWS and discuss with stake holders if they are ok with existing > > timestamp for new shf.cnt of 15. > > > > > > Thanks & Regards, > > Sanjeev Ranot > > > > > > > > On 29 August 2016 at 13:02, Yoshifumi Nishida > > wrote: > >> > >> Hi Sanjeev, > >> > >> On Sun, Aug 28, 2016 at 1:55 AM, Sanjeev Ranot > >> wrote: > >> > Hi Yoshi, > >> > > >> > thanks for replying. I have done some work in these couple of days on > >> > how exchange and interoperability of shift count 15 or greater will > >> > work. > >> > > >> > Basically my idea is for the new TCP stack (which will support shf.cnt > >> > >= > >> > 15) > >> > to exchange shf.cnt even in Data Transfer Phase and not only in > >> > connection > >> > establishment. I have presented this exchange work in the document > >> > enclosed. > >> > > >> > Please have a look at the document and let me know for any info or > >> > clarification > >> > >> Thanks for the doc. > >> I personally think you might want to clarify why we want to change > >> shift count in data transfer phase a bit more. > >> This is because even if we use shift count=15, I think we can specify > >> rather small window size by using a small number for the timestamp > >> value. So, if the stack supports shift count=15, I think it can just > >> use it from the beginning of the data transfer in most cases. > >> > >> If your focus is to have a feature to update shift count during data > >> transfer phase in general, I think it can be a separate proposal from > >> increasing max shift count. Because it looks a more broad topic to me. > >> > >> Thanks, > >> -- > >> Yoshi > > > > > --001a11439ef2d8b65b053bbaf71f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yoshi,

thank= s for the reply. I really want you and team to take forward this idea of dynamically changing the shift count whenever in future you start work on= this.
I will be glad if it gets implemented.

=
At present its out of my capacity to take it forward because I'm = looking to
relocate permanently abroad by getting some job and so is tr= ying to meet
the ends meet.=C2=A0

As per= your concerns, I too had similar concerns of reliably communicating
this information to the peer therefore in the document which conta= ins
implementation of the idea i.e. "shf.cnt_interop= erability.pdf"
has a note:

"The cond= ition is that these shf.cnt update will be transmitted only reliably
on = data segment or on non-empty ack segment (NOT using empty ack
segment or= pure ack)"

Thanks aga= in for your and team's valuable time and input.

Thank= s & Regards,
Sanjeev Ranot



On 4 September 2016 at 16:23, Yoshifumi Nishida <ni= shida@sfc.wide.ad.jp> wrote:
<sanjeev.ranot.81@gmail.com> wrote:
> Hi Yoshi,
>
> Yes, using shf.cnt of 15 in connection establishment phase is sufficie= nt
> enough, but=C2=A0 while thinking from migration and interoperability t= his
> suggestion of changing shf.cnt during Data Transfer Phase came to mind= .
>
> Present behavior is that if window limit is reached then we cannot
> transfer no matter how big cwnd is. This limits the rate of growth of<= br> > congestion window if not growth completely. Now with high speed interf= aces
> it will not always be the case that we increase size of MTU (as for ju= mbo
> frames) to get the bandwidth with support of bundling (etherChannels).=
>
> Generally when shf.cnt is chosen it defines the size of SND.WND
> within range from 0 to max SND.WND. SND.WND proves to be a
> constraint in situation discussed below.
>
> Note: With PAWS we need to make sure that it is sufficiently large
> enough to provide ample monotonically non-decreasing numbers so that > they can be differentiated or make its use in such a way so that
> its always sufficient to distinguish at-least between 2 successive
> windows. RFC 7323 defines such a way by putting same TSval for all
> segments belonging to the same window.
>
> Before citing situation for the need of dynamic exchange of shf.cnt we=
> need to discuss why sequence number of greater than 32 bit is not need= ed
> because of PAWS and PAWS timestamp Interface transfer speed and window=
> size are related
>
> With PAWS, each wrap of timestamp must be >=3D 2*MSL. This MSL is b= ased
> on transfer rate. Assuming 1 timestamp tick is 1 ms, hence if we
> transfer 2^30 bytes of data in each window i.e. with shf.cnt =3D 14 th= en
> maximum transfer rate which we need to get this big a window is of
> 1 Tera bytes (TbE) with PAWS in place
>
> 1000 ms (1s) =3D 1000 Gb (1TbE)
> 1ms=C2=A0 =3D 1 Gb ~ 2^30
>
> Therefore with PAWS timestamp tick of 1ms allows 1 Gb of window size t= hat
> we can transmit safely without data corruption due to duplicate data o= r
> ACK segments. This minimum timestamp click needed for PAWS safety is > provided with a base consideration of sequence number of 32 bits in si= ze.
> It takes 49.6 days for a 32 bit sequence number to wrap again when
> timestamp tick is 1ms.=C2=A0 If in future we were to increase sequence= numbers
> to 64 bits, then this timestamp tick can be reduced or we MAY never ne= ed
> PAWS again thereafter if 64 bit sequence number is used and we can nev= er
> increase bandwidth speed no matter how much we bundle cables.
>
> The situation discussed assume that we are never going to increase the=
> sequence number size and we are good with PAWS to provide us safety fr= om
> duplicate data and ACK segment or of old packets from previous incarna= tions
> of the same TCP connection.
>
> Another example with shf.cnt =3D 15 :
> With shf.cnt =3D 15
> 1000ms=C2=A0 =3D 2000 Gb (2TbE)
> 1ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 2000000000 bits =3D 2 Gb ~ 2^31
> Therefore with a speed of 2Tbps and 1 ms timestamp tick for PAWS we ca= n
> get a window size of 2 Gb.
>
> Migration Notes:
> This means that when we introduce a shf.cnt of 15, then we MAY either = let
> PAWS timestamp tick to remain same as used for 1 Gb of window size wit= h
> shf.cnt of 14 if its sufficient enough or we may think to readjust if = we
> want to gain more speed by lowering the previous PAWS timestamp.
>
> Similary with a speed of 4Tbps and 1 ms timestamp tick for PAWS we can=
> get a window size of 4 Gb.
>
> Situation:
> TCP connection is going on for days using same shf.cnt which was
> exchanged on day 1 when this TCP connection was established. Suppose > due to incredible high transfer rate of the inter-continent link
> cwnd =3D=3D SND.WND was already reached at end of day 1 and now the > transfer rate is limited by SND.WND (decided by shf.cnt) when only
> very small fraction of link speed is utilized. Now suppose a very
> huge surplus of memory is made available by hot-swappable memory
> card inserted on both ends while TCP connection is running its
> Data Transfer Phase. Shf.cnt was already decided in beginning of
> this TCP connection and it was decided on the basis of amount on
> total memory available at that time to be allocated to its RCV.BUF. > It required restarting this ongoing connection to have a new shf.cnt > that will now consider this new additional memory surplus (i.e.
> increase RCV.BUF) and start all over again from start or further
> from the last index received is area of improvement.
>
> My proposal is that (this is separate from the on going work on shf.cn= t =3D
> 15) :
> If TCP stack have support of exchanging shf.cnt in data transfer phase=
> when large amount of memory is available dynamically then we can achie= ve
> significant high transfer rates without ever having to restart the
> connection.
>
> This feature comes in heading "Dynamically adjustable TCP window&= quot; and
> shf.cnt_interoperability.pdf mentions one of the possible mechanisms > for implementing this introducing 7 new state variables and 1 TCP flag= .
>
> Also, just to reiterate regarding migration purposes please look into<= br> > PAWS and discuss with stake holders if they are ok with existing
> timestamp for new shf.cnt of 15.
>
>
> Thanks & Regards,
> Sanjeev Ranot
>
>
>
> On 29 August 2016 at 13:02, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
> wrote:
>>
>> Hi Sanjeev,
>>
>> On Sun, Aug 28, 2016 at 1:55 AM, Sanjeev Ranot
>> <sanjeev.ranot.81= @gmail.com> wrote:
>> > Hi Yoshi,
>> >
>> > thanks for replying. I have done some work in these couple of= days on
>> > how exchange and interoperability of shift count 15 or greate= r will
>> > work.
>> >
>> > Basically my idea is for the new TCP stack (which will suppor= t shf.cnt
>> > >=3D
>> > 15)
>> > to exchange shf.cnt even in Data Transfer Phase and not only = in
>> > connection
>> > establishment. I have presented this exchange work in the doc= ument
>> > enclosed.
>> >
>> > Please have a look at the document and let me know for any in= fo or
>> > clarification
>>
>> Thanks for the doc.
>> I personally think you might want to clarify why we want to change=
>> shift count in data transfer phase a bit more.
>> This is because even if we use shift count=3D15, I think we can sp= ecify
>> rather small window size by using a small number for the timestamp=
>> value. So, if the stack supports shift count=3D15, I think it can = just
>> use it from the beginning of the data transfer in most cases.
>>
>> If your focus is to have a feature to update shift count during da= ta
>> transfer phase in general, I think it can be a separate proposal f= rom
>> increasing max shift count. Because it looks a more broad topic to= me.
>>
>> Thanks,
>> --
>> Yoshi
>
>

--001a11439ef2d8b65b053bbaf71f-- From nobody Tue Sep 6 07:28:47 2016 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 C965912B04A for ; Tue, 6 Sep 2016 07:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 idbWRH0wpPyA for ; Tue, 6 Sep 2016 07:28:42 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED9A12B1A6 for ; Tue, 6 Sep 2016 07:24:59 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id u86DVLLa019603; Tue, 6 Sep 2016 08:31:22 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David Borman In-Reply-To: Date: Tue, 6 Sep 2016 09:24:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org" , Sanjeev Ranot Subject: Re: [tcpm] (ref. RFC 7323) Increase of shift count from 14 to 15. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 14:28:47 -0000 The biggest problem with changing the shift count midstream is that TCP = has no reliable mechanism for doing option negotiation midstream. The = only packets that are reliably delivered are packets that contain data = or have the SYN or FIN bit set. If the receiver changes its shift count = mid-stream, the sender side needs to know where in the packet stream the = new value applies. You have to allow for lost or reordered packets, and = the receiver, in a one-way data transfer, is only sending ACK packets, = none of which are reliably transferred and have no ordering, the = receivers sequence number remains constant, making it impossible to = reliably identify a point in time where the new value takes effect. One way to reliably change the shift count is to put it into every = packet, for interoperability older implementations could be identified = because they would only have it in the SYN packets. This was considered = years ago but was ruled out: the limitations of only negotiating the = shift count during connection establishment was considered acceptable = compared to putting it into every packet and using up valuable TCP = option space. To use a shift count of 15, you have to be able to determine whether or = not the other side can accept a value of 15. If you send a 15, but are = talking to an older implementation that clamps it at 14 and you don=E2=80=99= t know that, then your window values, sent assuming a shift count of 15, = will be halved by the receiver who clamped it at 14; that is probably = not desirable as the whole point of have a shift count of 15 is to allow = larger windows, not smaller windows. As to why the value is 14, that is explained in RFC 7323, section 2.4. = The logic is based on the assumption that if you allow a scale of 15, = that at some point someone will try to use all of it, and limiting it to = 14 ensured that we wouldn=E2=80=99t run into any sequence space = wrap-around problems. Whether or not that logic is correct is a = separate discussion, but that=E2=80=99s why 14 was chosen. -David Borman > On Sep 4, 2016, at 5:53 AM, Yoshifumi Nishida = wrote: >=20 > Hi Sanjeev, >=20 > I think there might be some useful cases if we can change shift count > in the middle of the session. > However, one tricky thing for this is you'll need to send new shift > count reliably. Because when an end node sends a new shift count, it > will be problematic if the peer cannot receive it. > But, TCP doesn't have a good mechanism to send TCP options reliably > during data transfer. So, in order to build this feature, we'll need > to think about how to solve it. That's the reason I think it'll be a > rather broad topic. >=20 > Thanks, > -- > Yoshi >=20 >=20 >=20 > On Tue, Aug 30, 2016 at 9:02 PM, Sanjeev Ranot > wrote: >> Hi Yoshi, >>=20 >> Yes, using shf.cnt of 15 in connection establishment phase is = sufficient >> enough, but while thinking from migration and interoperability this >> suggestion of changing shf.cnt during Data Transfer Phase came to = mind. >>=20 >> Present behavior is that if window limit is reached then we cannot >> transfer no matter how big cwnd is. This limits the rate of growth of >> congestion window if not growth completely. Now with high speed = interfaces >> it will not always be the case that we increase size of MTU (as for = jumbo >> frames) to get the bandwidth with support of bundling = (etherChannels). >>=20 >> Generally when shf.cnt is chosen it defines the size of SND.WND >> within range from 0 to max SND.WND. SND.WND proves to be a >> constraint in situation discussed below. >>=20 >> Note: With PAWS we need to make sure that it is sufficiently large >> enough to provide ample monotonically non-decreasing numbers so that >> they can be differentiated or make its use in such a way so that >> its always sufficient to distinguish at-least between 2 successive >> windows. RFC 7323 defines such a way by putting same TSval for all >> segments belonging to the same window. >>=20 >> Before citing situation for the need of dynamic exchange of shf.cnt = we >> need to discuss why sequence number of greater than 32 bit is not = needed >> because of PAWS and PAWS timestamp Interface transfer speed and = window >> size are related >>=20 >> With PAWS, each wrap of timestamp must be >=3D 2*MSL. This MSL is = based >> on transfer rate. Assuming 1 timestamp tick is 1 ms, hence if we >> transfer 2^30 bytes of data in each window i.e. with shf.cnt =3D 14 = then >> maximum transfer rate which we need to get this big a window is of >> 1 Tera bytes (TbE) with PAWS in place >>=20 >> 1000 ms (1s) =3D 1000 Gb (1TbE) >> 1ms =3D 1 Gb ~ 2^30 >>=20 >> Therefore with PAWS timestamp tick of 1ms allows 1 Gb of window size = that >> we can transmit safely without data corruption due to duplicate data = or >> ACK segments. This minimum timestamp click needed for PAWS safety is >> provided with a base consideration of sequence number of 32 bits in = size. >> It takes 49.6 days for a 32 bit sequence number to wrap again when >> timestamp tick is 1ms. If in future we were to increase sequence = numbers >> to 64 bits, then this timestamp tick can be reduced or we MAY never = need >> PAWS again thereafter if 64 bit sequence number is used and we can = never >> increase bandwidth speed no matter how much we bundle cables. >>=20 >> The situation discussed assume that we are never going to increase = the >> sequence number size and we are good with PAWS to provide us safety = from >> duplicate data and ACK segment or of old packets from previous = incarnations >> of the same TCP connection. >>=20 >> Another example with shf.cnt =3D 15 : >> With shf.cnt =3D 15 >> 1000ms =3D 2000 Gb (2TbE) >> 1ms =3D 2000000000 bits =3D 2 Gb ~ 2^31 >> Therefore with a speed of 2Tbps and 1 ms timestamp tick for PAWS we = can >> get a window size of 2 Gb. >>=20 >> Migration Notes: >> This means that when we introduce a shf.cnt of 15, then we MAY either = let >> PAWS timestamp tick to remain same as used for 1 Gb of window size = with >> shf.cnt of 14 if its sufficient enough or we may think to readjust if = we >> want to gain more speed by lowering the previous PAWS timestamp. >>=20 >> Similary with a speed of 4Tbps and 1 ms timestamp tick for PAWS we = can >> get a window size of 4 Gb. >>=20 >> Situation: >> TCP connection is going on for days using same shf.cnt which was >> exchanged on day 1 when this TCP connection was established. Suppose >> due to incredible high transfer rate of the inter-continent link >> cwnd =3D=3D SND.WND was already reached at end of day 1 and now the >> transfer rate is limited by SND.WND (decided by shf.cnt) when only >> very small fraction of link speed is utilized. Now suppose a very >> huge surplus of memory is made available by hot-swappable memory >> card inserted on both ends while TCP connection is running its >> Data Transfer Phase. Shf.cnt was already decided in beginning of >> this TCP connection and it was decided on the basis of amount on >> total memory available at that time to be allocated to its RCV.BUF. >> It required restarting this ongoing connection to have a new shf.cnt >> that will now consider this new additional memory surplus (i.e. >> increase RCV.BUF) and start all over again from start or further >> from the last index received is area of improvement. >>=20 >> My proposal is that (this is separate from the on going work on = shf.cnt =3D >> 15) : >> If TCP stack have support of exchanging shf.cnt in data transfer = phase >> when large amount of memory is available dynamically then we can = achieve >> significant high transfer rates without ever having to restart the >> connection. >>=20 >> This feature comes in heading "Dynamically adjustable TCP window" and >> shf.cnt_interoperability.pdf mentions one of the possible mechanisms >> for implementing this introducing 7 new state variables and 1 TCP = flag. >>=20 >> Also, just to reiterate regarding migration purposes please look into >> PAWS and discuss with stake holders if they are ok with existing >> timestamp for new shf.cnt of 15. >>=20 >>=20 >> Thanks & Regards, >> Sanjeev Ranot >>=20 >>=20 >>=20 >> On 29 August 2016 at 13:02, Yoshifumi Nishida = >> wrote: >>>=20 >>> Hi Sanjeev, >>>=20 >>> On Sun, Aug 28, 2016 at 1:55 AM, Sanjeev Ranot >>> wrote: >>>> Hi Yoshi, >>>>=20 >>>> thanks for replying. I have done some work in these couple of days = on >>>> how exchange and interoperability of shift count 15 or greater will >>>> work. >>>>=20 >>>> Basically my idea is for the new TCP stack (which will support = shf.cnt >>>>> =3D >>>> 15) >>>> to exchange shf.cnt even in Data Transfer Phase and not only in >>>> connection >>>> establishment. I have presented this exchange work in the document >>>> enclosed. >>>>=20 >>>> Please have a look at the document and let me know for any info or >>>> clarification >>>=20 >>> Thanks for the doc. >>> I personally think you might want to clarify why we want to change >>> shift count in data transfer phase a bit more. >>> This is because even if we use shift count=3D15, I think we can = specify >>> rather small window size by using a small number for the timestamp >>> value. So, if the stack supports shift count=3D15, I think it can = just >>> use it from the beginning of the data transfer in most cases. >>>=20 >>> If your focus is to have a feature to update shift count during data >>> transfer phase in general, I think it can be a separate proposal = from >>> increasing max shift count. Because it looks a more broad topic to = me. >>>=20 >>> Thanks, >>> -- >>> Yoshi >>=20 >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Sep 6 11:14:54 2016 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 AFE0212B319 for ; Tue, 6 Sep 2016 11:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 DSA03ZoXn3bQ for ; Tue, 6 Sep 2016 11:14:51 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 6325012B0B5 for ; Tue, 6 Sep 2016 11:14:51 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u86IERgh000602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Sep 2016 11:14:27 -0700 (PDT) To: David Borman , Yoshifumi Nishida References: From: Joe Touch Message-ID: Date: Tue, 6 Sep 2016 11:14:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u86IERgh000602 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" , Sanjeev Ranot Subject: Re: [tcpm] (ref. RFC 7323) Increase of shift count from 14 to 15. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 18:14:53 -0000 Hi, all, On 9/6/2016 7:24 AM, David Borman wrote: > The biggest problem with changing the shift count midstream is that TCP has no reliable mechanism for doing option negotiation midstream. Agreed. > The only packets that are reliably delivered are packets that contain data or have the SYN or FIN bit set. AFAICT, this isn't strictly true. The data and connection state are reliably "delivered" (or synchronized), but not the packets per se. Options in those packets aren't reliably delivered any more than any other packet, esp. because TCP has no strict requirement that the options of retransmitted segments don't vary. TCP gets around this by confirming the options exchanged during the SYN, but no other time during the connection. You *can* build your own handshake on top of TCP, but it's complicated. We did this for TCP-AO to support key rollover - the sender offers a new key, which cannot be used until the receiver confirms it. The same happens in the opposite direction. As Dave pointed out, this takes up option space (one extra byte in AO, in addition to the confirmation being overloaded with the current keyID) and requires that the option "protocol" consider how to handle handshake failure, packet reordering, etc. Joe From nobody Tue Sep 6 16:22:23 2016 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 CAA9D12B6F4 for ; Tue, 6 Sep 2016 08:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.429 X-Spam-Level: X-Spam-Status: No, score=-8.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 0-PkK2ztKwaJ for ; Tue, 6 Sep 2016 08:16:03 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F7A12B494 for ; Tue, 6 Sep 2016 08:11:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.30,292,1470726000"; d="scan'208";a="142150295" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx144-out.netapp.com with ESMTP; 06 Sep 2016 08:09:59 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Sep 2016 08:10:15 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::a009:cb7a:e519:7347%21]) with mapi id 15.00.1210.000; Tue, 6 Sep 2016 08:10:15 -0700 From: "Cui, Cheng" To: Yoshifumi Nishida Thread-Topic: [tcpm] question about if a recent Linux patch is compliant with RFC7323 on window scaling Thread-Index: AQHR/ktWq33ah5ClWE2yMFWt4EpCvqBhx/sAgAfmXYCAAyjpgA== Date: Tue, 6 Sep 2016 15:10:14 +0000 Message-ID: <1ED4AF08-5748-4BB2-B413-CF6D16D42216@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <26AEEF861FE7534CAA227882AFAAF6E6@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 06 Sep 2016 16:22:21 -0700 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] question about if a recent Linux patch is compliant with RFC7323 on window scaling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 15:16:09 -0000 On 9/4/16, 6:55 AM, "Yoshifumi Nishida" wrote: > I think the Linux patch at least follows the following principle in RFC79= 3. >=20 > The mechanisms provided allow a TCP to advertise a large window and to > subsequently advertise a much smaller window without having accepted > that much data. This, so called =B3shrinking the window,=B2 is strongl= y > discouraged. The robustness principle dictates that TCPs will not > shrink the window themselves, but will be prepared for such behavior > on the part of other TCPs. >=20 > I personally think a real question would be how FreeBSD prepares for > shrinking window. > Linux chose one way for it, but I guess all implementations don=B9t need > to follow the same way. >=20 > -- > Yoshi Hi Yoshi, Thanks a lot for the reply. I agree that's a choice for Linux. But I think FreeBSD has to follow the sa= me way; otherwise, Linux has to do something at its sender side to send a corr= ect th_seq number. I think this forum may not be a best place to talk about FreeBSD implementation. But talking about FreeBSD, I did not find anything in FreeB= SD to round-up the shrinking window due to window scale precision loss, neithe= r did I find anything about how FreeBSD can tolerate the incoming left-shifte= d th_seq ("tp->snd_una+tp->snd_wnd") in an ACK packet sent by Linux in this particular case, as Linux had sent all the data in a previous larger window= . I guess the FreeBSD will just drop the Linux ACK packet as a DUP (see "todrop= =3D tp->rcv_nxt - th->th_seq;"). I also sent a question to the FreeBSD mailing lists. But so far no reply ye= t: https://lists.freebsd.org/pipermail/freebsd-transport/2016-August/000141.ht= ml https://lists.freebsd.org/pipermail/freebsd-net/2016-September/046048.html Therefore, I think my best plan is to send separate patches to Linux and FreeBSD. For Linux, the patch will be correct the th_seq number at sender s= ide if window scale precision loss is detected. For FreebSD, I think the patch = has to round-up the receive-advertise-window at receiver side. -- Cheng From nobody Wed Sep 7 11:55:45 2016 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 52EFD12B240 for ; Wed, 7 Sep 2016 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 6wOcEYnjDWHn for ; Wed, 7 Sep 2016 11:55:42 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7074812B117 for ; Wed, 7 Sep 2016 11:55:42 -0700 (PDT) Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3F4AD278355 for ; Thu, 8 Sep 2016 03:55:40 +0900 (JST) Received: by mail-ua0-f170.google.com with SMTP id 31so21061002uao.0 for ; Wed, 07 Sep 2016 11:55:40 -0700 (PDT) X-Gm-Message-State: AE9vXwPs480wN611aA/iaG1dXr1qXr7pEQSQlgRvIn+ZyPW7D4b5vQzt9r7qJmf10uFx83J55oVUkRBpbDsF4Q== X-Received: by 10.159.32.2 with SMTP id 2mr30085021uam.74.1473274538635; Wed, 07 Sep 2016 11:55:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.194 with HTTP; Wed, 7 Sep 2016 11:55:38 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Wed, 7 Sep 2016 11:55:38 -0700 X-Gmail-Original-Message-ID: Message-ID: To: David Borman , "tcpm@ietf.org" , Sanjeev Ranot Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] (ref. RFC 7323) Increase of shift count from 14 to 15. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 18:55:44 -0000 Hi David, > On 9/6/2016 7:24 AM, David Borman wrote: > To use a shift count of 15, you have to be able to determine whether or n= ot the other side can accept a value of 15. If you send a 15, but are > talking to an older implementation that clamps it at 14 and you don=E2=80= =99t know that, then your window values, sent assuming a shift count of 15,= will > be halved by the receiver who clamped it at 14; that is probably not desi= rable as the whole point of have a shift count of 15 is to allow larger > windows, not smaller windows. Yes, exactly. But, I think we might be able to presume people who want to use shift count 15 will allocate more than 65535 * 2**15 + 65535 * 2**14 bytes memory for the connection. This won't be so difficult as I believe they should be able to allocate at least 65535 * 2 ** 14 bytes memory. Otherwise they don't need to use shift count 15. If this is possible, it can always offer 65535 window value when the peer uses shift count 14. This allows the peer to use the maximum window size it can handle. Thanks, -- Yoshi From nobody Mon Sep 12 05:31:11 2016 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 1494012B0DB; Mon, 12 Sep 2016 05:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.13 X-Spam-Level: X-Spam-Status: No, score=-104.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 qjNFb2xfmU76; Mon, 12 Sep 2016 05:31:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C94012B0A1; Mon, 12 Sep 2016 05:31:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0CA9FB80D4D; Mon, 12 Sep 2016 05:31:09 -0700 (PDT) To: bortzmeyer+ietf@nic.fr, ananth@cisco.com, randall@lakerest.net, mdalal@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160912123109.0CA9FB80D4D@rfc-editor.org> Date: Mon, 12 Sep 2016 05:31:09 -0700 (PDT) Archived-At: Cc: tcpm@ietf.org, ietf@kuehlewind.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Errata Held for Document Update] RFC5961 (4772) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 12:31:10 -0000 The following errata report has been held for document update for RFC5961, "Improving TCP's Robustness to Blind In-Window Attacks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5961&eid=4772 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Stéphane Bortzmeyer Date Reported: 2016-08-10 Held by: Mirja Kühlewind (IESG) Section: 7 Original Text ------------- [The entire section] Corrected Text -------------- No suggested text because it requires a much more serious analysis. May be adding that the rate-limit counter SHOULD be per-connection, in the spirit of RFC 6528? Notes ----- It appears the section does not specify that the counter for ACK throttling SHOULD be per-connection. In Linux, it is apparently global, which allowed its use as a side channel enabling nasty attacks (CVE-2016-5696 and the paper "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" ). Also see discussion on tcpm list about this reported errata! -------------------------------------- RFC5961 (draft-ietf-tcpm-tcpsecure-13) -------------------------------------- Title : Improving TCP's Robustness to Blind In-Window Attacks Publication Date : August 2010 Author(s) : A. Ramaiah, R. Stewart, M. Dalal Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Sep 12 05:34:03 2016 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 61D2912B210 for ; Mon, 12 Sep 2016 05:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-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 cBlQSABtctDa for ; Mon, 12 Sep 2016 05:33:59 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603F112B0FF for ; Mon, 12 Sep 2016 05:33:59 -0700 (PDT) Received: (qmail 24129 invoked from network); 12 Sep 2016 14:33:54 +0200 Received: from p5dec2ff6.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.246) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Sep 2016 14:33:54 +0200 From: "Mirja Kuehlewind (IETF)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Sep 2016 14:33:53 +0200 References: <20160730072629.D628FB80333@rfc-editor.org> To: "tcpm@ietf.org Extensions" Message-Id: <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [tcpm] Fwd: [Technical Errata Reported] RFC0793 (4753) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 12:34:01 -0000 FYI. > Anfang der weitergeleiteten Nachricht: >=20 > Von: RFC Errata System > Betreff: [Technical Errata Reported] RFC0793 (4753) > Datum: 30. Juli 2016 um 09:26:29 MESZ > An: iesg@ietf.org > Kopie: sanjeev.ranot.81@gmail.com, rfc-editor@rfc-editor.org >=20 > The following errata report has been submitted for RFC0793, > "Transmission Control Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D793&eid=3D4753 >=20 > -------------------------------------- > Type: Technical > Reported by: Sanjeev Ranot >=20 > Section: 1.5 >=20 > Original Text > ------------- > A pair of sockets uniquely identifies each connection. > That is, a socket may be simultaneously used in multiple > connections >=20 > Corrected Text > -------------- > A pair of sockets uniquely identifies each connection. Sockets can be > classified into client and server sockets. Typically a server socket=20= > may be simultaneously used in multiple connections. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Notes > ----- > TCP is connection oriented therefore when we say "sockets used in = multiple connections" it implies that the context is TCP. Considering = their use in TCP, though a single client socket can be implemented in a = way to multiplex it for connection with multiple server sockets and = exchange different SYN segments but then its same what a server process = listening for connections on server port does typically.=20 >=20 > I feel classification of sockets here is vital to facilitate = understand implicitly that in what use-case can > a socket be typically multiplexed while still keeping generality of = the statement. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC0793 (no draft string recorded) > -------------------------------------- > Title : Transmission Control Protocol > Publication Date : September 1981 > Author(s) : J. Postel > Category : INTERNET STANDARD > Source : Legacy > Area : Legacy > Stream : IETF > Verifying Party : IESG >=20 From nobody Mon Sep 12 06:42:36 2016 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 CA31D12B2A6 for ; Mon, 12 Sep 2016 06:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imuxuXIxgeEI for ; Mon, 12 Sep 2016 06:42:32 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 96FE612B2A4 for ; Mon, 12 Sep 2016 06:42:32 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id b187so136681187wme.1 for ; Mon, 12 Sep 2016 06:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=rFT4WrLtP6F0sI6mBqkjDucloRJ5+h0+OIMVcDycePE=; b=obEO/j21bOfQwJUdtZM/Ty9uNcKdKUQHjD9wq7EviwAJlQRHBWqFDgoXoTx4nryuKD VyOeJZkSJ4A4TxvrSvexzE9ULyV/eZcJg7zBSN0DkftscwIVR0IjmzPqtefC+Jxabuja UPaAIO10gDIvgXtsq+kt1PxReLuX76H0I2uKDrAXMwti0n2EFWrWwGutJ1jBDucyR8kD Omz6xqR0A+AmRsGDycZmtPZe4+4BOlagqHiDOpj46QpkHRzp4+XdRm9ZdO0I9l7JfNYr os+ouy3hb6G1os6lZtC1SL+Ev/RpzdHtbLNrEarYTUCYiKiS2g+SgfiFXg8XQOmkqM7f /b4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=rFT4WrLtP6F0sI6mBqkjDucloRJ5+h0+OIMVcDycePE=; b=VAfDcRhaGhLdYVBHqSWYYP1BphVmbGavHGsjMoGfrnIRvMSt/VeuMWm9rp7rk1DILp f6HIcD72OC9qbOclH69J9ErRKf3jPImGXCd3eqvt+AiJH9zOR0Eg7es4SCbZJBxZ9COP jA4yaSa1F/Eswd0KC+df07EL0vYm5WxA0Xvi0CmQptz1qldaGALitAjclwWmmSyxc5IV +NzQcDr1/E6zOrNRWY5B+eYQuFJWbiJThmFIwlGwvb84QXOdVNO3hzbypwHz598RSh6L rUQAuajza7WWg+pJ7wg+C/xmAmlQ14Cl0+Rzty6Y/pSczgQBL9Nbi38XqwE4x/p6S4aS wdcA== X-Gm-Message-State: AE9vXwNt8AQ2gX6zNdgiMk6aAKs3agvxqsI3PNZtsBq+RjGb1FuYtjfvGoluL6XZDnFsUhrO X-Received: by 10.28.41.131 with SMTP id p125mr10340764wmp.15.1473687750754; Mon, 12 Sep 2016 06:42:30 -0700 (PDT) Received: from wifi-65-250.uc3m.es ([2001:720:410:3343:7414:e5b5:3a66:615f]) by smtp.gmail.com with ESMTPSA id w203sm354993wmw.7.2016.09.12.06.42.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Sep 2016 06:42:29 -0700 (PDT) To: draft-ietf-tcpm-cubic@ietf.org, tcpm IETF list From: marcelo bagnulo braun Message-ID: Date: Mon, 12 Sep 2016 15:42:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] Questions and comments about draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 13:42:34 -0000 Hi, I have been reading draft-ietf-tcpm-cubic-02 and I have a few questions and comments about it that I attach below. In general, I found the draft easy to follow and overall in good shape. Dont want to open a can of worms here. If this has been debated before, point me to the proper thread and i will check it. I am not sure I understand why the intended status of this document is Informational if the status of RFC 5681 is Standards Track. Shouldnt this be standards track, or experimental if the WG feels that more experience is needed? In the Introduction, it reads: CUBIC maintains the same window growth rate independent of RTTs outside of the TCP-friendly region, and flows with different RTTs have the similar window sizes under steady state when they operate outside the TCP-friendly region. This ensures CUBIC flows with different RTTs to have their bandwidth shares linearly proportional to the inverse of their RTT ratio (the longer RTT, the smaller the share). I find this part a bit confusing. I mean, the first two sentences seem to say that in cubic, the rate is almost independent of the RTT and then the last sentence, seem to conclude from the two previous sentences that the longer the RTT, the smaller the rate. I understand what is meant is that cubic is less biased than classic TCP in terms of RTT but it is still somehow biased, but in the same sense than TCP. If this is the case, the last sentence should be in oposition to the two previous one maybe? In section 3.1, the formula for K is presented. I understnad this results from including in Eq.1 that W(t=0) is equal to W_max*beta_cubic. Maybe it would be worthwhile stating that explicitly. Later in section 3.1 it talks about W_cubic(t+RTT). How do you calculate RTT? Is it the RTT of the last ACK? do you do some kind of weighted average? Section 3.2. I would like to understand when is the sender int he TCP-friendly region. If we call t=0 the moment of the last congestion notification (i.e. last loss) and we call t=K the moment when the cwnd is Wmax, then at which point in time is the sender in the TCP-friendly region? I would assume that in an interval centered in t=K, is that the case? I mean, the way it is described i.e. first the TCP-friendly region and then the concave region and then the convex region, made me thought initially that they were sequential (i.e. at t=0 it starts in the TCP-friendly region and then it moves to the concave region and then to the convex) but I understand this is not the case? Maybe stating explicitly when the different regions occur may facilitate the reading? Section 3.3 and 3.4. I understand that the function that governs the growth in both regions is the same and that the difference is conceptual rather than in the algorithm, correct? Maybe it would be clearer to state this explicitly and maybe merge these two sections. Also, I think that having one section with a summary of the algorithm, where all the congestion control algorithm is described toghether would be beneficial. Maybe an appendix? Section 4.3 reads: CUBIC is designed to remedy the poor performance of TCP in fast long- distance networks. It is not designed for wireless networks. I find this very wierd. does this means that cubic doesnt work well if my first link is a wifi or a cellular link? This is probably/hopefully not what you mean. Maybe you are referring to wireless mesh/ad-hoc networks? If so, I suggest making it more explicit. Anyway, good work, thanks for doing it. Regards, marcelo From nobody Mon Sep 12 07:25:12 2016 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 005B412B377 for ; Mon, 12 Sep 2016 07:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 pAZwncErzd61 for ; Mon, 12 Sep 2016 07:25:06 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F3E12B2B1 for ; Mon, 12 Sep 2016 07:08:52 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id u8CDF6nE004643; Mon, 12 Sep 2016 08:15:06 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David Borman In-Reply-To: <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> Date: Mon, 12 Sep 2016 09:08:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160730072629.D628FB80333@rfc-editor.org> <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Technical Errata Reported] RFC0793 (4753) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 14:25:11 -0000 I don=E2=80=99t agree with this change. Sockets are generic; while many = applications that use sockets put a client/server model on top of = sockets, that is the semantics of the application, not the underlying = socket connection. At the TCP layer the only distinction is that you = have passive (LISTEN/ACCEPT) and active (CONNECT) sockets. For example, = FTP can set up the data socket pair in either direction. Even with the client/server model, a client can use bind() to use the = exact same socket (address/port) to connect to multiple machines, so = there=E2=80=99s no reason to imply that only the server side can use the = same socket for multiple connections. And then there is the simultaneous open case, where both sockets use = CONNECT and there is no distinction between them. -David Borman > On Sep 12, 2016, at 7:33 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > FYI. >=20 >> Anfang der weitergeleiteten Nachricht: >>=20 >> Von: RFC Errata System >> Betreff: [Technical Errata Reported] RFC0793 (4753) >> Datum: 30. Juli 2016 um 09:26:29 MESZ >> An: iesg@ietf.org >> Kopie: sanjeev.ranot.81@gmail.com, rfc-editor@rfc-editor.org >>=20 >> The following errata report has been submitted for RFC0793, >> "Transmission Control Protocol". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D793&eid=3D4753 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Sanjeev Ranot >>=20 >> Section: 1.5 >>=20 >> Original Text >> ------------- >> A pair of sockets uniquely identifies each connection. >> That is, a socket may be simultaneously used in multiple >> connections >>=20 >> Corrected Text >> -------------- >> A pair of sockets uniquely identifies each connection. Sockets can be >> classified into client and server sockets. Typically a server socket=20= >> may be simultaneously used in multiple connections. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Notes >> ----- >> TCP is connection oriented therefore when we say "sockets used in = multiple connections" it implies that the context is TCP. Considering = their use in TCP, though a single client socket can be implemented in a = way to multiplex it for connection with multiple server sockets and = exchange different SYN segments but then its same what a server process = listening for connections on server port does typically.=20 >>=20 >> I feel classification of sockets here is vital to facilitate = understand implicitly that in what use-case can >> a socket be typically multiplexed while still keeping generality of = the statement. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC0793 (no draft string recorded) >> -------------------------------------- >> Title : Transmission Control Protocol >> Publication Date : September 1981 >> Author(s) : J. Postel >> Category : INTERNET STANDARD >> Source : Legacy >> Area : Legacy >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Sep 12 11:19:33 2016 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 815A712B029 for ; Mon, 12 Sep 2016 11:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 cVa1jZov7rOg for ; Mon, 12 Sep 2016 11:19:31 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 2927512B026 for ; Mon, 12 Sep 2016 11:19:31 -0700 (PDT) Received: from [128.9.184.62] ([128.9.184.62]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u8CIHbHL008465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Sep 2016 11:17:37 -0700 (PDT) To: "Mirja Kuehlewind (IETF)" , "tcpm@ietf.org Extensions" References: <20160730072629.D628FB80333@rfc-editor.org> <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> From: Joe Touch Message-ID: <24a111cf-1e20-bc4e-2a9b-9eb0f3ee5821@isi.edu> Date: Mon, 12 Sep 2016 11:17:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u8CIHbHL008465 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] Fwd: [Technical Errata Reported] RFC0793 (4753) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 18:19:32 -0000 Hi, all, IMO this proposed errata confuses the concept of an OS socket (a mechanism used to attach network communications to a process) with a TCP socket (which is an pair. A TCP connection is defined by two TCP sockets, one on each end (a socket pair). A single TCP socket (the one addr:port pair) can have multiple of either incoming or outgoing connections or both. A Unix socket doesn't correspond to a TCP socket pair until after accept() or connect() returns at best, and may have other semantic differences. As a result, this errata should be rejected. Joe On 9/12/2016 5:33 AM, Mirja Kuehlewind (IETF) wrote: > FYI. > >> Anfang der weitergeleiteten Nachricht: >> >> Von: RFC Errata System >> Betreff: [Technical Errata Reported] RFC0793 (4753) >> Datum: 30. Juli 2016 um 09:26:29 MESZ >> An: iesg@ietf.org >> Kopie: sanjeev.ranot.81@gmail.com, rfc-editor@rfc-editor.org >> >> The following errata report has been submitted for RFC0793, >> "Transmission Control Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=793&eid=4753 >> >> -------------------------------------- >> Type: Technical >> Reported by: Sanjeev Ranot >> >> Section: 1.5 >> >> Original Text >> ------------- >> A pair of sockets uniquely identifies each connection. >> That is, a socket may be simultaneously used in multiple >> connections >> >> Corrected Text >> -------------- >> A pair of sockets uniquely identifies each connection. Sockets can be >> classified into client and server sockets. Typically a server socket >> may be simultaneously used in multiple connections. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Notes >> ----- >> TCP is connection oriented therefore when we say "sockets used in multiple connections" it implies that the context is TCP. Considering their use in TCP, though a single client socket can be implemented in a way to multiplex it for connection with multiple server sockets and exchange different SYN segments but then its same what a server process listening for connections on server port does typically. >> >> I feel classification of sockets here is vital to facilitate understand implicitly that in what use-case can >> a socket be typically multiplexed while still keeping generality of the statement. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC0793 (no draft string recorded) >> -------------------------------------- >> Title : Transmission Control Protocol >> Publication Date : September 1981 >> Author(s) : J. Postel >> Category : INTERNET STANDARD >> Source : Legacy >> Area : Legacy >> Stream : IETF >> Verifying Party : IESG >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Sep 12 11:23:40 2016 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 E275F12B020 for ; Mon, 12 Sep 2016 11:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 Tt7KNtX_KnC8 for ; Mon, 12 Sep 2016 11:23:36 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 C47BB127735 for ; Mon, 12 Sep 2016 11:23:35 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id o3so19916999ita.1 for ; Mon, 12 Sep 2016 11:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L02GziuT4B6GfvTrq+H7fzZAXF/OhEcXNm6rcEfXrFo=; b=Zra9FIcnfI12WUKworQ2QkzIlW2Jkp6RnCwfDShqJp/DhqJ7eGHowpaXLZbt29+nvl Ndxmleaz0QvUjrSAJTyx05DG8pZEaVY/c9mrp+fpw0Q+Os3KenfUlgBsXcMZETl1uGAm X82fBEE9inmc4w9z2OIy586JhBjqmV/1syQzZY+QZ2JdDTnO2x53pgCbuHuUGq3LmGk8 /i4ZVI+jwSl0i6twMip2iqTHsOz29BKu58JE1xnxpaMwgT9nkZytaP8TJUKQOtM46hLn te/E2XAHy2pG5ukXaRznU+50IdGhSnzeslxDqZimLEf5vjiys8u12zx/O3InHw693LMT mCpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L02GziuT4B6GfvTrq+H7fzZAXF/OhEcXNm6rcEfXrFo=; b=Od+lVKX1prwQJJ5QSn4foZVviemIjQZA+V/SvzaQQi/QRcK6l3u+u8zx+2BHYTuTW5 jVFvldAtzIoe1cu3d1ePSPcF+9SvIKsCeW4IrQfj2biE8GY/J0dziquABjbfPs25V3v0 9fqFgvTyd9bqIbC6rCUIfCpVaiSNfMQtI9KsS6Jdyc3Nb/aAK+4F0vz5YXb+Q8KLXhxt 6HrYv7iDReontmcUhqUeY8xfy7h+honUl9h3+9jBvu7Ob1ff96lXbQh+I8fnVHP5EP/w AYlbWxr203O6saYIibLYtHPUWy3Zz7DKdS0J4d156Wib2vYipK4AxvJeqG/RmThJ1f2K piaw== X-Gm-Message-State: AE9vXwPFBZJ+fXyqGbCbhlfzMjpv9FTOhmG9dNDn4YjnsZYbX0DG9wRR4A2WUE+qAgN8sdFgkogaK38k4EPh9M2P X-Received: by 10.157.32.111 with SMTP id n102mr22249368ota.56.1473704614761; Mon, 12 Sep 2016 11:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.135 with HTTP; Mon, 12 Sep 2016 11:22:54 -0700 (PDT) In-Reply-To: <24a111cf-1e20-bc4e-2a9b-9eb0f3ee5821@isi.edu> References: <20160730072629.D628FB80333@rfc-editor.org> <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> <24a111cf-1e20-bc4e-2a9b-9eb0f3ee5821@isi.edu> From: Yuchung Cheng Date: Mon, 12 Sep 2016 11:22:54 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a11370a8a11773a053c53982b Archived-At: Cc: "tcpm@ietf.org Extensions" , "Mirja Kuehlewind \(IETF\)" Subject: Re: [tcpm] Fwd: [Technical Errata Reported] RFC0793 (4753) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 18:23:38 -0000 --001a11370a8a11773a053c53982b Content-Type: text/plain; charset=UTF-8 i agree w/ Joe and David that this errata is not necessary. On Mon, Sep 12, 2016 at 11:17 AM, Joe Touch wrote: > Hi, all, > > IMO this proposed errata confuses the concept of an OS socket (a > mechanism used to attach network communications to a process) with a TCP > socket (which is an pair. > > A TCP connection is defined by two TCP sockets, one on each end (a > socket pair). > > A single TCP socket (the one addr:port pair) can have multiple of either > incoming or outgoing connections or both. > > A Unix socket doesn't correspond to a TCP socket pair until after > accept() or connect() returns at best, and may have other semantic > differences. > > As a result, this errata should be rejected. > > Joe > > > On 9/12/2016 5:33 AM, Mirja Kuehlewind (IETF) wrote: > > FYI. > > > >> Anfang der weitergeleiteten Nachricht: > >> > >> Von: RFC Errata System > >> Betreff: [Technical Errata Reported] RFC0793 (4753) > >> Datum: 30. Juli 2016 um 09:26:29 MESZ > >> An: iesg@ietf.org > >> Kopie: sanjeev.ranot.81@gmail.com, rfc-editor@rfc-editor.org > >> > >> The following errata report has been submitted for RFC0793, > >> "Transmission Control Protocol". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=793&eid=4753 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Sanjeev Ranot > >> > >> Section: 1.5 > >> > >> Original Text > >> ------------- > >> A pair of sockets uniquely identifies each connection. > >> That is, a socket may be simultaneously used in multiple > >> connections > >> > >> Corrected Text > >> -------------- > >> A pair of sockets uniquely identifies each connection. Sockets can be > >> classified into client and server sockets. Typically a server socket > >> may be simultaneously used in multiple connections. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Notes > >> ----- > >> TCP is connection oriented therefore when we say "sockets used in > multiple connections" it implies that the context is TCP. Considering > their use in TCP, though a single client socket can be implemented in a > way to multiplex it for connection with multiple server sockets and > exchange different SYN segments but then its same what a server process > listening for connections on server port does typically. > >> > >> I feel classification of sockets here is vital to facilitate understand > implicitly that in what use-case can > >> a socket be typically multiplexed while still keeping generality of the > statement. > >> > >> Instructions: > >> ------------- > >> This erratum is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC0793 (no draft string recorded) > >> -------------------------------------- > >> Title : Transmission Control Protocol > >> Publication Date : September 1981 > >> Author(s) : J. Postel > >> Category : INTERNET STANDARD > >> Source : Legacy > >> Area : Legacy > >> Stream : IETF > >> Verifying Party : IESG > >> > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a11370a8a11773a053c53982b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
i agree w/ Joe and David that this errata is not necessary= .

On Mon, Sep 12, = 2016 at 11:17 AM, Joe Touch <touch@isi.edu> wrote:
Hi, all,

IMO this proposed errata confuses the concept of an OS socket (a
mechanism used to attach network communications to a process) with a TCP socket (which is an <IP address:port> pair.

A TCP connection is defined by two TCP sockets, one on each end (a
socket pair).

A single TCP socket (the one addr:port pair) can have multiple of either incoming or outgoing connections or both.

A Unix socket doesn't correspond to a TCP socket pair until after
accept() or connect() returns at best, and may have other semantic
differences.

As a result, this errata should be rejected.

Joe


On 9/12/2016 5:33 AM, Mirja Kuehlewind (IETF) wrote:
> FYI.
>
>> Anfang der weitergeleiteten Nachricht:
>>
>> Von: RFC Errata System <rfc-editor@rfc-editor.org>
>> Betreff: [Technical Errata Reported] RFC0793 (4753)
>> Datum: 30. Juli 2016 um 09:26:29 MESZ
>> An: iesg@ietf.o= rg
>> Kopie: sanjeev.ranot.81@gmail.com, rfc-editor@rfc-editor.org
>>
>> The following errata report has been submitted for RFC0793,
>> "Transmission Control Protocol".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.o= rg/errata_search.php?rfc=3D793&eid=3D4753
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Sanjeev Ranot <sanjeev.ranot.81@gmail.com>
>>
>> Section: 1.5
>>
>> Original Text
>> -------------
>> A pair of sockets uniquely identifies each connection.
>> That is, a socket may be simultaneously used in multiple
>> connections
>>
>> Corrected Text
>> --------------
>> A pair of sockets uniquely identifies each connection. Sockets can= be
>> classified into client and server sockets. Typically a server sock= et
>> may be simultaneously used in multiple connections.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Notes
>> -----
>> TCP is connection oriented therefore when we say "sockets use= d in multiple connections" it implies that the context is TCP.=C2=A0 C= onsidering their use in TCP,=C2=A0 though a single client socket can be imp= lemented in a way to multiplex it for connection with multiple server socke= ts and exchange different SYN segments but then its=C2=A0 same what a serve= r process listening for connections on server port does typically.
>>
>> I feel classification of sockets here is vital to facilitate under= stand implicitly that in what use-case can
>> a socket be typically multiplexed while still keeping generality o= f the statement.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If neces= sary, please
>> use "Reply All" to discuss whether it should be verified= or
>> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=
>>
>> --------------------------------------
>> RFC0793 (no draft string recorded)
>> --------------------------------------
>> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tran= smission Control Protocol
>> Publication Date=C2=A0 =C2=A0 : September 1981
>> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: J. Postel
>> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : INTERNET STAND= ARD
>> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Legacy >> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Lega= cy
>> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
>> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a11370a8a11773a053c53982b-- From nobody Mon Sep 12 15:14:06 2016 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 B5E5412B0D2; Mon, 12 Sep 2016 15:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_SPAM=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 ncaB9V4ASIqo; Mon, 12 Sep 2016 15:14:02 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E8D12B008; Mon, 12 Sep 2016 15:14:02 -0700 (PDT) Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 687DD29C0A0; Tue, 13 Sep 2016 07:14:00 +0900 (JST) Received: by mail-vk0-f42.google.com with SMTP id m62so102685245vkd.3; Mon, 12 Sep 2016 15:14:00 -0700 (PDT) X-Gm-Message-State: AE9vXwPCljw4Qi4osoVJ8e7FzQ0hAv0pVu+CVYCIUfGJygVyX5Ij4k9Ahs7Rzmm0xUR66Sx7cLYfUZlrNZudfQ== X-Received: by 10.31.188.144 with SMTP id m138mr15044081vkf.84.1473718438964; Mon, 12 Sep 2016 15:13:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.194 with HTTP; Mon, 12 Sep 2016 15:13:58 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Mon, 12 Sep 2016 15:13:58 -0700 X-Gmail-Original-Message-ID: Message-ID: To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Questions and comments about draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 22:14:04 -0000 Hi Marcelo, Thanks for the review. On Mon, Sep 12, 2016 at 6:42 AM, marcelo bagnulo braun wrote: > Hi, > > > I have been reading draft-ietf-tcpm-cubic-02 and I have a few questions and > comments about it that I attach below. > > In general, I found the draft easy to follow and overall in good shape. > > Dont want to open a can of worms here. If this has been debated before, > point me to the proper thread and i will check it. I am not sure I > understand why the intended status of this document is Informational if the > status of RFC 5681 is Standards Track. Shouldnt this be standards track, or > experimental if the WG feels that more experience is needed? Yes, we had discussed it before and I believe it is our consensus. Please check the following threads. https://www.ietf.org/mail-archive/web/tcpm/current/msg09600.html https://www.ietf.org/mail-archive/web/tcpm/current/msg09639.html -- Yoshi From nobody Mon Sep 12 16:32:53 2016 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 F349512B14B for ; Mon, 12 Sep 2016 16:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-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 V_NYl29e1q9K for ; Mon, 12 Sep 2016 16:32:47 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1A512B12C for ; Mon, 12 Sep 2016 16:32:47 -0700 (PDT) Received: (qmail 14307 invoked from network); 13 Sep 2016 01:32:41 +0200 Received: from p5dec2bf8.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.248) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Sep 2016 01:32:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 13 Sep 2016 01:32:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <628F252F-2173-4812-BEC0-4EC4E97E789E@kuehlewind.net> References: <20160730072629.D628FB80333@rfc-editor.org> <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> <24a111cf-1e20-bc4e-2a9b-9eb0f3ee5821@isi.edu> To: Yuchung Cheng , dab@weston.borman.com, Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org Extensions" , sanjeev.ranot.81@gmail.com Subject: Re: [tcpm] [Technical Errata Reported] RFC0793 (4753) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 23:32:51 -0000 Hi all, thanks for your feedback. I also thought that the clarification is at = least not necessary. I=E2=80=99ll wait a few more days, just to give = others a chance to comment, and then reject if nobody shouts in the mean = time. Mirja > Am 12.09.2016 um 20:22 schrieb Yuchung Cheng : >=20 > i agree w/ Joe and David that this errata is not necessary. >=20 > On Mon, Sep 12, 2016 at 11:17 AM, Joe Touch wrote: > Hi, all, >=20 > IMO this proposed errata confuses the concept of an OS socket (a > mechanism used to attach network communications to a process) with a = TCP > socket (which is an pair. >=20 > A TCP connection is defined by two TCP sockets, one on each end (a > socket pair). >=20 > A single TCP socket (the one addr:port pair) can have multiple of = either > incoming or outgoing connections or both. >=20 > A Unix socket doesn't correspond to a TCP socket pair until after > accept() or connect() returns at best, and may have other semantic > differences. >=20 > As a result, this errata should be rejected. >=20 > Joe >=20 >=20 > On 9/12/2016 5:33 AM, Mirja Kuehlewind (IETF) wrote: > > FYI. > > > >> Anfang der weitergeleiteten Nachricht: > >> > >> Von: RFC Errata System > >> Betreff: [Technical Errata Reported] RFC0793 (4753) > >> Datum: 30. Juli 2016 um 09:26:29 MESZ > >> An: iesg@ietf.org > >> Kopie: sanjeev.ranot.81@gmail.com, rfc-editor@rfc-editor.org > >> > >> The following errata report has been submitted for RFC0793, > >> "Transmission Control Protocol". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=3D793&eid=3D4753 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Sanjeev Ranot > >> > >> Section: 1.5 > >> > >> Original Text > >> ------------- > >> A pair of sockets uniquely identifies each connection. > >> That is, a socket may be simultaneously used in multiple > >> connections > >> > >> Corrected Text > >> -------------- > >> A pair of sockets uniquely identifies each connection. Sockets can = be > >> classified into client and server sockets. Typically a server = socket > >> may be simultaneously used in multiple connections. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Notes > >> ----- > >> TCP is connection oriented therefore when we say "sockets used in = multiple connections" it implies that the context is TCP. Considering = their use in TCP, though a single client socket can be implemented in a = way to multiplex it for connection with multiple server sockets and = exchange different SYN segments but then its same what a server process = listening for connections on server port does typically. > >> > >> I feel classification of sockets here is vital to facilitate = understand implicitly that in what use-case can > >> a socket be typically multiplexed while still keeping generality of = the statement. > >> > >> Instructions: > >> ------------- > >> This erratum is currently posted as "Reported". If necessary, = please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC0793 (no draft string recorded) > >> -------------------------------------- > >> Title : Transmission Control Protocol > >> Publication Date : September 1981 > >> Author(s) : J. Postel > >> Category : INTERNET STANDARD > >> Source : Legacy > >> Area : Legacy > >> Stream : IETF > >> Verifying Party : IESG > >> > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Sep 12 18:23:01 2016 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 A665512B175; Mon, 12 Sep 2016 18:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0XCOQ--G95e; Mon, 12 Sep 2016 18:22:57 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0048.outbound.protection.outlook.com [207.46.163.48]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AC212B15F; Mon, 12 Sep 2016 18:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gOk3eFpSVHmPsqksjJAPM/PA3o/A5wP+N0Xg7ykGMZs=; b=wrjEZoZ5D56Ytonx61n8ItizrqzGuby7vPOlB3ZnDU1Nf6w1VJrl+cHXf8FSAxApLLjIt8XBwjrKWnvpi7OoI9ZfvdWu/ZVonWRG9LxdFyGw+M6MPGCyHyKb40QAENqEjeg+yZ43nRhrxDDWczC9Bx/mZvactFfThGopCEGX3ac= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.164] (97.98.140.59) by MWHPR08MB2525.namprd08.prod.outlook.com (10.173.230.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Tue, 13 Sep 2016 01:22:53 +0000 To: marcelo bagnulo braun References: From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Mon, 12 Sep 2016 20:22:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: CY1PR08CA0023.namprd08.prod.outlook.com (10.163.94.161) To MWHPR08MB2525.namprd08.prod.outlook.com (10.173.230.136) X-MS-Office365-Filtering-Correlation-Id: 9c8112ba-03c6-432e-a269-08d3db747cc6 X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2525; 2:LQ90mssHBD1zJSQIB0ynHaBIbrCoT4p31F41C8iwFUrn+7q5E/JnyHASyCfA5bXTQDkio2cMNTqa0I8FlkygOmDSWNFPv7GAgANLMxh6wSPG7/cuc//geQEMRZbUbL8J+Jgx+SAF4Xf3Qs3jPMpybqInbuHJlrYvuDFaM65Uoo1X7lB71mFW4dD2HtoOo3Aq; 3:6vqEiPRis9djfNilSYVcqU/Ni0yfKP/4TC9GV06e/RaO+mmRHx/u3WYM576DEaGc93oRIA+ai1d3yyzSdW6wDgRWG32nXY0VVlKbFA3UAM56l6+17kxHzpL+u2ldPgYO; 25:n3164bb/sG5SzZNIZhCg3AYqkbFBjpVyEYjg7eyZSNO2TzjmYH2haVQR2SKVmoFz8llJ7EEkvGD0qNluswlzB2AufuRb6OrIc0OXoEVP5o2h6T8oRuVfNX6duKd1oP3pyTOMrWasRS7V+M5KGLYkhUf1eiJSB1k1RPmK/Epe8OqoIKe/fxvE85zZVI0j2rJm2UckUCHWSQaGsDq4VsqC9mLwd+ILT36CITTfX3kuxLbpXxOo8UNodYG6MQP4qqUWF3VDZE0w0qLwqhdwVg8NDRdBM+gLxqNtcsQF5S61DxUDwFBlXjfHaGRo4ooyZlnO5IuNs+ST1rXiM/M+dk3UCAV9+Azg080WMexIypHRnLUKtxaFXNrvCWjOdnwcm4Km/byL+bMAoHu/wY5X8lwBVWMmU9DC2znWlRYkn0YLTRo= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR08MB2525; X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2525; 31:yDvwY/Fpst416jIy0cBVd+w04SHspT+Ns7uAukz4bzJ1yQ4m57ZzOx5K/9wPQxyEN09+IpxRXUuAsmYQ6HiBHsj7z4JGAgBvVJvVQsqb/5SUDXBerH0lWsTGTsk3M0PVAXoavGYiy0jKpk75vH8BnbLFmWjxlqhsp1Uw1nKSl3wPe+rID7z7HHc0aGMraeM00djhl4RdZ423kbzPGwP13ZnNZgIrrwN5oG5LiR1tTvM=; 20:YcCHUgblHgPLw5tv46PSr1ON4GLVBp/Vvpu/VPwR2fYAJ0m7j2rbLc4pmq0rsPUGgpvk0+6qpHjhh0MBZfNqJGrBXKYU/xz2KpZlmFWZX0GfeAbHdn3OaTmuMG/xrB0dHcs89f4Fhh4XPILqozj2s3fGrziEE3blgZRRbJUbg/WkSgHWcVS7VMvglzPa4BS+sTWGqP4FxBW6UtKSNhOPmdG8PNhJhBbTIEL/MdhGVOoOahpj5BW9Pnh1jhRgr/AfxwIKshnQqqGCSQgUBZLPMRaGiX3fWJQ30Vg4l2c03WS5RN/0vJ7jysfwOTH9cx+Wdb+6VGHx6SqIvdAZAuHmqDKnXtV7Jd8DD2Ca3wYxPF6SAeRzpqIvCaUvqk7ulzNVDXGsMJMHduy3oys4dd2Ij05R6bMM0G2Cpa3n80U2QWMye4/2UXrpeVgQAMkcGN406U0l5RZqiTCg5ZthtBwhCRDbBK4KFFqptEu8iMhOI4WJzd7ov2qe20/06lquyfeQ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(176510541525296); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:MWHPR08MB2525; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2525; X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2525; 4:rTmQa74YoDZkYcfVWMDb6Rq+V3V3ghlYmroUFOR0xxPbTShwmAPGn6mshTlnKFNX3Kdn3kqSYhcZH22CBf032rY/md11AzGcDVDFvFk1a1xwzm5sEHkbJ9xAEVkLujnuHjGLqVDl5pIIa5tgZBPN46eX0KYaUJ2d8yI747u6tsnAB3rR6oxUC1rl8V9Xshf+Q0Kpteb/4seVBo/Zj6t4+qLYgKI9bqOFv61I6BsqXgTztAbtXStPKFRzvsH1E5+3g1oyfTIv7J1YJOJFrDJQzUeEMfw75B62fkZMtoFSo6vMVxpF8PHjua+5wcfCGeKyDDKXP5lDfNt4SONW+lScIYTj4PxwjhE6Wv+al+rRppHyAT+Weocpbajl5DmTNXvgqaCnyr3ge2RXm6E4J/HNvtE0FukyhedZVUW6rwcLTkNd7KkwN8Gadth+amOC8wby X-Forefront-PRVS: 0064B3273C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(24454002)(189002)(43784003)(52314003)(199003)(51444003)(377454003)(25584004)(31014005)(65826007)(230700001)(230783001)(36756003)(77096005)(117156001)(189998001)(97736004)(75432002)(92566002)(15975445007)(31696002)(83506001)(86362001)(19580395003)(110136003)(47776003)(3846002)(2906002)(8676002)(305945005)(81156014)(4326007)(7736002)(6116002)(5890100001)(81166006)(19580405001)(64126003)(7846002)(33646002)(54356999)(68736007)(2950100001)(76176999)(50986999)(89122001)(586003)(101416001)(88552002)(106356001)(105586002)(66066001)(50466002)(4001350100001)(23746002)(31686004)(65806001)(90282001)(5660300001)(42186005)(65956001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2525; H:[192.168.0.164]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; MWHPR08MB2525; 23:upZiKkdZdHnh6obTcYgG0jgKKspCR5NC+qL2V?= =?Windows-1252?Q?ZmJzHxg4wuKOiahOR1I2mErrzpVK7xb6NdppAw3A58nK2vdUxZuk2CDA?= =?Windows-1252?Q?4dRlzyGCsIp5pOPFVopsJ4qGVGR9inLhUxIW5CaY5lXgoGz3sbXpkGXb?= =?Windows-1252?Q?vzKpDFq/7kB4gLNSB08rzo6lEBlFijxOKLOPpyl8QCsg6cww1SI3t3tk?= =?Windows-1252?Q?XWfmqH89vFJp3UzZ3KN8CLL/XzslJyOdRMxsiPMAihCRmNvXbY1lOoAH?= =?Windows-1252?Q?9n/QyIA8JwFaXuDP+3MAZI4Vm6MV6YXiH85hi4Pxqwq3b7YsrN/Y9+0K?= =?Windows-1252?Q?vmlD+XnhmAq5xwB02wHQbHn0h68wY+5PgwlmatU7UPNjZPsTY0OIBgXe?= =?Windows-1252?Q?BbZ18GJbzWPqGKneIkc5pj6rn+0TzjgOmoIfy4ZHoVjBgkz/TDqztTOF?= =?Windows-1252?Q?7B6ahn79KdraZ/UW2ODGkPMhvcK5edTHo11hKw9eq2GLX61IRLGUR9fq?= =?Windows-1252?Q?N4dbK+ABC24rkN0gLRSTNFwkGpZpjh1MyJ1CzfLYqQMsRK1n+Fi2GYOC?= =?Windows-1252?Q?E7pYIcFCCXwyTecgkC4N1YmadliEHvxGBhWIf370H73eQ0qxVUdgwe24?= =?Windows-1252?Q?ns3Bevf/pxsXRqz3c3ecLJTW+ZZ0tFlf/wEgvsmNd1j24KBNoFyY4WYS?= =?Windows-1252?Q?eKNvQzwb3ZKuOaSoF6/fnSWwX2e/ceKhiByRMpfSxwabcLQQ1cqUT4hP?= =?Windows-1252?Q?IJun0lj/YtGCie8edziL+kmNZyvN3eY1b9Qdyu9yvHn166HVw2ev9YsX?= =?Windows-1252?Q?7WSnHsqVOZhfNUQVvyedlcl+7YL4HsYm5mZeSGinWEosfURix2LBARdL?= =?Windows-1252?Q?34l0Lx5yyQd2KkrvdZyYYDAonlnjDsONKvLwD1S74AD7g6rrLYmu4Da4?= =?Windows-1252?Q?OqApLI3FaCalgLEn1E8P4rjyB50gHgTJUQ9i7D5WxcFcorsQZarxPQ6x?= =?Windows-1252?Q?RyeYbeq40+a2Kgw2evYi9I9ZFn6C40hD8rB/CkOyr3Folk3/T/mgb5QD?= =?Windows-1252?Q?27WsP4iejG7fCu7BuSs/grhMJJIbG70lm01Q+RXW7gfb7X2KpIvy+06w?= =?Windows-1252?Q?1UtZKBSPucvUnEkQfXLyMVejF2DPHMJaA+L2ao1SSEcojQl+bhyoDv+c?= =?Windows-1252?Q?bxm6IKknZAz3eICtdFFSmAA7cM00/97GQVgz9XeUghO/nU6SKcCfblP4?= =?Windows-1252?Q?PFm8dnhOxRRRQSdSfD0exch6R5Kmv8Ardr3d+9fPhGQTxJiom477p0BV?= =?Windows-1252?Q?hzpKJEJm3gqfIP3OCgDNgMAIV8onLx6Sz0PjodplV06rieqNoic2R0/4?= =?Windows-1252?Q?Wn8hZSVyda0UEIxjdY4UXRoyBMXbXF3C4kqJDrRkKSrnrK5nML692REe?= =?Windows-1252?Q?4e7eVexdA+c6GNyjw+Tb6zbKo+Uarj4oZtr4vbVROaf6/xJfhBC/jT8m?= =?Windows-1252?Q?m8t8HHqdLWybqNhBKbwhEx37DEGe/yAw6lpvtpeeLfSIEMQZ4U50SBHl?= =?Windows-1252?Q?6erQDscnnTwDsQiJ7DXQvpVq3BSVHFyudlcJ4hDf6syXJ994Yy4LNLvb?= =?Windows-1252?Q?0vIxVq8SNyslXcBsDkQwcRrv254VnB+McL+VAgYWxlPsGt95iNcw4soW?= =?Windows-1252?Q?P7JY8UAdfDRuXBB55YT1plA0mY4lCW34FjYloSW9dt7Kavsp1gM?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2525; 6:vkSZNLPmfBsEo9v1zdqFK3+pDtyVSjLL1Aw4a1ubTrAUoQyTLRPCI3o26woSDCYf2w46ZlsgTBNBBdlLHKH8JJycvYBbBqQQnYG7i88aENwzOoOaoD3DTYkiyVxom/IRqlXPbfA8d9klSSDBoULROszBY9HSItgopg/CUOtb7Ydo44Jo73jDOjKgYRlxQUHjSwKuVhOQobULxFj9P8M73d2KHBUcYFWF5WlUcp5CLZtVp0bRFcCHyE5zsg2RqgZS6bXjIDE5ByxUPqc71x+gttgvNVW7d+qWQ9vmlCo6Qwc=; 5:wIC7ZCGgkUb+uiy+jQhqAO59iu/LZIcF1G8VK3qavN9wrXTOKQLxp11I/ynCMTz6OBoIfUa9EcQn+0P3eOgBjLEIHLlxIMH/3gNkD3ODC1xUZZBkSw8P4vkL/k2RJUW2ErjCf2NHoc6WZUwz6+u/AQ==; 24:UOXfMlxJwJ+0q65X3ovPcLvMo3c8kGOSzI3xg38wSF8suxste/vssMcWFZw0owE/Bp0SkUaVJLmnKzTc4nI2PHuezprufHYLdmepQjPJ3g4=; 7:s6BUJZwIPrbrzXEFbLAkRFwTMQFr1WIVPlCuWVV2qHtwcbeoRODQ4L8EGSSYBmPQw5IEJRxEpRjYpKIATC8hQSD5jjdx4VwyYsS/x1H2CtoBc684ziIzfIDgWbWECQJsflFxHUN3aRNB4WehOqfISQyhwx0YoNLhyGTpyA93UOZblIO8JJrhC7SNNeNKWktS7CwR/iPto8TQFZG6t+Jt5p7eV6ZN1pJ7gdAV89ogXTy6DNChkfHihZSDMkqrMGZg SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2016 01:22:53.9148 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2525 Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Questions and comments about draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 01:23:00 -0000 Dear Marcel, Thanks for your comments! I will revise the draft accordingly. Below are some short and quick answers. Lisong On 9/12/2016 8:42 AM, marcelo bagnulo braun wrote: > Hi, > > > I have been reading draft-ietf-tcpm-cubic-02 and I have a few > questions and comments about it that I attach below. > > In general, I found the draft easy to follow and overall in good shape. > > Dont want to open a can of worms here. If this has been debated > before, point me to the proper thread and i will check it. I am not > sure I understand why the intended status of this document is > Informational if the status of RFC 5681 is Standards Track. Shouldnt > this be standards track, or experimental if the WG feels that more > experience is needed? > > > In the Introduction, it reads: > > CUBIC maintains the same window growth rate independent of RTTs > outside of the TCP-friendly region, and flows with different RTTs > have the similar window sizes under steady state when they operate > outside the TCP-friendly region. This ensures CUBIC flows with > different RTTs to have their bandwidth shares linearly proportional > to the inverse of their RTT ratio (the longer RTT, the smaller the > share). > > I find this part a bit confusing. I mean, the first two sentences seem > to say that in cubic, the rate is almost independent of the RTT and > then the last sentence, seem to conclude from the two previous > sentences that the longer the RTT, the smaller the rate. > I will revise it to make it more clearly. The first two sentences are about the congestion window size, and the last sentence is about the throughput=window/RTT. > I understand what is meant is that cubic is less biased than classic > TCP in terms of RTT but it is still somehow biased, but in the same > sense than TCP. If this is the case, the last sentence should be in > oposition to the two previous one maybe? > > In section 3.1, the formula for K is presented. I understnad this > results from including in Eq.1 that W(t=0) is equal to > W_max*beta_cubic. Maybe it would be worthwhile stating that explicitly. Thanks > > Later in section 3.1 it talks about W_cubic(t+RTT). How do you > calculate RTT? Is it the RTT of the last ACK? do you do some kind of > weighted average? We just use the average RTT estimated by TCP. > > Section 3.2. > I would like to understand when is the sender int he TCP-friendly region. > If we call t=0 the moment of the last congestion notification (i.e. > last loss) and we call t=K the moment when the cwnd is Wmax, then at > which point in time is the sender in the TCP-friendly region? I would > assume that in an interval centered in t=K, is that the case? > I mean, the way it is described i.e. first the TCP-friendly region and > then the concave region and then the convex region, made me thought > initially that they were sequential (i.e. at t=0 it starts in the > TCP-friendly region and then it moves to the concave region and then > to the convex) but I understand this is not the case? > Maybe stating explicitly when the different regions occur may > facilitate the reading? > Thanks, I will revise the draft to clearly explain it. Basically, TCP-friendly region is determined based on whether W_tcp(t)>W_cubic(t). > Section 3.3 and 3.4. > I understand that the function that governs the growth in both regions > is the same and that the difference is conceptual rather than in the > algorithm, correct? Maybe it would be clearer to state this explicitly > and maybe merge these two sections. > > Also, I think that having one section with a summary of the algorithm, > where all the congestion control algorithm is described toghether > would be beneficial. Maybe an appendix? Yes, Thanks, I will revise draft to clearly explain it. > > Section 4.3 reads: > > CUBIC is designed to remedy the poor performance of TCP in fast long- > distance networks. It is not designed for wireless networks. > > I find this very wierd. does this means that cubic doesnt work well if > my first link is a wifi or a cellular link? > This is probably/hopefully not what you mean. Maybe you are referring > to wireless mesh/ad-hoc networks? If so, I suggest making it more > explicit. > The traditional TCP does not work well in fast long-distance networks, and does not work well in wireless networks. CUBIC only addresses the first issue. Thanks again for your comments. Lisong > Anyway, good work, thanks for doing it. > > Regards, marcelo > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Sep 12 22:50:32 2016 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 76D4712B1F3 for ; Mon, 12 Sep 2016 22:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9T9MuBmI7DZ for ; Mon, 12 Sep 2016 22:50:25 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 A703F12B1F1 for ; Mon, 12 Sep 2016 22:50:24 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 1so180824555wmz.1 for ; Mon, 12 Sep 2016 22:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=CXOMA7qRiV3hoHhsmcXNkfmsYiR6lTs84NfvThgd1K4=; b=wMtv/cJX5Ohyo04/3gYFF9RIxVdcmmO0LhHrBHMfc/+61TF8hqDE5SpxN8pY8kVgid uegKpmHY5pfITHG8HHkuoWa/h5u/MPGZRF+SQ0pT5tsVMAWqrig27V3a4+Evk3a9CXE3 vVozASMEO+E96IuPAAf2eOc1hP+8N24OQbv5iHJG46KSm5uXpakKWIHGUQf9BLvDc1Lu tSeQ9zhxqaSQ3qh1xoEapjoRLb5h0+AVuKYs6YxzPQWiH/lFNWc9JJQqDCObfyJIyldf DQ36g3hrbqAu+L3rO209U4/AqN6Pp4h+0hNQ6Ip1TTvN6tjRtXy3cdZh7gf8Li8Ztd9A Umpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CXOMA7qRiV3hoHhsmcXNkfmsYiR6lTs84NfvThgd1K4=; b=gNm9AKuuZ1ZZpkkDXIIHhWuY8r9iQsyGoOk1HM3Bwq2TsuY3JV5KctNJd3dK04jFs4 Em8u0Dn3NsrAOAq8jgvVulf5wXs+PpmgK8ooUQgF9w9MN0e3rhj5uJnlgvEYcsKl2yJ6 4nxMqv1SOR+hajbHGR25Zb/kIzHiN6WDmUKN7HrPAbpcdeY4tHj27qJJe3aYSWhvX3T+ drSVXFnxYrz8LaXNqBZ4YzMHrUwVi0DR37/xBF/bYvw54vJ724Mnvmt2SiM1ScQ0vHuv QUE0LkETL50RlCxF4GzqkXXIkZ1BgBMVH6BCJfgbYxg33yaj1l+6othVJcqkvYWONjdK skLA== X-Gm-Message-State: AE9vXwO6/0GOBr0llPbrHOo80kx4d6ay6oWmDh1Qn3sBmS+k5IQOOK+eKbbqREJ+ci5RTFuC X-Received: by 10.195.2.40 with SMTP id bl8mr2646153wjd.191.1473745822409; Mon, 12 Sep 2016 22:50:22 -0700 (PDT) Received: from Macintosh-6.local (217.175.16.95.dynamic.jazztel.es. [95.16.175.217]) by smtp.gmail.com with ESMTPSA id z17sm21078214wmz.23.2016.09.12.22.50.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Sep 2016 22:50:21 -0700 (PDT) To: Lisong Xu References: From: marcelo bagnulo braun Message-ID: <3a178507-fbc4-2209-5b23-8d6685d8b044@it.uc3m.es> Date: Tue, 13 Sep 2016 07:50:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Questions and comments about draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 05:50:30 -0000 Thanks for the quick answer. some replies below... El 13/09/16 a las 03:22, Lisong Xu escribió: > Section 3.2. >> I would like to understand when is the sender int he TCP-friendly >> region. >> If we call t=0 the moment of the last congestion notification (i.e. >> last loss) and we call t=K the moment when the cwnd is Wmax, then at >> which point in time is the sender in the TCP-friendly region? I would >> assume that in an interval centered in t=K, is that the case? >> I mean, the way it is described i.e. first the TCP-friendly region >> and then the concave region and then the convex region, made me >> thought initially that they were sequential (i.e. at t=0 it starts in >> the TCP-friendly region and then it moves to the concave region and >> then to the convex) but I understand this is not the case? >> Maybe stating explicitly when the different regions occur may >> facilitate the reading? >> > Thanks, I will revise the draft to clearly explain it. Basically, > TCP-friendly region is determined based on whether W_tcp(t)>W_cubic(t). > I understood that much :-) But I would like to have a more intuitive perspective when does that happen. Maybe an example of a window evolution over time that goes through all the 3 phases would be enough? > >> >> Section 4.3 reads: >> >> CUBIC is designed to remedy the poor performance of TCP in fast long- >> distance networks. It is not designed for wireless networks. >> >> I find this very wierd. does this means that cubic doesnt work well >> if my first link is a wifi or a cellular link? >> This is probably/hopefully not what you mean. Maybe you are referring >> to wireless mesh/ad-hoc networks? If so, I suggest making it more >> explicit. >> > > The traditional TCP does not work well in fast long-distance networks, > and does not work well in wireless networks. This last one seems like a too broad statement to me. Maybe including a few references about what problems are you referring to and maybe point to some solutions that have been developped and deployed would make it clearer what you mean? Thanks again. Regards, marcelo > CUBIC only addresses the first issue. > > Thanks again for your comments. > Lisong > >> Anyway, good work, thanks for doing it. >> >> Regards, marcelo >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > From nobody Mon Sep 12 23:45:43 2016 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 E585F12B169 for ; Mon, 12 Sep 2016 23:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QRup4RchQe9J for ; Mon, 12 Sep 2016 23:45:40 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 59EEE12B118 for ; Mon, 12 Sep 2016 23:45:40 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id id6so58726548pad.3 for ; Mon, 12 Sep 2016 23:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wmPk9pek9vPYsS3zK6gVFDtSEiOBb8CrUPEFPJXmBKU=; b=Xs0Gn5IUsWGHvc6dBmnrF9jdv1n8KEM4GoS+3ldSRgOFfYiTfbYr/VXCEZE2gqE3CI VtDYIShBxgrcEJ1s9penWQoXp4TPeVGY26/kQLNs+awiQhPk2RZNtus2Mapglvib8Oy2 RV0qnyBM/T6c6H9KPqAQxclBNpG9rDRnOIQmlZ+Zv/EwBXTbZ+42R8ir0mjCJIJLN3I7 KLeCXbiPHbeedUSE0B9kM9k4VlhHOg/A8uLNhQi1Mw6wifNsrIoaAuxNweWkI6km+/2i 9/Y2wBlRT3QF9nSZt2u5JB252R781hUJBgpqKSu1fMJ48oh9E0IP8Cw/mhsRaK+T7daI AwmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wmPk9pek9vPYsS3zK6gVFDtSEiOBb8CrUPEFPJXmBKU=; b=JXF4VSrkquHCyGU471YUphCWGHCldwKIy6em+p4TybWwdfBolQ0l6WVPWPAMMeC9GD N8Hcj6ohxpok6iY46pIZgz9h+Qv2Dxm49HaWlJdoTJwxpTQ9TeXtVTC0wJpg2S6sjrx9 +yGWEihdXBo/4PgVSZyeQpFZMXT0mlzIV+VGa5zE+fj1BKWB2cnAtuY/F4pti9ggnaZx 0u3jwQXGBAo8E6h9ic4jT9vjBKCFWplkmMrHOyCsY+1LEZ+2N9JU0T6SGts1ld9OYLib Xz5ZcKIjxK+0+HI1Kb7w9pPXX3CA1ws4Fb07ORpjprRCN2ZYNzVSdRiGMy+x3+SVPcLH sZ9w== X-Gm-Message-State: AE9vXwNMi64Xo4kQwHtK9qPXevJvhFfTXq0xpC5cIlNfjapyz1SPY+wAtFS9LF0SbtUFU6IvLuEueV9IcTlrew== X-Received: by 10.66.222.202 with SMTP id qo10mr40803863pac.76.1473749139974; Mon, 12 Sep 2016 23:45:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.102.70 with HTTP; Mon, 12 Sep 2016 23:45:39 -0700 (PDT) In-Reply-To: References: <20160810183654.05358B80C3A@rfc-editor.org> <7ac89d58-fc3a-9e12-9d22-0602944f8677@isi.edu> <57B31020.60506@tik.ee.ethz.ch> From: Loganaden Velvindron Date: Tue, 13 Sep 2016 10:45:39 +0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] [Technical Errata Reported] RFC5961 (4772) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 06:45:42 -0000 On Fri, Aug 19, 2016 at 5:43 PM, Mirja K=C3=BChlewind wrote: >> sounds fine with me but do documents really get updated? > That depends on the working group. However the point here is, if the doc = gets updated, then this is still listed. > > Mirja > > I received feedback on the draft I posted. I can update it, based on the feedback I received so far, assuming there is interest to make the specs more clear. From nobody Tue Sep 13 00:13:32 2016 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 4F8DC12B186 for ; Tue, 13 Sep 2016 00:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 96Ih09Ju0K_K for ; Tue, 13 Sep 2016 00:13:29 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E7F12B059 for ; Tue, 13 Sep 2016 00:13:28 -0700 (PDT) Received: from [192.168.3.108] (214-173-16-190.fibertel.com.ar [190.16.173.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3399780D95; Tue, 13 Sep 2016 09:13:22 +0200 (CEST) To: "Mirja Kuehlewind (IETF)" , Yuchung Cheng , dab@weston.borman.com, Joe Touch References: <20160730072629.D628FB80333@rfc-editor.org> <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> <24a111cf-1e20-bc4e-2a9b-9eb0f3ee5821@isi.edu> <628F252F-2173-4812-BEC0-4EC4E97E789E@kuehlewind.net> From: Fernando Gont Message-ID: Date: Tue, 13 Sep 2016 03:49:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <628F252F-2173-4812-BEC0-4EC4E97E789E@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tcpm@ietf.org Extensions" , sanjeev.ranot.81@gmail.com Subject: Re: [tcpm] [Technical Errata Reported] RFC0793 (4753) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 07:13:31 -0000 On 09/12/2016 08:32 PM, Mirja Kuehlewind (IETF) wrote: > Hi all, > > thanks for your feedback. I also thought that the clarification is at least not necessary. I’ll wait a few more days, just to give others a chance to comment, and then reject if nobody shouts in the mean time. +1 to reject this errata. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Sep 13 08:05:28 2016 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 755F912B1D2 for ; Mon, 12 Sep 2016 21:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_1-sMXPwMUl for ; Mon, 12 Sep 2016 21:12:04 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202BD12B1A3 for ; Mon, 12 Sep 2016 21:12:04 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id v13so5304564uav.0 for ; Mon, 12 Sep 2016 21:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XEeyzZW05sOcm9vwPmbE3fmKUXTjfkNlOYE0ndlfMxA=; b=fvN+sTyi47dKCRBJyPUKhgKKn5kvNG3N5BzJyC32ZdlYGu8f5fs7x/SJj5PaJwE1bI VJ3iT9jIknA7clSGVL538M/E9PiUO/kqs30NmUQwV37rEtrRem6dc014MFz9oFjbQI37 7XpdaGxcAwdnOOxd6OX3mvKmK7kch2pxFK5A1tLqAgvTshQY3H/zsmswFJzjcjUnTBUG HWa78h0BY5EIW5xPq/Q9/gq5J/icxR2iiMc/sRZF57/Tvu4M7dQTSGPnyNvAG1LvUqxu eZm2T11ilFkyMxHy1hvwgJ6uSAtBBdUaiszuJbUZIj1Um5+j81lC288el+nGbRPudQMd Eqag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XEeyzZW05sOcm9vwPmbE3fmKUXTjfkNlOYE0ndlfMxA=; b=QA+Keo6t5j3IzIaXANx4jlySaZPYxa3ruqVx80hrAE/dj80tTXNQjklcFncowjtgOz /GBitFAWTUeXqdLoUGlm+8kZCCcWm6/Eve1q/B/tbT4mTmy3I54D9E+G2fgGAG0smGDv 4wMgpg93QN5ifHFvyqk0pvNmTcEn9/0xRNBnvtD8aMVvXLpNz9xHhukL4OXYxgWXXuy2 DJIy3rrWYC45/zFOJfABUUKAFboz9pf6uZHyCtOdmbhVzKE1EoMH+o+eMxhSrhpxqLYD 3jxgoagFnXChwtL9eRV1AjneESXYc2egp2GRurlXHCCKed1NlxlXPTs4TPrxzllwmCWZ /p9A== X-Gm-Message-State: AE9vXwPcbKLu+sG96VtfFSQ4ZV+iJw9IWpM7+Fnw5VRysGynL+0rhqX0RGHRbM9vt0zyGu+Np8YZol3x+LyPag== X-Received: by 10.176.3.174 with SMTP id 43mr1270911uau.110.1473739923171; Mon, 12 Sep 2016 21:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.199 with HTTP; Mon, 12 Sep 2016 21:12:02 -0700 (PDT) In-Reply-To: <628F252F-2173-4812-BEC0-4EC4E97E789E@kuehlewind.net> References: <20160730072629.D628FB80333@rfc-editor.org> <430A1E51-A608-4149-AF68-508D7E15488D@kuehlewind.net> <24a111cf-1e20-bc4e-2a9b-9eb0f3ee5821@isi.edu> <628F252F-2173-4812-BEC0-4EC4E97E789E@kuehlewind.net> From: Sanjeev Ranot Date: Tue, 13 Sep 2016 09:42:02 +0530 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=001a114fe3349cafeb053c5bd08f Archived-At: X-Mailman-Approved-At: Tue, 13 Sep 2016 08:05:27 -0700 Cc: dab@weston.borman.com, "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] [Technical Errata Reported] RFC0793 (4753) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 04:12:06 -0000 --001a114fe3349cafeb053c5bd08f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, wishing you on occasion of Eid al-Adha. I accept the team's decision and you are green flag from my side. The main thought when putting forward this errata was to mention typical practical use of TCP sockets so that the reader/ implementer may gain technical clarity. The multiplexing feature of a socket is realized most in client-server relationship of sockets in a TCP connection when almost always a server socket gets multiplexed. With significant duration past by since the RFC was introduced I think the readers/ implementers with legacy of various sources of information on sockets and their typical use-case may already have this clarification and hence render this explanation optional. Thanks for the team's valuable time and inputs. Thanks & Regards, Sanjeev Ranot On 13 September 2016 at 05:02, Mirja Kuehlewind (IETF) wrote: > Hi all, > > thanks for your feedback. I also thought that the clarification is at > least not necessary. I=E2=80=99ll wait a few more days, just to give othe= rs a > chance to comment, and then reject if nobody shouts in the mean time. > > Mirja > > > > Am 12.09.2016 um 20:22 schrieb Yuchung Cheng : > > > > i agree w/ Joe and David that this errata is not necessary. > > > > On Mon, Sep 12, 2016 at 11:17 AM, Joe Touch wrote: > > Hi, all, > > > > IMO this proposed errata confuses the concept of an OS socket (a > > mechanism used to attach network communications to a process) with a TC= P > > socket (which is an pair. > > > > A TCP connection is defined by two TCP sockets, one on each end (a > > socket pair). > > > > A single TCP socket (the one addr:port pair) can have multiple of eithe= r > > incoming or outgoing connections or both. > > > > A Unix socket doesn't correspond to a TCP socket pair until after > > accept() or connect() returns at best, and may have other semantic > > differences. > > > > As a result, this errata should be rejected. > > > > Joe > > > > > > On 9/12/2016 5:33 AM, Mirja Kuehlewind (IETF) wrote: > > > FYI. > > > > > >> Anfang der weitergeleiteten Nachricht: > > >> > > >> Von: RFC Errata System > > >> Betreff: [Technical Errata Reported] RFC0793 (4753) > > >> Datum: 30. Juli 2016 um 09:26:29 MESZ > > >> An: iesg@ietf.org > > >> Kopie: sanjeev.ranot.81@gmail.com, rfc-editor@rfc-editor.org > > >> > > >> The following errata report has been submitted for RFC0793, > > >> "Transmission Control Protocol". > > >> > > >> -------------------------------------- > > >> You may review the report below and at: > > >> http://www.rfc-editor.org/errata_search.php?rfc=3D793&eid=3D4753 > > >> > > >> -------------------------------------- > > >> Type: Technical > > >> Reported by: Sanjeev Ranot > > >> > > >> Section: 1.5 > > >> > > >> Original Text > > >> ------------- > > >> A pair of sockets uniquely identifies each connection. > > >> That is, a socket may be simultaneously used in multiple > > >> connections > > >> > > >> Corrected Text > > >> -------------- > > >> A pair of sockets uniquely identifies each connection. Sockets can b= e > > >> classified into client and server sockets. Typically a server socket > > >> may be simultaneously used in multiple connections. > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> Notes > > >> ----- > > >> TCP is connection oriented therefore when we say "sockets used in > multiple connections" it implies that the context is TCP. Considering > their use in TCP, though a single client socket can be implemented in a > way to multiplex it for connection with multiple server sockets and > exchange different SYN segments but then its same what a server process > listening for connections on server port does typically. > > >> > > >> I feel classification of sockets here is vital to facilitate > understand implicitly that in what use-case can > > >> a socket be typically multiplexed while still keeping generality of > the statement. > > >> > > >> Instructions: > > >> ------------- > > >> This erratum is currently posted as "Reported". If necessary, please > > >> use "Reply All" to discuss whether it should be verified or > > >> rejected. When a decision is reached, the verifying party (IESG) > > >> can log in to change the status and edit the report, if necessary. > > >> > > >> -------------------------------------- > > >> RFC0793 (no draft string recorded) > > >> -------------------------------------- > > >> Title : Transmission Control Protocol > > >> Publication Date : September 1981 > > >> Author(s) : J. Postel > > >> Category : INTERNET STANDARD > > >> Source : Legacy > > >> Area : Legacy > > >> Stream : IETF > > >> Verifying Party : IESG > > >> > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > --001a114fe3349cafeb053c5bd08f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,

wishing you on occasion of Eid al-Ad= ha.

I accept the team's decision and you are green fl= ag from my side.

The main thought when putting forward this errata = was to mention
typical practical use of TCP sockets so that the reader/= implementer
may gain technical clarity. The multiplexing feature of a = socket is
realized most in client-server relationship of sockets in a T= CP
connection when almost always a server socket gets multiplexed.
=
With significant duration past by since the RFC was introduced I think = the
readers/ implementers with legacy of various sources of information=
on sockets and their typical use-case may already have this
clarif= ication and hence render this explanation optional.

Thanks for the team's valuable time and inputs.
Thanks & Regards,
Sanjeev Ranot





On 13 September 2016 at 05:02, Mirja Kuehlewind (IETF) <ietf@kue= hlewind.net> wrote:
Hi all,

thanks for your feedback. I also thought that the clarification is at least= not necessary. I=E2=80=99ll wait a few more days, just to give others a ch= ance to comment, and then reject if nobody shouts in the mean time.

Mirja


> Am 12.09.2016 um 20:22 schrieb Yuchung Cheng <ycheng@google.com>:
>
> i agree w/ Joe and David that this errata is not necessary.
>
> On Mon, Sep 12, 2016 at 11:17 AM, Joe Touch <touch@isi.edu> wrote:
> Hi, all,
>
> IMO this proposed errata confuses the concept of an OS socket (a
> mechanism used to attach network communications to a process) with a T= CP
> socket (which is an <IP address:port> pair.
>
> A TCP connection is defined by two TCP sockets, one on each end (a
> socket pair).
>
> A single TCP socket (the one addr:port pair) can have multiple of eith= er
> incoming or outgoing connections or both.
>
> A Unix socket doesn't correspond to a TCP socket pair until after<= br> > accept() or connect() returns at best, and may have other semantic
> differences.
>
> As a result, this errata should be rejected.
>
> Joe
>
>
> On 9/12/2016 5:33 AM, Mirja Kuehlewind (IETF) wrote:
> > FYI.
> >
> >> Anfang der weitergeleiteten Nachricht:
> >>
> >> Von: RFC Errata System <rfc-editor@rfc-editor.org>
> >> Betreff: [Technical Errata Reported] RFC0793 (4753)
> >> Datum: 30. Juli 2016 um 09:26:29 MESZ
> >> An: iesg@ietf.org
> >> Kopie: sanjeev.= ranot.81@gmail.com, rfc-ed= itor@rfc-editor.org
> >>
> >> The following errata report has been submitted for RFC0793, > >> "Transmission Control Protocol".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >> http://www.rfc-edi= tor.org/errata_search.php?rfc=3D793&eid=3D4753
> >>
> >> --------------------------------------
> >> Type: Technical
> >> Reported by: Sanjeev Ranot <sanjeev.ranot.81@gmail.com>
> >>
> >> Section: 1.5
> >>
> >> Original Text
> >> -------------
> >> A pair of sockets uniquely identifies each connection.
> >> That is, a socket may be simultaneously used in multiple
> >> connections
> >>
> >> Corrected Text
> >> --------------
> >> A pair of sockets uniquely identifies each connection. Socket= s can be
> >> classified into client and server sockets. Typically a server= socket
> >> may be simultaneously used in multiple connections.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Notes
> >> -----
> >> TCP is connection oriented therefore when we say "socket= s used in multiple connections" it implies that the context is TCP.=C2= =A0 Considering their use in TCP,=C2=A0 though a single client socket can b= e implemented in a way to multiplex it for connection with multiple server = sockets and exchange different SYN segments but then its=C2=A0 same what a = server process listening for connections on server port does typically.
> >>
> >> I feel classification of sockets here is vital to facilitate = understand implicitly that in what use-case can
> >> a socket be typically multiplexed while still keeping general= ity of the statement.
> >>
> >> Instructions:
> >> -------------
> >> This erratum is currently posted as "Reported". If = necessary, please
> >> use "Reply All" to discuss whether it should be ver= ified or
> >> rejected. When a decision is reached, the verifying party (IE= SG)
> >> can log in to change the status and edit the report, if neces= sary.
> >>
> >> --------------------------------------
> >> RFC0793 (no draft string recorded)
> >> --------------------------------------
> >> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Transmission Control Protocol
> >> Publication Date=C2=A0 =C2=A0 : September 1981
> >> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: J. Postel=
> >> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : INTERNET = STANDARD
> >> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Lega= cy
> >> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := Legacy
> >> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF=
> >> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> >>
> > _______________________________________________<= br> > > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm<= /a>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm >
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

--001a114fe3349cafeb053c5bd08f-- From nobody Tue Sep 13 12:02:39 2016 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 10A7312B01E; Tue, 13 Sep 2016 12:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelab.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBuV281E6UXz; Tue, 13 Sep 2016 12:02:35 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0109.outbound.protection.outlook.com [104.47.38.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412FC12B4E0; Tue, 13 Sep 2016 12:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelab.onmicrosoft.com; s=selector1-cablelabs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FrTRPe5EaKxAjUM1cnM8q1KtAtYvMcXjWBGC8MnTs9k=; b=e7dzUGMh67Tp6CS2slqVQY83EG+iDfQoTKyQh0gxegZtPbg05lI4RGrx1bHWBqUpWpaT0sD2/GctThdxm6/3/kQVNy7QJcW2KVnlsYBvmsxXSSdFLV3hpvSocvLqNUcMRv+pYi5GkIHiJfgr1CmqMXzt93zYPitb9sLrWEd05rY= Received: from MWHPR06MB2352.namprd06.prod.outlook.com (10.168.247.14) by MWHPR06MB2352.namprd06.prod.outlook.com (10.168.247.14) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Tue, 13 Sep 2016 19:02:27 +0000 Received: from MWHPR06MB2352.namprd06.prod.outlook.com ([10.168.247.14]) by MWHPR06MB2352.namprd06.prod.outlook.com ([10.168.247.14]) with mapi id 15.01.0619.010; Tue, 13 Sep 2016 19:02:27 +0000 From: Greg White To: tcpm IETF list , "draft-ietf-tcpm-cubic@ietf.org" Thread-Topic: some editorial comments on draft-ietf-tcpm-cubic-02 Thread-Index: AQHSDfFe4fWT8tgS0E+QrSPYDeOUMQ== Date: Tue, 13 Sep 2016 19:02:26 +0000 Message-ID: <95CE3E8D-EAA7-4BD5-98C9-81204D49C29F@cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.19.0.160817 authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.160.73.64] x-ms-office365-filtering-correlation-id: 4390bc1e-e98f-4d9e-6897-08d3dc088100 x-microsoft-exchange-diagnostics: 1; MWHPR06MB2352; 6:XgyBL+tf5vmIBBEbQgPLrzo+Tepn6rsn3w4R+1HjtuA3z/gN0tDofE3O40P3b5YIfXY2Kn51mFLPN3sXs4sOtXhtqI0XOImXNnwawNWafAiyvxDq6vGrXrZdaRhH4yDZlGhNdZmS78D6xwMoUb5PSmgA3ZYbjrIiv7wSVHiXxbM0ClxmjOLtU6lfLMo6PlyIOAP+71fIqk/JsJ0Im/7UfT7lzbZky04EdRbgnCGYUDfBUAu9qrjzB0M0Mruj7Zp5MJUX1QMSYfnTdlRPJQPrKgrhYyC5VmJLR8yG0ID2CUPM25QvSfUg+zqacmr43J4I; 5:f1CMVwRkyCHkm0TrRDscXwDdCZLjidfYwDcwN8IVKR+xa4RZqvZn4ui4pImEFvqNMihAH0vunLAV+KVUWZM2PJX587nST7uH3yC50BFz8ilCmonXQT8VdBa8Oq5EgPyNKBUC1FboxvUPluvBouvc9Q==; 24:51CjaLb3QPSuNgJSfvBogzMAn0duiLG8MFd6Yxn66fpBJyrvSgLe/IaGChd/hdA6rHIC44avd8Vw7dSDNO/tKc0/PG5+Fs2hjiLXkECu/eE=; 7:Zo2KwmckOzw8rGoPcOAqn7EsJeBj06GjiiyZmHXB3uN4ycsP0m/P+ZQSV3EeUxN7/bUF4dJLsHRDY21Tr095i341JeHhC0SX4yV+pKhs1xba+n7PSbd2C+J7RD5vqFlOu3FFp+flnyHbve2Oa1BxZdOZPiuZscdS7s1zS+oo/ujQ9vNFKQNHktKRfrz7H+OJnOdZZqOMT9r7fF7GmjKRsPDAr06gW8MKzbq1F9KVfUYkiTVDjZ37v5qiaGW6YM+1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR06MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(176510541525296)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6043046)(6042046); SRVR:MWHPR06MB2352; BCL:0; PCL:0; RULEID:; SRVR:MWHPR06MB2352; x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(82746002)(2906002)(83506001)(7846002)(5001770100001)(107886002)(122556002)(83716003)(19580395003)(5002640100001)(11100500001)(77096005)(87936001)(36756003)(97736004)(66066001)(3660700001)(5660300001)(450100001)(230783001)(19300405004)(8936002)(3280700002)(7736002)(4001350100001)(15975445007)(586003)(101416001)(54356999)(102836003)(50986999)(105586002)(33656002)(16236675004)(92566002)(3846002)(68736007)(10400500002)(8676002)(19625215002)(106356001)(106116001)(99286002)(6116002)(2900100001)(2501003)(81166006)(229853001)(81156014)(189998001)(86362001)(104396002)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR06MB2352; H:MWHPR06MB2352.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_95CE3E8DEAA74BD598C981204D49C29Fcablelabscom_" MIME-Version: 1.0 X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2016 19:02:26.9086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2352 Archived-At: Subject: [tcpm] some editorial comments on draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 19:02:38 -0000 --_000_95CE3E8DEAA74BD598C981204D49C29Fcablelabscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlaW5nIE1hcmNlbG/igJlzIGNvbW1lbnRzIHByb21wdGVkIG1lIHRvIHJlYWQgdGhlIGRyYWZ0 IGFzIHdlbGwuICBJIGhhdmUganVzdCBhIGZldyBjb21tZW50cywgYW5kIGFsc28gSSBmb3VuZCBh IGNvdXBsZSBvZiB0eXBvcy4NCg0KDQpDb21tZW50IDE6ICBTZWN0aW9uIDQuOCBjb250YWlucyBh IGxvd2VyIGNhc2Ug4oCcc2hvdWxkIG5vdOKAnS4gIFRoaXMgc2VlbXMgbGlrZSBpdCBzaG91bGQg YmUgYSDigJxTSE9VTEQgTk9U4oCdLg0KDQogICBJbiBjYXNlcyBvZiBpZGxlIHBlcmlvZHMsIHQg aW4gRXEuIDEgU0hPVUxEIE5PVCBpbmNsdWRlIHRoZQ0KICAgaWRsZSB0aW1lOyBvdGhlcndpc2Us IFdfY3ViaWModCkgbWlnaHQgYmUgdmVyeSBoaWdoIGFmdGVyIHJlc3RhcnRpbmcNCiAgIGZyb20g YSBsb25nIGlkbGUgdGltZS4NCg0KDQoNCkNvbW1lbnQgMjogIFNlY3Rpb24gNC4zIHJlYWRzOg0K DQo0LjMuICBEaWZmaWN1bHQgRW52aXJvbm1lbnRzDQoNCiAgIENVQklDIGlzIGRlc2lnbmVkIHRv IHJlbWVkeSB0aGUgcG9vciBwZXJmb3JtYW5jZSBvZiBUQ1AgaW4gZmFzdCBsb25nLQ0KICAgZGlz dGFuY2UgbmV0d29ya3MuICBJdCBpcyBub3QgZGVzaWduZWQgZm9yIHdpcmVsZXNzIG5ldHdvcmtz Lg0KDQpTaW5jZSBhIGxhcmdlIHByb3BvcnRpb24gb2YgVENQIGZsb3dzIHRvZGF5IGNyb3NzIGEg d2lyZWxlc3MgbGluayAoV2lGaSBvciBMVEUpLCB0aGlzIHN0YXRlbWVudCBhbmQgdGhlIGhlYWRp bmcgc2VlbSBraW5kIG9mIGFuYWNocm9uaXN0aWMuICAgUGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0 ZXIgdG8gZGVzY3JpYmUgd2hhdCBzb21lIG9mIHRoZSBjb25jZXJucyBtaWdodCBiZSB3aXRoIG9w ZXJhdGlvbiBhY3Jvc3MgdG9kYXnigJlzIG5ldHdvcmtzIHRoYXQgYXJlIGxpa2VseSB0byBjb250 YWluIHdpcmVsZXNzIGxpbmtzIChpZiB0aGVyZSBhcmUgYW55KSwgb3Igc3RhdGUgd2hhdCBwcm9w ZXJ0aWVzIG9mIGEgd2lyZWxlc3MgbmV0d29yayB3b3VsZCBjYXVzZSBwcm9ibGVtcyBmb3IgQ1VC SUMuDQoNCg0KDQpDb21tZW50IDM6IFNlY3Rpb24gNC41IHN0YXRlczoNCg0KICAgSW4gY2FzZSB0 aGF0IHRoZXJlIGlzIGNvbmdlc3Rpb24gY29sbGFwc2UsIENVQklDIGJlaGF2ZXMgbGlrZWx5DQog ICBzdGFuZGFyZCBUQ1AgLi4uDQoNCkkgYmVsaWV2ZSB0aGF0IHRoZSB3aG9sZSBwb2ludCBvZiBj b25nZXN0aW9uIGF2b2lkYW5jZSBhbGdvcml0aG1zIHN1Y2ggYXMgQ1VCSUMgaXMgdG8gcHJldmVu dCBjb25nZXN0aW9uIGNvbGxhcHNlLiAgKEFsc28gbm90ZSB0aGUgdHlwbyDigJxsaWtlbHnigJ0g aW4gdGhhdCBzZW50ZW5jZS4pICBNYXliZSB0aGlzIHdvdWxkIGJlIGJldHRlciB3cml0dGVuIGFz Og0KDQogICBXaXRoIHJlZ2FyZCB0byB0aGUgcG90ZW50aWFsIG9mIGNhdXNpbmcgY29uZ2VzdGlv biBjb2xsYXBzZSwNCiAgIENVQklDIGJlaGF2ZXMgbGlrZSBzdGFuZGFyZCBUQ1AgLi4uDQoNCg0K DQoNClR5cG86DQoNCg0KDQpTZWN0aW9uIDMuMiwgZmlyc3Qgc2VudGVuY2UgcmVhZHM6DQoNCg0K DQogIFdoZW4gcmVjZWl2aW5nIGFuIEFDSyBpbiBjb25nZXN0aW9uIGF2b2lkYW5jZSwgd2UgZmly c3QgY2hlY2sgd2hldGhlcg0KDQogICB0aGUgcHJvdG9jb2wgaXMgaW4gdGhlIFRDUCByZWdpb24g b3Igbm90Lg0KDQoNCg0KSSBiZWxpZXZlIGl0IHNob3VsZCBiZToNCg0KDQoNCiAgIFdoZW4gcmVj ZWl2aW5nIGFuIEFDSyBpbiBjb25nZXN0aW9uIGF2b2lkYW5jZSwgd2UgZmlyc3QgY2hlY2sgd2hl dGhlcg0KDQogICB0aGUgcHJvdG9jb2wgaXMgaW4gdGhlIFRDUCAqKmZyaWVuZGx5KiogcmVnaW9u IG9yIG5vdC4NCg0KDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpHcmVnDQoNCg0KDQo= --_000_95CE3E8DEAA74BD598C981204D49C29Fcablelabscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiUFQgTW9ubyI7DQoJcGFub3NlLTE6MiA2IDUgOSAyIDIgNSAyIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCnNwYW4ubXNvSW5zDQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNl ZWluZyBNYXJjZWxv4oCZcyBjb21tZW50cyBwcm9tcHRlZCBtZSB0byByZWFkIHRoZSBkcmFmdCBh cyB3ZWxsLiZuYnNwOyBJIGhhdmUganVzdCBhIGZldyBjb21tZW50cywgYW5kIGFsc28gSSBmb3Vu ZCBhIGNvdXBsZSBvZiB0eXBvcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db21tZW50IDE6Jm5ic3A7IFNlY3Rpb24g NC44IGNvbnRhaW5zIGEgbG93ZXIgY2FzZSDigJxzaG91bGQgbm904oCdLiZuYnNwOyBUaGlzIHNl ZW1zIGxpa2UgaXQgc2hvdWxkIGJlIGEg4oCcU0hPVUxEIE5PVOKAnS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6IzFBMUExQSI+Jm5ic3A7Jm5ic3A7 IEluIGNhc2VzIG9mIGlkbGUgcGVyaW9kcywgdCBpbiBFcS4gMSBTSE9VTEQgTk9UIGluY2x1ZGUg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6IzFBMUExQSI+Jm5ic3A7Jm5ic3A7IGlkbGUg dGltZTsgb3RoZXJ3aXNlLCBXX2N1YmljKHQpIG1pZ2h0IGJlIHZlcnkgaGlnaCBhZnRlciByZXN0 YXJ0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztj b2xvcjojMUExQTFBIj4mbmJzcDsmbmJzcDsgZnJvbSBhIGxvbmcgaWRsZSB0aW1lLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkNvbW1lbnQgMjombmJzcDsgU2VjdGlvbiA0LjMgcmVhZHM6DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6IzFBMUExQSI+NC4zLiZu YnNwOyBEaWZmaWN1bHQgRW52aXJvbm1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6IzFB MUExQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6IzFBMUExQSI+Jm5ic3A7Jm5i c3A7IENVQklDIGlzIGRlc2lnbmVkIHRvIHJlbWVkeSB0aGUgcG9vciBwZXJmb3JtYW5jZSBvZiBU Q1AgaW4gZmFzdCBsb25nLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOiMxQTFBMUEiPiZuYnNw OyZuYnNwOyBkaXN0YW5jZSBuZXR3b3Jrcy4mbmJzcDsgSXQgaXMgbm90IGRlc2lnbmVkIGZvciB3 aXJlbGVzcyBuZXR3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlNpbmNlIGEgbGFyZ2UgcHJvcG9ydGlvbiBvZiBUQ1AgZmxvd3MgdG9kYXkgY3Jvc3MgYSB3 aXJlbGVzcyBsaW5rIChXaUZpIG9yIExURSksIHRoaXMgc3RhdGVtZW50IGFuZCB0aGUgaGVhZGlu ZyBzZWVtIGtpbmQgb2YgYW5hY2hyb25pc3RpYy4mbmJzcDsgJm5ic3A7UGVyaGFwcyBpdCB3b3Vs ZCBiZSBiZXR0ZXIgdG8gZGVzY3JpYmUgd2hhdCBzb21lIG9mIHRoZSBjb25jZXJucw0KIG1pZ2h0 IGJlIHdpdGggb3BlcmF0aW9uIGFjcm9zcyB0b2RheeKAmXMgbmV0d29ya3MgdGhhdCBhcmUgbGlr ZWx5IHRvIGNvbnRhaW4gd2lyZWxlc3MgbGlua3MgKGlmIHRoZXJlIGFyZSBhbnkpLCBvciBzdGF0 ZSB3aGF0IHByb3BlcnRpZXMgb2YgYSB3aXJlbGVzcyBuZXR3b3JrIHdvdWxkIGNhdXNlIHByb2Js ZW1zIGZvciBDVUJJQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q29tbWVu dCAzOiBTZWN0aW9uIDQuNSBzdGF0ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtQ VCBNb25vJnF1b3Q7O2NvbG9yOiMxQTFBMUEiPiZuYnNwOyZuYnNwOyBJbiBjYXNlIHRoYXQgdGhl cmUgaXMgY29uZ2VzdGlvbiBjb2xsYXBzZSwgQ1VCSUMgYmVoYXZlcyBsaWtlbHk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOiMxQTFBMUEiPiZu YnNwOyZuYnNwOyBzdGFuZGFyZCBUQ1AgLi4uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgYmVs aWV2ZSB0aGF0IHRoZSB3aG9sZSBwb2ludCBvZiBjb25nZXN0aW9uIGF2b2lkYW5jZSBhbGdvcml0 aG1zIHN1Y2ggYXMgQ1VCSUMgaXMgdG8gcHJldmVudCBjb25nZXN0aW9uIGNvbGxhcHNlLiZuYnNw OyAoQWxzbyBub3RlIHRoZSB0eXBvIOKAnGxpa2VseeKAnSBpbiB0aGF0IHNlbnRlbmNlLikmbmJz cDsgTWF5YmUgdGhpcyB3b3VsZCBiZSBiZXR0ZXIgd3JpdHRlbiBhczombmJzcDsNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtQVCBN b25vJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgV2l0aCByZWdhcmQgdG8gdGhlIHBvdGVudGlhbCBvZiBj YXVzaW5nIGNvbmdlc3Rpb24gY29sbGFwc2UsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtQVCBNb25vJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDtDVUJJQyBiZWhhdmVzIGxp a2Ugc3RhbmRhcmQgVENQIC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlR5cG86PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlNlY3Rpb24gMy4yLCBmaXJzdCBzZW50ZW5jZSByZWFkczombmJzcDsgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDsiPiZuYnNwOyZuYnNwO1doZW4gcmVjZWl2aW5nIGFu IEFDSyBpbiBjb25nZXN0aW9uIGF2b2lkYW5jZSwgd2UgZmlyc3QgY2hlY2sgd2hldGhlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDsiPiZuYnNwOyZu YnNwOyB0aGUgcHJvdG9jb2wgaXMgaW4gdGhlIFRDUCByZWdpb24gb3Igbm90LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBiZWxpZXZlIGl0IHNob3VsZCBiZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gcmVjZWl2aW5n IGFuIEFDSyBpbiBjb25nZXN0aW9uIGF2b2lkYW5jZSwgd2UgZmlyc3QgY2hlY2sgd2hldGhlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDsiPiZuYnNw OyZuYnNwOyB0aGUgcHJvdG9jb2wgaXMgaW4gdGhlIFRDUCAqKjxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+ZnJpZW5kbHk8L3NwYW4+KiogcmVnaW9u IG9yIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5HcmVnPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_95CE3E8DEAA74BD598C981204D49C29Fcablelabscom_-- From nobody Tue Sep 13 14:40:30 2016 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 E777612B0D9 for ; Tue, 13 Sep 2016 14:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 wx8fGnayYGBq for ; Tue, 13 Sep 2016 14:40:26 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 8BF6312B0B9 for ; Tue, 13 Sep 2016 14:39:59 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id o3so16779518ita.1 for ; Tue, 13 Sep 2016 14:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GK6Wbcn7r1FFpG3dcwu2AdXplqxu8ziX2zfBJFU6yD4=; b=haSVTbDTtWIn0bvZgvG7V/DNv/Ptprv+DdwEId2RQ62NcETufIoQD7Qk6Q0lErZSGo KL2myD7mhBpOaH2eYUO3o+b9cNO/otfdoqvmu6bTkjcnZjLl4qYSRHOwOwxf0zGrTBSt K0fuolq2jOijZ9CV4IWtz04z6m/VLMNjjApxFJthyfuTDG6MvLjqanCEYzGo/nf8qMIf 9ngbnVjOer4lUuO+qDSkOAzevxwb8SiKCCe1aiCE/CmvrjfDHmTAmRSlSgHjojDXEMuN mfP1OfxFoPq7K7UgIQK3LYK3N2z829RRW2C0IcY6sPyJnwFPhKiU/w16lVALR/Rq0dWK zetQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GK6Wbcn7r1FFpG3dcwu2AdXplqxu8ziX2zfBJFU6yD4=; b=gQlLAVkWbiWspujOM7ozJ9vnekqbGfexyjBhWnHDWtKfV/za1s53vACjiQjHb02ZCU xZaFTMsUM3rmjTdXp093A4qSIisPvUgKsN9oH1jqj2mEOuIXwKqyFYilLJThuRAsu26d 4991wTfoJIB8sgaDpSmBI7DlQw2QshVx9NL2p8y21vw0Hwmoke0RXZoY4Zp3xVDlym20 WAY6c2eZbbn5AFQmZFtW20D4764kpVwW18OoOvlHAR9575LSi4MK/T9IGrWcJoVwt7Hb m8y585uTaTDHvTXcJi9Iqb60bC56IomT8fRJq7RxRpQHijuoo3Qj5OrxERUTqolG1OOy t0Hg== X-Gm-Message-State: AE9vXwO2cYbWPOLziO+HeAAott270SgkRv/DV9V3UVN2vIT43DwsVv107EadQaz7TOCRTOISKA/pkbfkH30DZolD X-Received: by 10.107.18.214 with SMTP id 83mr5454229ios.37.1473802798499; Tue, 13 Sep 2016 14:39:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.135 with HTTP; Tue, 13 Sep 2016 14:39:18 -0700 (PDT) In-Reply-To: <95CE3E8D-EAA7-4BD5-98C9-81204D49C29F@cablelabs.com> References: <95CE3E8D-EAA7-4BD5-98C9-81204D49C29F@cablelabs.com> From: Yuchung Cheng Date: Tue, 13 Sep 2016 14:39:18 -0700 Message-ID: To: Greg White Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tcpm IETF list , "draft-ietf-tcpm-cubic@ietf.org" Subject: Re: [tcpm] some editorial comments on draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 21:40:29 -0000 On Tue, Sep 13, 2016 at 12:02 PM, Greg White wrote: > > Seeing Marcelo=E2=80=99s comments prompted me to read the draft as well. = I have just a few comments, and also I found a couple of typos. > > > > > > Comment 1: Section 4.8 contains a lower case =E2=80=9Cshould not=E2=80= =9D. This seems like it should be a =E2=80=9CSHOULD NOT=E2=80=9D. > > > > In cases of idle periods, t in Eq. 1 SHOULD NOT include the > > idle time; otherwise, W_cubic(t) might be very high after restarting > > from a long idle time. why SHOULD vs MUST? I can't think of any corner case that we'd want to include the idle time. > > > > > > > > Comment 2: Section 4.3 reads: > > > > 4.3. Difficult Environments > > > > CUBIC is designed to remedy the poor performance of TCP in fast long- > > distance networks. It is not designed for wireless networks. > > > > Since a large proportion of TCP flows today cross a wireless link (WiFi o= r LTE), this statement and the heading seem kind of anachronistic. Perhap= s it would be better to describe what some of the concerns might be with op= eration across today=E2=80=99s networks that are likely to contain wireless= links (if there are any), or state what properties of a wireless network w= ould cause problems for CUBIC. > > > > > > > > Comment 3: Section 4.5 states: > > > > In case that there is congestion collapse, CUBIC behaves likely > > standard TCP ... > > > > I believe that the whole point of congestion avoidance algorithms such as= CUBIC is to prevent congestion collapse. (Also note the typo =E2=80=9Clik= ely=E2=80=9D in that sentence.) Maybe this would be better written as: > > > > With regard to the potential of causing congestion collapse, > > CUBIC behaves like standard TCP ... > > > > > > > > Typo: > > > > Section 3.2, first sentence reads: > > > > When receiving an ACK in congestion avoidance, we first check whether > > the protocol is in the TCP region or not. > > > > I believe it should be: > > > > When receiving an ACK in congestion avoidance, we first check whether > > the protocol is in the TCP **friendly** region or not. > > > > > > > > Best Regards, > > Greg > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Sep 13 19:24:32 2016 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 8533212B47E; Tue, 13 Sep 2016 19:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfXpzqA_YFU9; Tue, 13 Sep 2016 19:24:29 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0020.outbound.protection.outlook.com [216.32.180.20]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E70412B176; Tue, 13 Sep 2016 19:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wSPxvXA7fftDabCc1k8SVLlLDxb8qT67FIgOy89jMXc=; b=fD44catCWeBH/a8zqgvqV8AUMwNURopbTNLLIEKnVOiaGFzhYOxNuKQUxp4/nobbeH4B0X5I7excSf5h3KSh5uCKAsQq6eqVq9U/DVWNtIzJ9NrD19ap0gTHnaSVPXU8INUZmmJirRmyaepm8BELvqjS70VV19+lqN+Ld27r+hs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.164] (97.98.140.59) by DM5PR08MB2522.namprd08.prod.outlook.com (10.173.220.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Wed, 14 Sep 2016 02:24:25 +0000 To: Greg White , tcpm IETF list , "draft-ietf-tcpm-cubic@ietf.org" References: <95CE3E8D-EAA7-4BD5-98C9-81204D49C29F@cablelabs.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <030f831b-5f2a-dc6b-8fe9-04a79d704041@unl.edu> Date: Tue, 13 Sep 2016 21:24:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <95CE3E8D-EAA7-4BD5-98C9-81204D49C29F@cablelabs.com> Content-Type: multipart/alternative; boundary="------------85E29D2B3048AF234994B523" X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BN6PR13CA0048.namprd13.prod.outlook.com (10.171.172.34) To DM5PR08MB2522.namprd08.prod.outlook.com (10.173.220.136) X-MS-Office365-Filtering-Correlation-Id: 4d862d1a-50e5-4f75-a1d3-08d3dc463fb5 X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 2:vi79TnczLQTPcjKCLFuVKhNnnthC4Trbc9WhbQl0KI+yxy9miVn1cx81xA6bsTkyulIP2s+plY1+OF8C6Qfh5uUBeVj6hhVTtV/Idplg6uU+bbCiiNHHkBzkdi/q3yb/rTU/bbyQmPDggJI/Z3Mb1C5tkK6O+8S9bF3i9XWR6eIE83Vf5VrUoSrP2byoNz2B; 3:d5y98fO5ErbYTHG6+2bOBH8UcZ5F0eYFVqd6uJOzOwGPvVlactmj3l7uF1l1zsr5tmZQol4TtOjPgoWgAuiTXuwLp1X3FPTlYZzRor0qyFWxy1obH+xwc0NMTsIZn6uT; 25:k3iGyHZM9yNt9qNlkM6YgYFne8m4MVlPnW0AmJV5eJ8K9eOdnbvN1fw/Pc/7/lMpsUNISINJ/FnadQrJxDtPC3tB40ueFXq1a3+UD6OzkuerCt4fWM1mfxYDXpZYAUcmKPOdLGnn9yWfWsJB1URivXFwQgz+ZhHqXgdOb1H1RYTOS+qhzipcxksfRmHBMkWmIPxzoWJ3uIXG0eZza4odIuRItie+GuLMQtdG/CP1SwnIi9tZCd9vGc2mSiPlcIp/d7dixBqq5LkF54wUQ0YGB9cX0xQtNLcsGoeuHqY6BijSU3a531/riXG1mp0GxWSwvsGkpS7+BtYrKlX8NEnuUf9XQZS8utv3d1zbskgukPCDgEjtx4UdHQvgeK9Ps6PFoq8fD0PPXnx0TLNkbY3m9zEZtjQ/PMb2lcsevJS8k94= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR08MB2522; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 31:4jqdK9rOogPeWCB4VXL7hNFyvS7xoPA+je0elaXzPouyEQdEdlOx6Nk/EZ23w98h4B9E0mLPn+jwQspYuR/QexqTNMbdK9V1pe0pwR8OTW0C6vFUv60fE6ZpAYcLZPNRS8viHlBVThVRaKZnrjJTcfrejtgjo31oOkLcZI7kusG6+3v6GIlhbV4AP0n0orCyjN4QwTPTjWl+wD0yT8sbpH9ssu749ikxPF2umtZf9Eg=; 20:df3D+VXxN4gBBtfsdxWUsUX22ccqKaaQRDksLH235boZyw9iWbJVrZJvwV3ntYyJkMLQdTvCMa55GDqar8x/3nj4amisVXQc8Ycn1aPfMoqGQfVuWx3FTqEvlsT7SxNmbyT87Y316A2JBFOaafb25N7gFlTRwUmBzf0jGV7vRlMjnKo0Hx+EKH56v0j1rKoAeL/F/hEmTF5H+tlPey1c7h3ElqGxmfaJN/0w2upBEiMGvMHUrvPy7uIVYZIvG5nA/8n8Y8ErEGRtLxoNEysWt0QQlBGTWbpuOTL5W0WPYoyBefQNFscXVjE9SDjiiGQ7PX/a9h5s68Bpyel2B2mmCMpWsYPGalKan0VoQsGH20HmsnCJxzhL8rAO2LRmR+0pXLQYfq0wsVRBwVKuDpPQa7Ii95XXLVXr9zcV0FbA8+Jbk8Mwj6E3hzz8I/OdjUurgM0znVbZ27NqoKTN4SCSr8yxofQaZZxo3MIoVpNXYnL/lN7e0p7DZ0Kotw7TtW9v X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(176510541525296); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM5PR08MB2522; BCL:0; PCL:0; RULEID:; SRVR:DM5PR08MB2522; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 4:R1V+FNUe49lK6FkFtwh/V66odsWpO17OFXhWu9eu3xGHsuAbdNrw8hLtmEfFTO3Ii1lSbmaCTyQxcq2SZ4aCL2SQBckK2CcW7AsELOqK4LVmgsOdKIYUu3cD6hT+saJnMjNbpYS+xXPDvWhv5a8qumHSuGq4H/WpNQZ5dFJfbdaahyLFCUmZYP6NwAFQW/kuiNgf7rAURKnvmnDKXy1jesTk8dAgng6eISuCn6Sqa/6ikmCNNGaaEwKQnWd5GrPZaKxOaLf45LzbI65hrswYRCD5+mrGjLYszPMDtcZU83Re+56YzFfI/STM9jp1DUNoxWdo8mSGYMAzIbiLmCDJKz87hAJcokeZ0zRTx2SDMHuqAMqa8g3mZ2MRkCTMp/2jImw886Z9yxKP4gsOQmjAoCLBC4PkKA53mkEHI8LoIRGaMJXyHEztHbDJQZf63Ma1 X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(189002)(377454003)(24454002)(199003)(4001350100001)(106356001)(19625215002)(2906002)(84326002)(19617315012)(77096005)(7906003)(66066001)(15975445007)(65806001)(31696002)(105586002)(81166006)(86362001)(81156014)(65956001)(75432002)(33646002)(2950100001)(68736007)(16236675004)(92566002)(88552002)(42186005)(31686004)(512944002)(7846002)(5660300001)(97736004)(101416001)(8676002)(76176999)(5001770100001)(107886002)(64126003)(7736002)(50986999)(117156001)(83506001)(230783001)(54356999)(89122001)(189998001)(2501003)(586003)(19580395003)(19580405001)(6116002)(36756003)(90282001)(3846002)(65826007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB2522; H:[192.168.0.164]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR08MB2522; 23:WNODtCfya+/TEVPQHpo+n66I9KF+HNyaEUQaouNv6?= =?us-ascii?Q?QOqv5CY2+YOhnYrJMdVNQkFhYVxnVd0yoRe3TiwEYWESLCYjBqsx7th7Zv9o?= =?us-ascii?Q?5hZ0/gjioU0Vatvpz6UzgxGNGMGVKEAXTAVEQUN6X6vO/J3bwbc18qhLTBAZ?= =?us-ascii?Q?BMQlMaycQHZltQGJNcrSsCMSUDJrh/3QLdrMJQ74ezJ1fqSDQH+m6LO3LV9W?= =?us-ascii?Q?d5X7XGm9DEnH+KeXm5Z4nU4wQ/zcOe1X5c1UcTLZ3rtRMAuHPcQnONLk6Zsu?= =?us-ascii?Q?bVtoan70sNp336H2g2Wq13FSRlwUyIIWoVe/opbbOwN8uHl+WFDyRpUcwEjs?= =?us-ascii?Q?hih37r6kfiIL1AhU/Vf71VW7lnzS3zYNchQ8g9TOz74VXuIWamySHMLuM4H8?= =?us-ascii?Q?WXvH2XLAo57J5C7Rsa0G45f2cwpucbXTWHm18rjr4+E/Ojz2Nrb/eS+sz26I?= =?us-ascii?Q?KxyoaAM/0TBwcUTler2MVMfEQWkbzHvmT2H/ZhUqAzz/ft2Ezpypmt9ecIyi?= =?us-ascii?Q?pN4oDTCR4WYA1GU8dRNsyuYaxP6NLV4IzLiZfsSldvOZUGc6f9MQKhzWimUa?= =?us-ascii?Q?87HO98h5yT5Sm/lOJhlJcB4nXMa4dZ/BtRplAVvPUHXMRIVDb13G0fHR9UIO?= =?us-ascii?Q?ZpOA10WnrS7jwHivMU5Xul4gI+eoe0dItXjW09W3O5Ew8CqSB1iJuAnxJ2dM?= =?us-ascii?Q?EKs1C61t8OXeCyOJlM0dq84eDMMJedN7TWkikzeysk5Ve7TxieOwbuWkTNCn?= =?us-ascii?Q?htHE3cbdDJe1K8CHFLw+GiJukpQXn+ktDCgIB8Oi5R+QrBmtClyv1jEe8bKY?= =?us-ascii?Q?VDgKhuraZ4hPTitEmFbWyZyFSMjJA6s03kFrqqdJe7mYSCGXO+aJQfWuIW3v?= =?us-ascii?Q?CcWb4ZAzAzQNqOpY+E8M6mzG1PnInJnGzDaNxCauuElYW1Fdb92+O6BfN/xI?= =?us-ascii?Q?xqWfEDf6mBKM3mx9MfuakSEg/iLD5D6lb/kGN8q4K5fOerZLZW21uYzAHh5I?= =?us-ascii?Q?bFtObrDjuc1JYDGYTeoG/cvG2BxHKbzNUrPE7T+jwRe3LWU1OLkk5UsYVCC8?= =?us-ascii?Q?RlTMXYVIQI4+eLQiK3Jb+U3My1mXPpx3QHSbxxG+VSuYrYNZ51cqVnaS2CC+?= =?us-ascii?Q?31h0lrrVXxTxudkCzRI4MSC62F4ONfVYvNhaCw2sFnK6Z8Z+PiczscbnKOmN?= =?us-ascii?Q?elma9qPsRK6I1Acq5bCGQtH8MuMkgNh+cMD62Hqgl3xLWxoB2DNOHGewwztI?= =?us-ascii?Q?aL2E9g6oEwT87wQeN38EYeloAzkpJvtvdL1J5zXRb7zYIBBPSTKk8lyKetoQ?= =?us-ascii?Q?TUFU/fH9rqgQNBNCXzs6iEjhTb9u9K19UaxjGHpF0wSvPQHD4hjL16ndpyNa?= =?us-ascii?Q?vEMK99vjBt7PUJT1vsT7/PX20VJpH97q4wApltLrg+4z62LW7VRzXFsgm/Vv?= =?us-ascii?Q?Kw5d6uIAJJTGxSnuy0U0uS6u0c+qqqIxsdvCotLv3Tbf63JQXwI8QWGvK1Xf?= =?us-ascii?Q?Dt84TlFOmvT9UjuUqHUpkLbmXHyPwKsjqI=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 6:HLKWVsdIIpaRtw4XhWRJxRVz3CMMrFsd47hRIVdYu9MF9lIf4RZcTe7Bk2Dt1eQv5k6/OQzQkcU3HUjB7oIEjsJssBBk+mWhYxsF8OCE98VHCilmqF14AjbwW6j49OWQPN/9CrcXR0Gl4nm+Ce5kVXZtAkALWny2gqx0b3w7qC3A36pKNWuNEztQrMPXvBUtCGyZLtx5WxhZRbWbi9kO3ZmHLt37W5D8rGwKMJ/5mefaF6CsT5VNzHUHIScn7Xllz8LWuLHmwuJj02m8a98GMlho7UAtkoRyTQBaWIJmeS4=; 5:jQGj/2+mh5IQ54UyDcfQsxNkPDeb6WqFV1j4VEcgFrzgkUAwfT0OVVPiUAzdPKeY1z+lHJT7iDYjNcBsY3C0+zoQRP+K3NK6tx+EfW7g70IQjdc/AqSpRdzQQm1N6ivF9IXhAP715ruYOrm/2ScfDw==; 24:mZDTeyYlxHkTvKqSHKHRjG4GbPCRt2LBYbOnfIrF0b1kEXqpVTZ2IOPreLtcSzCnaAoBvAjq6GgQq09eguF/ne7ZT8IjOI3fBSrH4ZxvP1I=; 7:ek7nlAbrBcBRk51lKSySck40Z38SZIYvCeOvmVLo0WqkHNieQyFdXLV9sKq5gXX8x7NDKdiM5TiW76htyVnx6BWyu15L8PPORUmIBdsPdgW1CQSNIMnFvRUrFKPvSaa68hUViAR94vZBzEwDQH5R8IdhFWrQgEqdOw/OHsRQOxT4n/Rc8bnk9vttUbn+OO0cetePk0/q3bfgu9GFE9pytFj8y/MZ0nM3LagxY4cUWQl6oTQ1IHJna3/kyzf7Ov9H SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 02:24:25.7876 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2522 Archived-At: Subject: Re: [tcpm] some editorial comments on draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 02:24:31 -0000 --------------85E29D2B3048AF234994B523 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Thanks, Greg, for your comments! Lisong On 9/13/2016 2:02 PM, Greg White wrote: > > Seeing Marcelo’s comments prompted me to read the draft as well. I > have just a few comments, and also I found a couple of typos. > > Comment 1: Section 4.8 contains a lower case “should not”. This seems > like it should be a “SHOULD NOT”. > > In cases of idle periods, t in Eq. 1 SHOULD NOT include the > > idle time; otherwise, W_cubic(t) might be very high after restarting > > from a long idle time. > > Comment 2: Section 4.3 reads: > > 4.3. Difficult Environments > > CUBIC is designed to remedy the poor performance of TCP in fast long- > > distance networks. It is not designed for wireless networks. > > Since a large proportion of TCP flows today cross a wireless link > (WiFi or LTE), this statement and the heading seem kind of > anachronistic. Perhaps it would be better to describe what some of > the concerns might be with operation across today’s networks that are > likely to contain wireless links (if there are any), or state what > properties of a wireless network would cause problems for CUBIC. > > Comment 3: Section 4.5 states: > > In case that there is congestion collapse, CUBIC behaves likely > > standard TCP ... > > I believe that the whole point of congestion avoidance algorithms such > as CUBIC is to prevent congestion collapse. (Also note the typo > “likely” in that sentence.) Maybe this would be better written as: > > With regard to the potential of causing congestion collapse, > > CUBIC behaves like standard TCP ... > > Typo: > > Section 3.2, first sentence reads: > > When receiving an ACK in congestion avoidance, we first check whether > > the protocol is in the TCP region or not. > > I believe it should be: > > When receiving an ACK in congestion avoidance, we first check whether > > the protocol is in the TCP **friendly** region or not. > > Best Regards, > > Greg > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------85E29D2B3048AF234994B523 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

Thanks, Greg, for your comments!

Lisong


On 9/13/2016 2:02 PM, Greg White wrote:

Seeing Marcelo’s comments prompted me to read the draft as well.  I have just a few comments, and also I found a couple of typos.

 

 

Comment 1:  Section 4.8 contains a lower case “should not”.  This seems like it should be a “SHOULD NOT”.

 

   In cases of idle periods, t in Eq. 1 SHOULD NOT include the

   idle time; otherwise, W_cubic(t) might be very high after restarting

   from a long idle time.

 

 

 

Comment 2:  Section 4.3 reads:

 

4.3.  Difficult Environments

 

   CUBIC is designed to remedy the poor performance of TCP in fast long-

   distance networks.  It is not designed for wireless networks.

 

Since a large proportion of TCP flows today cross a wireless link (WiFi or LTE), this statement and the heading seem kind of anachronistic.   Perhaps it would be better to describe what some of the concerns might be with operation across today’s networks that are likely to contain wireless links (if there are any), or state what properties of a wireless network would cause problems for CUBIC.

 

 

 

Comment 3: Section 4.5 states:

 

   In case that there is congestion collapse, CUBIC behaves likely

   standard TCP ...

 

I believe that the whole point of congestion avoidance algorithms such as CUBIC is to prevent congestion collapse.  (Also note the typo “likely” in that sentence.)  Maybe this would be better written as: 

 

   With regard to the potential of causing congestion collapse,

   CUBIC behaves like standard TCP ...

 

 

 

Typo:

 

Section 3.2, first sentence reads: 

 

  When receiving an ACK in congestion avoidance, we first check whether

   the protocol is in the TCP region or not.

 

I believe it should be:

 

   When receiving an ACK in congestion avoidance, we first check whether

   the protocol is in the TCP **friendly** region or not.

 

 

 

Best Regards,

Greg

 

 



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

--------------85E29D2B3048AF234994B523-- From nobody Tue Sep 13 19:26:59 2016 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 70EBB12B173; Tue, 13 Sep 2016 19:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40TmtoYYLqMR; Tue, 13 Sep 2016 19:26:55 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0086.outbound.protection.outlook.com [207.46.163.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2469912B175; Tue, 13 Sep 2016 19:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F6LIgQ6rcu8BPi48fcMTG3gv1+BZjvyiXpzMA4okDEo=; b=yDvGwmkaxxVxA7TKVtDrtPEh1HJv/BdjYPwdH0l/e3Jk5OCNNyO416zemdDs9oIAzI6FGCApeeMAl+RTFWmTqMGbZF1qKPMDOaRZCwVYLJRE8fAF2cdSr63s9TlbRJDguJCEiaQYIjweFRr/3lYYZ4Py5p010vpTAOMczqF92So= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.164] (97.98.140.59) by BN6PR08MB2513.namprd08.prod.outlook.com (10.172.147.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.619.10; Wed, 14 Sep 2016 02:26:52 +0000 To: Yuchung Cheng References: <95CE3E8D-EAA7-4BD5-98C9-81204D49C29F@cablelabs.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <99c0ba81-f616-ca5e-b3bf-6030c1fa5c06@unl.edu> Date: Tue, 13 Sep 2016 21:26:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BN6PR13CA0037.namprd13.prod.outlook.com (10.171.172.23) To BN6PR08MB2513.namprd08.prod.outlook.com (10.172.147.135) X-MS-Office365-Filtering-Correlation-Id: 3a159aa2-49d7-4e5f-7bf7-08d3dc469751 X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2513; 2:q3jHSBWcm7R/t3gRzyxuLYDssXlOpOJLv+aT+36NAU4clgJNLtWz8t890z76pHrBANqO2w1yHRl3QmEKcNmzhSEx77Inr8+iRnw/ubbS1xXux5VjbJKR5GTLF/C/AZ5dW5KUMblF4aobYNpzdTuXY/muXDm8ssT9d4EPO1wMHeSVVx5reN2zN/psYLOnHRx9; 3:X8nD8esVdWc1V4phkAHKUAV3JqEoN7cGHZm8RzF7q++u+zMx+XErMJItEwllfAX7AUJYbjKVSkMjIAOyOezIih8ihdXd9tzNin+TrsDs6QfmHxCURO57ebxczsZi3jXJ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR08MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2513; 25:q8Eg0vBwbdeJgaltubBoW7fgPtsH8gFLsXoSpIBSCNh1bCOkkfk8gBGzfd5vsyNzbVqmIuTQLZkTrIS6yBmMDOunkV5Y2tAaHGa8jf4jKcWSeYw6NoJ/4WQvwOhXg3fVRKFTuzryW8RkFmijeQwbdBKxHU8Hdmaz12rIZcT+LVcJSZI4NPYxkCXB8FnmgOXYTSwXyxM8fJsqJIXSW3iOu98KG0jIMSXTCsykmAwI0Y7a8uZjvi/7jiD8Z4eyQfcxdXU0iqSn8JtEpBzeoCeHlAz2DPZuG42nZIMDZccIk6Iz2WQLJOztaBvyK2WSazUpfXs7rrpRWsTZM/jHMIC1cf3J7Xz/DvP3dEFB/Nq1I0sLDF4gHqdK62/sdia5j8d+Imz0fbigVLHY7EEzeqzoERsfDS4Xlfft/dsK3otsYxLSlQEedVxei5RUlhEp0wONUl6R7Zq3nX4LBjCjOGDPJtrOK4HzPeKawMHh+9ny81LsUMy6MP/nnLAmkWrQwu6mtWa1yIliEO9etauMVhWnouHYOFTrfY55yaLKWj9Cz+nYAIstrIcLvkZyhZgtGbnmJkI7w4poMkqaoRanYk8QdFewB5yrPY8suByUdWc2uKFhPQi1mVeRitP1lYknyxQ3+TEXyhyUx9BjdkOv9FgZ6Sd+TmgDD8gATwYsQ+215Rsz5sIPGvaX9Qx/rZmCX+EzfKNQEc3RT6rWvAYIGUctN5APBP7dwdEg2HlqMZjxX+kovTlG7QL8+QeMU8CkJ2AMQa1NGpHPKtavLkXlacSUVsQi55kDhiDE5rHK2qIRGQ4VRDSudnfUaA6Oiq0xBi7hBIIY07iLcUrEcKP6SD6pBA== X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2513; 31:t5wZszc8H3zL5I912klNKN9jJeXkoSlXiraUP7X/k11PXC/sRAg4fJHkgOfQQKffKiFMB0kLoao/8CQs4RnaVpiYnL7IP3oUvbjRBhaoZLmMTHnSbSKqWZQkvbL2huViG8EuIkEtfaw1dZMwJrTc1J83ArZUxRBpTMLBFUTXIH1tmX6E2mTEtjGwbVVsnYYiZMQht7IbmM2p1xSLYDJ4/gYGI3+KLOwqnbgHBbUK3+g=; 20:/54zXJuvTjdj1F/pClwFMUni/t5wgmgGN644LE2y7tAL01eWeDOJx1R3a6zaqFhptdt5/dCeXy46O7sT6E9e1Agpf5ELn21FUBkGfP+r/MExYXCNgBCgovWVy8mb6w/0uFiu6cJ/Q8o0aSUhfjwZPDZVkzBIASbg2TkKRldmV79AHUBWRozfxUvQjTGMKVqYnUqkWeVlyrWOFQfngRtORsZ4c00zHjQ8ZmJbOfb00swI/zhlpvnvvvc3tOKXea5TdkTJxCDysQk14IEw9QXFSPTiVv1AupPTILTwk1TB8N6OSKJ2DNHG/sHDSOikdBb8Qvv6P0Um6XyrkLFypmqPLAgTL7rdK6NOttxvdToN2Z7QtTndiYSxoFtLjg84KxC/q991sGlZi0KUxwFusuMPtjahopj2uPlSL7+sVaKnx5jZVV9UXYcNlB925JX2YL6YhGUy/LcM2iHEOxkCG5zTDtqXE4FpFyFsfMI8wuco3FvApFqbWSMvGEjhc4wrChaw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(176510541525296); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR08MB2513; BCL:0; PCL:0; RULEID:; SRVR:BN6PR08MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2513; 4:edLgh62XLt4T/DxvhX6l4V+rmtUgH7xWHQyqoNYW+x9CD+9U46F8JM59Sqh8KmdP2mrXNnOu6LOYtRqZ1afmHWSrr4lILnQvbq3AhWiRNcd7l435S+hjXSr9t0J2Fe1D781M1rl7avzwKpji0QuJbSGR8WMOr5D9GwAwlGCKdxCAW45NbJIvji9LpVTBr6NF/SfJ3K8J2ILA0V4mEb8k+ITR5S/iUvZIyDjreK0T57lVEpxmiOq/9PGCJQ/E0aqzYQ7Y6gOwCiQWhy36yREnBB+teDak6ojVERT8Hp444icIuO1amKaeNPdXSV6oKgMtnlSqmQ5JHk4Zzp3yXq8dnSdwl/dfQQtuQFdRh8RMrKc/3PpiocZLyxf9SX44O+0sdr8DclJ4+L/UA16XnHCGDudvln0sKsPUqj1wDLZJGNUJYld9dF29bNWmn5ASc2LY X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(24454002)(377454003)(8676002)(68736007)(2950100001)(90282001)(305945005)(33646002)(106356001)(101416001)(23676002)(15975445007)(105586002)(77096005)(7736002)(54356999)(110136003)(7846002)(76176999)(81156014)(81166006)(36756003)(50986999)(89122001)(19580395003)(42186005)(586003)(92566002)(97736004)(2870700001)(88552002)(4326007)(5660300001)(47776003)(3846002)(6116002)(31696002)(86362001)(31686004)(2906002)(189998001)(75432002)(65806001)(83506001)(65956001)(50466002)(19580405001)(230783001)(66066001)(4001350100001)(64126003)(117156001)(65826007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR08MB2513; H:[192.168.0.164]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjA4TUIyNTEzOzIzOm1qRkVybkxVVjA2TXZseE8yaWs2TlZlN25i?= =?utf-8?B?WEl1NU9qS0swRERrS0pqdzVONzlyeG9CV3JncjAxaVJrb3kwOVlBbnBsMzFN?= =?utf-8?B?OGZtMTl1YjN0Rm42a1phRktnWVRWb3RsamowbHZQbGZiT2tOdUFRNDN5SlNl?= =?utf-8?B?akM4Rkc5UU0welBPNFlLU3BYTTZpMDJWOEtUaGE4T0pwR3htaWRWb1F5bVNp?= =?utf-8?B?MFczdFJKUlNKeVlMR21neVJmOTBOUUdVZzhkbSswekJzVE5pTWxGcy9ZNmFH?= =?utf-8?B?YzZJQjFzcCsrNHVxQ1djNTFyZlM3c0N1dDJZa3pLN3lYSG5YRDFmZnprb3Ir?= =?utf-8?B?YVFKSmRQL2pJMkRBWlJMNGd1aWUvbDRGYmNzdEU3MTJQY09UN0ljb29LbHFj?= =?utf-8?B?TzBSSVBLVlNDVDE1NjliaU92bHpYREdtbEJhbEQ4YlRuaE5NUWpINmkwN1dJ?= =?utf-8?B?L2xGTERmTEduTjJ4QVBITTRicll2WVFUSk9qNlBjeTkzL3pYTWp3Rk9ubVdm?= =?utf-8?B?aUdMblNld3JmTkZYMk1RTDROeVVSWnZCejhEdE1vU2JPeTVWRUJjUnZPbHdi?= =?utf-8?B?VzlHbXY3LzI1NUt1bm9kdjBZRWVtUkdEUW1BTUFwaHVuUk9TTVo0ZGtSbE5z?= =?utf-8?B?a0JLaXJuT0JONWNlTndnUHZSUzJJTjVuR1VkZ0hhc2VkRGx2WDBibXpJWkx6?= =?utf-8?B?U2dSSkdxanZIZEZQdlZPVVpVQ3VQT3d2MVdRTlJzVUd0d3U5ODJXZXdHV254?= =?utf-8?B?a0NhREtXdWJySDd6cmNHL2lqbEhKcHFLNVZUSGthQ01sY1ZkY3VkNzBUNkQw?= =?utf-8?B?WCtlUEsvVGhiWllmeHVtbGhaMTl2M3Vyem1iL1BXNUdVOStkT2hycVYwSyt3?= =?utf-8?B?cnRvMXpsMDNud2E1dlArNCtwYzNkeGQ4VmxHa3kzMlorSkszOFovVVZKRnFm?= =?utf-8?B?ajhYajNyemFxQ1AzRzNabjR0U05ZSWR1THpEcHp0TWdreGhxbE5UQkZOdEhS?= =?utf-8?B?QnFOK3hFL3VwZENzRVlYZFhIa1lvb2N1dlNDbXhWS2FiYVJlZnNIMzhDVENT?= =?utf-8?B?QmpyZUQ3dEl6akMvc2hnVnlxNHAxVDBxQ1Z1ZWwrZVhIbWl0N2VqMjUxcXUy?= =?utf-8?B?cmhXMXRGSklSV0cwdkZLK1lGV2Z3RXg3UElCdFNlekNXOXBNU3p4bWZjNE9E?= =?utf-8?B?UG04WmpKM2QvWExHOGxmMmtCZkpEUWFic3FKcmEwY3RQQlkzWkV3amRLY2Vt?= =?utf-8?B?RnZjYXJOcWorWnJScnZ2dWtRSUpZc2h6Z2tpT2RhZVpNam93NkNTV2kySWNv?= =?utf-8?B?cjVtcGpxOUZyU1pEK3BVcHFaSEZJSVEwMXM1M1E0SE9oamlQR2hJeFVoKzBr?= =?utf-8?B?THNlbFBCOXNKMXdrYXUweUJiQjVQSEdGZVdBSmVjcWNtUmp0VXVuSHlEMzM5?= =?utf-8?B?ZEhxT0NDY2I3eTlwN25CQWtaanB5WCs4VE5IYm9pRkdsQVI2R1kzTzlWY0dG?= =?utf-8?B?VXJmYzYwczdUT3RqeGRQM3dpb216RFJiZDg1NXZNb29ZSGFNcENSTHlYZFBV?= =?utf-8?B?YzBGa3o2Y1Fnc2M0QzVxdVJMd1BjQzUxUFVWdXJtcVBGbE9tN05KNFNLREdD?= =?utf-8?B?MWV4aGJPYWhWZWtvaHpnZnZBNmZQVitHaG5hRFg2d3p2OGpJa0JzOHRmdmJL?= =?utf-8?B?ejNZVXozY3FJdEZZV3dxdzRiaysvN2R5TVRNTE9hNXJXU21xQm9lUGtldmk5?= =?utf-8?B?QS9lSnZTdkhmeDNBclpleTdvSzZxRUladGQ2TGtxcDRIVThOY3pScUtibVFN?= =?utf-8?B?b0R5cHBMOWRBMXVXTXZsSWFRK1RUV2FkREVCZm1EUDZwcExCMEpLTmVJNW5C?= =?utf-8?B?Qk96M1A1V0FqeFZuWDJYTlhJNkRqNW1hMTNjZTZXYWErN3lMVFhCRWpmcVBO?= =?utf-8?Q?q86RRq7nRNyxkPrueLEst3c4FactHM=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2513; 6:quJnFVzPf5O/r7xHmLH+gp+co10CdjCvrP6EPtgYOJ9uEUI8V/v+WUFmWKf5IB2JlGtXAQh03sVvaf3BaE6eUhHJrtRrqVUPO1htol4k7WadpNIl6Kp9UvNEawsZif6BHF5xsz8V+CXb/I3nwe3PpTUQy5hMXwP1MEfLjjUkZDLV3kwEkREWOiVbwqkCzV5fo0TILWJ2X+XYHnT4fk0k0NkAnFm0ulQa0dRTTb0AiunEDbjepcCy2osVY4EhATm7MG1hLhxFeyFfnfZOkG920ZX0YfJUNhdJHSPSgAjn26c=; 5:1t8d/Y2XAyI38Aubm3AOC93KlkC6G/2pu17HdIC1IZGmwfgNRtYRHbEEXGMZ+ue2DwNRX/xdKBB5j22NGVTjXuu9ARgRLx40+8mlWMF9X34eIaplgWrI6ir9lgRnYSp/ZZ1EbiA9ZC25Bm2YslDEXw==; 24:6cb5U+aedRq2sVlYH3W7kVwt8taS8BsHlWiMDQ2va1FNx2bIcy/MhxfHEHXv+JxjJsSuJ/7DePp5yQFApR6tHuBwSiho98DEPd1w6K0gb5Y=; 7:Tb4woDyYhDTe3T2mnBNCiyCeYvVKXFEE4AhyN4GbcyEFPNWgmIp5s6ruWgHwOLdwvzJ0fGL3R5U34C/ajm3o0HzkNzWjGY43NCipaYAJkUIjLwAgqYtbRsx3fOkFwjob7osQ1B6bnuIo1s23x08sqL1y+4ouHyyzuQviWq+QC1xlEq0oRAeFB9C3ovDAzXhSiXWPHIl8ZrG/xf79mW1A3HXYx6avZvCphgxn3GTXa2d/073bxnpoPu6vpPvaOo3t SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 02:26:52.7407 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR08MB2513 Archived-At: Cc: tcpm IETF list , "draft-ietf-tcpm-cubic@ietf.org" Subject: Re: [tcpm] some editorial comments on draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 02:26:57 -0000 Thanks, Yuchung! If the idle time is very short, it might be ok to include the idle time? Lisong On 9/13/2016 4:39 PM, Yuchung Cheng wrote: > On Tue, Sep 13, 2016 at 12:02 PM, Greg White wrote: >> Seeing Marcelo’s comments prompted me to read the draft as well. I have just a few comments, and also I found a couple of typos. >> >> >> >> >> >> Comment 1: Section 4.8 contains a lower case “should notâ€. This seems like it should be a “SHOULD NOTâ€. >> >> >> >> In cases of idle periods, t in Eq. 1 SHOULD NOT include the >> >> idle time; otherwise, W_cubic(t) might be very high after restarting >> >> from a long idle time. > why SHOULD vs MUST? I can't think of any corner case that we'd want to > include the idle time. > >> >> >> >> >> >> >> Comment 2: Section 4.3 reads: >> >> >> >> 4.3. Difficult Environments >> >> >> >> CUBIC is designed to remedy the poor performance of TCP in fast long- >> >> distance networks. It is not designed for wireless networks. >> >> >> >> Since a large proportion of TCP flows today cross a wireless link (WiFi or LTE), this statement and the heading seem kind of anachronistic. Perhaps it would be better to describe what some of the concerns might be with operation across today’s networks that are likely to contain wireless links (if there are any), or state what properties of a wireless network would cause problems for CUBIC. >> >> >> >> >> >> >> >> Comment 3: Section 4.5 states: >> >> >> >> In case that there is congestion collapse, CUBIC behaves likely >> >> standard TCP ... >> >> >> >> I believe that the whole point of congestion avoidance algorithms such as CUBIC is to prevent congestion collapse. (Also note the typo “likely†in that sentence.) Maybe this would be better written as: >> >> >> >> With regard to the potential of causing congestion collapse, >> >> CUBIC behaves like standard TCP ... >> >> >> >> >> >> >> >> Typo: >> >> >> >> Section 3.2, first sentence reads: >> >> >> >> When receiving an ACK in congestion avoidance, we first check whether >> >> the protocol is in the TCP region or not. >> >> >> >> I believe it should be: >> >> >> >> When receiving an ACK in congestion avoidance, we first check whether >> >> the protocol is in the TCP **friendly** region or not. >> >> >> >> >> >> >> >> Best Regards, >> >> Greg >> >> >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Sep 13 21:19:45 2016 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 6507F12B51D for ; Tue, 13 Sep 2016 21:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 r_l0VnNF4n4z for ; Tue, 13 Sep 2016 21:19:42 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 CCC7112B1CD for ; Tue, 13 Sep 2016 21:19:41 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id r192so26913215ita.0 for ; Tue, 13 Sep 2016 21:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ezb77ix4kiSE3vQXLaovvGkdimzCarZL291XcXP+DuU=; b=pzD+UvT2iAKB/YohJdzg4Iu3VM6BhaevwpLvBKuq6W5Ur7wa7zLy6FZ4vuqyxndzCC BlYveY4l8dptsFOkBftLax7krYCp1bGo1yQuH8Jflh92DNlvzgB17KdK4ukYxv56GQV8 mBhJa/MoiZIJfs5ca7O0hoCkrOp7GNfdy8eYWk1qjgyVNnigBJBiG+VjRbxpHF+MHsw8 NoFXSjrXi2Bk7EaTcsbaG9dFZ8WMETwYhfDRS9zUBjzuHd2dSuEoGPIR7hNIYMJ22aFV MNmvQtno8luA1RnuhXeN7ctF7vBFtoIYx8+HVIoVESHDqKgDdyQgRlB2h+wEcmVl857g BWNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ezb77ix4kiSE3vQXLaovvGkdimzCarZL291XcXP+DuU=; b=Cpt1xgIw+Y5Sh7BlqGryVTOkJ/vnEkrHnadtSohXT8/QHKcWQzNso5GOXESLmxJu9C l4EMVoJadiy5fOe9iX8mCziH3BLo/Mo7M6NH2S73Z9qJizVjS6t6IzRDidhjSzq7Zk0p tq3Fzf6MM8aM1MCOkwuF0kp3aOPpkDhAHOv/469CmUkQTn7bCv7NiTr3Ljs9uHvocm16 uh5HaE0SoB2nlKpQt5pTKHSIfJ1nfbDqATnCQQH2YTRijbqvsvKzkxwLQs8ir3TCvRmb taFjlXzXdON8eNbUR+IdrcCva5DTKxR/ZsUj2MtxgOegRH4qKuLxo7UYTTLbkt9FBhDf lsRg== X-Gm-Message-State: AE9vXwM4ML4t/wZKqvhY32/oeg4mCJs84jb29y78RbNLBFrUgmD5VguMUak79OkFsVtcQAGZyE7rrDkwAZwfnmZf X-Received: by 10.107.145.10 with SMTP id t10mr2423889iod.42.1473826780829; Tue, 13 Sep 2016 21:19:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.135 with HTTP; Tue, 13 Sep 2016 21:19:00 -0700 (PDT) In-Reply-To: <99c0ba81-f616-ca5e-b3bf-6030c1fa5c06@unl.edu> References: <95CE3E8D-EAA7-4BD5-98C9-81204D49C29F@cablelabs.com> <99c0ba81-f616-ca5e-b3bf-6030c1fa5c06@unl.edu> From: Yuchung Cheng Date: Tue, 13 Sep 2016 21:19:00 -0700 Message-ID: To: Lisong Xu Content-Type: multipart/alternative; boundary=94eb2c055ea4bbed3c053c700955 Archived-At: Cc: tcpm IETF list , "draft-ietf-tcpm-cubic@ietf.org" Subject: Re: [tcpm] some editorial comments on draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 04:19:44 -0000 --94eb2c055ea4bbed3c053c700955 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 13, 2016 at 7:26 PM, Lisong Xu wrote: > Thanks, Yuchung! If the idle time is very short, it might be ok to > include the idle time? > Lisong Sure but to me a SHOULD means there is some legit cases where we would include idle time. Since any system has finite timer granularity, the case you mentioned does not violate MUST imo. > > > On 9/13/2016 4:39 PM, Yuchung Cheng wrote: > >> On Tue, Sep 13, 2016 at 12:02 PM, Greg White >> wrote: >> >>> Seeing Marcelo=E2=80=99s comments prompted me to read the draft as well= . I have >>> just a few comments, and also I found a couple of typos. >>> >>> >>> >>> >>> >>> Comment 1: Section 4.8 contains a lower case =E2=80=9Cshould not=E2=80= =9D. This seems >>> like it should be a =E2=80=9CSHOULD NOT=E2=80=9D. >>> >>> >>> >>> In cases of idle periods, t in Eq. 1 SHOULD NOT include the >>> >>> idle time; otherwise, W_cubic(t) might be very high after restartin= g >>> >>> from a long idle time. >>> >> why SHOULD vs MUST? I can't think of any corner case that we'd want to >> include the idle time. >> >> >>> >>> >>> >>> >>> >>> Comment 2: Section 4.3 reads: >>> >>> >>> >>> 4.3. Difficult Environments >>> >>> >>> >>> CUBIC is designed to remedy the poor performance of TCP in fast lon= g- >>> >>> distance networks. It is not designed for wireless networks. >>> >>> >>> >>> Since a large proportion of TCP flows today cross a wireless link (WiFi >>> or LTE), this statement and the heading seem kind of anachronistic. >>> Perhaps it would be better to describe what some of the concerns might= be >>> with operation across today=E2=80=99s networks that are likely to conta= in wireless >>> links (if there are any), or state what properties of a wireless networ= k >>> would cause problems for CUBIC. >>> >>> >>> >>> >>> >>> >>> >>> Comment 3: Section 4.5 states: >>> >>> >>> >>> In case that there is congestion collapse, CUBIC behaves likely >>> >>> standard TCP ... >>> >>> >>> >>> I believe that the whole point of congestion avoidance algorithms such >>> as CUBIC is to prevent congestion collapse. (Also note the typo =E2=80= =9Clikely=E2=80=9D >>> in that sentence.) Maybe this would be better written as: >>> >>> >>> >>> With regard to the potential of causing congestion collapse, >>> >>> CUBIC behaves like standard TCP ... >>> >>> >>> >>> >>> >>> >>> >>> Typo: >>> >>> >>> >>> Section 3.2, first sentence reads: >>> >>> >>> >>> When receiving an ACK in congestion avoidance, we first check whethe= r >>> >>> the protocol is in the TCP region or not. >>> >>> >>> >>> I believe it should be: >>> >>> >>> >>> When receiving an ACK in congestion avoidance, we first check wheth= er >>> >>> the protocol is in the TCP **friendly** region or not. >>> >>> >>> >>> >>> >>> >>> >>> Best Regards, >>> >>> Greg >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > --94eb2c055ea4bbed3c053c700955 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 13, 2016 at 7:26 PM, Lisong Xu <xu@unl.edu> wrote:<= br>
Thanks, Yuchung!=C2=A0 If the idle time i= s very short, it might be ok to include the idle time?
Lisong
Sure but to me a SHOULD means there i= s some legit cases where we would include idle time. Since any system has f= inite timer granularity, the case you mentioned does not violate MUST imo.= =C2=A0




On 9/13/2016 4:39 PM, Yuchung Cheng wrote:
On Tue, Sep 13, 2016 at 12:02 PM, Greg White <g.white@cablelabs.com> wrote:
Seeing Marcelo=E2=80=99s comments prompted me to read the draft as well.=C2= =A0 I have just a few comments, and also I found a couple of typos.





Comment 1:=C2=A0 Section 4.8 contains a lower case =E2=80=9Cshould not=E2= =80=9D.=C2=A0 This seems like it should be a =E2=80=9CSHOULD NOT=E2=80=9D.<= br>


=C2=A0 =C2=A0 In cases of idle periods, t in Eq. 1 SHOULD NOT include the
=C2=A0 =C2=A0 idle time; otherwise, W_cubic(t) might be very high after res= tarting

=C2=A0 =C2=A0 from a long idle time.
why SHOULD vs MUST? I can't think of any corner case that we'd want= to
include the idle time.







Comment 2:=C2=A0 Section 4.3 reads:



4.3.=C2=A0 Difficult Environments



=C2=A0 =C2=A0 CUBIC is designed to remedy the poor performance of TCP in fa= st long-

=C2=A0 =C2=A0 distance networks.=C2=A0 It is not designed for wireless netw= orks.



Since a large proportion of TCP flows today cross a wireless link (WiFi or = LTE), this statement and the heading seem kind of anachronistic.=C2=A0 =C2= =A0Perhaps it would be better to describe what some of the concerns might b= e with operation across today=E2=80=99s networks that are likely to contain= wireless links (if there are any), or state what properties of a wireless = network would cause problems for CUBIC.







Comment 3: Section 4.5 states:



=C2=A0 =C2=A0 In case that there is congestion collapse, CUBIC behaves like= ly

=C2=A0 =C2=A0 standard TCP ...



I believe that the whole point of congestion avoidance algorithms such as C= UBIC is to prevent congestion collapse.=C2=A0 (Also note the typo =E2=80=9C= likely=E2=80=9D in that sentence.)=C2=A0 Maybe this would be better written= as:



=C2=A0 =C2=A0 With regard to the potential of causing congestion collapse,<= br>
=C2=A0 =C2=A0 CUBIC behaves like standard TCP ...







Typo:



Section 3.2, first sentence reads:



=C2=A0 =C2=A0When receiving an ACK in congestion avoidance, we first check = whether

=C2=A0 =C2=A0 the protocol is in the TCP region or not.



I believe it should be:



=C2=A0 =C2=A0 When receiving an ACK in congestion avoidance, we first check= whether

=C2=A0 =C2=A0 the protocol is in the TCP **friendly** region or not.







Best Regards,

Greg






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

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


--94eb2c055ea4bbed3c053c700955-- From nobody Wed Sep 14 00:35:39 2016 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 53A8612B567 for ; Wed, 14 Sep 2016 00:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq60HMuqrSyk for ; Wed, 14 Sep 2016 00:35:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 770D612B566 for ; Wed, 14 Sep 2016 00:35:36 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-63-57d8fdc5c700 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id BD.AD.31035.5CDF8D75; Wed, 14 Sep 2016 09:35:34 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 14 Sep 2016 09:35:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MrEcHG5chZhhLKNuv+WMiiRpPHer6qm7JGLGIVFJQ+4=; b=ANMhApyXvXFJ7nMAF9MYKUPU/mVcUz3TT0bRo/4Etqlx+JLMR+BzXV/y8Qm9B0i9BdE6m6AYc482PfCch1gGsRLxDw4f903ZsdW/rqQR+jnXEB0HQkyuO/uUwAAswTlOjqtuEuIe3a3Hl/r7N0reWWkMVqnbMF1dRzMIjd5hF8U= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Wed, 14 Sep 2016 07:35:32 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0587.019; Wed, 14 Sep 2016 07:35:32 +0000 From: Ingemar Johansson S To: "tcpm@ietf.org" , "g.white@CableLabs.com" Thread-Topic: Cubic and LTE (was RE: some editorial comments on draft-ietf-tcpm-cubic-02) Thread-Index: AdIOWK6ci4YGMzrYTj26sVcOkZc1qA== Date: Wed, 14 Sep 2016 07:35:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.89] x-ms-office365-filtering-correlation-id: a565036a-c3cc-4af5-fd05-08d3dc71b596 x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:62c0lJObbuQxdlQ6uW+TB6mxz/26bbx5wK0LzuD0MBUo94VB7Kodw14qGU5LsNzaj3kDWuXWLG2o/wIl4guVTkYtnJMT7R9HcyrqzguXdlMG6z0Xq+pkm86UkVtWbE7ANG35Ee3bRv6mTSHeTKg9Z8R6XF34X12xW828uylomac5R87RqaOJI8zKdmV7C0DlLC5HfoD+LfP7Zy5VdBIPsda0ihCBQYsvM3hkhqEpkqRtGBR7nL3tmdgJcBhrilrk20lZOeCQoh8JR44gwiEatzgO9EQqNQMlE9S0NkHdt4o=; 5:G+sp6zcRkysUdPMW3jsI8/Y/aMaEAzLEwD7VWKPlCWGMgpvFTpNWT5ONKFYy6mCyBX8klFeued9VJkn+a3XSTbAMZUyVbE1J3bKkQASkyjqd5nY7CB6AAdyKy2oAjlfwZQ+rLWEovfIg3zXBQ+Dn/Q==; 24:aX8TfEinCyiwQodjroz0C/1tnGUyP9NHYq1J+TyAMCryr6aKm4d3U/qKUpaQhMu6kfYQ9IIlwXXfcEIYOz414CsFgsk+jnlNqQESo1ymk6I=; 7:0kQrxaOkKse2oQNeLXL18Cald9Bb2S8xuT6oxQrnJtqHrsk0hVLV5cdeJrmh8AtTt6MUpADgCQuL4Uf+L61dEYQm0fdN4//aLgcnwOtnsul/CjA8bv0q/J0zBzWWozgRZEMzyBd3ZKIyH6AGdy4wpERXBci1/E19fSWL48Sq+DrOq51JgY0FtXaC747W7ARI/P0IeYL++Hsp+FivSFuQrFESyq18RwZ0FXCEqNKHmQxs/c5jHyILMd+zueJ4YskB x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(176510541525296); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 006546F32A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(10400500002)(87936001)(81156014)(74316002)(77096005)(19580395003)(122556002)(2900100001)(68736007)(92566002)(5660300001)(101416001)(7736002)(586003)(230783001)(2906002)(9686002)(33656002)(3660700001)(229853001)(4326007)(7696004)(2501003)(19580405001)(305945005)(106356001)(7846002)(3280700002)(189998001)(4001430100002)(86362001)(105586002)(11100500001)(81166006)(8676002)(107886002)(54356999)(5001770100001)(8936002)(50986999)(66066001)(102836003)(5002640100001)(6116002)(76576001)(97736004)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2016 07:35:32.3483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbSyVYRzGu583j8NZj5OX/+RDO2O9IpVSlPog+mBTU6ItDp5hcdjziFQf lCNvGZm10eooB6HYSihsOcvraoepSHGWSMZpDXlZDjnn1ta33/W/rl3bde9mSdkt2pGNUybz glIRL2ckVMn5Jl/XTuNQyN7iD55e82t65NXYoyaOEwF39SoUoNEsE0FEmMQnmo+PS+EF92MR kthHcx100oz0yp37S2Q6SrfKRZYscAegR5tnkYskrIyrR1D/Ko/AohvB7YVe0iQoLp+EhXvN FHaKCOhsGNwQnQgG6sosTGUM5wPV2kVkYlvuHPwca2NMTHJHYL7LSJp4y/p9RF9E4cwF0L2c ZjC7wffPb8wZinOBnAKVuVPKhUFV6wNzBnH2sNj7hMCdDjA8ribwCA40rToSsx1MfVulcT4K Zj/l0/i+DboeGxjMgZBdk7nBBgb0OT6Y/WDOMIMwx0G/UWeB2Rum1RWMaTBwjQhafuVS2HCC wpEmEht9NBTVvjW3yjgeqp5mIrzYEUbe52ywE/z40kbjBXugrGWWKUQ7Sv8bVPqfhXk3VD6c JkvNj2EDPSXjVBmiapCdyIuRCTH79rvxQlyUKCYq3ZR88jO0/jvaG/64NKOBmRNaxLFIbi2N YIZCZLQiRUxL0CJgSbmttPP3+kkarUi7yguJ4cLleF7Uoq0sJXeQrr4bDJFxMYpk/hLPJ/HC P5dgLR3TUXblGauVNQvi+qGwYFmBd21wxcSmrOcr240fi5cijxr8Os5qxzwyDkt2asuu2Q37 TmZNLHuolCplQNDmgzecT6Wr/ZFRRds4x5eHVk9NNgeebktl218QmSclcntp5Os6Y4Suz7M9 9WKa69dR99HK8JsZ3XWz2lC5JtVftBbK++WUGKvw2EUKouIv2NpqHhkDAAA= Archived-At: Cc: Ingemar Johansson S Subject: [tcpm] Cubic and LTE (was RE: some editorial comments on draft-ietf-tcpm-cubic-02) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 07:35:38 -0000 Hi A comment on section 4.3 "Difficult environments" Based on LTE system simulation experience, I don't find Cubic to be worse t= han e.g. Reno, we see occasional issues with HyStart but that is another ma= tter. With the use of proper AQM (or ECN) I can see that Cubic is actually = quite well behaved. The root problem is that LTE networks seem to be bufferbloated today, AQMs = are in general not deployed or enabled. The outcome is that transport proto= cols with Cubic or Reno, or any other other loss based congestion control a= lgorithm for that matter, can be claimed to operate in congestion avoidance= . The results can be RTT in the order of seconds which may or may not cause= problems with RTO and/or large burst losses at handover depending on the d= eployment of packet forwarding in LTE networks. So at least my conclusion, based on my own experience is that Cubic is not = the big problem here. Regards Ingemar >=20 > Message: 1 > Date: Tue, 13 Sep 2016 19:02:26 +0000 > From: Greg White >=20 >=20 >=20 > Comment 2: Section 4.3 reads: >=20 > 4.3. Difficult Environments >=20 > CUBIC is designed to remedy the poor performance of TCP in fast long- > distance networks. It is not designed for wireless networks. >=20 > Since a large proportion of TCP flows today cross a wireless link (WiFi o= r LTE), > this statement and the heading seem kind of anachronistic. Perhaps it > would be better to describe what some of the concerns might be with > operation across today?s networks that are likely to contain wireless lin= ks (if > there are any), or state what properties of a wireless network would caus= e > problems for CUBIC. >=20 > ************************************ From nobody Wed Sep 14 07:55:42 2016 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 2787F12B4B5 for ; Wed, 14 Sep 2016 07:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkpgNd2XQlAQ for ; Wed, 14 Sep 2016 07:55:36 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0047.outbound.protection.outlook.com [216.32.180.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A140912BA30 for ; Wed, 14 Sep 2016 07:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ONwDPPPeMd4XmcEpZ5gPf4S3aPvhWjnxVUjfO8rhKvk=; b=W7rx2C5yFL1W5tV85LcGR0tmZwjBmEBUZhbvCW24mqnSmjKLYwL2HuL84xsJ7pzYvRykZL99P1J23a7t3i9swGrpf6bvV1MeUDbrycTNQaqUE97wjFjvyLZiFks16oPi7y2qN5+N2+F5Kh2uuaLZuC5bxhFWTTyuD5i8JvJeTG0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [10.211.135.36] (129.93.4.24) by DM5PR08MB2522.namprd08.prod.outlook.com (10.173.220.136) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Wed, 14 Sep 2016 14:23:44 +0000 To: Ingemar Johansson S , "tcpm@ietf.org" , "g.white@CableLabs.com" References: From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Wed, 14 Sep 2016 09:23:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.93.4.24] X-ClientProxiedBy: CY1PR0601CA0005.namprd06.prod.outlook.com (10.160.162.15) To DM5PR08MB2522.namprd08.prod.outlook.com (10.173.220.136) X-MS-Office365-Filtering-Correlation-Id: 96d6b2b4-e09e-4a92-b03a-08d3dcaabc13 X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 2:52XtCOuAzKwbYPwA5vV1byqGrM72KjU+cYuEJrPnQ0TTLk4p/J/4ihj4AcYy8GcEpL243wFFs7I0AG7kr/YuTjlDLVA2stKClnpXLJvBAQ01la3eJLsi1LxtyH+bYRMJcg05RXZVfPfkei/9b6T4KQZcT1Mn5Bj4ZxntRQd0CIZ7srTT5JtRigQEdShWUFnW; 3:TOY5P+57pQEqHSYI84cYzmmuvPjwBc2WBnUVrpR8y7tY2lzVrpm/wekA9upPFLF2B+C6/mzlcCsU6gKI9pfbSnJwCz1dmpXf5SskZP/oPNMCPnO6jLfhtMsYMRTHcd7n; 25:GX36dx1mnACfjjU4RrUMl+tzrIl0S6C8Qe72SKXDab+IsqImV2k0zbisdfrFtCFw7E5rw+sFptZVP5yafczciYe/6ijcfsDWIjHeQo15dM4FAAJTDj4Obulpbw8H7MmrdJX3CC5FAqGxtb6m1K6OaF3k49S6RVY81Z0rcvcX1iKIFFICu4qWadTec8oOrh1q66Cqp2MoCE+MOLwhf84g5pXx4RZkBtsFwQ3YAj6E7pjoSKYG3iJM1OJGlpjus9aYFgA6FACgqkPEsOUHnum6ezqSn3fnivkYnTDvDcL9t/Q0IoN7p687AZ+a2O45NZTWJJH1TQEoPCq/wE/Ve8GcAurRbO1WKriDDr9Bn6b5R6RIpvA7qvIlDvVuLKAePfEqORI7bX/MVpyfNTehVgjm5MY8h3X4tUea2nHi2uRhoJ8= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR08MB2522; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 31:iIoDwfmYFFU5ilSCgExdW/hKszMXW7xp05G6RAZr4tLXMJTuHgWYE3C3pNikWKWaToP6zKUK0iyizTsrAEjZh7srz+/DXxVo26LLuBdGGv2/ViYDtToprhIOtH4/cjmePV1jwVVNLWJlPi48iHN8MddfJV8jatnMHNj+tceVG7oDLtia8Y4pxyNINNXHVjMbaRNJXQcvSR58lKzfoUmB8s1xIB3BarOubzORaB7LRlU=; 20:VGzAZR5cMtd7ynzP1HEeXfkEoKHuopFoZoHiVZF8mMn0j6Mbvm+G65kXtXxQTpgkol6UQbsy8eAfp0VSKRqYEKVUhyhIPYZJoP/AP6H3C5Hoi3sSnjxEth86W2HSNMrnOuxAwvgGntRqVL+GSqe5rg92FJWfNCSkRHL6Hillc7BUJVXEQ0zOIvEjzYric41s8SiSrwiX/KSAn+clcbcgTij4rIBkN0LGkb8qJHkkQRN2Mr8S40REXH63rs36FNNGtQOkcGgJwuh0mbVd1SxdipldAQhcNGaOXihlf7Avz1T+/q7Adzf+pjvCZFT+bm3ZYaJ7dNUOnNTf2uj55I7BLcrDUafo3sAWySsK1xr4NPd7dP2OFJPG5DQULDxRtDP4iTs4DUmbtZowD2RUdDQLyBK8Zwj18WbGLAXQfOtoX5itgyZZ3psLJrqdS0AIZiA+suDODgespr+12qkAywpYsFrOjGmK28caOPyi9q8UQt5wUXSDA+q6Z5/7DLuQiZ5A X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(176510541525296); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM5PR08MB2522; BCL:0; PCL:0; RULEID:; SRVR:DM5PR08MB2522; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 4:p/hVbl9SudZ42DG29Z/EZRjNALFNk1F0t6wmPenI7kshjuvbJ2WxlxEElplZGMda6xOyielu2xJ22t9ytaYUvao0WaYOpqde/PSGtecNTXEiTeqqXXiVcOXeFIYuOEYM88fAvY0tmaTpTOrXI1iLs6L3+9KYJXGuNREnF2HqND8kuEmUgM3ZssYXjItXCscD55yKl2PVysyrfdPMUYr1/Khizl6zr9X1rFZ4I/AACfri4x5Ubr4IoCH9CnG49gzCxye0oQuazUlB1EEqthLkG5/BMt0QJxZy/eI1UGCVL59p1QuBPiFUGtgilQonbr3l1b83QUE2aSZrfu7o97rzMYXanrRY4GMXUvuxkrlNx6xiTY/4MfnsoJnh8es+uTGTOJBZLDkPG1u+MYdgEgfYDCqWl4QdU4KgMUeIm8W9yP7qqPSVmxAsPnsfrkkTi0iD X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(4001350100001)(5001770100001)(105586002)(47776003)(305945005)(77096005)(2906002)(66066001)(2201001)(65806001)(15975445007)(31696002)(81166006)(86362001)(88552002)(42186005)(65956001)(75432002)(81156014)(68736007)(2950100001)(31686004)(92566002)(33646002)(50466002)(7846002)(97736004)(5660300001)(101416001)(8676002)(106356001)(76176999)(107886002)(7736002)(50986999)(64126003)(23746002)(83506001)(586003)(89122001)(189998001)(230783001)(54356999)(19580395003)(2501003)(6116002)(230700001)(65826007)(36756003)(90282001)(3846002)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB2522; H:[10.211.135.36]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM5PR08MB2522; 23:8Uh2BR7PDWhpZqbe6PVb53oRO42p77TKH+6CN?= =?Windows-1252?Q?t5u2L4cP4uiJpQECOOWbbuuTmgFBvkXSHR+9ZPku/aH5l55iZNSsp706?= =?Windows-1252?Q?Cy1vM/H9oPtq3i60FsyY+T6eXLHsKF+gAvaSwABb7762QUOZaIJwgz+K?= =?Windows-1252?Q?1ejzOWO2sY8mX3uI8QsTu0xmpIG+ZMphv2ZncVJcbsCFrwX+xLGcyF1D?= =?Windows-1252?Q?iUQHwlEKMRXwpodxCipWhAyfTVwOoVQ77LcEzw6Qq8jPunYhK3J+KmNQ?= =?Windows-1252?Q?nGvuMgrwO7AyO5EqEKcOtj2OVj0YdZ9ztv2KX6WdmTKniGmPTtyIX4Rb?= =?Windows-1252?Q?//B3rqFmcQDSUoTaAzq6l9UbH1F47IekTeFOX7GzzMhrDtAgnp2ql7A2?= =?Windows-1252?Q?mHtSc3qyPAou0lsj86vGhl9IsvWTDaJ/zdx8sdZ5MQYdcDDp5/CtlpLv?= =?Windows-1252?Q?0UU8xDVpcp4XR6faW/DoYN5DsKJ35f6KOwEpBivSaIFroQc1yB/T6auN?= =?Windows-1252?Q?qXNrbhe8rUJUVtxcglkuMhPzcwPK+XFxkANOFMA1vnO2yK4QlTNAd1Vm?= =?Windows-1252?Q?KkQXw6dB0jRNS4gJcR0sCQncMSnVrK4gP9Y8q8IQfec5tgh2xHGc2BO6?= =?Windows-1252?Q?7VexRIU0x99Zn/Tllqe/v6coxtZCRDyEIQZc5LKyIKfogqek5m7MrfOL?= =?Windows-1252?Q?pvxBNw3f0HeuItre/B5zMHS5JAa9/mwrtLhJnh+qlkG8PFF+z0bfZJ7F?= =?Windows-1252?Q?QDAfuEFhyVgBBDxSpw0eYZi47JF5VNP9SNSqgnxnQ3boIuOjgKI276p5?= =?Windows-1252?Q?dpBmKAJtZGUIDn7xMuqVuWcD4h1q2LEq2yNfsiy9akRo0UVbRzLDbVyH?= =?Windows-1252?Q?KDPMI0GrOd9dqu8sx+AtrgNZip3/Nj/EOAaoNeN056Qtwd8EceS70xR7?= =?Windows-1252?Q?CGXpG1rN5rIpyIFiJq/9oKYp7dwF8I9Arc07EMml/QtATjk7dyIPhfYe?= =?Windows-1252?Q?AyRRoiYG/Zro/DkH9udKCoWq+L+ic01Lwv850HkSUiIw1x2wRw4A2SIN?= =?Windows-1252?Q?jRiIiOA0pjDZXi4cEayZFk6D1AYSXhClML8svk1eGkZGdEU3T0UwfArh?= =?Windows-1252?Q?gZ0MzunOq7U3fq3qrgxNPi99aitA5x6xwpcW96+gVlgYZjEl+qAyeFY9?= =?Windows-1252?Q?spyRD1cXVjb38GuqOT53uS7/xB3zUU8Sc5LELgFjurwlXIWHztfcX0RM?= =?Windows-1252?Q?zXntqDZDco3ExiVOWzb8b2FDAphDwCCJ8KUZj+p4Zq16AagnjAQuo6SW?= =?Windows-1252?Q?CbBdkf1I64aRRPXqmB8p5OzzUXKBS6ZXXBYW4ryLxs91kuK87jHyV7+z?= =?Windows-1252?Q?u0umi7UzAKMvqMSwtZ0X+k2Qrj4bRqToU2/7CToMKKR1RvWPpvNJ8Hgk?= =?Windows-1252?Q?78vkcZ7k2n8mrFuhamw+grNIF8pOzxJhDrx4/Yckicg98xIek2zfoTg9?= =?Windows-1252?Q?5yJvydxyb3A5EHN45Ld1AFHTsR5kTiCdydAkg6c3UiHzrDpxrN3EsMK4?= =?Windows-1252?Q?0848eYxd0AhI801n0MJLtmXENt/d1iQ/pOczwjNgGw6cznyrknsAuM8o?= =?Windows-1252?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 6:Ex9AYA2oRQW8ySmff3NAvzH1fhoYXICSLqo0Aj3TT6PEPG0F+4rgMFUyy16UUdJ9pBt7OBba8VwypPGSSzSAtgXEssAgJG7ZJMFUC0Ly+72ngbEB4irBljFNHHgcOlv8El8wMdpyFkLAHUE/gU7NrhtzCrFDeqgBZOKjqFfkclrOEQjonrVEOeATk3iaxElbew6uS/fDTaEAd+goG9wAYHh+prgu8dZUMj+xSb0SlnYYhMWUob+qrR5z5sS9ay9BREIEp+E2yUzHoEWdsT2Tulr60aTFDg55wYszmcsrnfE=; 5:LRhSD8ZiclHt6TSkpVQbNGAc0LBMHoBJ5XEcEiFvL8ybPhNOOzjfNViN/zRBMtd+QUkF2g+D3MXcJ2jbgxPVwDM23OKgc6IJFxBr9ADE+pQNjD2TzxzlLXPuGqhc8G7l9fRHUeLkpf3D51BoKd40cA==; 24:ITZBx3QqyAuZCIIcG3wrtOoOegaq+uMEo1mzOu0pCKzIIEbNbo9rrfDDlDreOwgoryySyJVlNUfF642qFXuaPbgGJ6OjCJUwxScSVm6ykHo=; 7:VVzQMt4abtg69/jyJ2HkJVVIa24JzGmEnyaBLvrsPy2jBBYR3/HV9Q4zT52B8Jb2Jbi/sYPEneSMZi+L8UWwtmiwrSIRM+QO7WuaO915FyeMuVutRq31G1ZfMnlY4P7vG6at8bvNFYwwBpZ7NFyVkBk8c4m7wqLAAdCupiy5VzzvL8G0d4+buQrB2zjuphGkzV9UQmKLQt5cUYhKSiqH1rt8pX0A99RqEoTvpiy7w39lHvg44R2P9VbLktPCvj01 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 14:23:44.3856 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2522 Archived-At: Subject: Re: [tcpm] Cubic and LTE (was RE: some editorial comments on draft-ietf-tcpm-cubic-02) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 14:55:41 -0000 Thanks, Ingemar, for your comments. Lisong On 9/14/2016 2:35 AM, Ingemar Johansson S wrote: > Hi > > A comment on section 4.3 "Difficult environments" > Based on LTE system simulation experience, I don't find Cubic to be worse than e.g. Reno, we see occasional issues with HyStart but that is another matter. With the use of proper AQM (or ECN) I can see that Cubic is actually quite well behaved. > The root problem is that LTE networks seem to be bufferbloated today, AQMs are in general not deployed or enabled. The outcome is that transport protocols with Cubic or Reno, or any other other loss based congestion control algorithm for that matter, can be claimed to operate in congestion avoidance. The results can be RTT in the order of seconds which may or may not cause problems with RTO and/or large burst losses at handover depending on the deployment of packet forwarding in LTE networks. > So at least my conclusion, based on my own experience is that Cubic is not the big problem here. > > Regards > Ingemar > >> Message: 1 >> Date: Tue, 13 Sep 2016 19:02:26 +0000 >> From: Greg White >> >> >> >> Comment 2: Section 4.3 reads: >> >> 4.3. Difficult Environments >> >> CUBIC is designed to remedy the poor performance of TCP in fast long- >> distance networks. It is not designed for wireless networks. >> >> Since a large proportion of TCP flows today cross a wireless link (WiFi or LTE), >> this statement and the heading seem kind of anachronistic. Perhaps it >> would be better to describe what some of the concerns might be with >> operation across today?s networks that are likely to contain wireless links (if >> there are any), or state what properties of a wireless network would cause >> problems for CUBIC. >> >> ************************************ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Sep 14 08:04:02 2016 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 4D8B012BB58; Wed, 14 Sep 2016 08:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_bCZzjyaI_R; Wed, 14 Sep 2016 08:03:57 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0024.outbound.protection.outlook.com [216.32.180.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB5112BDBE; Wed, 14 Sep 2016 07:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Nbs1ZVadibBSXnYqPh4uJAetJm1TM6P35hHOa9RjIwg=; b=PQtiLAeW7WmOu2OitlrbSIlj2iNBMtpPsbmXqF+T7b2lpgxKRzsVIXjDQ4JPZ4DH54ttDqV9XhMx/N531Sv3Y0JrBWXwhJ6MOo7mErhlIevv7U55K7FxO/p/eX+cWOkCls4u6U36jCmExBfa8i30Lps1gwtEIlOTnReu5wTRfLs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [10.211.135.36] (129.93.4.24) by CY4PR08MB2517.namprd08.prod.outlook.com (10.172.156.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Wed, 14 Sep 2016 14:30:16 +0000 To: Yuchung Cheng References: <95CE3E8D-EAA7-4BD5-98C9-81204D49C29F@cablelabs.com> <99c0ba81-f616-ca5e-b3bf-6030c1fa5c06@unl.edu> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Wed, 14 Sep 2016 09:30:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------03CD75BB95749C0D51A00803" X-Originating-IP: [129.93.4.24] X-ClientProxiedBy: CY1PR0601CA0025.namprd06.prod.outlook.com (10.160.162.35) To CY4PR08MB2517.namprd08.prod.outlook.com (10.172.156.138) X-MS-Office365-Filtering-Correlation-Id: bcec37be-a5b9-419a-8506-08d3dcaba60f X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2517; 2:iCe14OSm6uukMenpKcLYhcZz28fFJkkf5Lq4cCG8vnvhZ/OQWY/sh40JNEchA2L7wWa8EZ6OFaKwMUKRGT9SNdbjeBy1pvEUrTWRQVx/YtY/BTuWFhBCvhIhQ/+I2Kd5v4eRdmZ4m960ayxKpzkJk80PaNzOM8kXxBBFY6Eyi/8rB0VNO+1+DdMuanS0i66k; 3:4AnHl77Vj0ZuKISfFg7yg84NH+QyXfrxcbHj3ilTZXCLEbiV8mQiFM/8pc2bdXKXMn5/+JNJTrg1rZJiQmOra6SDNWCjbnq9lcYrsDz9FOTJVXnGEtKFvnoi+Fs+R2cv X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR08MB2517; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR08MB2517; 25:6Bhq8Hv3vDlZiov3sjjEr2sP8BaJ8xzHWZ9VOCBEK?= =?us-ascii?Q?I/Am+w02QSFYMPNJEg8Du7y633BfE6JchZ2VR/RGAsBC2akKQiAuvBgY/aai?= =?us-ascii?Q?207aljY5MrXscQnezu+yKQff5uHKGJOOFyrLBIwLhns+9Gf3+G7kdU35/CyY?= =?us-ascii?Q?422FFmUdIxG+cUmlSrSPNKSxo1cbuKK4tVZRYEMjUUJ76hAfKnPZ7D4d5oe2?= =?us-ascii?Q?+rU/IJSYxrJmw5pRLA815gufRC8f40iV3f7kWk+cUkPBq+sXkSyiVbcLz2ji?= =?us-ascii?Q?s0VDXnt9xPITT8ePpF3FMsEiOSgKwUiPB7QATzsz1fGFzFPwyPzxMpzMIxZO?= =?us-ascii?Q?GpNheR1BOihXOO3jlnHvEc8IBb5piaA1iGzonYoFLJb1q2KArzwxXFQYhnBR?= =?us-ascii?Q?2kWN/7UAK7dUxc5JNxaDvZ1nzSf77H8f5FBThrS9/jCZ9Z3af17JS1/gJX+U?= =?us-ascii?Q?I4f9d1FlaTVr6F2xWDLUR1ip1FUOq0rIwk/0/KK1SNH3NqTDbsOIVVk8Ke6F?= =?us-ascii?Q?bYPq6RuF0CDxBdOM+B5HyZ2GrDirVbWMSM/R6cWlqXUnKByZutbFKihEbc3/?= =?us-ascii?Q?XOelJWidQ8bvtGlq2vPKNcXYYqcLYZN2cMnhKRHRqUoL4kwq6pmduv8NLB1/?= =?us-ascii?Q?0N40bFHIm3txOd8yUKsoY6x4pkVAQcu00TF/YCwy5/gxwsnFKVmzElf4+MKa?= =?us-ascii?Q?rJXSYtHg6Oq1vKbLUKniamnpVjNzlFhwz8usSDHcOr852FMkHTOmFYhgy28N?= =?us-ascii?Q?zrO0T7TE3yXEo5PRwNqgpd6TnTwYaY+BPOip+vryYFj/WTD6C4Tl2nNUr68+?= =?us-ascii?Q?xm6Fg8zIDmkl2AmiwDdk4xUPhbWysqKXSZZSvuDP6U8pyUmXc0Nn4HCdKanc?= =?us-ascii?Q?Ka0bLcY6pVICBxDseMzEpONIsH0uLJMQ9+sBWTTTO81UadDJuL0r0ap0q2ZF?= =?us-ascii?Q?5ZfueHsGAr3TPexi1q7Ze/IQMdGKcQDkgyqgKo5CJX647qPOndf1Oj8m5ELA?= =?us-ascii?Q?i/QDXFhrHKVHRXRXIPDFdpl?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2517; 31:F8lO8VeZxNIvPna1avH/2qoAL7N0QG6LEWEEmvUDseYLSmsNpN3Kbp1KBcb86Z9nWFSuPAg2IFADAkdnaG1Vmf3xZi6BCTQ86BOX0MfpkpKQGLJBnQH1f0lj8M7E2isB6GULlMhGUm0AXLuOzHWQJrHml3FtCDQNrAjj06FwLoxn7uVHXGMWO9N1v3F5eMaT+LjpeOAZdqZU2vRYOA5cHqnn7Ud+FJXV1DHZydiN79w=; 20:aJ9dMKODcI1uyBLgy9XA+qnx9UB9/RSpQa0bni7w+BZwNgRXW+O27xIdJCUvXJgRWlN6JISLfPkYSqZR1OzFHjh113oheqDmmWyWX5NHV0uFNADaDnu/qVeo4/F+a+hhVFAf/vO590RBJ2hnMDxoo485ahm2La9U/t2cwgwDQyDW0B2ypWNsfRP7eh0iqKl+QcS6hE+VGbeGhbT/0fNdlFGtKhCuLzEJqk4yPsIu5zyuX1romJ+S4l/HT9fJyN3P5EJHjJhzm0AF13rRIh16UViQBwlt8nglULMgv+FOFDT9DNriTxQahtQkqhrWIbFHKKQRMKQTPYnhps19YsxhY5W+jSMX/dCZY/w0coPFr44dbSrGB68pnPcT1/4BqSXQZVDmVh5MCkKxDt8o0spkDpqX3cxzkJ3Vd0rPrc+fy6rurHABe+kISUP5OaxIadZ/DTmHF3HeCBSaEDKjTTN0Yci5b9SNI/BHZva+fqhCMJzB8IoqYX/Z4qUAhKHwzuhN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(176510541525296); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY4PR08MB2517; BCL:0; PCL:0; RULEID:; SRVR:CY4PR08MB2517; X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2517; 4:0lzppvLeyRkxt9Qt9jeVBRuez+gU6cVVS0tCL7j/NDikL83g+Pak+F1RooWWf6WAwhxnDeiJY0JsK6tC+Gq/7ZyZwg+1U4tT5Rl8myCrR/it4KEaUMryQniXDni+9+oTwhQaMk6lTZZpAeuveUJggBNdSUxBhGiTOBgJ46ibYNkljaJuFPPBak2T8S6lopEzFd7YAssLr3WseeqX80TdrA2W+4+dpmS6KsnGnhZoe5jDHArV+Jy4adfzEIak27jfod0ykOukzQ3lMmwdhreFyUbBI5UsdCF12woJjVS9eBkebHT7nwj3vzSvyHda6Nr2i0kqAMUMT4Pbk7a58ZHyfqm7oR2ri0rWS1xFCphBzQ0w9UPOj0KmX8WhJ1ESg8iKFvfD3Jx8RlOkXR9XValEyW3DdrpFHdyiKUACByhvkRymewblbb2zzWWMhqAZYKmN X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(199003)(377454003)(189002)(24454002)(83506001)(97736004)(92566002)(84326002)(512874002)(230783001)(4001350100001)(6116002)(101416001)(31696002)(3846002)(36756003)(5660300001)(88552002)(15975445007)(90282001)(31686004)(2906002)(33646002)(110136003)(19617315012)(8676002)(4326007)(42186005)(7906003)(89122001)(93886004)(81156014)(65806001)(65956001)(64126003)(106356001)(16236675004)(54356999)(105586002)(76176999)(50986999)(189998001)(66066001)(2950100001)(81166006)(86362001)(75432002)(19580405001)(586003)(7846002)(65826007)(68736007)(77096005)(7736002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR08MB2517; H:[10.211.135.36]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR08MB2517; 23:82pX6ARaBjIQvt/lrPKZ3jX0LmEBGfmjZ6JqX0Zr3?= =?us-ascii?Q?9Y4Fs0hBx/Q83K14fHxbvHCMZ1d4evRDTcc6eHh2mVXTTAK2HKx4j+ma/85p?= =?us-ascii?Q?s2k7ChzRv2zpqJ+ggwY40F/gOMtmT9PK34neMtjKCYyudxj2J8iii5skV94e?= =?us-ascii?Q?IWCS/y/K0krjc7DhAS9qq/wYs+uvq6FZILf/BRnrOlKgMeA2xl0xAk8uQUIs?= =?us-ascii?Q?EOoaGbgkTzL+vMumfKQVNXqK0SGEMzzUN6+lUCXog7KqDy4eHgVfbKII0neZ?= =?us-ascii?Q?egBfRAYPA/UBJah5e9kmHgxrZAGVYq3+1RBUDtp6nSrdXgfjDklWQYlSl1FN?= =?us-ascii?Q?rj83Q5tB5j+Xl7gh3PZ9ExoHZh74VOayZnljAcjAESDlmkpzCnqAuwPWp4We?= =?us-ascii?Q?r+X+5lo8UMfsnnKSnCzYPWc/lT3RqzR1ykmPye6BYC04PC5k1MkQ5TMbVX6x?= =?us-ascii?Q?Yhs/pAdwhMzBY4nRy8a13JCJwbSNznZTOrCQAMdP8YGzcRQnJYHELLdpzi/0?= =?us-ascii?Q?fRFh+YbWanZanFqjZL5H7ttsmLck8Nd8DZ+Cl/Ma5kIyjg756ohcbVPe+k1Y?= =?us-ascii?Q?mJmvz7LP7ulfpZlQSfQ64dKa3Q7OIcovJUGZSLYcD6xD2gJAZr7EI1HCruW/?= =?us-ascii?Q?Nhlp3lziOPwEM34VPq9ARju7z9JZwZAuyDsNfPxRoxQk9J7tzP9M27liQXLi?= =?us-ascii?Q?4JHCBksHaSq76rBdmgryjy8DVBUNEN/XfYuWARpZrv80yqI7TCp/+JK+iU4u?= =?us-ascii?Q?uT5xxi1e1N2x/wt4ljxEVAxbHxQImkAsaEnqEB+8XJqjYeWr4IXhlPnM44Hg?= =?us-ascii?Q?I9c9tMw78/L75zMNKfd78+lKDfD0N7DZbyPA6cGob9hqjWSW+xeqoIlXANzr?= =?us-ascii?Q?ijR7yAnOpn88Y8Ha9ZMP1kgcXtkuYszRiwy8cyzr7YRZV3ula3QOy3LG0KJO?= =?us-ascii?Q?u9dGYiUK/lOW/9Y0htqWHF56z2UwKnmQ9/0cR2+jjreJmPIEU3QPicwQDiqi?= =?us-ascii?Q?4CojnAGbd0mDxUKUWaG0Tq8q5+V0CaRmm3g0Py0sXplVyY/QWjRdfhArSb6W?= =?us-ascii?Q?Twsj0yVMBL4SxuZ/vUZyalDszMrwprgGim8QzoRC1XxpLZezx4p8JPCm9BoH?= =?us-ascii?Q?vBM/Gz1jttYtWJtbHkXOFRkSMBKYUTFQCZOO8p2R92YB7AAuaq06NFLkgSDJ?= =?us-ascii?Q?5wrHVuNo+xOQaDmssdmcGx9u4bLbY3+PqToTHah3aKbSmFvQu2AQ02f8IlR+?= =?us-ascii?Q?bT8X5+DCNOFdD31fIL+NNp6FTLPn0dzbH6A05vUq0F4Qj4M+tn2gaplepiHb?= =?us-ascii?Q?F284Gxd88VeOXT//BgKdeeP8OrJZs5QRSDwlobKiAiHQQ7NRU1gFg/zXv1WQ?= =?us-ascii?Q?HuZgy0CO33jiu79e+gV+0MXo3b54oAgUxsn8pYBw3jfhfxpA1SzfkHH/34UP?= =?us-ascii?Q?IFQNA/rFRmI3Wo4Ci/8yRLWle0MKjo=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2517; 6:gI6oVdQeQSMOsl3h7ip/kSo5K7dMzat9THn1qJOXi94ZGRXwRyBRcGT7/dRPsX0X18ihayxPq0gl7v1pdviQn5Te4CtppU2jloCUo+5qqNTXDKA6vOSkbZWQDX1I+6hdyiA1JguZMk8H6qwJn3l1YVd0FDxP9mdqF5OX9grQAxxMyPZsSyBLC+KfBzOf9zFgbFkj1Y6/YtVtlmIdodDNiiAxA4J769gDl23BtK9QoB0IQoBV1PNM45S4KSmPsUtHkbTRCO9+72I/s4+vV34L0zT4Qh55ZsZYjb66W5apjlM=; 5:g/uuGP/xC263e28varSAwmYf1viSl8SZtOO0SaxaW96IGXwj2IgRsPsPGuxtrflf9t6ykpjIP4qia+A6NpUN/SWx2X2M7duUltXZcJ9B+TOHHclh2MzpqWAC8M7+VTCncZxEAMeOCB0m0NHVCf83NA==; 24:bEUHNsxen+7iSeizFLkEnsIdM6xzm5oMcFdHj6K6YgQaByUcdOrMTgLitI3UgjkPVaBQcaLJhzHOILYEJ5w7vjGdP9vslLwxSUd7SP6BT2I=; 7:4P3Qpo9TaJ/pWrSzq05JOyuIHjjiqHXBeXp92AHM/54hnOH20J9yLFeBbNj44ecJGNwIfkd8qMg9Ih0Q7JjVHsCBp8P45Bqhkuvr8I66+KLCftw1VDat10OprythUMknChMs62tIiiT65YQDyM9DZ2L5XBk7B++aAWjBn65lXlgdbpuNMITJuYWeMi3bLqPoX/fz8ezvY6AGxKO4V4UqFUP3AcJ9W/EnCYXMoaF6d4WIweiz/GvbUPMyL0tjGaPQ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 14:30:16.9472 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR08MB2517 Archived-At: Cc: tcpm IETF list , "draft-ietf-tcpm-cubic@ietf.org" Subject: Re: [tcpm] some editorial comments on draft-ietf-tcpm-cubic-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 15:04:01 -0000 --------------03CD75BB95749C0D51A00803 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Thanks, Yuchung. I think you are right that we should change it to "Must Not". Lisong On 9/13/2016 11:19 PM, Yuchung Cheng wrote: > > > On Tue, Sep 13, 2016 at 7:26 PM, Lisong Xu > wrote: > > Thanks, Yuchung! If the idle time is very short, it might be ok > to include the idle time? > Lisong > > Sure but to me a SHOULD means there is some legit cases where we would > include idle time. Since any system has finite timer granularity, the > case you mentioned does not violate MUST imo. > > > > > On 9/13/2016 4:39 PM, Yuchung Cheng wrote: > > On Tue, Sep 13, 2016 at 12:02 PM, Greg White > > wrote: > > Seeing Marcelo’s comments prompted me to read the draft as > well. I have just a few comments, and also I found a > couple of typos. > > > > > > Comment 1: Section 4.8 contains a lower case “should > notâ€. This seems like it should be a “SHOULD NOTâ€. > > > > In cases of idle periods, t in Eq. 1 SHOULD NOT > include the > > idle time; otherwise, W_cubic(t) might be very high > after restarting > > from a long idle time. > > why SHOULD vs MUST? I can't think of any corner case that we'd > want to > include the idle time. > > > > > > > > Comment 2: Section 4.3 reads: > > > > 4.3. Difficult Environments > > > > CUBIC is designed to remedy the poor performance of > TCP in fast long- > > distance networks. It is not designed for wireless > networks. > > > > Since a large proportion of TCP flows today cross a > wireless link (WiFi or LTE), this statement and the > heading seem kind of anachronistic. Perhaps it would be > better to describe what some of the concerns might be with > operation across today’s networks that are likely to > contain wireless links (if there are any), or state what > properties of a wireless network would cause problems for > CUBIC. > > > > > > > > Comment 3: Section 4.5 states: > > > > In case that there is congestion collapse, CUBIC > behaves likely > > standard TCP ... > > > > I believe that the whole point of congestion avoidance > algorithms such as CUBIC is to prevent congestion > collapse. (Also note the typo “likely†in that > sentence.) Maybe this would be better written as: > > > > With regard to the potential of causing congestion > collapse, > > CUBIC behaves like standard TCP ... > > > > > > > > Typo: > > > > Section 3.2, first sentence reads: > > > > When receiving an ACK in congestion avoidance, we first > check whether > > the protocol is in the TCP region or not. > > > > I believe it should be: > > > > When receiving an ACK in congestion avoidance, we > first check whether > > the protocol is in the TCP **friendly** region or not. > > > > > > > > Best Regards, > > Greg > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > --------------03CD75BB95749C0D51A00803 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Thanks, Yuchung. I think you are right that we should change it to "Must Not".

Lisong



On 9/13/2016 11:19 PM, Yuchung Cheng wrote:


On Tue, Sep 13, 2016 at 7:26 PM, Lisong Xu <xu@unl.edu> wrote:
Thanks, Yuchung!  If the idle time is very short, it might be ok to include the idle time?
Lisong
Sure but to me a SHOULD means there is some legit cases where we would include idle time. Since any system has finite timer granularity, the case you mentioned does not violate MUST imo. 




On 9/13/2016 4:39 PM, Yuchung Cheng wrote:
On Tue, Sep 13, 2016 at 12:02 PM, Greg White <g.white@cablelabs.com> wrote:
Seeing Marcelo’s comments prompted me to read the draft as well.  I have just a few comments, and also I found a couple of typos.





Comment 1:  Section 4.8 contains a lower case “should notâ€.  This seems like it should be a “SHOULD NOTâ€.



    In cases of idle periods, t in Eq. 1 SHOULD NOT include the

    idle time; otherwise, W_cubic(t) might be very high after restarting

    from a long idle time.
why SHOULD vs MUST? I can't think of any corner case that we'd want to
include the idle time.







Comment 2:  Section 4.3 reads:



4.3.  Difficult Environments



    CUBIC is designed to remedy the poor performance of TCP in fast long-

    distance networks.  It is not designed for wireless networks.



Since a large proportion of TCP flows today cross a wireless link (WiFi or LTE), this statement and the heading seem kind of anachronistic.   Perhaps it would be better to describe what some of the concerns might be with operation across today’s networks that are likely to contain wireless links (if there are any), or state what properties of a wireless network would cause problems for CUBIC.







Comment 3: Section 4.5 states:



    In case that there is congestion collapse, CUBIC behaves likely

    standard TCP ...



I believe that the whole point of congestion avoidance algorithms such as CUBIC is to prevent congestion collapse.  (Also note the typo “likely†in that sentence.)  Maybe this would be better written as:



    With regard to the potential of causing congestion collapse,

    CUBIC behaves like standard TCP ...







Typo:



Section 3.2, first sentence reads:



   When receiving an ACK in congestion avoidance, we first check whether

    the protocol is in the TCP region or not.



I believe it should be:



    When receiving an ACK in congestion avoidance, we first check whether

    the protocol is in the TCP **friendly** region or not.







Best Regards,

Greg






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

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



--------------03CD75BB95749C0D51A00803-- From nobody Sat Sep 17 21:55:06 2016 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 D4D5D12B10B; Sat, 17 Sep 2016 21:55:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147417450483.3031.11281645638510602098.idtracker@ietfa.amsl.com> Date: Sat, 17 Sep 2016 21:55:04 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 04:55:05 -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 of the IETF. Title : RACK: a time-based fast loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Filename : draft-ietf-tcpm-rack-00.txt Pages : 14 Date : 2016-09-17 Abstract: This document presents a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment"). RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option. It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 28 09:12:02 2016 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 14C9012B20E for ; Wed, 28 Sep 2016 09:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuaKIGJL3dNu for ; Wed, 28 Sep 2016 09:11:59 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 4B00A12B200 for ; Wed, 28 Sep 2016 09:11:59 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id g67so51842710qkd.0 for ; Wed, 28 Sep 2016 09:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=TmJlyyYScw2GNJMG+mCgkuJTSVppM5twzJEiVItdH1s=; b=zIoXq9TpklGzYHX4OJ8EOPBcPetJ8jVaDN4rkOV5UhFbRPIHFS1OWeiUj6flEQCIr2 Ch556nR2AqIdF/mx2qKegEOjU7uZ01n9tfhM4F+kMMMkTmADzCo9X5lwjmNmr6lMVRlG LGXIM8Nld5d0AH/h/dZMeFr4RpcMjKaaoxele2q5a7N+u5VQXx6SkU2qEGATwSlnx3Ot V0HghzUhHHT7oJaInZmr3YwYvwJdIUOlUczPP309hd5OmsqsKytnvAOjqvaLyEAige7h u/gej2Fy/1hg03h2q+3SfbK/koB5Cei1G7tf7IEueLA5DQJdeSL0n0bbUAq9A4JgN6Ga YJyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=TmJlyyYScw2GNJMG+mCgkuJTSVppM5twzJEiVItdH1s=; b=LNaRsQ2lmEKhrOCavs+lxjeHq/SOXyM6sbTSl1+mXvdXaqPRHLRrAOVPsVlIZJsEW/ hsOyFge38NqXyKWk3TXuIiP30OQw2yIkSzmW4Q1gCFovAFfw8W3p6AqfCYtfv9ALUpp0 3VZlvlibJaS8RPBlk7uhkxgYiDGMqCcFrLIAYQFFjr8D+9RcL+xOjKXMzNlFdGFJ70jW Nz5duWuL3S0CAY8JI1BNQwVarc16u81q/shkjgyfKYporgHm9j8/lGb1nQmpcGSktuv9 hv4P+5hUVPQ3H5J8envpYZ9fyy781/wJOW3zwHQ7XO9RaeTNBB4J3c05cFa+xC+UuAr2 OImw== X-Gm-Message-State: AA6/9Rm1mOikh5bcYs2H3xZugLcaKCnQh7WlwAURJAdv3dhf6lOR0flho2I5EdvNYkrRDQ== X-Received: by 10.55.214.27 with SMTP id t27mr11590379qki.272.1475079118115; Wed, 28 Sep 2016 09:11:58 -0700 (PDT) Received: from [192.168.1.148] (user-12l31s2.cable.mindspring.com. [69.81.135.130]) by smtp.gmail.com with ESMTPSA id 62sm4212855qtg.14.2016.09.28.09.11.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Sep 2016 09:11:57 -0700 (PDT) To: tcpm@ietf.org From: Wesley Eddy Message-ID: Date: Wed, 28 Sep 2016 12:11:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] 793bis: proposed multihoming clarification from 1122 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 16:12:01 -0000 A couple of places in RFC 1122 discuss TCP behavior for source address selection on multihomed hosts. Section 4.2.4.4 has non-requirements language in the implementation section that nebulously says "the networking software will choose an appropriate local IP address". The actual requirements-language "MUST" on how this works is in 4.2.3.7 that describes what happens more explicitly. In 793bis, my proposal is to condense material from these 2 different sections together more clearly, into: For an active OPEN call, a specified "local IP address" parameter will be used for opening the connection. If the parameter is unspecified, TCP MUST ask the IP layer to select a local IP address before sending the (first) SYN. See the function GET_SRCADDR() in Section 3.3.4.3 of RFC1122. I think that's basically just an editorial change, but wanted to make sure the WG sees it. My plan is to include this (or whatever improved version the WG suggests) in the next revision of 793bis. Any feedback is appreciated. From nobody Wed Sep 28 09:59:57 2016 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 89F1F12B1EE for ; Wed, 28 Sep 2016 09:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.216 X-Spam-Level: X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] 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 oyGW8evOPReb for ; Wed, 28 Sep 2016 09:59:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 ED19D12B28B for ; Wed, 28 Sep 2016 09:58:38 -0700 (PDT) Received: from [128.9.184.198] ([128.9.184.198]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u8SGvuGs006181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Sep 2016 09:57:57 -0700 (PDT) To: Wesley Eddy , tcpm@ietf.org References: From: Joe Touch Message-ID: <529aa92e-4039-800e-308c-d181e2c59ffc@isi.edu> Date: Wed, 28 Sep 2016 09:57:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 793bis: proposed multihoming clarification from 1122 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 16:59:55 -0000 Hi, Wes, Do we also need language that says that if the parameter IS specified, it MUST NOT be overwritten (e.g., by the process below)? I'm not sure if anyone does this, but I'm increasingly seeing implementation discussions where developers do virtually anything that isn't explicitly prohibited. Joe On 9/28/2016 9:11 AM, Wesley Eddy wrote: > A couple of places in RFC 1122 discuss TCP behavior for source address > selection on multihomed hosts. > > Section 4.2.4.4 has non-requirements language in the implementation > section that nebulously says "the networking software will choose an > appropriate local IP address". The actual requirements-language > "MUST" on how this works is in 4.2.3.7 that describes what happens > more explicitly. > > In 793bis, my proposal is to condense material from these 2 different > sections together more clearly, into: > > For an active OPEN call, a specified "local IP address" > parameter will be used for opening the connection. If the > parameter is unspecified, TCP MUST ask the IP layer to select > a local IP address before sending the (first) SYN. See the > function GET_SRCADDR() in Section 3.3.4.3 of RFC1122. > > I think that's basically just an editorial change, but wanted to make > sure the WG sees it. My plan is to include this (or whatever improved > version the WG suggests) in the next revision of 793bis. > > Any feedback is appreciated. > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Sep 28 10:11:04 2016 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 5796B12B1F0 for ; Wed, 28 Sep 2016 10:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZtx343oErMD for ; Wed, 28 Sep 2016 10:11:01 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 CA8AF12B1B7 for ; Wed, 28 Sep 2016 10:11:00 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z190so53400475qkc.3 for ; Wed, 28 Sep 2016 10:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=2MmK2+TSw01FcWwlkvVaNF6keSGsYhwMKd24TtfuR14=; b=oAwW5c8psOcnMLanOPTGuFvQYf5BD8e7kia4u+rjJakN+wusSlb77iKLSz0WyhzjYl CKCnBqA9BZotna8G53Myf1rvngiG5oHqZVvJU5Bm3ao0dQ2bh3o6OLtBw3SopERg5noK 3tTxS9gYOfQt67FL5zeWXcokRDpYjGSyHcO0A4vBWODicyGbQQDmOLVAImY+uuKY7dO0 h1/0FMwNwgH0GrOB9Hn6LOoAsb1lXaPsDnrUzZxDWz1VsVhzSBNoObHfbaFZEP9Knbfm /8aJ3hMsDZp1Xhj76tKcjEuHIzCv8dRnF23lrwafNQl3NSfvUgU0eRa/HVYow0rVqi4C LPig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2MmK2+TSw01FcWwlkvVaNF6keSGsYhwMKd24TtfuR14=; b=iDm3sHokELLrTVVqT15uqU3aABteMXmcUznwe7Ktwa+fQHlRmjWulUpXad13/K/cjn bCzF9lRLWG1Z/C3PFvBhU/dRZ2cI0Pi6wjxa9/1PkRKJtuyo6lTAmq004VsK41wXqoft RPlmGeR9hwGkLeSrWmKzQs68IiivncUaNZ7G7zHA4s8M+GKe7bcM3pFTkhXuGqO9jyGo gB73ai71A8in2hw81etgSWQRyROiaiQ35uvV4FMtL+mxlogf+i9lOOV8gO3Dr9ayWyMB KIhjmJTUOCOrOOy+tHQBJxf7czilNMT8000etCDCjJ24d56f24HdsUY+oQlS2uq/OErW RLkw== X-Gm-Message-State: AA6/9RnBCQ+7Z0AbsEK+ZWVle9bkI2+HGM3T1VtH0WboLyAzmG9GXGx4hPrIzGjcWJQP9g== X-Received: by 10.55.174.2 with SMTP id x2mr36432638qke.63.1475082659972; Wed, 28 Sep 2016 10:10:59 -0700 (PDT) Received: from [192.168.1.148] (user-12l31s2.cable.mindspring.com. [69.81.135.130]) by smtp.gmail.com with ESMTPSA id a25sm878527qtb.22.2016.09.28.10.10.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Sep 2016 10:10:59 -0700 (PDT) To: Joe Touch , tcpm@ietf.org References: <529aa92e-4039-800e-308c-d181e2c59ffc@isi.edu> From: Wesley Eddy Message-ID: Date: Wed, 28 Sep 2016 13:10:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <529aa92e-4039-800e-308c-d181e2c59ffc@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] 793bis: proposed multihoming clarification from 1122 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 17:11:03 -0000 We could change "will be used" to "MUST be used". On 9/28/2016 12:57 PM, Joe Touch wrote: > Hi, Wes, > > Do we also need language that says that if the parameter IS specified, > it MUST NOT be overwritten (e.g., by the process below)? > > I'm not sure if anyone does this, but I'm increasingly seeing > implementation discussions where developers do virtually anything that > isn't explicitly prohibited. > > Joe > > > On 9/28/2016 9:11 AM, Wesley Eddy wrote: >> A couple of places in RFC 1122 discuss TCP behavior for source address >> selection on multihomed hosts. >> >> Section 4.2.4.4 has non-requirements language in the implementation >> section that nebulously says "the networking software will choose an >> appropriate local IP address". The actual requirements-language >> "MUST" on how this works is in 4.2.3.7 that describes what happens >> more explicitly. >> >> In 793bis, my proposal is to condense material from these 2 different >> sections together more clearly, into: >> >> For an active OPEN call, a specified "local IP address" >> parameter will be used for opening the connection. If the >> parameter is unspecified, TCP MUST ask the IP layer to select >> a local IP address before sending the (first) SYN. See the >> function GET_SRCADDR() in Section 3.3.4.3 of RFC1122. >> >> I think that's basically just an editorial change, but wanted to make >> sure the WG sees it. My plan is to include this (or whatever improved >> version the WG suggests) in the next revision of 793bis. >> >> Any feedback is appreciated. >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Sep 28 10:21:25 2016 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 68D0B12B2A2 for ; Wed, 28 Sep 2016 10:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.216 X-Spam-Level: X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] 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 XG_5NQytP6Hl for ; Wed, 28 Sep 2016 10:21:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 5986312B2B7 for ; Wed, 28 Sep 2016 10:21:18 -0700 (PDT) Received: from [128.9.184.198] ([128.9.184.198]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u8SHK4tv013193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Sep 2016 10:20:05 -0700 (PDT) To: Wesley Eddy , tcpm@ietf.org References: <529aa92e-4039-800e-308c-d181e2c59ffc@isi.edu> From: Joe Touch Message-ID: <393e2311-a7a4-c1ac-2e3b-f0d4f393ed0b@isi.edu> Date: Wed, 28 Sep 2016 10:20:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 793bis: proposed multihoming clarification from 1122 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 28 Sep 2016 17:21:24 -0000 Yes - that does it. ;-) On 9/28/2016 10:10 AM, Wesley Eddy wrote: > We could change "will be used" to "MUST be used". > > > On 9/28/2016 12:57 PM, Joe Touch wrote: >> Hi, Wes, >> >> Do we also need language that says that if the parameter IS specified, >> it MUST NOT be overwritten (e.g., by the process below)? >> >> I'm not sure if anyone does this, but I'm increasingly seeing >> implementation discussions where developers do virtually anything that >> isn't explicitly prohibited. >> >> Joe >> >> >> On 9/28/2016 9:11 AM, Wesley Eddy wrote: >>> A couple of places in RFC 1122 discuss TCP behavior for source address >>> selection on multihomed hosts. >>> >>> Section 4.2.4.4 has non-requirements language in the implementation >>> section that nebulously says "the networking software will choose an >>> appropriate local IP address". The actual requirements-language >>> "MUST" on how this works is in 4.2.3.7 that describes what happens >>> more explicitly. >>> >>> In 793bis, my proposal is to condense material from these 2 different >>> sections together more clearly, into: >>> >>> For an active OPEN call, a specified "local IP address" >>> parameter will be used for opening the connection. If the >>> parameter is unspecified, TCP MUST ask the IP layer to select >>> a local IP address before sending the (first) SYN. See the >>> function GET_SRCADDR() in Section 3.3.4.3 of RFC1122. >>> >>> I think that's basically just an editorial change, but wanted to make >>> sure the WG sees it. My plan is to include this (or whatever improved >>> version the WG suggests) in the next revision of 793bis. >>> >>> Any feedback is appreciated. >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Sep 28 23:13:21 2016 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 79AC012B074 for ; Wed, 28 Sep 2016 23:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHE_50tXRo8m for ; Wed, 28 Sep 2016 23:13:16 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 253BF12B05D for ; Wed, 28 Sep 2016 23:13:16 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w72so4939999wmf.1 for ; Wed, 28 Sep 2016 23:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=CYPoHo+bjf+lxxFfasvEShDwf2qYnrxVVpDASsBVzeY=; b=TUuhZvo0MhEmIhePD/gl+Jlg0XQaSFPEjIhvbf0xRAUPKdcAwOB0BCFUBQ0a9aVwIo sf1HoCX2PE/P+vhGELfNwYm5cTPfEtGm3YaUoBqRuALaLyFF74MX7bQta9Unu8Wn/mqq e0rRuojZS92zIXMlcjVnjF7k0LizjFEohwomD8+aEZ/1Ya6t6ZLwP0QQdIkacRpNqFLY IAP55rFDLOoQrVZaQEIpuOUbtskeSdIhJEJj9QHYb10cCZI70/Ke1Lt56TUb+61ZAAkE Hl28G3G5YzXLYeQitZEFNDiYJprSjjxCUd6b6jYilP2957O7ERNuOi0GeW54z34Rc6ZB JRcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=CYPoHo+bjf+lxxFfasvEShDwf2qYnrxVVpDASsBVzeY=; b=gi+HDUDpezlLenjfzhEopPhRLqGBfrsi66AxrEHweey3dl4TNh9WfyHgznocYAZe5Y Ex3FJLc+IXRojL3RmF8RaiM/OKVf6DJH2N3VXebSmPRtUb4NRNAHa8TOBCteLFynIH9F QSsrPNajFlD2IgGS6Ggpx2A1S4FSmaDL3xcZRl7ACrAS6Io9lMKekm03UY4eFwYRpgWS LrRwBeDQGup2bzFL0uKv5TShZIjHjwqs85wSLwoxsFTvF+vEWh3wDI6md/rvWeV7RZYo TUGIWMfDRzR3Ze+k4GEx8UY3lOPqZq/tgqxyVl50/ZBeTX1/dh/LhIIEe8a4WrZsIDz2 rssw== X-Gm-Message-State: AA6/9RmpSlGOfZB0XB1THoW91sjhSi3CKjtMx7PhReNrPR42irWj8QJVo1wKjlJbAMFz5Itp X-Received: by 10.194.173.168 with SMTP id bl8mr20125354wjc.105.1475129594524; Wed, 28 Sep 2016 23:13:14 -0700 (PDT) Received: from Macintosh-6.local ([2001:720:410:1010:2d78:fd53:9beb:aac7]) by smtp.gmail.com with ESMTPSA id md9sm12173765wjb.20.2016.09.28.23.13.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Sep 2016 23:13:13 -0700 (PDT) To: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org From: marcelo bagnulo braun Message-ID: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> Date: Thu, 29 Sep 2016 08:13:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 06:13:19 -0000 Hi, Does cubic assumes that there is a different phase when the connection starts? i.e. slow start? It may be worthwhile stating this explicitly? In the current draft, it always reffers to a packet loss event, but I couldnt find how is the packet loss detected i.e. via duplicated ACKs or via timeout. Is the reaction of cubic the same in both cases? Does it reduces the window to 1 MSS and enters in slow start if the loss is detected via a timeout? Sorry if this is already in the draft and i missed it. Regards, marcelo From nobody Thu Sep 29 07:50:23 2016 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 B40D012B1D4; Thu, 29 Sep 2016 07:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.216 X-Spam-Level: X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] 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 axs4tAssH5II; Thu, 29 Sep 2016 07:50:21 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 9436B12B172; Thu, 29 Sep 2016 07:50:21 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u8TEnf9X019108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 Sep 2016 07:49:43 -0700 (PDT) To: marcelo bagnulo braun , tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> From: Joe Touch Message-ID: <0a48dabd-713a-f86b-311a-2937c37d1833@isi.edu> Date: Thu, 29 Sep 2016 07:49:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 14:50:22 -0000 On 9/28/2016 11:13 PM, marcelo bagnulo braun wrote: > Hi, > > Does cubic assumes that there is a different phase when the connection > starts? i.e. slow start? It may be worthwhile stating this explicitly? > > In the current draft, it always reffers to a packet loss event, but I > couldnt find how is the packet loss detected i.e. via duplicated ACKs > or via timeout. A duplicate ACK does not necessarily imply a loss - the Internet is not guaranteed to avoid duplication. Joe From nobody Thu Sep 29 08:06:08 2016 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 7EC4D12B14B; Thu, 29 Sep 2016 08:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 gpqAyIXA2amH; Thu, 29 Sep 2016 08:06:02 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA8512B0FC; Thu, 29 Sep 2016 08:06:02 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id u8TEBap1005853; Thu, 29 Sep 2016 09:11:36 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: David Borman In-Reply-To: <0a48dabd-713a-f86b-311a-2937c37d1833@isi.edu> Date: Thu, 29 Sep 2016 10:05:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7292BAA9-C327-4C7E-908D-F266712CA440@weston.borman.com> References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> <0a48dabd-713a-f86b-311a-2937c37d1833@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3226) Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 15:06:06 -0000 > On Sep 29, 2016, at 9:49 AM, Joe Touch wrote: >=20 > On 9/28/2016 11:13 PM, marcelo bagnulo braun wrote: >> Hi, >>=20 >> Does cubic assumes that there is a different phase when the = connection >> starts? i.e. slow start? It may be worthwhile stating this = explicitly? >>=20 >> In the current draft, it always reffers to a packet loss event, but I >> couldnt find how is the packet loss detected i.e. via duplicated ACKs >> or via timeout.=20 >=20 > A duplicate ACK does not necessarily imply a loss - the Internet is = not > guaranteed to avoid duplication. More commonly, reordering of packets will cause dup acks to be = generated. That=E2=80=99s why implementations require multiple duplicate ACKs = before inferring that there was a packet loss. -David Borman >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Sep 29 08:24:59 2016 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 F1EED12B337; Thu, 29 Sep 2016 08:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 yyZbTci2nZt7; Thu, 29 Sep 2016 08:24:56 -0700 (PDT) Received: from s2.neomailbox.net (s2.neomailbox.net [5.148.176.60]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F21D12B308; Thu, 29 Sep 2016 08:24:56 -0700 (PDT) To: Joe Touch , tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> <0a48dabd-713a-f86b-311a-2937c37d1833@isi.edu> From: marcelo bagnulo Message-ID: Date: Thu, 29 Sep 2016 17:24:47 +0200 MIME-Version: 1.0 In-Reply-To: <0a48dabd-713a-f86b-311a-2937c37d1833@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 15:24:58 -0000 El 29/09/16 a las 16:49, Joe Touch escribió: > > On 9/28/2016 11:13 PM, marcelo bagnulo braun wrote: >> Hi, >> >> Does cubic assumes that there is a different phase when the connection >> starts? i.e. slow start? It may be worthwhile stating this explicitly? >> >> In the current draft, it always reffers to a packet loss event, but I >> couldnt find how is the packet loss detected i.e. via duplicated ACKs >> or via timeout. > A duplicate ACK does not necessarily imply a loss - the Internet is not > guaranteed to avoid duplication. :-) I know that much. Clearly, i failed to formulate my question properly. Let me try again. RFC5681 defines two different behaviour when a "loss" is detected/inferred. If the loss is detected by a timeout, the cwnd is set to 1 MSS If the loss is detected via a number of dup ACKS, the cwnd is set to about half its value (omitting the specific details, can be found in fast retransmit and fast recovery, section 3.2 of RFC5681) Now, draft-ietf-tcpm-cubic mentions generically a packet loss event (unless i missed something), so i was wondering if it means a packet loss detected by the means of dup acks or a packet loss detected by the means of a timeout. I assume it is based on dup acks, but i couldnt find it stated explicitly. I understand the the reaction of a cubic sender to a timeout is still the same as the one described in rfc5681, i.e. cwnd is set to 1 mss, but i wanted to confirm that (and possibly suggest that it should be mentioned explicitly in the document) Hope this clarifies and apologies for the poorly phrased question before. Regards, marcelo > Joe > > From nobody Thu Sep 29 10:00:29 2016 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 8FB8712B1A7; Thu, 29 Sep 2016 10:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.216 X-Spam-Level: X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] 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 6Wxb33Ky3QyE; Thu, 29 Sep 2016 10:00:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 33AFF12B1D3; Thu, 29 Sep 2016 10:00:14 -0700 (PDT) Received: from [10.123.78.255] (usc-secure-wireless-206-255.usc.edu [68.181.206.255]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u8TGxZtB003663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 Sep 2016 09:59:45 -0700 (PDT) To: marcelo bagnulo , tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> <0a48dabd-713a-f86b-311a-2937c37d1833@isi.edu> From: Joe Touch Message-ID: Date: Thu, 29 Sep 2016 09:59:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 17:00:27 -0000 On 9/29/2016 8:24 AM, marcelo bagnulo wrote: > El 29/09/16 a las 16:49, Joe Touch escribió: >> >> On 9/28/2016 11:13 PM, marcelo bagnulo braun wrote: >>> Hi, >>> >>> Does cubic assumes that there is a different phase when the connection >>> starts? i.e. slow start? It may be worthwhile stating this explicitly? >>> >>> In the current draft, it always reffers to a packet loss event, but I >>> couldnt find how is the packet loss detected i.e. via duplicated ACKs >>> or via timeout. >> A duplicate ACK does not necessarily imply a loss - the Internet is not >> guaranteed to avoid duplication. > > :-) > I know that much. > > Clearly, i failed to formulate my question properly. Let me try again. > > RFC5681 defines two different behaviour when a "loss" is > detected/inferred. > > If the loss is detected by a timeout, the cwnd is set to 1 MSS > > If the loss is detected via a number of dup ACKS, the cwnd is set to > about half its value (omitting the specific details, can be found in > fast retransmit and fast recovery, section 3.2 of RFC5681) This is part of the point, though - these two indications are not quite the same, and might not be treated the same. I appreciate your question, but I'm pointing out that there might be two answers. Joe From nobody Thu Sep 29 10:21:18 2016 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 D106912B0AF for ; Thu, 29 Sep 2016 10:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCLSFuw322c5 for ; Thu, 29 Sep 2016 10:21:14 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 0AA0512B1BE for ; Thu, 29 Sep 2016 10:21:14 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id b4so42156796wmb.0 for ; Thu, 29 Sep 2016 10:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=fffl8rzgdlH6HwwU1MW1TLouigfUxnr28XZgnrXJbl8=; b=1fu57k115hKiEFztaUL8LF9zmTTqLzgm1JhhUhykcX3dc+Cj5JswCiQbUBEfs5l+LM MEl/JiWwfu0QnKR0q2ZfDLIuMJdivwyDZ+Ob/OaColLuvPs/4kzvilWbQxpnTYWzPFtw dcvMqURq0/LKLMQ7fldShhhzEjlCVvbDW3l4yp12cgscnhAoou5DfnKPmxFWsM/RGLRZ evrQH6orfnRhjGp4rXa49jTSkykd0rrs2E7r1sc1GjWeTZb1ckhWCi10dSxXvwV6ZRDm GEs2w1b9RxiOtxPsKYoA4PLMQhVflG3YT5shWN41S1foc6jKj6CqwN6LM/Azx+fou+hL z2Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fffl8rzgdlH6HwwU1MW1TLouigfUxnr28XZgnrXJbl8=; b=lWEjgr+tjftK8SpWbIe7c+X/G1Yg0IQ6PFfJo6sSljTKmSSAtE6WnYK0pveXEThGKm t8Kn/GcOTVANWcMB36ZKGaloFE0QRp6FeLKa0/8VL+n/3V4VLMWEWYsTIaqhcYU5CAKx dkKhkGdnH+P6jLcgwa2cF04lyCMc78IYjo/Duozq4420vfSRrXnVn7+NwjNc3JMOyzTq E+2qU1tc73dcL8uZexaG7fAMoqb31Als5vEXk4CMf18z8b96K77U3+u+EN9UDTaqlRx0 Ft4ga0PFZzJAK8qk+UixiiigQ8qgdJBUCfsgF22ykNg7OTpfJKOunkoxHMQbG8a5Ynqt k4sA== X-Gm-Message-State: AA6/9RmZwimqQNzA4M4eUL0Bpc+1fC4KE8vY/GIANIAsv/2IljVb4sJQoc7orTx6m3G39lpw X-Received: by 10.28.24.14 with SMTP id 14mr3019041wmy.107.1475169672278; Thu, 29 Sep 2016 10:21:12 -0700 (PDT) Received: from Macintosh-6.local (41.175.16.95.dynamic.jazztel.es. [95.16.175.41]) by smtp.gmail.com with ESMTPSA id a3sm15252058wjg.33.2016.09.29.10.21.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Sep 2016 10:21:11 -0700 (PDT) To: tcpm@ietf.org References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> <0a48dabd-713a-f86b-311a-2937c37d1833@isi.edu> From: marcelo bagnulo braun Message-ID: <6a7dc05c-4e33-bc4b-58e7-f0de92defcfa@it.uc3m.es> Date: Thu, 29 Sep 2016 19:21:10 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 17:21:18 -0000 El 29/09/16 a las 18:59, Joe Touch escribió: > > On 9/29/2016 8:24 AM, marcelo bagnulo wrote: >> El 29/09/16 a las 16:49, Joe Touch escribió: >>> On 9/28/2016 11:13 PM, marcelo bagnulo braun wrote: >>>> Hi, >>>> >>>> Does cubic assumes that there is a different phase when the connection >>>> starts? i.e. slow start? It may be worthwhile stating this explicitly? >>>> >>>> In the current draft, it always reffers to a packet loss event, but I >>>> couldnt find how is the packet loss detected i.e. via duplicated ACKs >>>> or via timeout. >>> A duplicate ACK does not necessarily imply a loss - the Internet is not >>> guaranteed to avoid duplication. >> :-) >> I know that much. >> >> Clearly, i failed to formulate my question properly. Let me try again. >> >> RFC5681 defines two different behaviour when a "loss" is >> detected/inferred. >> >> If the loss is detected by a timeout, the cwnd is set to 1 MSS >> >> If the loss is detected via a number of dup ACKS, the cwnd is set to >> about half its value (omitting the specific details, can be found in >> fast retransmit and fast recovery, section 3.2 of RFC5681) > This is part of the point, though - these two indications are not quite > the same, and might not be treated the same. > > I appreciate your question, but I'm pointing out that there might be two > answers. Right, agree and that i why i think that simply stating packet loss in the cubic draft without indicating how it is detected, may be less specified than what is needed. So i think we are aligned. > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From nobody Thu Sep 29 11:38:50 2016 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 E247012B21D for ; Thu, 29 Sep 2016 11:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.316] 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 hAR0dNC7MHph for ; Thu, 29 Sep 2016 11:38:43 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 4199C12B20A for ; Thu, 29 Sep 2016 11:38:43 -0700 (PDT) Received: from [10.123.78.255] (usc-secure-wireless-206-255.usc.edu [68.181.206.255]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u8TIc6EW025927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 Sep 2016 11:38:08 -0700 (PDT) To: marcelo bagnulo braun , tcpm@ietf.org References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> <0a48dabd-713a-f86b-311a-2937c37d1833@isi.edu> <6a7dc05c-4e33-bc4b-58e7-f0de92defcfa@it.uc3m.es> From: Joe Touch Message-ID: <5abbad5b-9ed6-75c9-3618-f010359601ee@isi.edu> Date: Thu, 29 Sep 2016 11:38:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <6a7dc05c-4e33-bc4b-58e7-f0de92defcfa@it.uc3m.es> Content-Type: multipart/alternative; boundary="------------8AE378B913AB68591D8F6760" X-MailScanner-ID: u8TIc6EW025927 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 18:38:48 -0000 This is a multi-part message in MIME format. --------------8AE378B913AB68591D8F6760 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 9/29/2016 10:21 AM, marcelo bagnulo braun wrote: >> I appreciate your question, but I'm pointing out that there might be two >> answers. > > Right, agree and that i why i think that simply stating packet loss in > the cubic draft without indicating how it is detected, may be less > specified than what is needed. > So i think we are aligned. Agreed - a protocol should describe behaviors based on directly observed events, not inferences. I.e., it can say why three dupacks is treated as inferred loss, but it needs to go back to the observable events. Joe --------------8AE378B913AB68591D8F6760 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



On 9/29/2016 10:21 AM, marcelo bagnulo braun wrote:
I appreciate your question, but I'm pointing out that there might be two
answers.

Right, agree and that i why i think that simply stating packet loss in the cubic draft without indicating how it is detected, may be less specified than what is needed.
So i think we are aligned.

Agreed - a protocol should describe behaviors based on directly observed events, not inferences.

I.e., it can say why three dupacks is treated as inferred loss, but it needs to go back to the observable events.

Joe
--------------8AE378B913AB68591D8F6760-- From nobody Thu Sep 29 23:14:26 2016 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 B995512B191 for ; Thu, 29 Sep 2016 23:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjKDG1qQZj4t for ; Thu, 29 Sep 2016 23:14:21 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 94E2912B152 for ; Thu, 29 Sep 2016 23:14:19 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id p138so4639703wmb.1 for ; Thu, 29 Sep 2016 23:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=C9oEqkcUVdZZrtN5/Dv44VBLfY+RjFMYNrzVaW8qqZE=; b=vqUAiB2OUZC2aYur8DjGq1sIfUlWKi5woakphPTi9NsiNDf+uiymCJx46tNGQW4QWs tSQGlqDL3y/cJfyOS8fk0J0g56zaYFtLflxGlxynqwA9pPqkQdl5aa37PTXvq2n2dqoc 1qKDLgXPtmbjMOSaNm/Xmz902aDVobifxcD9/1s85XOiW4OOrXVOovD4nk6is0f3hu9j 5s9PhaspkLgcqSpKXw2mEHyuczKBimUPNKwkV4xnc1IRlIcJpco9f0wnmi23p2Jo9fSj GWaUCLKqIDQ84qEP5LMYi9DIsAKhk8kydgCOiZgKLcl5W2yogORuyuX4MHk3DWWjN4Y8 Va1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=C9oEqkcUVdZZrtN5/Dv44VBLfY+RjFMYNrzVaW8qqZE=; b=fnZ8k5es9CFhgLJUmX/j8PASbctiir4PzUSshvev9NqPfJQpQClCT1KYhAJfOpWv5C gWUAJCxPhloCNeL0X0n5lwF1AN5lVUj/LcjWQ4DWsUJ49SyZ2/cVgW9CNNwZA2p/QR/E S/10z7ASysUaDXdN4athfP/S8WKTc6vc+ULGBBNso/Xoc2EGXkX6A+ATJYu9J1pSVyyR FtuiVC4PT7/D5Dl7V6cTcHdVXazaaX+6l78n7JHRnyiH9rSzIBBMDFwoEuaGd/idzNyk Lw8fgeycQVE2FATGizVsO1SFLKeF061dTHH/Q3p3a+aGkYP1yQ9zIFqmkMiK5vxaip6P Mclg== X-Gm-Message-State: AA6/9RmoInffNmb671hiMYY4z0EyRKIYIP4Eu1IiAmHcbYDuqcbIFDgWKfLBVOs3dKL1N/AV X-Received: by 10.28.91.11 with SMTP id p11mr1972865wmb.98.1475216057891; Thu, 29 Sep 2016 23:14:17 -0700 (PDT) Received: from Macintosh-6.local ([2001:720:410:1010:b9fd:7aa:d292:6e17]) by smtp.gmail.com with ESMTPSA id lz5sm17779842wjb.24.2016.09.29.23.14.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Sep 2016 23:14:17 -0700 (PDT) References: <147521493612.18534.2870935234304413131.idtracker@ietfa.amsl.com> To: tcpm IETF list From: marcelo bagnulo braun X-Forwarded-Message-Id: <147521493612.18534.2870935234304413131.idtracker@ietfa.amsl.com> Message-ID: <5da0c3b3-fcd3-8a97-6d32-09ac66a90084@it.uc3m.es> Date: Fri, 30 Sep 2016 08:14:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147521493612.18534.2870935234304413131.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 06:14:25 -0000 Hi, After the presentation and discussion in Berlin, we have submitted a new version of the draft that includes the details of how to add ECN support to TCP control packets and retransmissions. Comments are welcome. Regards, marcelo -------- Mensaje reenviado -------- Asunto: I-D Action: draft-bagnulo-tcpm-generalized-ecn-00.txt Fecha: Thu, 29 Sep 2016 22:55:36 -0700 De: internet-drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Adding Explicit Congestion Notification (ECN) to TCP control packets and TCP retransmissions Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-bagnulo-tcpm-generalized-ecn-00.txt Pages : 23 Date : 2016-09-29 Abstract: This document describes an experimental modification to ECN to allow the use of ECN to the following TCP packets: SYNs, Pure ACKs, Window probes, FINs, RSTs and retransmissions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-generalized-ecn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Sep 30 00:20:36 2016 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 347D612B020 for ; Fri, 30 Sep 2016 00:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-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 3Z6IUterQqZT for ; Fri, 30 Sep 2016 00:20:32 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33B71200DF for ; Fri, 30 Sep 2016 00:20:31 -0700 (PDT) Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 906A629C032 for ; Fri, 30 Sep 2016 16:20:29 +0900 (JST) Received: by mail-vk0-f43.google.com with SMTP id y190so64980326vkd.3 for ; Fri, 30 Sep 2016 00:20:29 -0700 (PDT) X-Gm-Message-State: AA6/9RkAGUk4ZENnu75FMnBAhsUjtZvbPdu31qmOBMPfkElVk6Ozo8w6FcUZjSGvcxa0HBAwwRzKogadgetwyQ== X-Received: by 10.31.172.83 with SMTP id v80mr4349608vke.79.1475220028114; Fri, 30 Sep 2016 00:20:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.33.210 with HTTP; Fri, 30 Sep 2016 00:20:27 -0700 (PDT) From: Yoshifumi Nishida Date: Fri, 30 Sep 2016 00:20:27 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a1144065abdd23b053db46d69 Archived-At: Subject: [tcpm] comments for draft-ietf-tcpm-rack-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 07:20:34 -0000 --001a1144065abdd23b053db46d69 Content-Type: text/plain; charset=UTF-8 Hello, Thanks for an interesting proposal. I've read the draft-ietf-tcpm-rack-00.txt and have the following comments on the draft. Please point out if I miss something. 1: I think the draft should mention how to control pipe size during loss recovery. When RACK identifies lost packets, how it reduces cwnd? 2: Similar to 1:, doesn't RACK have a certain back-off mechanism? I couldn't find it in the draft. It is nice that it can find the lost of retransmitted packets, but does it retransmits them again with the same settings? It seems to me that RACK might become aggressive under heavy congestions as it keeps retransmitting packets with short intervals while other TCPs wait for RTO. 3: I am not very sure if using the minimum value in all RTT measurements for RACK.min_RTT is a really good option. If RTT is significantly increased all of sudden, it might cause lots of spurious retransmits unless reordering window is dynamically adjusted. 4: It is a bit confusing to me that the abstract says "modern TCP implementations that can support per-packet timestamps.." because I thought it was referring timestamp option. But, RACK actually doesn't rely on it. I might prefer to say something like keep tracking transmit time per packet. 5: I guess you might want to add explanations of "RACK packet" and "RACK.ack_ts" in Section 4. I think their definitions are not very clear. Thanks, -- Yoshi --001a1144065abdd23b053db46d69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thanks for an interesting proposal.
I'= ;ve read the draft-ietf-tcpm-rack-00.txt and have the following comments on= the draft.
Please point out if I miss something.

1: I think the = draft should mention how to control pipe size during loss recovery.
=C2= =A0 =C2=A0 When RACK identifies lost packets, how it reduces cwnd?

= 2: Similar to 1:, doesn't RACK have a certain back-off mechanism? I cou= ldn't find it in the draft.
=C2=A0 =C2=A0 It is nice that it can fin= d the lost of retransmitted packets, but does it retransmits them again wit= h the same settings?
=C2=A0 =C2=A0 It seems to me that RACK might become= aggressive under heavy congestions as it keeps retransmitting packets with= short intervals while other TCPs wait for RTO.

3: I am not very sur= e if using the minimum value in all RTT measurements for RACK.min_RTT is a = really good option.
=C2=A0 =C2=A0 If RTT is significantly increased all = of sudden, it might cause lots of spurious retransmits unless reordering wi= ndow is dynamically adjusted.

4: It is a bit confusing t= o me that the abstract says "modern TCP implementations that can suppo= rt per-packet timestamps.." because I thought it was referring timesta= mp option. But, RACK actually doesn't rely on it. I might prefer to say= something like keep tracking transmit time per packet.=C2=A0
5: I guess you might want to add explanations of "RACK pac= ket" and "RACK.ack_ts" in Section 4. I think their definitio= ns are not very clear.

Thanks,
--
<= div>Yoshi

--001a1144065abdd23b053db46d69-- From nobody Fri Sep 30 01:06:14 2016 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 53AD312B15B for ; Fri, 30 Sep 2016 01:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316, SPF_PASS=-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 uXQw1xbBFwE5 for ; Fri, 30 Sep 2016 01:06:11 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE0D12B074 for ; Fri, 30 Sep 2016 01:06:10 -0700 (PDT) Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BFDFE2D98F1 for ; Fri, 30 Sep 2016 17:06:08 +0900 (JST) Received: by mail-ua0-f178.google.com with SMTP id v7so13232037uaa.0 for ; Fri, 30 Sep 2016 01:06:08 -0700 (PDT) X-Gm-Message-State: AA6/9RllAlEmHRk84xQKNOlcNGC4k2hEwno4WzngGLFbA16hyvDb08VmS10Pw/9q2loZQ80B6Qx/QzKBGxy3vA== X-Received: by 10.159.55.138 with SMTP id q10mr4459980uaq.131.1475222767110; Fri, 30 Sep 2016 01:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.33.210 with HTTP; Fri, 30 Sep 2016 01:06:06 -0700 (PDT) In-Reply-To: References: <7070553C-65D1-46EE-95F4-DAE82E1F5A5E@weston.borman.com> <2D524A8D-A5CA-45A6-B94D-FA1DA0CEE609@weston.borman.com> From: Yoshifumi Nishida Date: Fri, 30 Sep 2016 01:06:06 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=94eb2c041f22ff9945053db5104d Archived-At: Cc: Kobby Carmona , David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] Possible deadlock scenario with retransmission on both sides at the same time X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 08:06:13 -0000 --94eb2c041f22ff9945053db5104d Content-Type: text/plain; charset=UTF-8 Hello, I'm not very sure how many folks are interested in this, but anyway... I have tested this with packetdrill on linux, netbsd, freebsd and openbsd. As far as I tested, linux works just like Neal described. On the other hand, I found a minor issue in others' behavior. In their tcp input functions, they haven't checked sequence number when they update ack value while it is checked later in the code. Because of this, it behaves like the followings. 00:42:58.395100 192.0.2.1.54613 > 192.168.0.1.8080: Flags [S], seq 0, win 20000, options [mss 1000], length 0 00:42:58.395120 192.168.0.1.8080 > 192.0.2.1.54613: Flags [S.], seq 4183682776, ack 1, win 65535, length 0 00:43:01.422728 192.168.0.1.8080 > 192.0.2.1.54613: Flags [S.], seq 4183682776, ack 1, win 65535, length 0 00:43:01.422801 192.0.2.1.54613 > 192.168.0.1.8080: Flags [.], seq 1, ack 1, win 20000, length 0 00:43:02.443166 192.0.2.1.54613 > 192.168.0.1.8080: Flags [.], seq 2001:3001, ack 1, win 20000, length 1000 00:43:02.468148 192.168.0.1.8080 > 192.0.2.1.54613: Flags [.], seq 1, ack 1, win 65535, length 0 00:43:04.471409 192.168.0.1.8080 > 192.0.2.1.54613: Flags [P.], seq 1:1001, ack 1, win 65535, length 1000 00:43:06.531462 192.0.2.1.54613 > 192.168.0.1.8080: Flags [.], seq 1:1001, ack 1001, win 20000, length 1000 00:43:06.555492 192.168.0.1.8080 > 192.0.2.1.54613: Flags [.], seq 1001:2001, ack 1001, win 65000, length 1000 00:43:06.555973 192.168.0.1.8080 > 192.0.2.1.54613: Flags [P.], seq 2001:3001, ack 1001, win 65000, length 1000 00:43:07.056276 192.0.2.1.54613 > 192.168.0.1.8080: Flags [.], seq 1001:2001, ack 1001, win 20000, length 1000 00:43:07.084910 192.168.0.1.8080 > 192.0.2.1.54613: Flags [.], seq 3001, ack 3001, win 63000, length 0 00:43:07.585918 192.0.2.1.54613 > 192.168.0.1.8080: Flags [.], seq 1001:2001, ack 2001, win 20000, length 1000 00:43:07.607117 192.168.0.1.8080 > 192.0.2.1.54613: Flags [.], seq 3001, ack 3001, win 63000, length 0 00:43:08.109788 192.0.2.1.54613 > 192.168.0.1.8080: Flags [.], seq 2001, ack 2001, win 20000, length 0 00:43:13.908734 192.168.0.1.8080 > 192.0.2.1.54613: Flags [P.], seq 2001:3001, ack 3001, win 63000, length 1000 In this dump file, src addr 192.0.2.1 are the packets generated by packetdrill and src addr 192.168.0.1 are the packets from OSes. While the ack values in packets at 00:43:07.585918 and 00:43:13.908734 should be ignored, it is actually used to update snd_nxt. As the result, we saw seq 2001:3001 was retransmited after timeout instead of 1001:2001. (But, it also means this logic won't create the deadlock situation Kobby mentioned) When I added seq num check in updating ack value in FreeBSD code, it works just like expected. -- Yoshi On Tue, Aug 23, 2016 at 12:06 AM, Yoshifumi Nishida wrote: > Hi Neal, > > Oh. I see. Thanks for the explanation. > I'd like to think about it a bit more. > Thanks, > -- > Yoshi > > > On Sun, Aug 21, 2016 at 12:44 PM, Neal Cardwell > wrote: > >> I am pretty sure Linux does not have the issue Kobby pointed out in this >> thread. >> >> At a high level Linux should be OK because it follows the principle >> David Borman laid out in his August 16 email: "ACK-only packets should >> be sent with the largest in-window sequence number that has ever been >> sent." >> >> Linux obeys that principle by using tp->snd_nxt to store the largest >> sequence number that has ever been sent, and having >> tcp_acceptable_seq() use tp->snd_nxt but clamp the outgoing sequence >> number to make sure it is in-window. To be able to do this, in Linux, >> the sender does not rewind tp->snd_nxt on retransmissions. >> >> neal >> >> On Sun, Aug 21, 2016 at 1:25 PM, Yoshifumi Nishida >> wrote: >> > Hi Neal, >> > >> > Thanks for the info. >> > So, it seems to me that the linux code has the issue Kobby pointed out. >> > Or, am I missing something? >> > -- >> > Yoshi >> > >> > >> > On Mon, Aug 15, 2016 at 6:18 PM, Neal Cardwell >> wrote: >> >> >> >> On Mon, Aug 15, 2016 at 6:39 PM, Yoshifumi Nishida >> >> wrote: >> >> > Hello, >> >> > I personally think this is an interesting corner case for discussion. >> >> > It looks a minor one, but I'm not not very sure if we can leave it >> for >> >> > each >> >> > implementation. >> >> > I also guess a question would be if the BSD's fix is the best way for >> >> > the >> >> > issue. >> >> >> >> Yes, I agree this is an interesting case for discussion. >> >> >> >> FWIW, as a point of comparison for discussion, Linux's approach is a >> >> little different: in Linux, the sender does not rewind SND.NXT on >> >> retransmissions (RTO or Fast Recovery). Then the sender usually uses >> >> SND.NXT for the seq field of outgoing pure ACKs. I say "usually" >> >> because the Linux code has some code to deal with the case where the >> >> receiver has withdrawn the receive window, so that SND.NXT is now >> >> beyond the receive window. The code tcp_send_ack() uses to pick a seq >> >> for outgoing pure ACKs looks like: >> >> >> >> /* SND.NXT, if window was not shrunk. >> >> * If window has been shrunk, what should we make? It is not clear at >> >> all. >> >> * Using SND.UNA we will fail to open window, SND.NXT is out of >> >> window. :-( >> >> * Anything in between SND.UNA...SND.UNA+SND.WND also can be already >> >> * invalid. OK, let's make this for now: >> >> */ >> >> static inline __u32 tcp_acceptable_seq(const struct sock *sk) >> >> { >> >> const struct tcp_sock *tp = tcp_sk(sk); >> >> >> >> if (!before(tcp_wnd_end(tp), tp->snd_nxt)) >> >> return tp->snd_nxt; >> >> else >> >> return tcp_wnd_end(tp); >> >> } >> >> >> >> neal >> > >> > >> > > --94eb2c041f22ff9945053db5104d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I'm not very sure how many folks a= re interested in this, but anyway...
I have tested this with pack= etdrill on linux, netbsd, freebsd and openbsd.

As = far as I tested, linux works just like Neal described.=C2=A0
On t= he other hand, I found a minor issue in others' behavior.=C2=A0
In their tcp input functions, they haven't checked sequence number w= hen they update ack value while it is checked later in the code. Because of= this, it behaves like the followings.

00:42:58.395100 192.0.2.1.54613 > 192.168.0.1.8080: Flags [S]= , =C2=A0seq 0, win 20000, options [mss 1000], length 0
00:42:58.395120 192.168.0.1.8080 > 192.0.2.1.54613: Flags = [S.], seq 4183682776, ack 1, win 65535, length 0
00:43:01.422728 192.168.0.1.8080 > 192.0.2.1.54613: Flags [S.], = seq 4183682776, ack 1, win 65535, length 0
00:43:01.422801 192.0.2.1.54613 > 192.168.0.1.8080: Flags [.], =C2=A0s= eq 1, ack 1, win 20000, length 0
00:43:02= .443166 192.0.2.1.54613 > 192.168.0.1.8080: Flags [.], =C2=A0seq 2001:30= 01, ack 1, win 20000, length 1000
00:43:0= 2.468148 192.168.0.1.8080 > 192.0.2.1.54613: Flags [.], =C2=A0seq 1, ack= 1, win 65535, length 0
00:43:04.471409 1= 92.168.0.1.8080 > 192.0.2.1.54613: Flags [P.], seq 1:1001, ack 1, win 65= 535, length 1000
00:43:06.531462 192.0.2.= 1.54613 > 192.168.0.1.8080: Flags [.], =C2=A0seq 1:1001, ack 1001, win 2= 0000, length 1000
00:43:06.555492 192.168= .0.1.8080 > 192.0.2.1.54613: Flags [.], =C2=A0seq 1001:2001, ack 1001, w= in 65000, length 1000
00:43:06.555973 192= .168.0.1.8080 > 192.0.2.1.54613: Flags [P.], seq 2001:3001, ack 1001, wi= n 65000, length 1000
00:43:07.056276 192.= 0.2.1.54613 > 192.168.0.1.8080: Flags [.], =C2=A0seq 1001:2001, ack 1001= , win 20000, length 1000
00:43:07.084910 = 192.168.0.1.8080 > 192.0.2.1.54613: Flags [.], =C2=A0seq 3001, ack 3001,= win 63000, length 0
00:43:07.585918 192.= 0.2.1.54613 > 192.168.0.1.8080: Flags [.], =C2=A0seq 1001:2001, ack 2001= , win 20000, length 1000
00:43:07.607117 = 192.168.0.1.8080 > 192.0.2.1.54613: Flags [.], =C2=A0seq 3001, ack 3001,= win 63000, length 0
00:43:08.109788 192.= 0.2.1.54613 > 192.168.0.1.8080: Flags [.], =C2=A0seq 2001, ack 2001, win= 20000, length 0
00:43:13.908734 192.168.= 0.1.8080 > 192.0.2.1.54613: Flags [P.], seq 2001:3001, ack 3001, win 630= 00, length 1000

In this dump file, sr= c addr 192.0.2.1 are the packets generated by packetdrill and src addr 192.= 168.0.1 are the packets from OSes. While the ack values in packets at=C2=A0= 00:43:07.585918 and=C2=A000:43:13.= 908734 should be ignored, it is actually used to update snd_nxt.=C2= =A0
As the result, we saw seq 2001:3001 was retransmited after ti= meout instead of 1001:2001.
(But, it also means this logic won= 9;t create the deadlock situation Kobby mentioned)

When I added seq num check in updating ack value in FreeBSD code, it works= just like expected.
--
Yoshi

=

On Tue, Aug 23, 2= 016 at 12:06 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi Neal,

Oh. I see. Thanks for the explanation.
I'd like to think ab= out it a bit more.
Thanks,
--
Yoshi
<= div class=3D"gmail-m_3426810027158076340h5">
=
On Sun, Aug 21, 2016 at 12:44 PM, Neal Cardw= ell <ncardwell@google.com> wrote:
I a= m pretty sure Linux does not have the issue Kobby pointed out in this threa= d.

At a high level Linux should be OK because it follows the principle
David Borman laid out in his August 16 email: "ACK-only packets should=
be sent with the largest in-window sequence number that has ever been
sent."

Linux obeys that principle by using tp->snd_nxt to store the largest
sequence number that has ever been sent, and having
tcp_acceptable_seq() use tp->snd_nxt but clamp the outgoing sequence
number to make sure it is in-window. To be able to do this, in Linux,
the sender does not rewind tp->snd_nxt on retransmissions.

neal

On Sun, Aug 21, 2016 at 1:25 PM, Yoshifumi Nishida
<n= ishida@sfc.wide.ad.jp> wrote:
> Hi Neal,
>
> Thanks for the info.
> So, it seems to me that the linux code has the issue Kobby pointed out= .
> Or, am I missing something?
> --
> Yoshi
>
>
> On Mon, Aug 15, 2016 at 6:18 PM, Neal Cardwell <ncardwell@google.com> wrote:<= br> >>
>> On Mon, Aug 15, 2016 at 6:39 PM, Yoshifumi Nishida
>> <ni= shida@sfc.wide.ad.jp> wrote:
>> > Hello,
>> > I personally think this is an interesting corner case for dis= cussion.
>> > It looks a minor one, but I'm not not very sure if we can= leave it for
>> > each
>> > implementation.
>> > I also guess a question would be if the BSD's fix is the = best way for
>> > the
>> > issue.
>>
>> Yes, I agree this is an interesting case for discussion.
>>
>> FWIW, as a point of comparison for discussion, Linux's approac= h is a
>> little different: in Linux, the sender does not rewind SND.NXT on<= br> >> retransmissions (RTO or Fast Recovery). Then the sender usually us= es
>> SND.NXT for the seq field of outgoing pure ACKs. I say "usual= ly"
>> because the Linux code has some code to deal with the case where t= he
>> receiver has withdrawn the receive window, so that SND.NXT is now<= br> >> beyond the receive window. The code tcp_send_ack() uses to pick a = seq
>> for outgoing pure ACKs looks like:
>>
>> /* SND.NXT, if window was not shrunk.
>>=C2=A0 * If window has been shrunk, what should we make? It is not = clear at
>> all.
>>=C2=A0 * Using SND.UNA we will fail to open window, SND.NXT is out = of
>> window. :-(
>>=C2=A0 * Anything in between SND.UNA...SND.UNA+SND.WND also can be = already
>>=C2=A0 * invalid. OK, let's make this for now:
>>=C2=A0 */
>> static inline __u32 tcp_acceptable_seq(const struct sock *sk)
>> {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const struct tcp_sock *tp =3D tcp= _sk(sk);
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!before(tcp_wnd_end(tp), tp-&= gt;snd_nxt))
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retur= n tp->snd_nxt;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retur= n tcp_wnd_end(tp);
>> }
>>
>> neal
>
>


--94eb2c041f22ff9945053db5104d-- From nobody Fri Sep 30 02:31:56 2016 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 EF1F612B05C; Fri, 30 Sep 2016 02:31:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147522791497.20389.8756174793293866855.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 02:31:54 -0700 Archived-At: Cc: tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org Subject: [tcpm] tcpm - Update to a Meeting Session Request for IETF 97 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 09:31:55 -0000 An update to a 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.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: tsvwg tsvarea taps mptcp tcpinc httpbis iccrg quic plus Second Priority: rmcat rtcweb aqm maprg Third Priority: ippm teas Special Requests: --------------------------------------------------------- From nobody Fri Sep 30 11:11:18 2016 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 9F7B212B1A7; Fri, 30 Sep 2016 11:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwDjk4orE0Vq; Fri, 30 Sep 2016 11:11:15 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263E312B1A5; Fri, 30 Sep 2016 11:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yIJLSOPU7zorC/nvSGpRslTd+6iqgxMwuI4sjCjSYaQ=; b=s9xl1AEGGFDZmUvEbDnEl4mbM5DvKz+2HRr3IrTPZm90uRlO+EwbxLcrSiDgQ6r7EC9KCwKt2HS0N4hAjynI1PZ35Aejj4oEsHY+dz3n6ePmAU23fLgSiYkOCwfV3oi/Szv/kQEV9BW+MQxW+JDdAoXQ3sY1d6QDP9O9TlTbm24= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [10.211.130.238] (129.93.4.25) by CY4PR08MB2520.namprd08.prod.outlook.com (10.172.156.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Fri, 30 Sep 2016 18:11:13 +0000 To: marcelo bagnulo braun , tcpm IETF list , References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Fri, 30 Sep 2016 13:11:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.93.4.25] X-ClientProxiedBy: YTOPR01CA0051.CANPRD01.PROD.OUTLOOK.COM (10.166.146.147) To CY4PR08MB2520.namprd08.prod.outlook.com (10.172.156.141) X-MS-Office365-Filtering-Correlation-Id: e1b74eff-4393-4500-5e05-08d3e95d2a1a X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2520; 2:TKp7pUbzudweGiKKucJ+TG/xCygzKxoLeYwQ7joILSG3gJFaoxFTQp0z4wNEZnp93YKgwRsBIC8foRZbFBQsXsEtwFvrTd1xshhpWzmWFX80e6IqgldtxPJx1Mt9+hVj66sLdpp8SIKZyRxc2B6pVn7TIWN86+GjL++xzKdup7PURC37PAz73jdl5pVYFvM0; 3:49OGW88s60e3oQd1YDtSxGwhVOVLLXWo2EACdFkaaH6jtQjdt5ieIu1ouVTQjW+H7h4RGDNb3jfTzyqhvvQDyKovZ/8NK+7/hDzwj9f+q+wX2rHtXYctjR1EAe4VV5iS; 25:zlnjmt17Ekkqhg4Q0gR89+LprjkEQV24sLKYunQMn1OXHG7PJPnp2/WSgOIdEYZSK5CD/T9Hte2g1GFmAyXFNZ/VELN9EC6vgP4qOoEUxBx6mpcmYiZaNbCMwDFzabnlZg+lIiBKeurJGdwjYy66rRRQ870mV9+eLaNiL78m4QSkNK9DZ4J4Jt60TF+LIGWMb1N4iDPqcriuT5prSHzj8Z/Kzjq/Zt5kLmbkv/6+Y7U6RTdiQaVStjcUq9LvMmKohRBTk2BS0XJZ6ula9i04fM5t6y5j+cE4QrN5Pmf1yB9R8URfyaUaaO0j7Zn7FPb+SQAOYAt9CjRkT3StslNMqXkKETqx0FouuiCib7USaE5d13yRtH8k/mADj4R1yL2pfqghP+N5ehpOA6us9g8T/mFIH0bR98G+qVkxAeiuaos= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR08MB2520; X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2520; 31:ycMlRnyESmtysNtV8YXzsGKCcyGzaFOyRRk7J0DoM8YM4+QUpMu7tvwXk5JvtWCn+QErnraUn9AuE5p3EGkK4Xo01AxNe2P+o1Wx89F4WyhKbwi1CW3ylLadxt50i6QrydSXQoDwJAzDvCI19ezX3DNnQ9trUZgvKW2N2t9rY8axJs8k7OX6oyUJtBGDtf7D0IAhPnaVhH3H0FHwonrpwVPWS3BiQnThCrfbBiEuh3Q=; 20:x3OcpQSlrtcn7BUiUAsIzC+prvCSgr3Yepz6L+GXbd7SyNtp3ywh1a/Q6RmcYffYR3x1AbgXidRGBaVZsnTnbtBlJ2QI8DnVWTPZ+0pLhX5zovp2kxSe/ywvTn3AuGPPmCUjnnzjFqhkUfFO0tCd/CFmeBhvyECUTFT3RZlYipBCIPlxZzTwlpu3MJHi5xbtOcghJhAHVpjhNWHcOu6glJVLQzgahdpAsaOco5bXfNIw2aFo803sfKDekem9AbnJ5L06xdwddmwjq6PPIttvXbdB94kTirln/GyDa+kiWg1SZ9Dr2Dsw6MU43kVozOkFSZ6Es9aI4APCsHE/g6hlZ7kr1nFoPj2m+DSotbGAgmGd1ClcHDpRpAYDW0YdmyfIa3HrgWSmoP5XdXY/PDT7NblUAXUR2NTm7gWQ931AUlNcEzNg5yW+VWsD1/02whXNKyV0amulivp1t4fGD/gVtHNaWoCuwuoGUpfekIkk9KoDnOyb35mGt7zFUmju60p0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY4PR08MB2520; BCL:0; PCL:0; RULEID:; SRVR:CY4PR08MB2520; X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2520; 4:+6GmvOSwSag0uKlNm9UJgwGN+GvXVV4aRAGcbGBc10sdbxHk3RrHXg4NEV7rIApdD53+GHvW6JeJhnkrXK9CnM58BC/F2Ewddl/Po6cmSeITZrwaie8zBizMRJUOjFlCUbETN7w/D4h8Xpn8m3kv5k1+enSOBcLxj/W7YmtxuvGQWGFe/Txr7ovtLlKOD6919+mX8KmV+Idub9A9fsklPA1TMPrIIxTXb3aUkQywwF/hI+OddkNFUeqsjJmFDZqq4Gi6438nE/LaCWurftPEFd2/rBXG1iknh6kbWhWo7vyZXavpbbVZ/9HKafePQEH4xwMBaN/LeahmJeAtuVZsKhfL0AY21uxIbdnPrJE3aC+GUPJX1YF1m/G8tG8ootpL16TOZg7RFyP6rP1bL5Sk+A== X-Forefront-PRVS: 008184426E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(24454002)(199003)(189002)(377454003)(19580405001)(23746002)(19580395003)(89122001)(64126003)(4001350100001)(586003)(54356999)(6666003)(65806001)(5660300001)(47776003)(65956001)(105586002)(50466002)(50986999)(68736007)(76176999)(3846002)(65826007)(2906002)(230700001)(6116002)(106356001)(107886002)(83506001)(31696002)(66066001)(97736004)(5001770100001)(77096005)(86362001)(92566002)(75432002)(305945005)(101416001)(189998001)(15975445007)(33646002)(90282001)(81166006)(36756003)(7736002)(88552002)(2950100002)(42186005)(8676002)(7846002)(81156014)(31686004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR08MB2520; H:[10.211.130.238]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY4PR08MB2520; 23:uGpX+JrYZOfJzjmNpf04nGzD+8bKhcejx45lT?= =?Windows-1252?Q?j30uKVGc+Uq3g2LWwM71ZI0+cJVyFODSfJwTKQaVuckcSyWKWnxW2t4Q?= =?Windows-1252?Q?ycBx5Sk0WwpcPylj47EKwHogou10BhkiRZ8mnkImlsJVssXRsBV93tAp?= =?Windows-1252?Q?3xQhyiN0PsUWIatXm+YR+yq0J6bj9xRokaFLPCJWLjr/NHUAYny7p7dF?= =?Windows-1252?Q?XH2XK56QEcPDGM9gEuvjdrI27nX2ZH7FeAPHXFFYCv2ZTlVxdibEA5R5?= =?Windows-1252?Q?IooAUp4VOFnPCewcT5pBanHV4JZgQni1rU3HhiK2gUaIi8t3fd1gqBdJ?= =?Windows-1252?Q?BOzM6kSpiiwdhYwqkTLRpPGIwSSBNTTfoRmQpR4QoukS8dcgmSc2yHeA?= =?Windows-1252?Q?Szz5qXI5jd9oojfZRJfVznjztLOqaLlb4SbFFhrJYFDYcL0HkZU0jian?= =?Windows-1252?Q?n7MYPrsoOMqj8gmNvcK+aegIA3P1675rV7uAL+BPhZHqXlEvnU0cNJUW?= =?Windows-1252?Q?ZNt+SCWQ1OzoVWovECBL1uDXFwSRU4AGWUv6TTPJCXrsa9UvEAHrxJCT?= =?Windows-1252?Q?VNFY/3Oowo9yYLS/r1bljl2lyCSTuzAxwcsnTGA/tbHjsQIAPEJk9Cj2?= =?Windows-1252?Q?1AQGrFJJbz7TFPCSPMT1y6iIEAdVe1wbCCwN64u7OXqrsUPEbhVUFXzh?= =?Windows-1252?Q?tfkvLHZpWEPkwVRZf98PKadMBrPBZpBD0k8jMRqpWa22IPBqPqhlEZ4i?= =?Windows-1252?Q?+SJ/1cEuPHOoqSDh7bQup7b1MSXN698gT2/w9KX7/r/4K9vJqYETYPaC?= =?Windows-1252?Q?Xe0djd7V9d57vYF6nNSjKgRreqwg1o2+IOgx7h3CLHgPdmuvWVD6B4Kk?= =?Windows-1252?Q?eEccXRUybd7CG3ZunYGFHyuvg+/m6eNlhCRHIMQaJgA1+uwbw3gZLCDe?= =?Windows-1252?Q?oA3gdrf/UaQ08uY6BB1Sr5zK3Bk4CkFhtPze1Xu6jabjbHbVI7TYPbzm?= =?Windows-1252?Q?tQWMjozUHW4oGUKbjpYzIyjK8EgWT1RaAnGRg9nOTQN5SyNau7yxWETt?= =?Windows-1252?Q?jGKmsGPL5QdKHpLmfpX/v6ziGFYhMsu6eqtN5uSKHALjSYpESALLRjmC?= =?Windows-1252?Q?Mcme4MwLEG10JyIwG4KQQbo0eLIYQpWeaIGRF217T+Co4xaqAmYeR8A1?= =?Windows-1252?Q?fZoUaOR1p0xLBAehjlfijke6hCRvQh34g5Hermgfu+5KIdJ2W3kS+jKc?= =?Windows-1252?Q?XV+4Tq/0qSsUnj3k67D0dvgW3x5dOIOqXcqKV5xv4Puja3sjUGouE0AO?= =?Windows-1252?Q?9EHxNCLd7+kxROnS5LmN1wza3SrF4HHc1Vif8q44NF7ZlJ2P13D0LYbk?= =?Windows-1252?Q?Qax/K0QTIuuBbOFvutJC+ihQkVP1p/e612a1wxNvN2bUS4leqsNoMI9x?= =?Windows-1252?Q?cMggjuYN2BrKSVjEu7PQ5QkjdrmAbGnokLspx6RQxq+Bop/oxAFKauKH?= =?Windows-1252?Q?fXsutqGnqeCmgtL6+XmGvN9jBdNjg+qYLOQ+nRWWA5WgcELyd4Yf5zQP?= =?Windows-1252?Q?GY+AH1ztSucpqY=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2520; 6:vrz47ravI7pfoQJ4lYUS53o9MTdpH9KpwgYi7ft5cixmsoTw6FVIpduRGjlRJHAtFbAUwqEw763UF5TciqgYk5DJkj+CybyGadAOawdIyVlhnZgJ5Vg8a2Yo1W87J9EU6jJNKDCloy1rpYVSgWozBQy5yq6PQZViGFNDK6YOPtb5VuYjy968Y5SEIErb5mLKPd1O9IHgG926djaZAdu8PVefAEhBuWTzKJxXz1RNljs0xXZVrNO92Ud+FNBJfcfCOqBKVu1YUs51rjAHu11nBAUSyyNA8TzzNouxwxlzS+w=; 5:s7kXRQ7vyuDB+ljCwVkAdB7yZOIUbt3MliJ9bSzP/tXleqSbj7vFtEiUQMWPT8lGku89+5AjfOHZzKIFjpK+N1mBfCqd88acEfxvTDIcpisfdNFQa3N9w6eCdDjPlLNXD/rwM4QlHeezUYyPFhq/hA==; 24:wutK31kHae+g7T0q747kq6Z4WyGEJYbBdMybKUKCN3AGINdVTHfs6G80E0KdowsjTCNeDVtLyO4rQRKMP4Gw7FsmRq30/vykp5Vh9m+2WUI=; 7:6MxLHgAvNjUEs4pAUVzTQRV5+fr4Eqb0BrE1jQLTi+tGuAL29IenTm14Edqv7xgPjXhxtPEujhuVHLInVep9RIs1bf59VPVmHzRs9bzENyZNZVvqe+zz8A88mykLFT36HK+KisZuhu8b4blU1lpSl127195L0UFyiir23TjkjtoVQirERxc3U7RgVcYl7KHWFAewkymPJsezPdjve1Rd2V0KJbpeAQHMhU+s/kxvVU0NXX9Yl+OGedVSCQ8STbQLwnsZGVnzI5NQ5jOSY5jVX1aLhLXrgU4A60c17tkbno2H7joCWTVwAKOmrUFDJE1e SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2016 18:11:13.2549 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR08MB2520 Archived-At: Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 18:11:17 -0000 Thanks, Marcelo! We will revise the draft to more clearly explain the protocol behavior according to your discussion with Joe yesterday. Thanks Lisong On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: > Hi, > > Does cubic assumes that there is a different phase when the connection > starts? i.e. slow start? It may be worthwhile stating this explicitly? > > In the current draft, it always reffers to a packet loss event, but I > couldnt find how is the packet loss detected i.e. via duplicated ACKs > or via timeout. Is the reaction of cubic the same in both cases? Does > it reduces the window to 1 MSS and enters in slow start if the loss is > detected via a timeout? > > Sorry if this is already in the draft and i missed it. > > Regards, marcelo > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Sep 30 12:23:04 2016 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 6F54712B13F for ; Fri, 30 Sep 2016 12:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 cRzkzlHd568l for ; Fri, 30 Sep 2016 12:23:00 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 1439412B1B8 for ; Fri, 30 Sep 2016 12:22:57 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id o19so41050571ito.1 for ; Fri, 30 Sep 2016 12:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=seSBf8x0MPzJq3saKYtJQhxfBIfHVGBAS4XfHonMCek=; b=S6xctgokb84dsz+5xGsEzKFGUQEYdXd+jmnu2dp+NjbrFF9lnUCPSYoDl47lTWZWDM Eny4uKRn2EOpFGy9bXyYMDunQ29TqJCdjaRswto8eI20jMjWHXbh/1CquEDYHc6WGkTH Ajhr6yWU9yV0RfsALQxobjRAvFsc+bpW9mXhCAm4eH156+J4qRahODUSwxzAlN9H+sUL VOyY0cG65TFhcsziWJyjFwK1XJvhu7QQMWIqKsDJtopqu6qAyrVR+mZalNU6B59R0Py9 vO4TXhogCZOrp1mHv3aIG073rVCgJzWHs4dacKAq3iiQ5AUetiJxRDcsmg/83nR81yWo JzqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=seSBf8x0MPzJq3saKYtJQhxfBIfHVGBAS4XfHonMCek=; b=NTY8vk0joRhFUv4NP5NZOItJ5tGP6ldpt7+aKHln4UcksnPVQ+64YqWwcRPJzqV/tK a+C78vuT1t9DvT5UHnq//Jlq2lLLrCsj/jyktqvxZAfkfeS6G+2h2SVn6B7EGne+V65J iwLEC2VvrfaYR3IxU/mwE5swximI7ou4ELZH4Km+H2dmXfFIbTRADnFaGuc0hxjb4y4S Na3DoR6612wsnYtOD+aPW69eXI8z61iFIbKHzsT2GugoRQhdPKjbu3Fm8fjZz9KH1GoZ GeIAcHMbzhio7SCvVwGG7RP32xozE4CwzVL7ixCebGhl6jbryVlqy6cspcbmCGwDNU9Z OIsw== X-Gm-Message-State: AA6/9Rn1umywGIDi07RuGscB+MopCrb6yoGuUAAXj6tbjprj2etS/l7OFO1iPA/1GVFknNFGKKRGio9nz+k3HHn5 X-Received: by 10.36.139.4 with SMTP id g4mr6659810ite.97.1475263376182; Fri, 30 Sep 2016 12:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.135 with HTTP; Fri, 30 Sep 2016 12:22:15 -0700 (PDT) In-Reply-To: References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> From: Yuchung Cheng Date: Fri, 30 Sep 2016 12:22:15 -0700 Message-ID: To: Lisong Xu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 19:23:02 -0000 A small suggestion: the loss event may imply one single packet drop. But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss event, not N loss events. And 3 packet drops in round trip 1 plus 6 packet drops in round trip 2 mean 2 loss events. A fast recovery can span across many round trips if retransmission is lost again. It might be worth clarifying that otherwise the (incorrect) implementation will be a lot slower. On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu wrote: > Thanks, Marcelo! > > We will revise the draft to more clearly explain the protocol behavior > according to your discussion with Joe yesterday. > > Thanks > > Lisong > > > > On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: >> >> Hi, >> >> Does cubic assumes that there is a different phase when the connection >> starts? i.e. slow start? It may be worthwhile stating this explicitly? >> >> In the current draft, it always reffers to a packet loss event, but I >> couldnt find how is the packet loss detected i.e. via duplicated ACKs or via >> timeout. Is the reaction of cubic the same in both cases? Does it reduces >> the window to 1 MSS and enters in slow start if the loss is detected via a >> timeout? >> >> Sorry if this is already in the draft and i missed it. >> >> Regards, marcelo >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Sep 30 12:28:32 2016 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 1896B12B1B9; Fri, 30 Sep 2016 12:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjwxKOVgkhnd; Fri, 30 Sep 2016 12:28:29 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0016.outbound.protection.outlook.com [216.32.181.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D63312B128; Fri, 30 Sep 2016 12:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7kkU+twdwQGvdGVWr34IVUOEc77TNk5ofkZQESQ09Bk=; b=d67V7DHIw1rHUoev+hcdrej1C0ZVv+DlR9eIPyI2wAsKKh9WleOevvHntDHC5jWKBuu6qB8yjEYKAU2vajjlDrBnNxP9E8lQXF+ViMKTk30dsv1yBi8zNqVl87oDaSocwoijFFdv4gdXeV6Nafv0abkAnD6HmYOOOCaBrBpyFSE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [10.211.130.238] (129.93.4.25) by CY4PR08MB2520.namprd08.prod.outlook.com (10.172.156.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Fri, 30 Sep 2016 19:28:27 +0000 To: marcelo bagnulo braun , tcpm IETF list , References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <8301ee20-2aa6-4352-2ad8-4cb376e42a8f@unl.edu> Date: Fri, 30 Sep 2016 14:28:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.93.4.25] X-ClientProxiedBy: BY2PR01CA0014.prod.exchangelabs.com (10.163.25.24) To CY4PR08MB2520.namprd08.prod.outlook.com (10.172.156.141) X-MS-Office365-Filtering-Correlation-Id: 34d1e7c0-23fb-41dc-1c1b-08d3e967f460 X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2520; 2:n0X8caKDjcR/RYnsAMo9CQ4fsqZQHqdBzirsFqyCrCx6O5/M4rSTLr9WMbYAWBkIQk6Rke9RhSkfGwn1bX4u6KtojNLOHktqKnZ0ZUHz2JanQc5r0VIUPj0l55CXDMI+ltwKQb0Bs8kIIs4O7p7QBHuXXrDgoFALlVAXa1SjZHzgJKzalh9ur+dRemae+xfV; 3:WSSitF5RJddLWEIFUUew3aKEDhK5Moz85u2H80mo3Bf/YlbJWPGnrrDp3VVWPCkcjGtBsL0z4U/n6ucDYGvCWsXSys0AwRJwUR1Mmlg/J64CFWh5JTI4s21WhTRbj+H8; 25:y8ZsZJuXpmJGhYk2NX3JD35jwxODzsucYSf45xdd5c6tHvIaWYjjxjqyfvd5K86gJEhafsTrfV8Jnu2XQy0Tvkx9hnvpq6rekZjab8HL32MFYRjOfbUGEui9QSfa82J5M9/ClD1vBIRjuhgS6SPArs8dasOV73S639HVMQwwG/SKzxUqszxqeL01WZNfVhvCRvneeCK79Ej8eqfoW1kHKKf77toInPteb3qgomLZ4fCDdo54nxrkj4piJXGF2YJykFh3zevjXoO0NmP/iFQL1Hc8/vdHUdxEevxwZut8f3LQTT5OqjnvSKEvYs2nOrDZgcVD1PeshgG8/BGnx9A4B7jex/S7rxNWKvZsI3JIjl9R+xmjRVB9i2BH51I9mU5NzDVRGTfr19TVTGD9m8mgXjdkX2QFfnm30mkIChtgK+o= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR08MB2520; X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2520; 31:DsvDchXymOpNaGxo9hGANqCpKqtn8jyXjJaYeGIdhwghntArh9ZHT/YXqJTLaH6hABUXAF3BRFD8BXUzlOayn6RDZyx22u4nZHl3OxIDEiQYMCZYwvlMAqEqWzefl1LQqZNK+FgVxr2b7L1rde+PcvynAhhWOJlxji2lW0mp+Ba3NFBov2S73hDWNrw1gK/MrKmJyw9Bqkf1xbi5MS6j2t8ScoV9HEAtIWhSPhpZ/kKAwOFpjFrhQrzP3M78Cg89; 20:DcLTDcDNNI6nVpxuxluDA9MHUH5+zgqXTd5dn+rVVTSEYdw20svs25QQfuw79wkTBFhkF2zNtUP8eKcDrTcErWB/kQYYJxdk84ne922saKqNb2rJMVnZlDNC3PS0vlaTVU1GPSTJu2WJE9QKAFXvGbNTciBjMlsMVGx9lYEhC4JdRg07COkyCYvNCnkqENq6uwcGYmWX/xK7zwG8THboSBqD5W1EfSXAEfJGCSX9NGfkdfCs0z6CCZxayn+HlfF9o6CDtABFxKHQsKE+iuVkJwcz+oWSlaYgezn0mEcEt3SEd9cY/7tEufCzFWcukqC5xH7pfVay2V0t2IRMB8cj6uzwBEKgjWWkKjdwgZtQEgnxjVjqIJNs5oCvVhxdV/Y8Fg5E1SUpkeAyk2DyVpAacWJvG/Yg3CipmPBxlStTSpLXDbENFO1+isNaR9FGoRogXNNKuEmZopEb1bbsEcJl3PoRE953ruYzfV01ZpCWdhTPlAZ+3riL97p8GqdBmyYO X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY4PR08MB2520; BCL:0; PCL:0; RULEID:; SRVR:CY4PR08MB2520; X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2520; 4:MaW09p820tdM+G9zUtHo9plJHjBFClaCxJooGafbCgTTK1dlMsTC9BEyD1yXZprQlJ1guKXkTMQYpxOu8Y63B6Nx2QXtINF+zgJM9s8UQTqoCicDDgfDLlD+lpWlPWcjbtR+MqxYfifa5GgNenIsPzbj8fjZyXHakVsL2b87mQuE3WhidvHQC08NPi0SQvY3jZmp5Q9fzJqA7skUKvuV0nH/kSP75IUxAcIsCSDVQJ10u+BAIHypSRbw61jmGviBORff8TaLzWfzBdabHv96vI2yHJmxXx82XGVZ12H7jdEEM6qtnvJwLJ6DvUqfoxNnOx0gEz7HFquCJmUmtHeiF3Z7KNjkzw/pls46tYr9BMBX3sNnmRa51et3ocGFnE3l2YVC8n8XwVPPLSorLMYnSA== X-Forefront-PRVS: 008184426E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(24454002)(199003)(189002)(86362001)(77096005)(97736004)(305945005)(101416001)(189998001)(15975445007)(66066001)(92566002)(75432002)(107886002)(31696002)(83506001)(81156014)(31686004)(8676002)(7846002)(36756003)(33646002)(90282001)(81166006)(2950100002)(42186005)(88552002)(7736002)(5001770100001)(5660300001)(50466002)(65806001)(47776003)(6666003)(105586002)(65956001)(19580405001)(586003)(54356999)(89122001)(19580395003)(64126003)(4001350100001)(23746002)(3846002)(50986999)(106356001)(2906002)(230700001)(65826007)(6116002)(68736007)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR08MB2520; H:[10.211.130.238]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY4PR08MB2520; 23:GsiSCgRBkPZoZj3XYguDNj8beY/AU5EpJf4rQ?= =?Windows-1252?Q?PZbj/5XdqBageDzluB0GlsQifxU9w2MRS9KtN+uzPMTeU64pUeF+viqM?= =?Windows-1252?Q?hNaYYm2yIzzvIjR4SjfV0W612dxIbk0cOS5nN7HjLRTYBay0YQTCGhdg?= =?Windows-1252?Q?qgrmq4+Tr0E4ncj7X8DxsDOc7z6Uywoc5gDNmn5WVNWSTByXMwZiGpKh?= =?Windows-1252?Q?MdeBjGwD9iw+3oeRA8ZTItWs7cgBCP19cUlqYXIC9z3ihqHJGjITRcWS?= =?Windows-1252?Q?PTzveIW+KX+DCq/jNN9Cp34KnRuvTpCGDsCJ27yQXphfznQg2VzOQird?= =?Windows-1252?Q?Xj2gZcY2AlpSsYnXCI8oeejRSUJE9JIG0ajnFbwUlvLqtXkoCmmkTcxL?= =?Windows-1252?Q?NUmEeDhYW8pCrJ10IT5H+cXNI1wq3boq+Sd+f/2RiscsyQleTLl4nYaK?= =?Windows-1252?Q?++71y4NbXPVse05++4dv3/x4zd2rxTGWXWFkSGGqgZMJ0Q70EArfDS43?= =?Windows-1252?Q?rH3RrrP0JBDMQW7WAdZcdvmYQskKtXM1KtA9xUonAT/Kax2rU+tSY6w3?= =?Windows-1252?Q?eQtpsNFHogKXfabZkHGD9/bTDs3PP2rMdlD0Uuuylfs/g4YBx4WDz1g7?= =?Windows-1252?Q?QlVuc6pi6QpaJuNDBL6DPXRPUQ4FeWYFqMniUYD4htse6dUTwHcYBeMb?= =?Windows-1252?Q?Ljkt8Soj/R4+i0HQkTr7Rx9E8B58FbvuvNbpDYepT71xh3INILrq1Gpx?= =?Windows-1252?Q?xtwGe4si/xSqa3uCtV/DZ9iZf65HbQTS2lDYQZIbEoEDxzxDBc6AfCms?= =?Windows-1252?Q?zu1mGGqSo1e9eqcCVKVO1W318SRlHgBO352W6O3S+YyWENug8ewTmJU8?= =?Windows-1252?Q?oaIFaogmsUeIvptqL4FAeLcCjCKNDSqJhMVNVxHCYDCOcr4pu22+0A5i?= =?Windows-1252?Q?4fUIeDpp0vcAuDI8hzs1kC5PHyi64yUVPlInamVk1bMdmItULFPJHHf+?= =?Windows-1252?Q?O2PGe1bD6YeqYzbp/veB/0uDW4sCquPv6P3Gb4vcnyx3ysng0Lfn4YQT?= =?Windows-1252?Q?hNRdaQJx61bfFwyZlUZoNLfKk2PZiEDIuh98CeNb3Hmp3jy0x8rfNk2W?= =?Windows-1252?Q?6sMXBAkCYkgOuZ7QZ8JzlXb5nnTbe7YRP1Jvf/jXaCk+l0cVmLM2nED7?= =?Windows-1252?Q?4Cj1v1brggfOUS2XQGdj8rBeXA7oizCMhf5ciq8wX6ybGWDfYFIkaNN4?= =?Windows-1252?Q?2OGrMDk4ZEBHy6exBL+Q0mJhqrIhyu0919UYDGO+retxbjIyOcKbsfUN?= =?Windows-1252?Q?dD4YxRMCd0gGEnaZMm6tbhdJFC3Wvj4WC2DVBoREFuaU16H8pRkMqyYk?= =?Windows-1252?Q?wxhMemoTI3RP237n7nZcZE/pbmAdfzM4dEJG2N2PqOGZF8ksCJaA+VtJ?= =?Windows-1252?Q?1HbzDQalhiXxHmAW0WByPfAZgXC5Fy1ohfNjszKwjH+o0b30gFyzkXcp?= =?Windows-1252?Q?VJvcOmvVVuWtdyXF1Zg0QeBJmVjgn8CSmt/wBjVxo2yQ/UOFUe47SgGf?= =?Windows-1252?Q?xQpujte2Uvz8Go=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2520; 6:nuHZhcZtODtmLhGfwB2uOPKdd2b8f39YfFLgp4MzJvHgeflcVUJpbPOf9Z2ftUSPMXETyGb1Uq0pFNkfYbJQYIQHfiQ5UveLZHPTJyaoAeT/bAQND0XG9wwr9CrMKpTPTpTO3hDrwJksgubVhaZOpVs5AJTY9Kt9d5luJREdVnUB6m3XNbr4PZr+BFStEkrZBDYCghTB151NFnoNrJDy2zXSiqijrUaNKqLsGployFAZT0gwCQUokAArgwlDuzf7KmrDfJMvnhNLLf2prlH/Fc3zmE050Q7j+yLscswg+2M=; 5:wKhgFgZnFqjs77Q9iyOiP1p7bVdqbGLLvaKwKP/SO48s4clOSNPXUszXHkokQVCYZw6b65KGD9H4yb2TUQ7a83fQBy5MS3x4IZ2I2tf55TqCcGdx50LzHwBW+b79282EtGAW4rc0bnHaEQwj+tRxqQ==; 24:jL5Cgs1AWATD5lqG6Q5fMxp/zJQ7YMcKp2rqwjmWoUgie9Pqie6m7aYmjmAXJl3YnTRdAzM+PRblOL7JJAC/lFKjMHxta6sEPw0HmciYssM=; 7:jb7eu6Fy1VtOpyDXbwstgvKXe+s+RKfja3BTzj2dbY/32GuaBB5bA2uzmYRA/afJdWQKbKvmRWZ67QigK+t1ZygGTsQihO5rP6gQmBrWSB/ied5MfkRVNiLoifw6rNFZBDLz8mQM4BBAj3RXYZL2zH9ybN+oR9GabPbPAkQDUwIkEX/4gfbUUEBEfCe0DKwVgVkQ7Usvn7mj93jjn0yJ99WtBUYL79QHMESwbfNgBnLIAfzUwBwwdgsIo6+mQZYQNDImU8EEwkBHFYMMZuz88q98NrkRox0Nyd4so4BrkOKKYi03iyf8Z7CHOXf3oXAs SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2016 19:28:27.5130 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR08MB2520 Archived-At: Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 19:28:31 -0000 Hi Marcelo, Please see my replies below. Thanks On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: > Hi, > > Does cubic assumes that there is a different phase when the connection > starts? i.e. slow start? It may be worthwhile stating this explicitly? Yes, there is still the slow start phase. > > In the current draft, it always reffers to a packet loss event, but I > couldnt find how is the packet loss detected i.e. via duplicated ACKs > or via timeout. Is the reaction of cubic the same in both cases? Does > it reduces the window to 1 MSS and enters in slow start if the loss is > detected via a timeout? > Yes, it refers to a packet loss event inferred by dup acks. In this case, both the slow start threshold (ssthresh) and the congestion window set (cwnd) are set to cwnd*(1-beta), and then CUBIC increases cwnd according to a cubic function described in the draft. In case of a timeout, ssthresh is set to cwnd*(1-beta), and cwnd is set to 1 (CUBIC does not change this value). Thanks Lisong > Sorry if this is already in the draft and i missed it. > > Regards, marcelo > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Sep 30 15:32:08 2016 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 4983C12B00C for ; Fri, 30 Sep 2016 15:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 61fNa0IJcWnG for ; Fri, 30 Sep 2016 15:32:05 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 EA6AC1200DF for ; Fri, 30 Sep 2016 15:32:04 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id m79so73037564ioo.3 for ; Fri, 30 Sep 2016 15:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ccMqP1Xc7JzcD1k+KJCQbx5YpV7CUO6djX09iqdYHBE=; b=A0t9+CxWPlXvnTamCIPmZ+2dkoWATmKW7KMcceQ2CW/IGJICBf1d6XZKksQrMRO7Sa iVOk8/Vxa73c1l/GTeHFwZ3ggyMtvhpzRsLktkUWFmC/cUDahNqPyLwaE+KvHHeRFamm iB9jciYUFF4YSbRoGgLPx1TMjsfJEZvyTGajDaJIK86hUi+F510CjB1VOiqG+edh2s6j gjcKJOcxbGX5ZRB/k61Gj4wlph19OjK+a0y/U+fLB7cCeeifTQMrlSXk/iAT59DU79RR H8NX4V2dSoO2kYF11Xn3NZtsg+EgtoHa2MdjTz+FnqCMrWkkevKmiEObR4Y7HYVvEKT+ g2lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ccMqP1Xc7JzcD1k+KJCQbx5YpV7CUO6djX09iqdYHBE=; b=J6Mt0YRg6IABNNw2y1EtAKTVfB6aJLCHdNQLw6zTNTiCgU0w/gcSiR0cxclliex1Zo 24fn/lxNZZbAghAwZgjgDOy8DAzUkqK4t5UYfC/VjS2Gru1sZBvHp/W2G+V9Gf7i+/ao js4F9oWFbkr3mHrCcoe2UiT3okP/GIg+f43RE2E+CGKCKdz6s14wIH/gzs/azTDpYC/U XZSdzg0BXZwRZcwDP63kelFK/6FxaN7w2WHx90cG1hIDDZlpgig73R9stCNgeV/q/+yC QW6WvvgwgDnf6ose9mCefwzvKOqnFUovirPHw3Rzk8UEhTgBMYifF6vGS5AQI0tdMuWQ FgBQ== X-Gm-Message-State: AA6/9RlwbCUx0bcwzbfGr31DDEHzh17a2Nlpps9uZQwJ/IA97lGqtO6CMzgziJCGh+Xl7HLPvuNhwELnLx2j5dav X-Received: by 10.107.181.211 with SMTP id e202mr10879086iof.99.1475274723528; Fri, 30 Sep 2016 15:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.135 with HTTP; Fri, 30 Sep 2016 15:31:22 -0700 (PDT) In-Reply-To: <201609301923.u8UJNHmF009945@ngzemlsmt04-prd.corp.netapp.com> References: <201609301923.u8UJNHmF009945@ngzemlsmt04-prd.corp.netapp.com> From: Yuchung Cheng Date: Fri, 30 Sep 2016 15:31:22 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [tcpm] Fwd: Returned mail: see transcript for details X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 22:32:07 -0000 btw, the emails of some authors are invalid. please update. ---------- Forwarded message ---------- From: Mail Delivery Subsystem Date: Fri, Sep 30, 2016 at 12:23 PM Subject: Returned mail: see transcript for details To: ycheng@google.com The original message was received at Fri, 30 Sep 2016 12:23:17 -0700 (PDT) from vmwexchts01-prd.hq.netapp.com [10.122.105.12] ----- The following addresses had permanent fatal errors ----- "|/usr/local/bin/mreject srichard" (reason: 1) (expanded from: srichard) "|/usr/local/bin/mreject alexandz" (reason: 1) (expanded from: alexandz) ----- Transcript of session follows ----- 451 4.0.0 putbody: write error: Broken pipe sh: /usr/local/bin/mreject: not found 554 5.3.0 unknown mailer error 1 sh: /usr/local/bin/mreject: not found 554 5.3.0 unknown mailer error 1 Final-Recipient: RFC822; rs@netapp.com X-Actual-Recipient: X-Unix; |/usr/local/bin/mreject srichard Action: failed Status: 5.0.0 Diagnostic-Code: X-Unix; 1 Last-Attempt-Date: Fri, 30 Sep 2016 12:23:17 -0700 (PDT) Final-Recipient: RFC822; alexander.zimmermann@netapp.com X-Actual-Recipient: X-Unix; |/usr/local/bin/mreject alexandz Action: failed Status: 5.0.0 Diagnostic-Code: X-Unix; 1 Last-Attempt-Date: Fri, 30 Sep 2016 12:23:17 -0700 (PDT) ---------- Forwarded message ---------- From: Yuchung Cheng To: Lisong Xu Cc: marcelo bagnulo braun , tcpm IETF list , Date: Fri, 30 Sep 2016 12:22:15 -0700 Subject: Re: [tcpm] Another question about cubic A small suggestion: the loss event may imply one single packet drop. But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss event, not N loss events. And 3 packet drops in round trip 1 plus 6 packet drops in round trip 2 mean 2 loss events. A fast recovery can span across many round trips if retransmission is lost again. It might be worth clarifying that otherwise the (incorrect) implementation will be a lot slower. On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu wrote: > Thanks, Marcelo! > > We will revise the draft to more clearly explain the protocol behavior > according to your discussion with Joe yesterday. > > Thanks > > Lisong > > > > On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: >> >> Hi, >> >> Does cubic assumes that there is a different phase when the connection >> starts? i.e. slow start? It may be worthwhile stating this explicitly? >> >> In the current draft, it always reffers to a packet loss event, but I >> couldnt find how is the packet loss detected i.e. via duplicated ACKs or via >> timeout. Is the reaction of cubic the same in both cases? Does it reduces >> the window to 1 MSS and enters in slow start if the loss is detected via a >> timeout? >> >> Sorry if this is already in the draft and i missed it. >> >> Regards, marcelo >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Sep 30 16:13:22 2016 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 CC8A512B00C for ; Fri, 30 Sep 2016 16:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316, SPF_PASS=-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 ZbSUHphYxHoj for ; Fri, 30 Sep 2016 16:13:16 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78305128B44 for ; Fri, 30 Sep 2016 16:13:16 -0700 (PDT) Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com [209.85.217.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 14C18318AC9 for ; Sat, 1 Oct 2016 08:13:14 +0900 (JST) Received: by mail-ua0-f173.google.com with SMTP id l16so88577061uaa.1 for ; Fri, 30 Sep 2016 16:13:13 -0700 (PDT) X-Gm-Message-State: AA6/9RlfI5SzQtGtLhLXO2kKkK1Dd1rsfTmagZB/dejAiBs9BMh4b1xgHLPlYPSy3i3ELmemD/wIBndOBY7DMA== X-Received: by 10.159.55.138 with SMTP id q10mr7154580uaq.131.1475277192557; Fri, 30 Sep 2016 16:13:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.33.210 with HTTP; Fri, 30 Sep 2016 16:13:12 -0700 (PDT) In-Reply-To: References: <201609301923.u8UJNHmF009945@ngzemlsmt04-prd.corp.netapp.com> From: Yoshifumi Nishida Date: Fri, 30 Sep 2016 16:13:12 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Yuchung Cheng Content-Type: multipart/alternative; boundary=94eb2c041f2201fdef053dc1bd9f Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: Returned mail: see transcript for details X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 23:13:20 -0000 --94eb2c041f2201fdef053dc1bd9f Content-Type: text/plain; charset=UTF-8 Hmm. a simple work around might be to not include draft-ietf-tcpm-cubic@ ietf.org for the time being and wait for updating authors' mail addresses in a new version. -- Yoshi On Fri, Sep 30, 2016 at 3:31 PM, Yuchung Cheng wrote: > btw, the emails of some authors are invalid. please update. > > > ---------- Forwarded message ---------- > From: Mail Delivery Subsystem > Date: Fri, Sep 30, 2016 at 12:23 PM > Subject: Returned mail: see transcript for details > To: ycheng@google.com > > > The original message was received at Fri, 30 Sep 2016 12:23:17 -0700 (PDT) > from vmwexchts01-prd.hq.netapp.com [10.122.105.12] > > ----- The following addresses had permanent fatal errors ----- > "|/usr/local/bin/mreject srichard" > (reason: 1) > (expanded from: srichard) > "|/usr/local/bin/mreject alexandz" > (reason: 1) > (expanded from: alexandz) > > ----- Transcript of session follows ----- > 451 4.0.0 putbody: write error: Broken pipe > sh: /usr/local/bin/mreject: not found > 554 5.3.0 unknown mailer error 1 > sh: /usr/local/bin/mreject: not found > 554 5.3.0 unknown mailer error 1 > > Final-Recipient: RFC822; rs@netapp.com > X-Actual-Recipient: X-Unix; |/usr/local/bin/mreject srichard > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Unix; 1 > Last-Attempt-Date: Fri, 30 Sep 2016 12:23:17 -0700 (PDT) > > Final-Recipient: RFC822; alexander.zimmermann@netapp.com > X-Actual-Recipient: X-Unix; |/usr/local/bin/mreject alexandz > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Unix; 1 > Last-Attempt-Date: Fri, 30 Sep 2016 12:23:17 -0700 (PDT) > > > ---------- Forwarded message ---------- > From: Yuchung Cheng > To: Lisong Xu > Cc: marcelo bagnulo braun , tcpm IETF list > , > Date: Fri, 30 Sep 2016 12:22:15 -0700 > Subject: Re: [tcpm] Another question about cubic > A small suggestion: the loss event may imply one single packet drop. > But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss > event, not N loss events. And 3 packet drops in round trip 1 plus 6 > packet drops in round trip 2 mean 2 loss events. A fast recovery can > span across many round trips if retransmission is lost again. > > It might be worth clarifying that otherwise the (incorrect) > implementation will be a lot slower. > > On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu wrote: > > Thanks, Marcelo! > > > > We will revise the draft to more clearly explain the protocol behavior > > according to your discussion with Joe yesterday. > > > > Thanks > > > > Lisong > > > > > > > > On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: > >> > >> Hi, > >> > >> Does cubic assumes that there is a different phase when the connection > >> starts? i.e. slow start? It may be worthwhile stating this explicitly? > >> > >> In the current draft, it always reffers to a packet loss event, but I > >> couldnt find how is the packet loss detected i.e. via duplicated ACKs > or via > >> timeout. Is the reaction of cubic the same in both cases? Does it > reduces > >> the window to 1 MSS and enters in slow start if the loss is detected > via a > >> timeout? > >> > >> Sorry if this is already in the draft and i missed it. > >> > >> Regards, marcelo > >> > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --94eb2c041f2201fdef053dc1bd9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm. a simple work around might be to not include=C2=A0draft-ietf= -tcpm-cubic@ietf.org=C2=A0for the time being and wait for updating= authors' mail addresses in a new version.
--
Yoshi<= br>

On Fri, Sep 30= , 2016 at 3:31 PM, Yuchung Cheng <ycheng@google.com> wrote:<= br>
btw, the emails of som= e authors are invalid. please update.


---------- Forwarded message ----------
From: Mail Delivery Subsystem <MAILER-DAEMON@netapp.com>
Date: Fri, Sep 30, 2016 at 12:23 PM
Subject: Returned mail: see transcript for details
To: ycheng@google.co= m


The original message was received at Fri, 30 Sep 2016 12:23:17 -0700 (PDT)<= br> from vmwexchts01-prd.hq.netapp.com [10.122.105.12]

=C2=A0 =C2=A0----- The following addresses had permanent fatal errors -----=
"|/usr/local/bin/mreject srichard"
=C2=A0 =C2=A0 (reason: 1)
=C2=A0 =C2=A0 (expanded from: srichard)
"|/usr/local/bin/mreject alexandz"
=C2=A0 =C2=A0 (reason: 1)
=C2=A0 =C2=A0 (expanded from: alexandz)

=C2=A0 =C2=A0----- Transcript of session follows -----
451 4.0.0 putbody: write error: Broken pipe
sh: /usr/local/bin/mreject: not found
554 5.3.0 unknown mailer error 1
sh: /usr/local/bin/mreject: not found
554 5.3.0 unknown mailer error 1

Final-Recipient: RFC822; rs@netapp.com
X-Actual-Recipient: X-Unix; |/usr/local/bin/mreject srichard
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Unix; 1
Last-Attempt-Date: Fri, 30 Sep 2016 12:23:17 -0700 (PDT)

Final-Recipient: RFC822; alexander.zimmermann@netapp.com
X-Actual-Recipient: X-Unix; |/usr/local/bin/mreject alexandz
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Unix; 1
Last-Attempt-Date: Fri, 30 Sep 2016 12:23:17 -0700 (PDT)


---------- Forwarded message ----------
From: Yuchung Cheng <ycheng@google.com>
To: Lisong Xu <xu@unl.ed= u>
Cc: marcelo bagnulo braun <marcelo@it.uc3m.es>, tcpm IETF list
<tcpm@ietf.org>= ;, <= draft-ietf-tcpm-cubic@ietf.org>
Date: Fri, 30 Sep 2016 12:22:15 -0700
Subject: Re: [tcpm] Another question about cubic
A small suggestion: the loss event may imply one single packet drop.
But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss
event, not N loss events. And 3 packet drops in round trip 1 plus 6
packet drops in round trip 2 mean 2 loss events. A fast recovery can
span across many round trips if retransmission is lost again.

It might be worth clarifying that otherwise the (incorrect)
implementation will be a lot slower.

On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu <xu@unl.edu> wrote:
> Thanks, Marcelo!
>
> We will revise the draft to more clearly explain the protocol behavior=
> according to your discussion with Joe yesterday.
>
> Thanks
>
> Lisong
>
>
>
> On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote:
>>
>> Hi,
>>
>> Does cubic assumes that there is a different phase when the connec= tion
>> starts? i.e. slow start? It may be worthwhile stating this explici= tly?
>>
>> In the current draft, it always reffers to a packet loss event, bu= t I
>> couldnt find how is the packet loss detected i.e. via duplicated A= CKs or via
>> timeout. Is the reaction of cubic the same in both cases? Does it = reduces
>> the window to 1 MSS and enters in slow start if the loss is detect= ed via a
>> timeout?
>>
>> Sorry if this is already in the draft and i missed it.
>>
>> Regards, marcelo
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--94eb2c041f2201fdef053dc1bd9f-- From nobody Fri Sep 30 20:00:54 2016 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 7E2B512B1D9; Fri, 30 Sep 2016 20:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOVQoQYhNVAN; Fri, 30 Sep 2016 20:00:50 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0049.outbound.protection.outlook.com [207.46.163.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C669D12B034; Fri, 30 Sep 2016 20:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q0bDFAk3sM3hGQsHMfFXihInE7mv4dQLzinRX9Gdxpk=; b=AYi6Ay577gDjwe7uWsHVVOH5ifj+qcFBiWpdO+ZRIsnVMQD7j1dgW+/dixDm0mBrW3bMpieDPz8SRRf7gM3d+8Uvb1RdjKBLnBJXICpyuWlzJaJwHoAyweIPDoEU5IkZi4qjnzjPbdKgWe2t2bz9pvm4wBE9gsyD5QAxPqBvM5g= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.164] (97.98.140.59) by DM5PR08MB2522.namprd08.prod.outlook.com (10.173.220.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.619.10; Sat, 1 Oct 2016 03:00:35 +0000 To: Yuchung Cheng References: <2b315b93-3121-8d86-a5b2-6428844f1dc2@it.uc3m.es> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Fri, 30 Sep 2016 22:00:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: YTXPR01CA0003.CANPRD01.PROD.OUTLOOK.COM (10.165.183.141) To DM5PR08MB2522.namprd08.prod.outlook.com (10.173.220.136) X-MS-Office365-Filtering-Correlation-Id: 3fd4eca4-3262-4183-a931-08d3e9a71dfe X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 2:Egbc5ilepNRMx0Ji11lRBQRSoTDX9gxQ1H1tRHksAlzzGdWtzsOFsiDEQHB3jSbRskP9RMiu1VqXyVruiojUwywfMkvAo7klcXxITWkXz1EOLA0fwhH9BtIZgAEls7fKdyBZlf3wEimCdBHeawpnglyGGshjRj6OXJObJJKGsk9Z7xjPvIRa33COlCxEsqde; 3:NTY6oq+eVj6X8WaVtdepyt9I+2QGwn8hQ6on4qnC/mTdYoEst2+6u2brivUee6GXkfEbyvu+XGqkCrUuJsD104AnPLAOR3MhrB2PnA1aTfEHCG2H0+zIr8HdpNjzOoSt; 25:KHOD6tuMMQxqpydjzG3tW2ssq1RCa0rp6iJlrF/+3d6mQOFjWEINKz1cl9G5h1ObqxvScFdNb+8lHpKVhyOvF0BsPlpdJXeHCyfmgxj84/KbH/tBBl+e/8dg+/rlfDb0nHuNAGTifB9vMip62b/vfOKuuo6BQE1qT5U0XEk1S2cmx2M3wTZPvqTq5SVOeDBJhmSbauCSi1TwgMhuCog+gGc6l0X5F/x8RrzUnSWo0FZ6TxqXl70E1F2B16J1Obg1wNDCTdECS+em5V3rhTRRulyuRBEu9cqB8lXLRIh7tuq2RUKoqEnsQlKk4DDgu7NgOYFcRuU1rn7EVQx6CzKfokpxkQjI/mwuzOrxgJoz6nDuMhSo0m0jT4YxALHxu8pVRbwjLR1ounbkDfCWaFiFr2bnbnzrLsHlCcxnM2gKIo4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR08MB2522; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 31:DPSDxY7jOj4iqNsoekNmoolaxnw0lJctwwLMeyZvVVoa6/+89vETVN9Eq6PfEEGOH8fqAaT1u1PIZlE7DrB1OPuXOJ9M5vkCL57xVoGD6Ic1u2DVhol1wGPM/rZ+05QV4W9PRKTtal7wqbFdaHtZsrMT0dFGt3hH3HglRd2qP6KYzheSWfdsyO4QmhB3I278aoGhLc0b2yqvb+sJttLo3odmxC946jFoHNDQGZk9xV8=; 20:TskfPkeV7nRhrRi0WOscAAQYIaNQJgK3+fDzPx4aBv4qBicOnIQhCMpRaLGzZ4Ezuf6ONmzWj+R/K03WcUwDVcgRrnpqw+8os2yr9EFcB2gJHH2aI68aiJnn1YZHEULchCwREeGeWmvCovbnFFs2uRuZ92V1H1YjsI02AdDU52azZHGA1gT3HAdnHY4mNdqmBbDS64WNV9GJ4XM1ljfKGw/580ZY7rr93XgyrLytlm5fYof/W73mzadnpEyx1XsquCA86G1XHG3LwVjWpV6a9O5f0aJosCT/7OVatx1Wz1+XdXHmBjta8QahjxmjHKomUh0UDSqD2HVV7bhi2sGKeFxp7lO3pMsGwzHnGI4FR5bUefTJv368H0bv7zPOrt5BWZvI/sybD6gEY7vB0cqxp3NJHgUslFLG7uW3DZyHkRW0LBHn2yl1pd2j3F/H2E3JTeUAyJMeQSspklaEEx6+S8I5iaun3bpcVLcIPhlRGOzFSCsuR38H71YAQWhJ1cg7 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM5PR08MB2522; BCL:0; PCL:0; RULEID:; SRVR:DM5PR08MB2522; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 4:yAQXegzkhYdg15SRQDz7wqP9nV+wsT0bxZa9i+xU+FaXXh0udcwM1uovucagaHOyPvdBlUNEPowVGj1LY3lHmt3PrTXG35cxu2aJr8QallezCnsqHJfleXLtSx0X4X0z4l7ff54Ynq1m+Dka0X+7tACqtPJvgNRRiho8teT/SLBfXFKxGq/JfeR7GpM88YuMpRs1MkVuRGmHuVrV47WtuEvVMDoq8keZbHPtyEYeke9QnDTUFaWfItEZ+qT8IFDhCbfh6Ca6GhzA66LtSBjN5QAEeFY6njEfYFyxQZVsKEpKcdo+ep4c/MJXvRy478PLlsY1g/8BWiPE/qbWanw/0cw888rfiMLNYuagatHDSbUFWyO5ISBO4Bv7AB6BZ88c7PB/AP/l84xKhmKFb4JvJQ== X-Forefront-PRVS: 00826B6158 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6049001)(6009001)(7916002)(24454002)(199003)(377454003)(189002)(4001350100001)(7846002)(106356001)(117156001)(64126003)(47776003)(5660300001)(189998001)(19580405001)(50986999)(23676002)(6116002)(101416001)(90282001)(7736002)(19580395003)(2950100002)(89122001)(65826007)(54356999)(586003)(230700001)(83506001)(3846002)(76176999)(36756003)(68736007)(110136003)(77096005)(6666003)(305945005)(15975445007)(2906002)(97736004)(65956001)(8676002)(50466002)(88552002)(92566002)(81166006)(75432002)(65806001)(4326007)(31686004)(33646002)(86362001)(66066001)(31696002)(105586002)(42186005)(6916009)(81156014)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB2522; H:[192.168.0.164]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjA4TUIyNTIyOzIzOmYyd21tVktJK285RHI2S0hWTXZuZGVYM1dC?= =?utf-8?B?NEczaGEyblZ5VitiN3VDK3YxZXpkUE1rajB4QUlsSzNzbGJHYnlDUmo2eWll?= =?utf-8?B?bVdYcjFOSTkwTGNvUDI4VHpxajdlTmQ5SGV3eFF1RXZwblBrb3R2endKZkJr?= =?utf-8?B?UTMzME5rSUlhT21rbU55RU90aTVEdC9KVzkxV2VRcnRFZys5U1N4NWVYeWhC?= =?utf-8?B?a1BXWWZEMVhnSUc4UGpnd1I1KzduYXliNG5OQTg4ZTFkdlFPVm51QWgwa0Q2?= =?utf-8?B?cWJXbmF0UDU1dDAxMFVSUGhNd0N2UlJITmU1Y2Z1SjNlSEpXZXVNK1hZb1Y1?= =?utf-8?B?UWczeEhxRFlBVENkYis4T0tNeHRSNFBLTkdDU2NvTjFCYnNwNGlGN0ZiQUVB?= =?utf-8?B?MGNKVEd1Mi9xOW5pSEhxMzBvcXZIYzhtWDFpUENqUjFHbnN3bVdJMFFaR3FY?= =?utf-8?B?ZENuUnpsMHFYeEY4ck5LdkNXd3NPK2VNSCt3dFJCQlc0L2YxVGVPbVBXdUtC?= =?utf-8?B?NnVnT1JEQWxOeCs4ZTVUcEY2TWpId1pRcmtEWmlpK2o3TnVJRTZpKzZQVkdz?= =?utf-8?B?OGR2M0ZreWFEUUdUK3dUdGlMTmdRMFB4dlVxVnpydzd1dUhvT1Z0enBLWURZ?= =?utf-8?B?cFJsYm1xUVI1MFJPYkFTWjdUaXRzM1lWb01ISGhGTnV5ZS8zWXREc3luZ0Q1?= =?utf-8?B?eGpkaXhOSmh6d3pBNnpEUnYraUpnSGg4WGlCemV0MnF3bUZZSG9zbmFib3hE?= =?utf-8?B?bkZVMDdydStWdCtsNDNwcTNydWFmckdQSnBuTmgxMXpNQ0htRWc2UjRtNFdl?= =?utf-8?B?aVV6VjExeFVzUnJwamdJYnFzQzFHQVVoNlEzUUs5TE9GWHlJZUJENW9nRFpq?= =?utf-8?B?bjY0dzgyZEpvOVN5Mk5JU2RyMnFVNzc4dHgxL0RSWitpYlQ5Y3RqN0hXSDhz?= =?utf-8?B?ZzFXMEZNc2x5em83cWNnZWN5UUFBR0R5VjRENWlGMy9Uc09tdDNaTlpDc1JH?= =?utf-8?B?YyswWVBNbE5jMWdrZ294b21rUjJKSytTampxL1FLa3dNUW05N1JlYjNWaDV2?= =?utf-8?B?U1NyVHR3MlFUZDNobXRkMGk0aHZSbDVXUjRtOUN0UnR1c1owWDR2ZTZGbTdo?= =?utf-8?B?dkVSdTQ1VkZRUkRHTGIrd0NIcDJVSkswZnRHd3hEbi9hdGhXUGMxQ0o0SFZX?= =?utf-8?B?Wlg4MUh3R21rTFBRTlFGRW54ZndxdDJHQ1FpSnNmeUgxdTRpajY3MVJzcjR4?= =?utf-8?B?MUU3Mzg3bkk2Y21BTzRMb3ZYaDI3cnFqNmpPeEdKUFg2bGdHbFdnWElUVk8x?= =?utf-8?B?QTMwdGpheU1BdnlmTEtXZHJDK3NBclNmcUtLWW53b0JoTDlRL0piUmEzTXNm?= =?utf-8?B?QUpJVXBwMXQ1cG80OTJGU1pVY2Y1NU9FNjVobzh0Q1dybzFtVjFhc1FGMW9o?= =?utf-8?B?bUJVOE0rdkNvbjNreWtLS2ZtMWdINjZpM2FCMTFVZkJnclk5SVozRjVLRERJ?= =?utf-8?B?SWI0QlpONzJJT0pFMHRPZlh6UEs1eVpQWndSeEFjc0lqMmJmSmg3NnlSSU9j?= =?utf-8?B?clhWclFpanIrdXMweXV4UHNhN0NjODVzekNUUVZhU015MGJEaEdtUE9xbitk?= =?utf-8?B?cHlLazY3SjFKVHRjaG1aNHc4dCtaend3M1RtcVY2YnlWbnFsYzNBdlZRWnpJ?= =?utf-8?B?ZHZXT2pVSlhYVUtMNlFrenc5SFdkYm1pVUlqR2k0WU1oMFhselgvdll5N0Yx?= =?utf-8?B?WG9WZmdNb3lVNXFqanR3YUNaQnd3NHZqbmE5ajZkUlNQc3hjNWt4bnFMN1Vo?= =?utf-8?B?ajlqak9QUGhMMDZzOUlleWFXRm5wWjdLalVmRXRwL0tneVorSGJsbHpYSEcw?= =?utf-8?B?ZzRBUTUyMzcwUjZkMWVNclNFU3Z1ZVV2b1pQbFVoV2cxVC81OC9uZUdGWWl2?= =?utf-8?B?UFNwWVp6eGxGRFZnbGZ3ZWdMaW8wczNpUkdtOFUrNnV3Ym5kNU1JbzY0SFBa?= =?utf-8?B?RFhjTUJMdFRxYld6TnFKOS9WRlhkOEFnNTd3VEJZSTRFTFRkZFBHRVFtL3dK?= =?utf-8?B?b1B6L29RK1JsZnJBYUFaWHhpZGtoMjh0OWh6VEErV2MzWm8wTWk5Wkk1T3ZG?= =?utf-8?Q?iBt+ZZc6YibDC8pKXm6j/cM=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2522; 6:+aj2eKsQW5nDJk9GiZbC55xoSq8+mJ7VlbFFLb1E3VqLXUhS9J/suq2i7AhdHmJAw1wpgkkubHFO0GOUsgN2UPUiXiKQVnApfRMNcP2khT6Lb0omFae29uuvqNPdkZOGZ02VL/4eIbSLdrFgKpIWknID2h5jRJCeqEX6bo+WQnWsEWGt8maAGzg3uT8QQOSx1PvATDy39NPeOvRIDuAIWOotBK47pjvSk2RUGP8JtmTqoZnNb/qKJbAlR1DBjVU8KlnNjxD04ho5Rqqhk4y/F/WifhNYOnmnmeNHX+Tk+Rg=; 5:LDxRo1zYHcsMm04Iz2G/T4P4Df9TpEO+pW4dbGf6DYcuj0wlqIlsp8sMAPG6TjvfxV6m9CjTAftuHqFZt1JN9U23ItObwYqtcvnVRXwAuvzgVAsAvIrn8qk0GHFEUUNmRGbbJoVUMdWvwpmxcrvHCQ==; 24:3SyWm92j5jrVoh7NQWuxgnhJWuSRdXcClEhuKMwHRob6NNHR6iYLysO7kgChazMHaQwBzbyTWYLb6SIPTg8Y14HAqlBHkqRZaLAp+AotOSY=; 7:yOCNSbFiUvaLX/2XchBzvjIguTrWnCR2dSiGd2RES3fSmOoy+6yJe47dxhZNMNYE0F5pOjErGPoI9Th9XL4dNn4S+Kvv++qH3VsVR4JB4EM4XRScYFvR+xyAJx9igfCx+IJJq2LXqpUYKjIlqk8koeQsZJVgvWJSFrTdmHJRDJeBvwGrA//d/nhOcvBokXDviNC5P5Zq28RM3pgeE+B5SA7PQxfX2dmbqmnf5dpqJIgpFnBEQnH1JchiyWbmZoo7+PLACzZZK9kE1fiz8QfNm9jZItTDPzdCQgrjp2ZE34AAKH8u5qninun+aBooZZwI SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2016 03:00:35.1752 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2522 Archived-At: Cc: tcpm IETF list , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] Another question about cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 03:00:53 -0000 Hi Yuchung, A quick clarification about your example "3 packet drops in round trip 1 plus 6 packet drops in round trip 2 mean 2 loss events." If the 6 packet drops happen during the fast recovery of the 3 packet drops, TCP stays in the fast recovery until all lost packets are successfully recovered. In this case (assuming no retransmissions are lost), ssthresh is reduced only once, and there is only one loss event. Right? Thanks Lisong On 9/30/2016 2:22 PM, Yuchung Cheng wrote: > A small suggestion: the loss event may imply one single packet drop. > But AFAIK about Cubic, N>0 packet drops in one round trip is 1 loss > event, not N loss events. And 3 packet drops in round trip 1 plus 6 > packet drops in round trip 2 mean 2 loss events. A fast recovery can > span across many round trips if retransmission is lost again. > > It might be worth clarifying that otherwise the (incorrect) > implementation will be a lot slower. > > On Fri, Sep 30, 2016 at 11:11 AM, Lisong Xu wrote: >> Thanks, Marcelo! >> >> We will revise the draft to more clearly explain the protocol behavior >> according to your discussion with Joe yesterday. >> >> Thanks >> >> Lisong >> >> >> >> On 9/29/2016 1:13 AM, marcelo bagnulo braun wrote: >>> Hi, >>> >>> Does cubic assumes that there is a different phase when the connection >>> starts? i.e. slow start? It may be worthwhile stating this explicitly? >>> >>> In the current draft, it always reffers to a packet loss event, but I >>> couldnt find how is the packet loss detected i.e. via duplicated ACKs or via >>> timeout. Is the reaction of cubic the same in both cases? Does it reduces >>> the window to 1 MSS and enters in slow start if the loss is detected via a >>> timeout? >>> >>> Sorry if this is already in the draft and i missed it. >>> >>> Regards, marcelo >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm