From nobody Wed Mar 1 02:18:37 2017 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 F2BBA129967; Wed, 1 Mar 2017 02:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wANDoIxEXrb; Wed, 1 Mar 2017 02:18:34 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 79ED3128824; Wed, 1 Mar 2017 02:18:34 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7BACF7604A607; Wed, 1 Mar 2017 10:18:29 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v21AIUS5029734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Mar 2017 11:18:31 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v21AIF1w028639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Mar 2017 10:18:30 GMT Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.65]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 1 Mar 2017 11:18:14 +0100 From: "De Schepper, Koen (Nokia - BE)" To: "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSht1kq1X/jxxo5k+Qc2zpAI+3x6F/wR9A Date: Wed, 1 Mar 2017 10:18:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 01 Mar 2017 10:18:37 -0000 I have a comment on the following text: It would be useful to implement DCTCP as additional actions on top of an existing congestion control algorithm like NewReno. The DCTCP implementation MAY also allow configuration of resetting the value of DCTCP.Alpha as part of processing any loss episodes. Setting alpha to its max value (btw resetting might imply setting to zero) = has many=20 complications and in the current Linux implementation turned out to not fun= ction. The Linux patch I provided additionally halves the window (once per RTT) wh= en a=20 drop is encountered, independent from alpha. This is also, as far as I unde= rstood,=20 how the Windows version works. Both implementations are working now in drop-based networks next to Classic TCP flows. As far as I know there is no working implementation that is setting alpha t= o max so=20 I propose to describe the working implementation instead of a theoretical o= ne. For the rest I support publication. Koen. > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Nokia - DE) > Sent: dinsdag 14 februari 2017 17:32 > To: tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 >=20 > Hi, >=20 > TCPM chairs are not aware of outstanding issues in draft-ietf-tcpm-dctcp-= 04 > "Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters". >=20 > Therefore, this e-mail starts a working group last call for draft-ietf-tc= pm- > dctcp-04. >=20 > The WGLC runs until Friday March 3. Please send any comments to the TCPM > mailing list by then. Statements supporting the publication of the docume= nt > are also helpful. >=20 > We assume that TCPM working group is aware of the IPR disclosure related > to draft-bensley-tcpm-dctcp-00 (https://datatracker.ietf.org/ipr/2319/). = A > separate note will be sent out to confirm that all IPR has already been > disclosed, in conformance with BCPs 78 and 79. >=20 > The draft is available at https://tools.ietf.org/html/draft-ietf-tcpm-dct= cp-04 >=20 > Thanks >=20 > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Mar 3 15:56:20 2017 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 BBCB9129501; Fri, 3 Mar 2017 15:55:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532076.15846.17963408999914742468.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:20 -0800 Archived-At: Cc: tcpm@ietf.org, ietf@kuehlewind.net Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 98 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, 03 Mar 2017 23:55:21 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:30:00) Wednesday, Morning Session I 0900-1130 Room Name: Zurich E/F size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- 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: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig maprg rtcweb rmcat teas Third Priority: ippm People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Meetecho support in room Special Requests: A plus BoF/WG would also be a first priority conflict --------------------------------------------------------- From nobody Fri Mar 3 16:41:08 2017 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 F1BD7129405 for ; Fri, 3 Mar 2017 16:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICJamIezBqX0 for ; Fri, 3 Mar 2017 16:41:05 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0138.outbound.protection.outlook.com [104.47.38.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2BD129438 for ; Fri, 3 Mar 2017 16:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4q7keRLsJYVPvjmQFb++jC11fsN73SSqTDl+a2Hzf/U=; b=dlDm4Le98uNxvHz0oe4EzVY8HjvkcL318vp8nTBFjBzvZlwFQODWU1gaf9dPWztzxkJFePktLyRj8LqaNCKj9ndB07/3EWa2eHCXYXUJfBL2LNOxu68mc8SF1sbMfAuMZQTHDAw6tb+ARPzjo1vCvYwpfkq7N0QxMcDg1gp08yM= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0278.namprd21.prod.outlook.com (10.173.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.3; Sat, 4 Mar 2017 00:41:02 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0947.012; Sat, 4 Mar 2017 00:41:02 +0000 From: Praveen Balasubramanian To: Yuchung Cheng , "tcpm@ietf.org" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSht1kq1X/jxxo5k+Qc2zpAI+3x6F/H+QAgAFqKZA= Date: Sat, 4 Mar 2017 00:41:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::584] x-ms-office365-filtering-correlation-id: b53689fb-393b-4f54-924a-08d4629722b3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0278; x-microsoft-exchange-diagnostics: 1; CY4PR21MB0278; 7:KtaxQ97K3mp9QQShwCQc2KLW+kws/A7aXRuuhk48+yhUu9Wf+jFcfVBWgAFMc11wkmp9umhaWpLC77OhNyoClC1ZkN+BIrkk6OHzHefb8v8P58WBCV2f1Bcjs/MZxGhMnTSWhVC0vbl8zBU3Lwouv+e68D8Jlb2Ly+DlrMRAxQCPwpjLU0QwWorIfjMpnxmR3lMxuoFdYfTj6NsypZ2noKf8fSF0rcEWMOnugmWkccGSMCuw90tuaQpy6m6A8XmnVTjcpSmqseVOexcy7PJxee6n5c1kC9Qdb0KcPQ37o8WNZyC7OcR8lCFYkENg5CpNZxi/bTADQvn+OP0+bcARi4B9U8A5eSrXQC/G4ulAQsQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY4PR21MB0278; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0278; x-forefront-prvs: 0236114672 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39450400003)(39860400002)(39850400002)(39840400002)(377454003)(24454002)(2501003)(92566002)(5005710100001)(10090500001)(230783001)(7696004)(19609705001)(8676002)(99286003)(4326008)(236005)(122556002)(25786008)(5660300001)(6306002)(8936002)(2950100002)(9686003)(10290500002)(54896002)(229853002)(2900100001)(55016002)(606005)(54356999)(3280700002)(6436002)(50986999)(77096006)(3660700001)(53936002)(189998001)(81166006)(86362001)(76176999)(2906002)(38730400002)(7906003)(106116001)(6116002)(102836003)(74316002)(6246003)(7736002)(790700001)(53546006)(33656002)(6506006)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0278; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB02779CE14B416DA68C5C87C2B62A0CY4PR21MB0277namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2017 00:41:02.6238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0278 Archived-At: Cc: Abdul Kabbani Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 04 Mar 2017 00:41:07 -0000 --_000_CY4PR21MB02779CE14B416DA68C5C87C2B62A0CY4PR21MB0277namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIERDVENQIGFkanVzdHMgY3duZCBhdCBtb3N0IG9uY2UgZXZlcnkgcm91bmQgdHJpcC4NCg0K U2VlIHN0ZXAgNDoNCg0KSWYgdGhlIGFja25vd2xlZGdtZW50IG51bWJlciBpcyBsZXNzIHRoYW4g b3IgZXF1YWwgdG8NCiAgICAgICBEQ1RDUC5XaW5kb3dFbmQsIHN0b3AgcHJvY2Vzc2luZy4gIE90 aGVyd2lzZSwgdGhlIGVuZCBvZiB0aGUNCiAgICAgICBvYnNlcnZhdGlvbiB3aW5kb3cgaGFzIGJl ZW4gcmVhY2hlZCwgc28gcHJvY2VlZCB0byB1cGRhdGUgdGhlDQogICAgICAgY29uZ2VzdGlvbiBl c3RpbWF0ZSBhcyBmb2xsb3dzOg0KDQpTbyBzdGVwcyA1IHRocm91Z2ggOCBhcmUgY29uZGl0aW9u YWwgYW5kIG9ubHkgZXhlY3V0ZWQgb25jZSBwZXIgcm91bmQuIFdoYXQgaXMgYSBiaXQgY29uZnVz aW5nIGlzIHRoYXQgdGhlIGN3bmQgY2FsY3VsYXRpb24gaXMgbm90IGluZGljYXRlZCBhcyBzdGVw IDkuIEkgd2lsbCBmaXggdGhpcyBpbiBhbiB1cGRhdGUgdG8gdGhlIGRyYWZ0Lg0KDQpPdGhlciB0 aGFuIHRoaXMgd2UgYWxzbyBoYXZlIHRoZSBmb2xsb3dpbmcgY2xhcmlmeWluZyBzZW50ZW5jZToN Ckp1c3QgYXMgc3BlY2lmaWVkIGluIFtSRkMzMTY4PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmMzMTY4Pl0sIERDVENQIGRvZXMgbm90IHJlYWN0IHRvIGNvbmdlc3Rpb24NCiAgIGluZGlj YXRpb25zIG1vcmUgdGhhbiBvbmNlIGZvciBldmVyeSB3aW5kb3cgb2YgZGF0YS4NCg0KDQpGcm9t OiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWXVjaHVu ZyBDaGVuZw0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjgsIDIwMTcgMzowMyBQTQ0KVG86IHRj cG1AaWV0Zi5vcmcNCkNjOiBBYmR1bCBLYWJiYW5pIDxha2FiYmFuaUBnb29nbGUuY29tPg0KU3Vi amVjdDogUmU6IFt0Y3BtXSBXR0xDIGZvciBkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDQNCg0KVGhl IHdvcmRpbmdzIG9uIGN3bmQgYWRqdXN0bWVudCBpbiBzZWN0aW9uIDMuMyBjYW4gYmUgbW9yZSBj bGVhcjoNCg0KIiIiDQpSYXRoZXIgdGhhbiBhbHdheXMgaGFsdmluZyB0aGUgY29uZ2VzdGlvbiB3 aW5kb3cgYXMgZGVzY3JpYmVkIGluDQogICBbUkZDMzE2OF0sIHdoZW4gdGhlIHNlbmRlciByZWNl aXZlcyBhbiBpbmRpY2F0aW9uIG9mIGNvbmdlc3Rpb24NCiAgIChFQ0UpLCB0aGUgc2VuZGVyIE1V U1QgdXBkYXRlIGN3bmQgYXMgZm9sbG93czoNCg0KICAgICAgY3duZCA9IGN3bmQgKiAoMSAtIERD VENQLkFscGhhIC8gMikNCg0KICAgVGh1cywgd2hlbiBubyBzZW50IGJ5dGUgZXhwZXJpZW5jZWQg Y29uZ2VzdGlvbiwgRENUQ1AuQWxwaGEgZXF1YWxzDQogICB6ZXJvLCBhbmQgY3duZCBpcyBsZWZ0 IHVuY2hhbmdlZC4gIFdoZW4gYWxsIHNlbnQgYnl0ZXMgZXhwZXJpZW5jZWQNCiAgIGNvbmdlc3Rp b24sIERDVENQLkFscGhhIGVxdWFscyBvbmUsIGFuZCBjd25kIGlzIHJlZHVjZWQgYnkgaGFsZi4N CiAgIExvd2VyIGxldmVscyBvZiBjb25nZXN0aW9uIHdpbGwgcmVzdWx0IGluIGNvcnJlc3BvbmRp bmdseSBzbWFsbGVyDQogICByZWR1Y3Rpb25zIHRvIGN3bmQuDQoiIiINCg0KQUZBSUNUIERDVENQ IHBhcGVyIG9ubHkgYWRqdXN0cyBjd25kIGF0IG1vc3QgZXZlcnkgcm91bmQgdHJpcCAod2hpY2gg aXMgYWxzbyBob3cgTGludXggaW1wbGVtZW50cyBpdCkuIEJ1dCB0aGUgdGV4dCBpbXBsaWVzIHRo ZSBjd25kIHJlZHVjdGlvbiBjYW4gaGFwcGVuIGZvciBldmVyeSBFQ0UgbWFyaz8NCg0KDQpPbiBU dWUsIEZlYiAxNCwgMjAxNyBhdCA4OjMxIEFNLCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUp IDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb208bWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNv bT4+IHdyb3RlOg0KSGksDQoNClRDUE0gY2hhaXJzIGFyZSBub3QgYXdhcmUgb2Ygb3V0c3RhbmRp bmcgaXNzdWVzIGluIGRyYWZ0LWlldGYtdGNwbS1kY3RjcC0wNCAiRGF0YWNlbnRlciBUQ1AgKERD VENQKTogVENQIENvbmdlc3Rpb24gQ29udHJvbCBmb3IgRGF0YWNlbnRlcnMiLg0KDQpUaGVyZWZv cmUsIHRoaXMgZS1tYWlsIHN0YXJ0cyBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFm dC1pZXRmLXRjcG0tZGN0Y3AtMDQuDQoNClRoZSBXR0xDIHJ1bnMgdW50aWwgRnJpZGF5IE1hcmNo IDMuIFBsZWFzZSBzZW5kIGFueSBjb21tZW50cyB0byB0aGUgVENQTSBtYWlsaW5nIGxpc3QgYnkg dGhlbi4gU3RhdGVtZW50cyBzdXBwb3J0aW5nIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgZG9jdW1l bnQgYXJlIGFsc28gaGVscGZ1bC4NCg0KV2UgYXNzdW1lIHRoYXQgVENQTSB3b3JraW5nIGdyb3Vw IGlzIGF3YXJlIG9mIHRoZSBJUFIgZGlzY2xvc3VyZSByZWxhdGVkIHRvIGRyYWZ0LWJlbnNsZXkt dGNwbS1kY3RjcC0wMCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjMxOS8pLiBB IHNlcGFyYXRlIG5vdGUgd2lsbCBiZSBzZW50IG91dCB0byBjb25maXJtIHRoYXQgYWxsIElQUiBo YXMgYWxyZWFkeSBiZWVuIGRpc2Nsb3NlZCwgaW4gY29uZm9ybWFuY2Ugd2l0aCBCQ1BzIDc4IGFu ZCA3OS4NCg0KVGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBhdCBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWRjdGNwLTA0DQoNClRoYW5rcw0KDQpNaWNoYWVsDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5n IGxpc3QNCnRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg0K --_000_CY4PR21MB02779CE14B416DA68C5C87C2B62A0CY4PR21MB0277namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzIERDVENQIGFkanVzdHMgY3duZCBh dCBtb3N0IG9uY2UgZXZlcnkgcm91bmQgdHJpcC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNl ZSBzdGVwIDQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPklmIHRoZSBhY2tub3dsZWRnbWVudCBudW1iZXIgaXMgbGVzcyB0aGFuIG9y IGVxdWFsIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IERDVENQLldpbmRvd0VuZCwgc3RvcCBwcm9jZXNzaW5nLiZuYnNwOyBPdGhl cndpc2UsIHRoZSBlbmQgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9ic2VydmF0aW9uIHdpbmRvdyBoYXMgYmVlbiByZWFj aGVkLCBzbyBwcm9jZWVkIHRvIHVwZGF0ZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZ2VzdGlvbiBlc3RpbWF0ZSBhcyBm b2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gc3RlcHMgNSB0aHJvdWdo IDggYXJlIGNvbmRpdGlvbmFsIGFuZCBvbmx5IGV4ZWN1dGVkIG9uY2UgcGVyIHJvdW5kLiBXaGF0 IGlzIGEgYml0IGNvbmZ1c2luZyBpcyB0aGF0IHRoZSBjd25kIGNhbGN1bGF0aW9uIGlzIG5vdCBp bmRpY2F0ZWQgYXMgc3RlcCA5LiBJIHdpbGwgZml4IHRoaXMgaW4gYW4gdXBkYXRlIHRvIHRoZSBk cmFmdC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdGhlciB0aGFuIHRoaXMgd2UgYWxzbyBo YXZlIHRoZSBmb2xsb3dpbmcgY2xhcmlmeWluZyBzZW50ZW5jZTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkp1 c3QgYXMgc3BlY2lmaWVkIGluIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMzE2OCIgdGl0bGU9IiZxdW90O1RoZSBBZGRpdGlvbiBvZiBFeHBsaWNpdCBDb25nZXN0aW9u IE5vdGlmaWNhdGlvbiAoRUNOKSB0byBJUCZxdW90OyI+UkZDMzE2ODwvYT5dLA0KIERDVENQIGRv ZXMgbm90IHJlYWN0IHRvIGNvbmdlc3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IGluZGljYXRpb25zIG1v cmUgdGhhbiBvbmNlIGZvciBldmVyeSB3aW5kb3cgb2YgZGF0YS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTo8L2I+IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJl aGFsZiBPZg0KPC9iPll1Y2h1bmcgQ2hlbmc8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVi cnVhcnkgMjgsIDIwMTcgMzowMyBQTTxicj4NCjxiPlRvOjwvYj4gdGNwbUBpZXRmLm9yZzxicj4N CjxiPkNjOjwvYj4gQWJkdWwgS2FiYmFuaSAmbHQ7YWthYmJhbmlAZ29vZ2xlLmNvbSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSBXR0xDIGZvciBkcmFmdC1pZXRmLXRjcG0tZGN0 Y3AtMDQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB3b3JkaW5ncyBvbiBjd25k IGFkanVzdG1lbnQgaW4gc2VjdGlvbiAzLjMgY2FuIGJlIG1vcmUgY2xlYXI6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDsmcXVvdDsmcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S YXRoZXIgdGhhbiBhbHdheXMgaGFsdmluZyB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgYXMgZGVzY3Jp YmVkIGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7W1JGQzMxNjhdLCB3aGVuIHRoZSBzZW5kZXIgcmVjZWl2ZXMgYW4gaW5k aWNhdGlvbiBvZiBjb25nZXN0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7KEVDRSksIHRoZSBzZW5kZXIgTVVTVCB1cGRh dGUgY3duZCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBjd25kID0gY3duZCAqICgxIC0g RENUQ1AuQWxwaGEgLyAyKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7VGh1cywgd2hlbiBubyBzZW50IGJ5dGUgZXhwZXJp ZW5jZWQgY29uZ2VzdGlvbiwgRENUQ1AuQWxwaGEgZXF1YWxzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7emVybywgYW5kIGN3 bmQgaXMgbGVmdCB1bmNoYW5nZWQuJm5ic3A7IFdoZW4gYWxsIHNlbnQgYnl0ZXMgZXhwZXJpZW5j ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtjb25nZXN0aW9uLCBEQ1RDUC5BbHBoYSBlcXVhbHMgb25lLCBhbmQgY3duZCBp cyByZWR1Y2VkIGJ5IGhhbGYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7TG93ZXIgbGV2ZWxzIG9mIGNvbmdlc3Rpb24gd2ls bCByZXN1bHQgaW4gY29ycmVzcG9uZGluZ2x5IHNtYWxsZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtyZWR1Y3Rpb25zIHRv IGN3bmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZxdW90OyZxdW90OyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BRkFJQ1QgRENUQ1AgcGFwZXIgb25seSBhZGp1c3Rz IGN3bmQgYXQgbW9zdCBldmVyeSByb3VuZCB0cmlwICh3aGljaCBpcyBhbHNvIGhvdyBMaW51eCBp bXBsZW1lbnRzIGl0KS4gQnV0IHRoZSB0ZXh0IGltcGxpZXMgdGhlIGN3bmQgcmVkdWN0aW9uIGNh biBoYXBwZW4gZm9yIGV2ZXJ5IEVDRSBtYXJrPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDE0LCAyMDE3IGF0IDg6MzEg QU0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgJmx0OzxhIGhyZWY9Im1haWx0bzptaWNo YWVsLnNjaGFyZkBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5taWNoYWVsLnNjaGFyZkBub2tp YS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8YnI+DQo8YnI+DQpUQ1BNIGNoYWlycyBhcmUgbm90IGF3YXJlIG9m IG91dHN0YW5kaW5nIGlzc3VlcyBpbiBkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDQgJnF1b3Q7RGF0 YWNlbnRlciBUQ1AgKERDVENQKTogVENQIENvbmdlc3Rpb24gQ29udHJvbCBmb3IgRGF0YWNlbnRl cnMmcXVvdDsuPGJyPg0KPGJyPg0KVGhlcmVmb3JlLCB0aGlzIGUtbWFpbCBzdGFydHMgYSB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi10Y3BtLWRjdGNwLTA0Ljxicj4NCjxi cj4NClRoZSBXR0xDIHJ1bnMgdW50aWwgRnJpZGF5IE1hcmNoIDMuIFBsZWFzZSBzZW5kIGFueSBj b21tZW50cyB0byB0aGUgVENQTSBtYWlsaW5nIGxpc3QgYnkgdGhlbi4gU3RhdGVtZW50cyBzdXBw b3J0aW5nIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgZG9jdW1lbnQgYXJlIGFsc28gaGVscGZ1bC48 YnI+DQo8YnI+DQpXZSBhc3N1bWUgdGhhdCBUQ1BNIHdvcmtpbmcgZ3JvdXAgaXMgYXdhcmUgb2Yg dGhlIElQUiBkaXNjbG9zdXJlIHJlbGF0ZWQgdG8gZHJhZnQtYmVuc2xleS10Y3BtLWRjdGNwLTAw ICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yMzE5LyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIzMTkvPC9hPikuIEEg c2VwYXJhdGUgbm90ZSB3aWxsIGJlIHNlbnQgb3V0IHRvIGNvbmZpcm0NCiB0aGF0IGFsbCBJUFIg aGFzIGFscmVhZHkgYmVlbiBkaXNjbG9zZWQsIGluIGNvbmZvcm1hbmNlIHdpdGggQkNQcyA3OCBh bmQgNzkuPGJyPg0KPGJyPg0KVGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWRjdGNwLTA0IiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWRj dGNwLTA0PC9hPjxicj4NCjxicj4NClRoYW5rczxicj4NCjxicj4NCk1pY2hhZWw8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRjcG0gbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90Y3BtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90Y3BtPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB02779CE14B416DA68C5C87C2B62A0CY4PR21MB0277namp_-- From nobody Fri Mar 3 16:52:18 2017 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 681BB12940B; Fri, 3 Mar 2017 16:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9MP_IuqxP1J; Fri, 3 Mar 2017 16:52:15 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46F612706D; Fri, 3 Mar 2017 16:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bzPRAsq+On10p3/24JnL/qe43F1qqAegnpEUPZLZ6ao=; b=R/+76iqDXeSjuJNaAtR5CJFNS4JpbCNfdTj5ubFN5B65ImwMYFKcPFxs39EwNygBeS5bToo4EbStAPH3aFjox/8WnjnNtmJeLCTzNpPgN6upDRQ1BUe5la3730zqk5sProekkdNZ67KjV6IffgzMbUNYPgX2QjjKepcTwsCr5n8= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0279.namprd21.prod.outlook.com (10.173.193.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.3; Sat, 4 Mar 2017 00:52:13 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0947.012; Sat, 4 Mar 2017 00:52:13 +0000 From: Praveen Balasubramanian To: "De Schepper, Koen (Nokia - BE)" , "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSht1kq1X/jxxo5k+Qc2zpAI+3x6F/wR9AgAQyWFA= Date: Sat, 4 Mar 2017 00:52:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia-bell-labs.com; dkim=none (message not signed) header.d=none;nokia-bell-labs.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::584] x-ms-office365-filtering-correlation-id: f9626356-7a4e-49f8-9318-08d46298b28e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0279; x-microsoft-exchange-diagnostics: 1; CY4PR21MB0279; 7:pJDtQHW7KPMKB4cBqjWh4YqJ/9talCpb+MbnSUIA5EZVpidPTQ/2ulDrgykWXg053P+drfZ0L13nwI29ueYUAx3VOD51i3BuY6mtc+Ku5Dk36ALFaMV2sQZJ0UBOIbv+jQYXckctusd6pfsQ2O7KvT4bFOoI2AhQWN7oxci5ExabUJFHjl/VtrlKouOW05tyXOVtMAbNkAY3yspIVNxSPc9n8SbIM3WPi+19lcQEVpU+B2lBpGnzUVKUHTZjrdFZKPAoxwTWsxMbNpsAgW7oNvVuWFLeW6eHDL7S5VXa+HV17CL9pR6rcCr4of6t7escJOpISgU3Y8+O0mOMCaJcSmV8rSBNNquXKmNPYq24w/s= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(6072148)(6042181); SRVR:CY4PR21MB0279; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0279; x-forefront-prvs: 0236114672 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(377454003)(13464003)(8936002)(77096006)(25786008)(92566002)(81166006)(102836003)(189998001)(2501003)(54356999)(6116002)(230783001)(6506006)(2950100002)(8676002)(50986999)(76176999)(305945005)(229853002)(2906002)(99286003)(33656002)(86362001)(122556002)(74316002)(55016002)(6436002)(10090500001)(3660700001)(3280700002)(2900100001)(4326008)(5005710100001)(7736002)(6306002)(38730400002)(9686003)(53936002)(53546006)(8990500004)(10290500002)(5660300001)(6246003)(7696004)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0279; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2017 00:52:13.4470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0279 Archived-At: Cc: "tcpm-chairs@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 04 Mar 2017 00:52:17 -0000 The text around allowing a reset of Alpha was added on suggestions from the= Linux implementation experience. The text already suggests that this is op= tional. The Windows implementation does not reset the value of Alpha or the= other tracking variables. I think that we don't need to remove this text. = If you still strongly object and I don't hear any other opinions, I will re= move it in the next revision.=20 >> The Linux patch I provided additionally halves the window (once per RTT)= when a drop is encountered, independent from alpha The handling of a timeout and dup acks should ideally be identical to NewRe= no. The only change in response is in presence of ECN marks. Thanks -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of De Schepper, Koen (N= okia - BE) Sent: Wednesday, March 1, 2017 2:18 AM To: Scharf, Michael (Nokia - DE) ; tcpm@ietf.org Cc: tcpm-chairs@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 I have a comment on the following text: It would be useful to implement DCTCP as additional actions on top of an existing congestion control algorithm like NewReno. The DCTCP implementation MAY also allow configuration of resetting the value of DCTCP.Alpha as part of processing any loss episodes. Setting alpha to its max value (btw resetting might imply setting to zero) = has many complications and in the current Linux implementation turned out t= o not function. The Linux patch I provided additionally halves the window (once per RTT) wh= en a drop is encountered, independent from alpha. This is also, as far as I= understood, how the Windows version works. Both implementations are workin= g now in drop-based networks next to Classic TCP flows. As far as I know there is no working implementation that is setting alpha t= o max so I propose to describe the working implementation instead of a theo= retical one. For the rest I support publication. Koen. > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael=20 > (Nokia - DE) > Sent: dinsdag 14 februari 2017 17:32 > To: tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 >=20 > Hi, >=20 > TCPM chairs are not aware of outstanding issues in=20 > draft-ietf-tcpm-dctcp-04 "Datacenter TCP (DCTCP): TCP Congestion Control = for Datacenters". >=20 > Therefore, this e-mail starts a working group last call for=20 > draft-ietf-tcpm- dctcp-04. >=20 > The WGLC runs until Friday March 3. Please send any comments to the=20 > TCPM mailing list by then. Statements supporting the publication of=20 > the document are also helpful. >=20 > We assume that TCPM working group is aware of the IPR disclosure=20 > related to draft-bensley-tcpm-dctcp-00=20 > (https://datatracker.ietf.org/ipr/2319/). A separate note will be sent=20 > out to confirm that all IPR has already been disclosed, in conformance wi= th BCPs 78 and 79. >=20 > The draft is available at=20 > https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-04 >=20 > Thanks >=20 > Michael > _______________________________________________ > 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 Sun Mar 5 08:34:54 2017 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 6D66D1294DC for ; Sun, 5 Mar 2017 08:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6Qdy1WJaKZYL for ; Sun, 5 Mar 2017 08:34:52 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CC5129474 for ; Sun, 5 Mar 2017 08:34:51 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id m27so37767087iti.1 for ; Sun, 05 Mar 2017 08:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Aak/L5zENTxpD1cievQDsb7bQYKjVGvT2Ork34T0yqg=; b=ntIIIQCljT8qgbbBY0ocW8B4TLziT5a3rYsKQfG4772iqkNRUiJHQw0X2AQ2Wr5yKR M4FmMGS0DJ9KBywJrQ2DjCqysD1Edtj0we0Mj9tU67quz0zuBoa06v3qSO6798ACldcj 1wOxggqPIwK6+F2+xX735qUC5zZde0wHdX3U+o0cgLJtFktSMgfBXyBnpUKzV8PLJTwX RpyTSV643eCoX1DFKvBm4TtC2FzNahfsYDlfUd6jC4+D30gIr8idvum1SlQN3gkQiBdR Oy4U54jLBMqWxGvMdFg1sDETJ9PiRDVpTm0nWVkPEebeIPdn9c0QkMTk/KSdZ1yZPsg/ +7LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Aak/L5zENTxpD1cievQDsb7bQYKjVGvT2Ork34T0yqg=; b=gzny9KFyW/vJLWf4DU1dlkwQVAXHJJsJOpwPkApbtdWc41yjIWgyPjf2GJbR1g21Kd E3zeCCl4NSG3huv2QHF374csi6vy05vDePqzuZ35DUJJKAOD8PzfIT5xCKSdUMy1rkSa 6kn7q3Viaolk1QN9HSD4qyYXIIyECndbOqtc3bf2sbchU2sg3/9EEY2zWhJ8KovwdXlM AxrYpz6rs1Js8vjYzS413iqjjfxfw5tFXKIACchfbS1WbUn27FzyVny2UUyMTlRJu7az il993GxT7Db/lYQEwlShr1wU0l1brK2ChFDeyh8KN55C3KxfVXSaH6VPmSPkC78CvwBy 7cgg== X-Gm-Message-State: AMke39kP3D2lsKngf3ANJbyvlHAjHgOUpkt3iycHUOnyxHB3LcOSaaSBOFbLzr9hHOySD/sy18/dCwfqTiGlnd58 X-Received: by 10.36.44.4 with SMTP id i4mr11486477iti.105.1488731691133; Sun, 05 Mar 2017 08:34:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Sun, 5 Mar 2017 08:34:10 -0800 (PST) In-Reply-To: References: From: Yuchung Cheng Date: Sun, 5 Mar 2017 08:34:10 -0800 Message-ID: To: Praveen Balasubramanian Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Abdul Kabbani , "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 05 Mar 2017 16:34:53 -0000 On Fri, Mar 3, 2017 at 4:41 PM, Praveen Balasubramanian wrote: > > Yes DCTCP adjusts cwnd at most once every round trip. > > > > See step 4: > > > > If the acknowledgment number is less than or equal to > > DCTCP.WindowEnd, stop processing. Otherwise, the end of the > > observation window has been reached, so proceed to update the > > congestion estimate as follows: > > > > So steps 5 through 8 are conditional and only executed once per round. Wh= at is a bit confusing is that the cwnd calculation is not indicated as step= 9. I will fix this in an update to the draft. > > > > Other than this we also have the following clarifying sentence: > > Just as specified in [RFC3168], DCTCP does not react to congestion > > indications more than once for every window of data. Thanks for clarification. I notice the draft is also less clear about the window reduction on packet losses. For example, if sender experiences ECE and then losses in the same window of data. Does DCTCP reduces the window twice (once on ECN, then again on Loss)? The draft implies cwnd would be reduced twice: A DCTCP sender MUST deal with loss episodes in the same way as conventional TCP. In case of a timeout or fast retransmit or any change in delay (for delay based congestion control), the cwnd and other state variables like ssthresh must be changed in the same way that a conventional TCP would have changed them. AFAICT Linux's implementation for both DCTCP and RFC3168 would only reduce cwnd once on ECN + loss. Since this is a common scenario, it'd be nice to be explicit in the DCTCP draft. > > > > > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng > Sent: Tuesday, February 28, 2017 3:03 PM > To: tcpm@ietf.org > Cc: Abdul Kabbani > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 > > > > The wordings on cwnd adjustment in section 3.3 can be more clear: > > > > """ > > Rather than always halving the congestion window as described in > > [RFC3168], when the sender receives an indication of congestion > > (ECE), the sender MUST update cwnd as follows: > > > > cwnd =3D cwnd * (1 - DCTCP.Alpha / 2) > > > > Thus, when no sent byte experienced congestion, DCTCP.Alpha equals > > zero, and cwnd is left unchanged. When all sent bytes experienced > > congestion, DCTCP.Alpha equals one, and cwnd is reduced by half. > > Lower levels of congestion will result in correspondingly smaller > > reductions to cwnd. > > """ > > > > AFAICT DCTCP paper only adjusts cwnd at most every round trip (which is a= lso how Linux implements it). But the text implies the cwnd reduction can h= appen for every ECE mark? > > > > > > On Tue, Feb 14, 2017 at 8:31 AM, Scharf, Michael (Nokia - DE) wrote: > > Hi, > > TCPM chairs are not aware of outstanding issues in draft-ietf-tcpm-dctcp-= 04 "Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters". > > Therefore, this e-mail starts a working group last call for draft-ietf-tc= pm-dctcp-04. > > The WGLC runs until Friday March 3. Please send any comments to the TCPM = mailing list by then. Statements supporting the publication of the document= are also helpful. > > We assume that TCPM working group is aware of the IPR disclosure related = to draft-bensley-tcpm-dctcp-00 (https://datatracker.ietf.org/ipr/2319/). A = separate note will be sent out to confirm that all IPR has already been dis= closed, in conformance with BCPs 78 and 79. > > The draft is available at https://tools.ietf.org/html/draft-ietf-tcpm-dct= cp-04 > > Thanks > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From nobody Sun Mar 5 11:42:45 2017 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 C48E21294CE for ; Sun, 5 Mar 2017 11:42:44 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mi5kjk3bQoyZ for ; Sun, 5 Mar 2017 11:42:42 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 6D8AF1294CD for ; Sun, 5 Mar 2017 11:42:42 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id v186so49441058wmd.0 for ; Sun, 05 Mar 2017 11:42:42 -0800 (PST) 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=ANR3plUP+yuxJ3n4zUR4z/2HHSU/NUaJYHvEZnncUeQ=; b=JEIlZAPzsDbDi1NqDDRkyazvabH3LjZKII6VhUZj2eAQuDQfhH0oy9QM77wsSquJvv TaWTLPqPER/4XrF7RY/2Qh0VuvABqixYSFSruJY4cLgIwMXmBUJYVdLCJxKiI6NAdbvN MrH6wOWjb3EKgSz18hQE00aijsQCUTUzFAsy+l4xHzfMs5CB1idiaocOonq3KE25hvgC MYuvGBPLTcOwH3oya+h+lSmwXdW4cZh/fDZEf/6zq/SBxVgH+6OCspJRkCowoZjCVeFa l/f12ephWaKh+JwFwWR3hvNMG7RqpTavmYB7uVF3qvzK0Ns5kwezets2nccqAKDwzIve mvRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ANR3plUP+yuxJ3n4zUR4z/2HHSU/NUaJYHvEZnncUeQ=; b=sE+KMYgTg3hBFG7q69eb13ZOYxRrUm0Rf5jnMQEldCvd87yowpMsuiOrDd8XGbdVKj /3hfkN+qLUeMoMf7I/XBsxApuvQh/LOqJqIQYd2NwQa5c2e2xaZc35p5qlvnEw82NDU3 Ck3ODRSDJBjL0BIBNptQgeQGhY9SfavjnOleznUdM7ciMfYify2ELlcn/b60HALbp8LG BlCi5Yi+YHM9uOe3apGLBYGlFsBM7rSKlNwEBSMiJZDhI4ava4byD6+M85Swnag76kGd Pjg4z0vnc2WnAKtqOkoSMGtKRVBPnlIUD4JHU5ni0rqWvaPpIAkEhzbCjX1kM8+QSDwm LCVQ== X-Gm-Message-State: AMke39lC7JxDfmfgcLpxp4kOmc3yBp1eZmiYJ7kaa+9GKTEDh7DB6ydyOpnRMI9s3PpSdxND X-Received: by 10.28.94.194 with SMTP id s185mr1071465wmb.52.1488742960674; Sun, 05 Mar 2017 11:42:40 -0800 (PST) Received: from Macintosh-6.local (20.163.16.95.dynamic.jazztel.es. [95.16.163.20]) by smtp.gmail.com with ESMTPSA id 65sm24052994wri.53.2017.03.05.11.42.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Mar 2017 11:42:39 -0800 (PST) To: tcpm@ietf.org References: From: marcelo bagnulo braun Message-ID: <91541d03-09d6-a445-daf9-34e4eb505389@it.uc3m.es> Date: Sun, 5 Mar 2017 20:42:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 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] WGLC for draft-ietf-tcpm-dctcp-04 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, 05 Mar 2017 19:42:44 -0000 I support this document moving forward. El 14/02/17 a las 17:31, Scharf, Michael (Nokia - DE) escribió: > Hi, > > TCPM chairs are not aware of outstanding issues in draft-ietf-tcpm-dctcp-04 "Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters". > > Therefore, this e-mail starts a working group last call for draft-ietf-tcpm-dctcp-04. > > The WGLC runs until Friday March 3. Please send any comments to the TCPM mailing list by then. Statements supporting the publication of the document are also helpful. > > We assume that TCPM working group is aware of the IPR disclosure related to draft-bensley-tcpm-dctcp-00 (https://datatracker.ietf.org/ipr/2319/). A separate note will be sent out to confirm that all IPR has already been disclosed, in conformance with BCPs 78 and 79. > > The draft is available at https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-04 > > Thanks > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Mar 6 08:01:14 2017 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 BD2B0129867; Mon, 6 Mar 2017 08:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-KrRV76iF6S; Mon, 6 Mar 2017 08:01:10 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF2E129522; Mon, 6 Mar 2017 08:01:10 -0800 (PST) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:408:2082:8a9b:529]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 810A91B0144E; Mon, 6 Mar 2017 17:58:49 +0000 (GMT) References: From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <74665a11-0762-5c3c-5f1e-10138c71dcd4@erg.abdn.ac.uk> Date: Mon, 6 Mar 2017 16:01:01 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Subject: Re: [tcpm] Agenda requests for IETF 98 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:01:13 -0000 TCP Alternative Backoff with ECN (ABE) draft-ietf-tcpm-alternativebackoff-ecn Presenter G Fairhurst / M Welzl Total time (including Q&A): 5 minutes We'd be happy for a slide to be presented on ABE status, now that this has been adopted. Gorry, Michael, Naeem. > I will present updates on the draft as well as experimentation results > that've been requested in previous meetings. > > On Mon, Feb 27, 2017 at 9:38 AM, Scharf, Michael (Nokia - DE) > > wrote: > > Hi all, > > For the Chicago meeting, tentatively (!) TCPM got the 2.5h slot on > Wednesday morning. > > If you want to present something in the TCPM meeting, please let the > chairs know until Sunday March 12: > > * Draft name / title > * Presenter > * Total time (including Q&A) > > Thanks! > > Michael > > _______________________________________________ > 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 Wed Mar 8 08:23:50 2017 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 2A65412947A; Wed, 8 Mar 2017 08:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 ZBnbzg4Se57z; Wed, 8 Mar 2017 08:23:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2B39A1293FB; Wed, 8 Mar 2017 08:23:46 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A848A596AA4B6; Wed, 8 Mar 2017 16:23:40 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v28GNgwi005599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Mar 2017 17:23:44 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v28GNaWg016561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Mar 2017 16:23:41 GMT Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.65]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Wed, 8 Mar 2017 17:23:37 +0100 From: "De Schepper, Koen (Nokia - BE)" To: Praveen Balasubramanian , "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSht1kq1X/jxxo5k+Qc2zpAI+3x6F/wR9AgAQyWFCAA+dJUA== Date: Wed, 8 Mar 2017 16:23:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 08 Mar 2017 16:23:48 -0000 > -----Original Message----- > From: Praveen Balasubramanian [mailto:pravb@microsoft.com] > Sent: zaterdag 4 maart 2017 1:52 > To: De Schepper, Koen (Nokia - BE) labs.com>; Scharf, Michael (Nokia - DE) ; > tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: RE: WGLC for draft-ietf-tcpm-dctcp-04 >=20 > The text around allowing a reset of Alpha was added on suggestions from t= he > Linux implementation experience. [KDS] I see it was added from the Linux implementation, but clearly not bas= ed on the experience ;-). This implementation is not working. I don't know if the FreeBSD implementation has drop compatibility, and how = it works. If that has a working implementation by setting alpha to max, we can keep t= he text. > The text already suggests that this is > optional. [KDS] That is OK, as in the Linux patch it is also optional (default on).=20 The new parameter is called dctcp_drop_compatible as it does not have anyth= ing to do with alpha clamping. Koen. > The Windows implementation does not reset the value of Alpha or > the other tracking variables. I think that we don't need to remove this t= ext. If > you still strongly object and I don't hear any other opinions, I will rem= ove it in > the next revision. >=20 > >> The Linux patch I provided additionally halves the window (once per RT= T) > when a drop is encountered, independent from alpha > The handling of a timeout and dup acks should ideally be identical to > NewReno. The only change in response is in presence of ECN marks. >=20 > Thanks >=20 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of De Schepper, > Koen (Nokia - BE) > Sent: Wednesday, March 1, 2017 2:18 AM > To: Scharf, Michael (Nokia - DE) ; tcpm@ietf.or= g > Cc: tcpm-chairs@ietf.org > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 >=20 > I have a comment on the following text: >=20 > It would be useful to implement DCTCP as additional actions on top of > an existing congestion control algorithm like NewReno. The DCTCP > implementation MAY also allow configuration of resetting the value of > DCTCP.Alpha as part of processing any loss episodes. >=20 > Setting alpha to its max value (btw resetting might imply setting to zero= ) has > many complications and in the current Linux implementation turned out to > not function. > The Linux patch I provided additionally halves the window (once per RTT) > when a drop is encountered, independent from alpha. This is also, as far = as I > understood, how the Windows version works. Both implementations are > working now in drop-based networks next to Classic TCP flows. >=20 > As far as I know there is no working implementation that is setting alpha= to > max so I propose to describe the working implementation instead of a > theoretical one. >=20 > For the rest I support publication. >=20 > Koen. >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > > (Nokia - DE) > > Sent: dinsdag 14 februari 2017 17:32 > > To: tcpm@ietf.org > > Cc: tcpm-chairs@ietf.org > > Subject: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 > > > > Hi, > > > > TCPM chairs are not aware of outstanding issues in > > draft-ietf-tcpm-dctcp-04 "Datacenter TCP (DCTCP): TCP Congestion Contro= l > for Datacenters". > > > > Therefore, this e-mail starts a working group last call for > > draft-ietf-tcpm- dctcp-04. > > > > The WGLC runs until Friday March 3. Please send any comments to the > > TCPM mailing list by then. Statements supporting the publication of > > the document are also helpful. > > > > We assume that TCPM working group is aware of the IPR disclosure > > related to draft-bensley-tcpm-dctcp-00 > > (https://datatracker.ietf.org/ipr/2319/). A separate note will be sent > > out to confirm that all IPR has already been disclosed, in conformance = with > BCPs 78 and 79. > > > > The draft is available at > > https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-04 > > > > Thanks > > > > Michael > > _______________________________________________ > > 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 Fri Mar 10 12:33:23 2017 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 B38D41294D0; Fri, 10 Mar 2017 12:33:21 -0800 (PST) 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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148917800171.2982.17317484633710972061@ietfa.amsl.com> Date: Fri, 10 Mar 2017 12:33:21 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-05.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: Fri, 10 Mar 2017 20:33:21 -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 : Retransmission Timeout Requirements Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-05.txt Pages : 9 Date : 2017-03-10 Abstract: Ensuring reliable communication often manifests in a timeout and retry mechanism. Each implementation of a retransmission timeout mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for retransmission timeout schemes appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-05 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 Sat Mar 11 00:03:26 2017 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 2D6FC129409; Sat, 11 Mar 2017 00:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a551qOW5P_75; Sat, 11 Mar 2017 00:03:23 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0911293FD; Sat, 11 Mar 2017 00:03:22 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2B83Je0047783; Sat, 11 Mar 2017 09:03:20 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id DFDC71D53C1; Sat, 11 Mar 2017 09:03:19 +0100 (CET) Received: from 83.50.59.42 by webmail.entel.upc.edu with HTTP; Sat, 11 Mar 2017 09:03:43 +0100 Message-ID: Date: Sat, 11 Mar 2017 09:03:43 +0100 From: "Carles Gomez Montenegro" To: lwip@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Sat, 11 Mar 2017 09:03:20 +0100 (CET) Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-02.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: Sat, 11 Mar 2017 08:03:25 -0000 Dear all, We have submitted version -02 of the "TCP over Constrained-Node Networks" draft. Please find pointers to the updated document below. Cheers, Carles ---------------------------- Original Message ---------------------------- Subject: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-02.txt From: internet-drafts@ietf.org Date: Sat, March 11, 2017 8:33 am To: "Jon Crowcroft" "Carles Gomez" -------------------------------------------------------------------------- A new version of I-D, draft-gomez-lwig-tcp-constrained-node-networks-02.txt has been successfully submitted by Carles Gomez and posted to the IETF repository. Name: draft-gomez-lwig-tcp-constrained-node-networks Revision: 02 Title: TCP over Constrained-Node Networks Document date: 2017-03-10 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-gomez-lwig-tcp-constrained-node-networks-02.txt Status: https://datatracker.ietf.org/doc/draft-gomez-lwig-tcp-constrained-node-networks/ Htmlized: https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-networks-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-gomez-lwig-tcp-constrained-node-networks-02 Abstract: This document provides a profile for the Transmission Control Protocol (TCP) over Constrained-Node Networks (CNNs). The overarching goal is to offer simple measures to allow for lightweight TCP implementation and suitable operation in such environments. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sat Mar 11 00:31:53 2017 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 A20B9126D73; Sat, 11 Mar 2017 00:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYE9JgG1jp19; Sat, 11 Mar 2017 00:31:50 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05891279EB; Sat, 11 Mar 2017 00:24:43 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2B8Odv0051115; Sat, 11 Mar 2017 09:24:39 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 3BA631D53C1; Sat, 11 Mar 2017 09:24:38 +0100 (CET) Received: from 83.50.59.42 by webmail.entel.upc.edu with HTTP; Sat, 11 Mar 2017 09:25:02 +0100 Message-ID: <31c0efd99c203beeb3115f5900341326.squirrel@webmail.entel.upc.edu> In-Reply-To: <655C07320163294895BBADA28372AF5D48B68E11@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <563cd49c505340a559cded05282a3dc6.squirrel@webmail.entel.upc.edu> <655C07320163294895BBADA28372AF5D48B68E11@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Sat, 11 Mar 2017 09:25:02 +0100 From: "Carles Gomez Montenegro" To: "Scharf, Michael (Nokia - DE)" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: Delayed for 00:21:19 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Sat, 11 Mar 2017 09:24:39 +0100 (CET) Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , jon.crowcroft@cl.cam.ac.uk Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-01.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: Sat, 11 Mar 2017 08:31:51 -0000 Hi Michael, First of all, sorry for the delay in this response, and thanks a lot for your comments, suggestions and pointers. We have updated the draft with the aim to address your comments. Latest version is -02. Please find below inline responses: > I like this version better than the former one. Yet, I still have quite a > number of observations: > > 1/ Target of the document (Best Current Practice) > > The survey in the Appendix is very useful and it would be good to expand > it. It states: > > 7.2. lwIP > > lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. > lwIP has a total code size of ~14 kB to ~22 kB (which comprises > memory management, checksumming, network interfaces, IP, ICMP and > TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk]. > > In contrast with uIP, lwIP decouples applications from the network > stack. lwIP supports a TCP transmission window greater than a single > segment, as well as buffering of incoming and outcoming data. Other > implemented mechanisms comprise slow start, congestion avoidance, > fast retransmit and fast recovery. SACK and Window Scale are not > implemented. > > So, it seems to me that the guidance written in the document (only a > single window etc.) is actually *not* the best current practice actually > used in lightweight implementations. So, to me the document needs > significant changes to cover the lwIP implementation correctly, which I > think would be appropriate. > > Or does the document target only environments for which this lwIP stack > does not apply? The correct intended status for the draft is Informational. The “BCP” previously shown in the draft should have already been replaced by "Informational" in -01. Solved in -02. > 2/ Section 2 > > I think you should better define the what exactly you mean by > Constrained-Node Networks. For instance, is this limited to 6LoWPAN? What > about some of the emerging 4G/5G radio interfaces that focus on energy > constrained devices? Does the same guidance really apply to all (radio) > networks? CNNs are defined in RFC 7228 as networks whose characteristics are influenced by being composed of a significant portion of constrained nodes. CNNs are not limited to 6LoWPAN/6Lo networks. Guidance may apply to other networks as long as devices (and the links/networks they use) suffer the type of constraints described for ‘constrained nodes’. Please note that the actual definition of CNNs [RFC 7228] is not tied to 6LoWPAN or any particular type of network/technology. > 2/ Section 4.2 Maximum Segment Size (MSS) > > I think this section would first benefit from a wider survey of link > technologies before coming to conclusions. -02 refers also to other technologies used in the CNN space (such as MS/TP, IEEE 802.11ah and NB-IoT) which do not suffer the same degree of frame (payload) size limitation as the ones already mentioned. > This sentence needs rewording regarding the "in any case", which could be > read in different ways in particular in isolation: "In any case, the TCP > MSS must not be set to a value leading to an IPv6 datagram size exceeding > 1280 bytes." Agreed and done. > The next sentence also needs rewording: "If a link layer technology used > by a constrained device offers a link layer MTU greater than 1280 bytes, > it is still useful to set the MSS so that IPv6 datagram size does not > exceed 1280 bytes, in order to avoid issues due to Internet links that do > not support greater MTUs." The Internet as a whole has means to handle > MTUs larger than 1280 bytes, so this guidance seems not in general > "useful". Agreed. This text has been removed. > 3/ Section 4.3. Window Size > > Why does this document include this recommendation even if there are > relevant lightweight stacks that can do much better? > > I think what is more appropriate would be a wording such as: "A TCP stack > can reduce the implementation complexity by advertising a TCP window size > of one MSS, and also transmit at most one MSS of unacknowledged data, at > the cost of decreased performance." Agreed and applied to the document. > And the following sentence should probably replace "use" by "allow": "For > devices that can afford greater TCP window size, it may be useful to use > window sizes of at least five MSSs, in order to allow Fast Retransmit and > Fast Recovery [RFC5681]." If a sender has larger window sizes, it has to > implement congestion control, and as a result the window size will be > variable. After an RTO, it can be as low as one MSS and is thus less than > 5 MSS. I could read this sentence as suggesting a fixed minimum window > size, which is not appropriate. Agreed and applied to the document. > 4/ Section 4.4. RTO estimation > > This section must be entirely rewritten. First of all, this section should > cite draft-ietf-tcpm-rto-consider and consider the guidance therein (in > particular Section 3). One of the key insights of > draft-ietf-tcpm-rto-consider is that there is typically no single best > algorithm, as there are always tradeoffs. If this conclusion was wrong, > this document would have to explicitly explain why. > draft-ietf-tsvwg-rfc5405bis could also be referenced. > > To me, the key aspect that this section should probably discuss is that if > a sender uses only very small window sizes and can hardly use fast > retransmit (or even SACK), the RTO algorithm has a larger impact on the > performance than for a more powerful TCP stack. This may open room for > some algorithm tuning. But then the downsides of doing that should also be > discussed (e.g., spurious timeouts etc.). Modified the section accordingly. However, CoCoA RTO work is still mentioned (now as a note on a related area, just for informational purposes). > 5/ Section 4.5. TCP connection lifetime > > I think in this section you should better separate what a TCP stack should > support, or not, and how the TCP stack should be used by applications, > e.g., whether to close connections or not. Agreed. This will be done in future revisions. > 6/ Section 4.6. Explicit congestion notification > > As motivation for ECN the text notes "As transactional data size > decreases, the probability of detecting congestion by the presence of > three duplicate ACKs decreases." But three DUPACKs are quite impossible if > the sender follows Section 4.3, right? After the changes in section 4.3, this comment is hopefully addressed. > 7/ Section TCP options > > The sentence > > "A TCP implementation for a constrained device that uses a single-MSS > TCP receive or transmit window size will benefit from not supporting, > and ignoring if received, the following TCP options: Window scale > [RFC1323], TCP Timestamps [RFC1323], Selective Acknowledgements (SACK) > and SACK-Permitted [RFC2018]." > > should at least be reworded to > > "A TCP implementation for a constrained device that uses a single-MSS > TCP receive or transmit window size may not benefit supporting from the > following TCP options: Window scale [RFC1323], TCP Timestamps [RFC1323], > Selective Acknowledgements (SACK) and SACK-Permitted [RFC2018]." Agreed. Applied to the document. > I do not believe that RFC 2119 language of the form "Other TCP options > SHOULD NOT be used, in keeping with the principle of lightweight > operation." is appropriate, in particular since it may also exclude future > new TCP options that specifically target lightweight operation. Sorry, we missed that one in -01. Removed this 2119 form now. > Also, this section may have to consider TFO options as this is discussed > elsewhere in the draft. TFO is now mentioned in the section for completeness, although the main description of TFO comes already in section 4.5. > 8/ Section 4.8. Delayed Acknowledgments > > I think the last paragraph in this section should be moved earlier in the > document, i.e., the document should probably explain early the different > types of workloads in a CCN as well as their possibly different needs > regarding TCP stack configuration. The assumption that most communication > sizes is smaller than one MSS is very fundamental and if it is violated, a > lot of the reasoning in the document does not apply. Updated text in -02 just describes when delayed ACKs are recommended and when they are not, without stating whether some scenarios are more likely than others. Even if my current *impression* is the one formerly expressed in the document, a more solid support for it would be needed, and also the way CNNs are used may vary over time (and it definitely varies across scenarios). Implementers or administrators may choose the most appropriate setting for each particular scenario. > 9/ Section 5. Security Considerations > > I am not a security expert but here is a question: If an attacker knows > that a TCP stack only uses a window of one MSS (because it sits in a CCN), > and if some packet can be passively intercepted, isn't the likelihood of > successfully injecting segments into an established TCP connection larger? Do you mean something like a replay attack? Generating a spoofed duplicate? Why is the likelihood of successfully injecting segments greater? Is it e.g. because it makes it easier for the attacker to appear as a legitimate sender when the actual legitimate sender is silent? > Another aspect to be mentioned is that certain TCP options can improve TCP > security (e.g., MD5, TCP-AO) but come along with complexity. Agreed. A brief description of these has been added. Cheers, Carles > Thanks > > Michael From nobody Sat Mar 11 17:45:07 2017 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 0E3E01295DD; Sat, 11 Mar 2017 17:45:05 -0800 (PST) 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 PMAgHWpKlTF6; Sat, 11 Mar 2017 17:45:03 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBDC1294E8; Sat, 11 Mar 2017 17:45:03 -0800 (PST) Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:48720 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cmsZA-0006YF-Vg; Sun, 12 Mar 2017 01:45:01 +0000 To: "Scharf, Michael (Nokia - DE)" References: From: Bob Briscoe Message-ID: Date: Sun, 12 Mar 2017 01:45:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 12 Mar 2017 01:45:05 -0000 I can confirm that all my earlier concerns have been addressed. So I support this draft going forward, assuming the proposed improvements around loss handling currently being discussed will be sorted. Bob On 14/02/17 16:31, Scharf, Michael (Nokia - DE) wrote: > Hi, > > TCPM chairs are not aware of outstanding issues in draft-ietf-tcpm-dctcp-04 "Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters". > > Therefore, this e-mail starts a working group last call for draft-ietf-tcpm-dctcp-04. > > The WGLC runs until Friday March 3. Please send any comments to the TCPM mailing list by then. Statements supporting the publication of the document are also helpful. > > We assume that TCPM working group is aware of the IPR disclosure related to draft-bensley-tcpm-dctcp-00 (https://datatracker.ietf.org/ipr/2319/). A separate note will be sent out to confirm that all IPR has already been disclosed, in conformance with BCPs 78 and 79. > > The draft is available at https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-04 > > Thanks > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Mar 13 02:52:21 2017 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 339D0129400; Mon, 13 Mar 2017 02:52:19 -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, RP_MATCHES_RCVD=-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 Hjx_VhyfljgC; Mon, 13 Mar 2017 02:52:17 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 096FF1294F7; Mon, 13 Mar 2017 02:52:17 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id D82911B01665; Mon, 13 Mar 2017 11:49:28 +0000 (GMT) Message-ID: <58C66BB3.1000003@erg.abdn.ac.uk> Date: Mon, 13 Mar 2017 09:51:47 +0000 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-tcpm-dctcp@ietf.org Subject: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:52:19 -0000 I think this document looks in good shape. I have two sets of WG comments relating to the language used in the current draft: (1) I think the language surrounding loss treatment needs to be still strengthened. (2) I would like to see the contradition with RFC3168 reworked to avoid this INFO docuemnt attempting to over-ride that PS. Best wishes, Gorry --- In section 1: " This protocol is not meant for uncontrolled deployment in the global Internet. " - To me this statement seems far too opn, and the draft has alreday found a clearer recommendations that I would agree to, as cited in the abstract: "DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it MUST NOT be deployed over the public Internet without additional measures" - Is it possible to re-use this statement in place of the one quoted above at the end of the conclusion? --- I'd also really like to see a statement about loss-treatment in the introduction. (see my comemt on section 5, but calling-out from the start that loss triggers standard TCP congestion control measures is I think a very important thing to make the reader aware about. Especially when the introduction (quite correctly) points to the merits of ECN reacting faster than loss-based methods. --- In section 3: "A DCTCP sender MUST deal with loss episodes in the same way as conventional TCP." - I agree. Could we replace "deal with" perhaps with something like "react to" --- 3.4. Handling of SYN, SYN-ACK, RST Packets " The switching fabric can drop TCP packets that do not have the ECT set in the IP header. If SYN and SYN-ACK packets for DCTCP connections do not have ECT set, they will be dropped with high probability. For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets." - I'd take the position that the fabric can and will drop any packets under overload, as per RFC7567. I'd prefer to explicitly state that to avoid a misconception that ECT eliminates all drop (rather than nearly all drops). --- Section 4: "It is RECOMMENDED that an implementation provide a configuration knob that will cause ECT to be set on such control packes" - please correct typo /packes" - I'm not a fan of an informational document over-riding a PS. I do not think this is appropriate. - I suggest once way to help, could be to say that "future versions of this protocol provide a configuration knob that will cause ECT to be set on such control packets [xx]." and then cite "draft-ietf-tsvwg-ecn-experimentation". - The present text is clearly at odds with the RFC series. --- In section 5: The following statement is correct, in as much as SCTP needs to go back loss-based CC, but I'd prefer personally to see this expressed as "reverts to loss-based congestion control" - to make this a little more clear, and I'd much rather it said when it encounters loss, rather than perhaps suggesting this is only drop-tail: "DCTCP will degrade to loss-based congestion control when transiting a congested drop-tail link." - e.g. something like this: "DCTCP will revert to loss-based congestion control when packet loss is experienced (e.g. when transiting a congested drop-tail link, or a link with an AQM drop behaviour). --- In section 6: This statement could be better written: "If the estimation gain is small relative to the packet loss rate, the estimate may not be too inaccurate." - First, I think the loss rate noted, may be the loss rate for the return path (i.e., the opposite direction to the packets bing CE-marked?) - Second, may not be too inacurrate sounds odd - do you think the accuracy is acceptable for normal use? If this relates to ACK loss, the following statement isn't necessarily true. And especially wculd be far from true for an internet with asymmetric routing: "o If packet loss mostly occurs under heavy congestion, most drops will occur during an unbroken string of CE packets, and the estimate will be unaffected. " From nobody Mon Mar 13 09:38:28 2017 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 92EB11295B3 for ; Mon, 13 Mar 2017 09:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4dzHM5scsB8 for ; Mon, 13 Mar 2017 09:38:24 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0128.outbound.protection.outlook.com [104.47.38.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E21012950E for ; Mon, 13 Mar 2017 09:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JL8savFghShaH3N/RvybhY1QcqW5Cfft7k9nzghASho=; b=MgVdV51WhtJjTGMkAesCAEZTXFxxX7WOyCJwbIDvFfuEjo8ierPIg/YJCVSt1zlluuf4oJWevLPUE/aaey3qNtHEPm7uzIdssfra8DxJYDbqWRixFU68GkWgurvv+ODQlYSxKiXOrJk5svAYPvapMebbayfnLL47OVNeTibLngw= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0278.namprd21.prod.outlook.com (10.173.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Mon, 13 Mar 2017 16:38:22 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0991.002; Mon, 13 Mar 2017 16:38:22 +0000 From: Praveen Balasubramanian To: Yuchung Cheng Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSht1kq1X/jxxo5k+Qc2zpAI+3x6F/H+QAgAFqKZCABgTZAIALnVBA Date: Mon, 13 Mar 2017 16:38:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::584] x-microsoft-exchange-diagnostics: 1; CY4PR21MB0278; 7:xUE0T1fqOsVoDdvzXFmELWy/MKZETHbxcQpyYAnPjta81jZtF8NgQ5ix6LF7m/SLF/G01eqPGb0wqek4Fi/Cz8khYWnIzyLlQfWQaT+iOv8jmAY+17L9V7z9q4LKxirOaOptxuUMqyed2UZlopqoaiPhr/+kn5LlPbx5YksBbw/XBp+HTkciCvBxhvWj3FtYnzVaa0IZXUrYehiwcPn7CJ2ZNWJ6KXzxTaXa9N0Q9KSxWBOqvG+UHz7QglTYzIyIo5ubrlgA3IvQ1SNVIUJ3Z6M9hp9dM4Wdl73SDpqWl1es2Ywlu3CmDy+OdmYem1w5xRJVB7TMGa9d0oHUNpCEqfgKsLm/mxKN2byNamN4ofY= x-ms-office365-filtering-correlation-id: 6a2b8cf6-4144-4ca5-fe2f-08d46a2f5d1c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0278; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR21MB0278; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0278; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39410400002)(39860400002)(39450400003)(24454002)(377454003)(86612001)(33656002)(6116002)(102836003)(8936002)(86362001)(8990500004)(10290500002)(3660700001)(5005710100001)(2906002)(5660300001)(53546007)(3280700002)(2900100001)(55016002)(230783001)(6436002)(25786008)(6916009)(93886004)(9686003)(2950100002)(4326008)(6306002)(76176999)(54906002)(99286003)(50986999)(54356999)(7696004)(106116001)(53936002)(122556002)(6506006)(10090500001)(38730400002)(110136004)(81166006)(8676002)(6246003)(74316002)(305945005)(229853002)(189998001)(77096006)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0278; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 16:38:22.2139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0278 Archived-At: Cc: Abdul Kabbani , "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 13 Mar 2017 16:38:26 -0000 PiBUaGFua3MgZm9yIGNsYXJpZmljYXRpb24uIEkgbm90aWNlIHRoZSBkcmFmdCBpcyBhbHNvIGxl c3MgY2xlYXIgYWJvdXQgdGhlIHdpbmRvdyByZWR1Y3Rpb24gb24gcGFja2V0IGxvc3Nlcy4gRm9y IGV4YW1wbGUsIGlmIHNlbmRlciBleHBlcmllbmNlcyBFQ0UgYW5kIHRoZW4gbG9zc2VzIGluIHRo ZSBzYW1lIHdpbmRvdyBvZiA+IGRhdGEuIERvZXMgRENUQ1AgcmVkdWNlcyB0aGUgd2luZG93IHR3 aWNlIChvbmNlIG9uIEVDTiwgdGhlbiBhZ2FpbiBvbiBMb3NzKT8NCg0KRENUQ1Agd2lsbCByZWR1 Y2UgdGhlIHdpbmRvdyBvbmx5IG9uY2UgcGVyIHdpbmRvdyBvZiBkYXRhIGZvciB0aGUgbG9zcyBz aWduYWxzIG9mIEVDTiBhbmQgZHVwbGljYXRlIEFDS3MuIE9uIGEgdGltZW91dCBjd25kIHdpbGwg YmUgdW5jb25kaXRpb25hbGx5IHJlZHVjZWQgdG8gMSBNU1MgZXZlbiBpZiB0aGVyZSB3YXMgYSBw cmVjZWRpbmcgY3duZCByZWR1Y3Rpb24gZHVlIHRvIGEgbG9zcyBzaWduYWwgaW4gYSBnaXZlbiB3 aW5kb3cgb2YgZGF0YS4gDQoNCj4gVGhlIGRyYWZ0IGltcGxpZXMgY3duZCB3b3VsZCBiZSByZWR1 Y2VkIHR3aWNlOg0KDQo+IEEgRENUQ1Agc2VuZGVyIE1VU1QgZGVhbCB3aXRoIGxvc3MgZXBpc29k ZXMgaW4gdGhlIHNhbWUgd2F5IGFzDQo+ICAgIGNvbnZlbnRpb25hbCBUQ1AuICBJbiBjYXNlIG9m IGEgdGltZW91dCBvciBmYXN0IHJldHJhbnNtaXQgb3IgYW55DQo+ICAgIGNoYW5nZSBpbiBkZWxh eSAoZm9yIGRlbGF5IGJhc2VkIGNvbmdlc3Rpb24gY29udHJvbCksIHRoZSBjd25kIGFuZA0KPiAg ICBvdGhlciBzdGF0ZSB2YXJpYWJsZXMgbGlrZSBzc3RocmVzaCBtdXN0IGJlIGNoYW5nZWQgaW4g dGhlIHNhbWUgd2F5DQo+ICAgIHRoYXQgYSBjb252ZW50aW9uYWwgVENQIHdvdWxkIGhhdmUgY2hh bmdlZCB0aGVtLg0KDQpUaGlzIHdvcmRpbmcgY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IGluIFdp bmRvd3MgYXQgbGVhc3QgRENUQ1AgaXMgaW1wbGVtZW50ZWQgYXMgYW4gZXh0ZW5zaW9uIHRvIE5l d1Jlbm8sIGluIHRoZSBzZW5zZSB0aGF0IG9ubHkgdGhlIEVDTiBoYW5kbGVyIGJlaGF2ZXMgZGlm ZmVyZW50bHkuIEkgd2lsbCBjaGFuZ2UgdGhpcyB3b3JkaW5nIHRvIGV4cGxpY2l0bHkgbWVudGlv biB0aGUgYWJvdmUgYmVoYXZpb3Igb2YgaGFuZGxpbmcgb3RoZXIgbG9zcyBldmVudHMuIA0KDQo+ IEFGQUlDVCBMaW51eCdzIGltcGxlbWVudGF0aW9uIGZvciBib3RoIERDVENQIGFuZCBSRkMzMTY4 IHdvdWxkIG9ubHkgcmVkdWNlIGN3bmQgb25jZSBvbiBFQ04gKyBsb3NzLiBTaW5jZSB0aGlzIGlz IGEgY29tbW9uIHNjZW5hcmlvLCBpdCdkIGJlIG5pY2UgdG8gYmUgZXhwbGljaXQgaW4gdGhlIERD VENQIGRyYWZ0Lg0KDQpZZXMgYWdyZWVkLiBXZSB3aWxsIHB1Ymxpc2ggYW4gdXBkYXRlIHNvb24u IA0KDQpUaGFua3MNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWXVjaHVu ZyBDaGVuZyBbbWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tXSANClNlbnQ6IFN1bmRheSwgTWFyY2gg NSwgMjAxNyA4OjM0IEFNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jv c29mdC5jb20+DQpDYzogdGNwbUBpZXRmLm9yZzsgQWJkdWwgS2FiYmFuaSA8YWthYmJhbmlAZ29v Z2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbdGNwbV0gV0dMQyBmb3IgZHJhZnQtaWV0Zi10Y3BtLWRj dGNwLTA0DQoNCk9uIEZyaSwgTWFyIDMsIDIwMTcgYXQgNDo0MSBQTSwgUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPg0KPiBZZXMgRENUQ1AgYWRq dXN0cyBjd25kIGF0IG1vc3Qgb25jZSBldmVyeSByb3VuZCB0cmlwLg0KPg0KPg0KPg0KPiBTZWUg c3RlcCA0Og0KPg0KPg0KPg0KPiBJZiB0aGUgYWNrbm93bGVkZ21lbnQgbnVtYmVyIGlzIGxlc3Mg dGhhbiBvciBlcXVhbCB0bw0KPg0KPiAgICAgICAgRENUQ1AuV2luZG93RW5kLCBzdG9wIHByb2Nl c3NpbmcuICBPdGhlcndpc2UsIHRoZSBlbmQgb2YgdGhlDQo+DQo+ICAgICAgICBvYnNlcnZhdGlv biB3aW5kb3cgaGFzIGJlZW4gcmVhY2hlZCwgc28gcHJvY2VlZCB0byB1cGRhdGUgdGhlDQo+DQo+ ICAgICAgICBjb25nZXN0aW9uIGVzdGltYXRlIGFzIGZvbGxvd3M6DQo+DQo+DQo+DQo+IFNvIHN0 ZXBzIDUgdGhyb3VnaCA4IGFyZSBjb25kaXRpb25hbCBhbmQgb25seSBleGVjdXRlZCBvbmNlIHBl ciByb3VuZC4gV2hhdCBpcyBhIGJpdCBjb25mdXNpbmcgaXMgdGhhdCB0aGUgY3duZCBjYWxjdWxh dGlvbiBpcyBub3QgaW5kaWNhdGVkIGFzIHN0ZXAgOS4gSSB3aWxsIGZpeCB0aGlzIGluIGFuIHVw ZGF0ZSB0byB0aGUgZHJhZnQuDQo+DQo+DQo+DQo+IE90aGVyIHRoYW4gdGhpcyB3ZSBhbHNvIGhh dmUgdGhlIGZvbGxvd2luZyBjbGFyaWZ5aW5nIHNlbnRlbmNlOg0KPg0KPiBKdXN0IGFzIHNwZWNp ZmllZCBpbiBbUkZDMzE2OF0sIERDVENQIGRvZXMgbm90IHJlYWN0IHRvIGNvbmdlc3Rpb24NCj4N Cj4gICAgaW5kaWNhdGlvbnMgbW9yZSB0aGFuIG9uY2UgZm9yIGV2ZXJ5IHdpbmRvdyBvZiBkYXRh Lg0KVGhhbmtzIGZvciBjbGFyaWZpY2F0aW9uLiBJIG5vdGljZSB0aGUgZHJhZnQgaXMgYWxzbyBs ZXNzIGNsZWFyIGFib3V0IHRoZSB3aW5kb3cgcmVkdWN0aW9uIG9uIHBhY2tldCBsb3NzZXMuIEZv ciBleGFtcGxlLCBpZiBzZW5kZXIgZXhwZXJpZW5jZXMgRUNFIGFuZCB0aGVuIGxvc3NlcyBpbiB0 aGUgc2FtZSB3aW5kb3cgb2YgZGF0YS4gRG9lcyBEQ1RDUCByZWR1Y2VzIHRoZSB3aW5kb3cgdHdp Y2UgKG9uY2Ugb24gRUNOLCB0aGVuIGFnYWluIG9uIExvc3MpPw0KDQpUaGUgZHJhZnQgaW1wbGll cyBjd25kIHdvdWxkIGJlIHJlZHVjZWQgdHdpY2U6DQoNCkEgRENUQ1Agc2VuZGVyIE1VU1QgZGVh bCB3aXRoIGxvc3MgZXBpc29kZXMgaW4gdGhlIHNhbWUgd2F5IGFzDQogICBjb252ZW50aW9uYWwg VENQLiAgSW4gY2FzZSBvZiBhIHRpbWVvdXQgb3IgZmFzdCByZXRyYW5zbWl0IG9yIGFueQ0KICAg Y2hhbmdlIGluIGRlbGF5IChmb3IgZGVsYXkgYmFzZWQgY29uZ2VzdGlvbiBjb250cm9sKSwgdGhl IGN3bmQgYW5kDQogICBvdGhlciBzdGF0ZSB2YXJpYWJsZXMgbGlrZSBzc3RocmVzaCBtdXN0IGJl IGNoYW5nZWQgaW4gdGhlIHNhbWUgd2F5DQogICB0aGF0IGEgY29udmVudGlvbmFsIFRDUCB3b3Vs ZCBoYXZlIGNoYW5nZWQgdGhlbS4NCg0KQUZBSUNUIExpbnV4J3MgaW1wbGVtZW50YXRpb24gZm9y IGJvdGggRENUQ1AgYW5kIFJGQzMxNjggd291bGQgb25seSByZWR1Y2UgY3duZCBvbmNlIG9uIEVD TiArIGxvc3MuIFNpbmNlIHRoaXMgaXMgYSBjb21tb24gc2NlbmFyaW8sIGl0J2QgYmUgbmljZSB0 byBiZSBleHBsaWNpdCBpbiB0aGUgRENUQ1AgZHJhZnQuDQoNCj4NCj4NCj4NCj4NCj4NCj4gRnJv bTogdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFl1Y2h1 bmcgQ2hlbmcNCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjgsIDIwMTcgMzowMyBQTQ0KPiBU bzogdGNwbUBpZXRmLm9yZw0KPiBDYzogQWJkdWwgS2FiYmFuaSA8YWthYmJhbmlAZ29vZ2xlLmNv bT4NCj4gU3ViamVjdDogUmU6IFt0Y3BtXSBXR0xDIGZvciBkcmFmdC1pZXRmLXRjcG0tZGN0Y3At MDQNCj4NCj4NCj4NCj4gVGhlIHdvcmRpbmdzIG9uIGN3bmQgYWRqdXN0bWVudCBpbiBzZWN0aW9u IDMuMyBjYW4gYmUgbW9yZSBjbGVhcjoNCj4NCj4NCj4NCj4gIiIiDQo+DQo+IFJhdGhlciB0aGFu IGFsd2F5cyBoYWx2aW5nIHRoZSBjb25nZXN0aW9uIHdpbmRvdyBhcyBkZXNjcmliZWQgaW4NCj4N Cj4gICAgW1JGQzMxNjhdLCB3aGVuIHRoZSBzZW5kZXIgcmVjZWl2ZXMgYW4gaW5kaWNhdGlvbiBv ZiBjb25nZXN0aW9uDQo+DQo+ICAgIChFQ0UpLCB0aGUgc2VuZGVyIE1VU1QgdXBkYXRlIGN3bmQg YXMgZm9sbG93czoNCj4NCj4NCj4NCj4gICAgICAgY3duZCA9IGN3bmQgKiAoMSAtIERDVENQLkFs cGhhIC8gMikNCj4NCj4NCj4NCj4gICAgVGh1cywgd2hlbiBubyBzZW50IGJ5dGUgZXhwZXJpZW5j ZWQgY29uZ2VzdGlvbiwgRENUQ1AuQWxwaGEgZXF1YWxzDQo+DQo+ICAgIHplcm8sIGFuZCBjd25k IGlzIGxlZnQgdW5jaGFuZ2VkLiAgV2hlbiBhbGwgc2VudCBieXRlcyBleHBlcmllbmNlZA0KPg0K PiAgICBjb25nZXN0aW9uLCBEQ1RDUC5BbHBoYSBlcXVhbHMgb25lLCBhbmQgY3duZCBpcyByZWR1 Y2VkIGJ5IGhhbGYuDQo+DQo+ICAgIExvd2VyIGxldmVscyBvZiBjb25nZXN0aW9uIHdpbGwgcmVz dWx0IGluIGNvcnJlc3BvbmRpbmdseSBzbWFsbGVyDQo+DQo+ICAgIHJlZHVjdGlvbnMgdG8gY3du ZC4NCj4NCj4gIiIiDQo+DQo+DQo+DQo+IEFGQUlDVCBEQ1RDUCBwYXBlciBvbmx5IGFkanVzdHMg Y3duZCBhdCBtb3N0IGV2ZXJ5IHJvdW5kIHRyaXAgKHdoaWNoIGlzIGFsc28gaG93IExpbnV4IGlt cGxlbWVudHMgaXQpLiBCdXQgdGhlIHRleHQgaW1wbGllcyB0aGUgY3duZCByZWR1Y3Rpb24gY2Fu IGhhcHBlbiBmb3IgZXZlcnkgRUNFIG1hcms/DQo+DQo+DQo+DQo+DQo+DQo+IE9uIFR1ZSwgRmVi IDE0LCAyMDE3IGF0IDg6MzEgQU0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1pY2hh ZWwuc2NoYXJmQG5va2lhLmNvbT4gd3JvdGU6DQo+DQo+IEhpLA0KPg0KPiBUQ1BNIGNoYWlycyBh cmUgbm90IGF3YXJlIG9mIG91dHN0YW5kaW5nIGlzc3VlcyBpbiBkcmFmdC1pZXRmLXRjcG0tZGN0 Y3AtMDQgIkRhdGFjZW50ZXIgVENQIChEQ1RDUCk6IFRDUCBDb25nZXN0aW9uIENvbnRyb2wgZm9y IERhdGFjZW50ZXJzIi4NCj4NCj4gVGhlcmVmb3JlLCB0aGlzIGUtbWFpbCBzdGFydHMgYSB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi10Y3BtLWRjdGNwLTA0Lg0KPg0KPiBU aGUgV0dMQyBydW5zIHVudGlsIEZyaWRheSBNYXJjaCAzLiBQbGVhc2Ugc2VuZCBhbnkgY29tbWVu dHMgdG8gdGhlIFRDUE0gbWFpbGluZyBsaXN0IGJ5IHRoZW4uIFN0YXRlbWVudHMgc3VwcG9ydGlu ZyB0aGUgcHVibGljYXRpb24gb2YgdGhlIGRvY3VtZW50IGFyZSBhbHNvIGhlbHBmdWwuDQo+DQo+ IFdlIGFzc3VtZSB0aGF0IFRDUE0gd29ya2luZyBncm91cCBpcyBhd2FyZSBvZiB0aGUgSVBSIGRp c2Nsb3N1cmUgcmVsYXRlZCB0byBkcmFmdC1iZW5zbGV5LXRjcG0tZGN0Y3AtMDAgKGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIzMTkvKS4gQSBzZXBhcmF0ZSBub3RlIHdpbGwgYmUg c2VudCBvdXQgdG8gY29uZmlybSB0aGF0IGFsbCBJUFIgaGFzIGFscmVhZHkgYmVlbiBkaXNjbG9z ZWQsIGluIGNvbmZvcm1hbmNlIHdpdGggQkNQcyA3OCBhbmQgNzkuDQo+DQo+IFRoZSBkcmFmdCBp cyBhdmFpbGFibGUgYXQgDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXRjcG0tZGN0Y3AtMDQNCj4NCj4gVGhhbmtzDQo+DQo+IE1pY2hhZWwNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5nIGxpc3QN Cj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RjcG0NCj4NCj4NCg== From nobody Mon Mar 13 09:41:15 2017 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 838B61297C2; Mon, 13 Mar 2017 09:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQgbMlWk0pCv; Mon, 13 Mar 2017 09:41:12 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0101.outbound.protection.outlook.com [104.47.41.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F283E12950E; Mon, 13 Mar 2017 09:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VLibcyCgc370SRb72Jk7MT6NU7e5jYOoGLvUFkNJMdc=; b=j+q/gm/yu+UJJ8Or4oX543uG0Hz2C3zoWok8y7SJgZx9yVWN6cWYCRsC6FEhRiTPBzB2G+N8OO5orbUezk+5CpaHW9dNNtdf3MqSDAunZWaHL7SZyWFz0e0fGvCezD2YK/+v+Fsnfs53ef1DyB7SmCPXYhJNzYvlS6fO+1fxNqs= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0280.namprd21.prod.outlook.com (10.173.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Mon, 13 Mar 2017 16:41:08 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0991.002; Mon, 13 Mar 2017 16:41:08 +0000 From: Praveen Balasubramanian To: "De Schepper, Koen (Nokia - BE)" , "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSht1kq1X/jxxo5k+Qc2zpAI+3x6F/wR9AgAQyWFCAA+dJUIAKU0eg Date: Mon, 13 Mar 2017 16:41:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia-bell-labs.com; dkim=none (message not signed) header.d=none;nokia-bell-labs.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::584] x-microsoft-exchange-diagnostics: 1; CY4PR21MB0280; 7:hRM0G+o2l7c4ShdjU/nvdIuJHjZi0mkqhYagVFXGAlTAORPUU5DfQnkIoC7InH3kj1EWdxo/CwVHCoj6Lbv6IcUUKN2IGvpA5oSj8GBV9Z3Te6uziYM7uPzhDZ/P1Jx6CqTg1iRP8IWAh9zvBHS1lBtqSxKGqlYZA5Y6LAWNtRIZzdPVh5cQC81AP6yNrqeLibF7yzOrQwmg8gYPklYLVNa49ZOcoNoZyrTvt1VgopMIoRQHaafGpPES76+AZXjBXYJE1yOUZWVe3yukWL3lQPUj5/QV22+Q4rNX5igsOc2mPNHCYlxWy/vibiV59+AzT53s/7H7NZXAbajw7RZaTPsvei9vspn05F46R7QfGnQ= x-ms-office365-filtering-correlation-id: 94e673be-b2bc-4099-65c7-08d46a2fc024 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0280; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:CY4PR21MB0280; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0280; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(377454003)(51444003)(38730400002)(6246003)(2906002)(122556002)(8990500004)(8676002)(81166006)(8936002)(189998001)(76176999)(54356999)(50986999)(4326008)(53936002)(53546007)(93886004)(230783001)(33656002)(55016002)(99286003)(2501003)(5660300001)(7696004)(2950100002)(6306002)(25786008)(9686003)(2900100001)(6506006)(77096006)(106116001)(6436002)(229853002)(10290500002)(102836003)(5005710100001)(6116002)(86362001)(3280700002)(86612001)(3660700001)(74316002)(7736002)(305945005)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0280; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 16:41:08.4679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0280 Archived-At: Cc: "tcpm-chairs@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 13 Mar 2017 16:41:14 -0000 > The DCTCP > implementation MAY also allow configuration of resetting the value of > DCTCP.Alpha as part of processing any loss episodes. Changing this to: If experimental results show a benefit, a DCTCP implementation MAY reset th= e value of DCTCP.Alpha to 1 value as part of processing any loss episodes.= =20 Thanks -----Original Message----- From: De Schepper, Koen (Nokia - BE) [mailto:koen.de_schepper@nokia-bell-la= bs.com]=20 Sent: Wednesday, March 8, 2017 8:24 AM To: Praveen Balasubramanian ; Scharf, Michael (Nokia -= DE) ; tcpm@ietf.org Cc: tcpm-chairs@ietf.org Subject: RE: WGLC for draft-ietf-tcpm-dctcp-04 > -----Original Message----- > From: Praveen Balasubramanian [mailto:pravb@microsoft.com] > Sent: zaterdag 4 maart 2017 1:52 > To: De Schepper, Koen (Nokia - BE) labs.com>; Scharf, Michael (Nokia - DE) ;=20 > tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: RE: WGLC for draft-ietf-tcpm-dctcp-04 >=20 > The text around allowing a reset of Alpha was added on suggestions=20 > from the Linux implementation experience. [KDS] I see it was added from the Linux implementation, but clearly not bas= ed on the experience ;-). This implementation is not working. I don't know if the FreeBSD implementation has drop compatibility, and how = it works. If that has a working implementation by setting alpha to max, we can keep t= he text. > The text already suggests that this is optional. [KDS] That is OK, as in the Linux patch it is also optional (default on).=20 The new parameter is called dctcp_drop_compatible as it does not have anyth= ing to do with alpha clamping. Koen. > The Windows implementation does not reset the value of Alpha or the=20 > other tracking variables. I think that we don't need to remove this=20 > text. If you still strongly object and I don't hear any other=20 > opinions, I will remove it in the next revision. >=20 > >> The Linux patch I provided additionally halves the window (once per=20 > >> RTT) > when a drop is encountered, independent from alpha The handling of a=20 > timeout and dup acks should ideally be identical to NewReno. The only=20 > change in response is in presence of ECN marks. >=20 > Thanks >=20 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of De Schepper,=20 > Koen (Nokia - BE) > Sent: Wednesday, March 1, 2017 2:18 AM > To: Scharf, Michael (Nokia - DE) ;=20 > tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 >=20 > I have a comment on the following text: >=20 > It would be useful to implement DCTCP as additional actions on top of > an existing congestion control algorithm like NewReno. The DCTCP > implementation MAY also allow configuration of resetting the value of > DCTCP.Alpha as part of processing any loss episodes. >=20 > Setting alpha to its max value (btw resetting might imply setting to=20 > zero) has many complications and in the current Linux implementation=20 > turned out to not function. > The Linux patch I provided additionally halves the window (once per=20 > RTT) when a drop is encountered, independent from alpha. This is also,=20 > as far as I understood, how the Windows version works. Both=20 > implementations are working now in drop-based networks next to Classic TC= P flows. >=20 > As far as I know there is no working implementation that is setting=20 > alpha to max so I propose to describe the working implementation=20 > instead of a theoretical one. >=20 > For the rest I support publication. >=20 > Koen. >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf,=20 > > Michael (Nokia - DE) > > Sent: dinsdag 14 februari 2017 17:32 > > To: tcpm@ietf.org > > Cc: tcpm-chairs@ietf.org > > Subject: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 > > > > Hi, > > > > TCPM chairs are not aware of outstanding issues in > > draft-ietf-tcpm-dctcp-04 "Datacenter TCP (DCTCP): TCP Congestion=20 > > Control > for Datacenters". > > > > Therefore, this e-mail starts a working group last call for > > draft-ietf-tcpm- dctcp-04. > > > > The WGLC runs until Friday March 3. Please send any comments to the=20 > > TCPM mailing list by then. Statements supporting the publication of=20 > > the document are also helpful. > > > > We assume that TCPM working group is aware of the IPR disclosure=20 > > related to draft-bensley-tcpm-dctcp-00=20 > > (https://datatracker.ietf.org/ipr/2319/). A separate note will be=20 > > sent out to confirm that all IPR has already been disclosed, in=20 > > conformance with > BCPs 78 and 79. > > > > The draft is available at > > https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-04 > > > > Thanks > > > > Michael > > _______________________________________________ > > 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 Mar 13 13:28:54 2017 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 DC44A1294C0; Mon, 13 Mar 2017 13:28:52 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943693286.20397.8573577793090041440@ietfa.amsl.com> Date: Mon, 13 Mar 2017 13:28:52 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-02.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: Mon, 13 Mar 2017 20:28:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : RACK: a time-based fast loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Filename : draft-ietf-tcpm-rack-02.txt Pages : 22 Date : 2017-03-13 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 15:12:36 2017 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 6C0251299CF for ; Mon, 13 Mar 2017 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 VwdHnSIrJ2rY for ; Mon, 13 Mar 2017 15:12:33 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 9A7D9129518 for ; Mon, 13 Mar 2017 15:12:33 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m27so8641301iti.1 for ; Mon, 13 Mar 2017 15:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tujcq+TxZ1XHMsd56/n2V9Nptwuz6JQZUqqTjwhWYQY=; b=X6tsOsrpce/xWkVkH7eUIgNdDAP172jaBIqGI6fuvldW6v+QFDJ575VQ5Y7fI39iiV t7a/50h+56fQ/x41rV8Hpa7PPDj4gzaK4sFJhFvpV2mwvy1xK2BUnG3VP9VcsAfQ2fVZ SCTHdu1D6B+DbBE29xHTeDmvJPCb91D4CspAXYUPvvbI5JMi2ypLO7Yo7JVY0BANLBuz 5TghUY70Ji/70AqrfFrl2ZFpH6hNn3tA6kCzYVoX+eeshj9iAi+nwNr+ScIft7MKmt8Q gvEo2d7gEt/1XLxCGYPnTwYuPETFXH/ZlAzkiRxMe0H4/glWlum7iKkfQ8PEQGQlfQSj NUQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tujcq+TxZ1XHMsd56/n2V9Nptwuz6JQZUqqTjwhWYQY=; b=JUTaYH8R0ZX3TdgsgzddRbJknEzZT2HtIx30GUUjZt7DMq9cwIvqjSkdL5lH+sLlFz ln9eYWY78mRuMrenpYrEJuYJGvDJ94HLD3YMsR+2k+gF2fS0YxAWtmMLWvOLKHeTNdBh KdzWxf/9kRsDQgKGVxzAAtGs7mfX9lNPCjxsHVAJu9eMRc3+o0/Fp5LdDlIgLRPhoYm6 bQxoot4TNa+8ERRGY3Xtn7HYb8tZ7kXqm8gQ5z4Kpu+gYW+sYXSRWyA4wnZz/WZ4MLyu wPr+ZcknEm1TgF/GCZBhuoM9zau9s2lcFK9nyOzOcBIhlGfxPAz5iiTJT7sLwVg2BSjp e23A== X-Gm-Message-State: AFeK/H3racAgO0M8wi/IojqGl6ZPR+Q9W9yEjXW133uSVh7CpmBtukLuQJhxWGDePy2J3ZFIc4+fXcewjaMt1pFP X-Received: by 10.36.80.213 with SMTP id m204mr12586189itb.105.1489443152795; Mon, 13 Mar 2017 15:12:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Mon, 13 Mar 2017 15:11:52 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Mon, 13 Mar 2017 15:11:52 -0700 Message-ID: To: Praveen Balasubramanian Content-Type: multipart/alternative; boundary=001a1145f2fa097df3054aa4026f Archived-At: Cc: Abdul Kabbani , "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 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, 13 Mar 2017 22:12:35 -0000 --001a1145f2fa097df3054aa4026f Content-Type: text/plain; charset=UTF-8 On Mon, Mar 13, 2017 at 9:38 AM, Praveen Balasubramanian < pravb@microsoft.com> wrote: > > Thanks for clarification. I notice the draft is also less clear about > the window reduction on packet losses. For example, if sender experiences > ECE and then losses in the same window of > data. Does DCTCP reduces the > window twice (once on ECN, then again on Loss)? > > DCTCP will reduce the window only once per window of data for the loss > signals of ECN and duplicate ACKs. On a timeout cwnd will be > unconditionally reduced to 1 MSS even if there was a preceding cwnd > reduction due to a loss signal in a given window of data. > > > The draft implies cwnd would be reduced twice: > > > A DCTCP sender MUST deal with loss episodes in the same way as > > conventional TCP. In case of a timeout or fast retransmit or any > > change in delay (for delay based congestion control), the cwnd and > > other state variables like ssthresh must be changed in the same way > > that a conventional TCP would have changed them. > > This wording comes from the fact that in Windows at least DCTCP is > implemented as an extension to NewReno, in the sense that only the ECN > handler behaves differently. I will change this wording to explicitly > mention the above behavior of handling other loss events. > Thanks for the clarification. I assume you mean Reno not NewReno. NewReno is not a congestion control... okay I really need to start a thread to correct this. > > > AFAICT Linux's implementation for both DCTCP and RFC3168 would only > reduce cwnd once on ECN + loss. Since this is a common scenario, it'd be > nice to be explicit in the DCTCP draft. > > Yes agreed. We will publish an update soon. > > Thanks > > > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: Sunday, March 5, 2017 8:34 AM > To: Praveen Balasubramanian > Cc: tcpm@ietf.org; Abdul Kabbani > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 > > On Fri, Mar 3, 2017 at 4:41 PM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > > > Yes DCTCP adjusts cwnd at most once every round trip. > > > > > > > > See step 4: > > > > > > > > If the acknowledgment number is less than or equal to > > > > DCTCP.WindowEnd, stop processing. Otherwise, the end of the > > > > observation window has been reached, so proceed to update the > > > > congestion estimate as follows: > > > > > > > > So steps 5 through 8 are conditional and only executed once per round. > What is a bit confusing is that the cwnd calculation is not indicated as > step 9. I will fix this in an update to the draft. > > > > > > > > Other than this we also have the following clarifying sentence: > > > > Just as specified in [RFC3168], DCTCP does not react to congestion > > > > indications more than once for every window of data. > Thanks for clarification. I notice the draft is also less clear about the > window reduction on packet losses. For example, if sender experiences ECE > and then losses in the same window of data. Does DCTCP reduces the window > twice (once on ECN, then again on Loss)? > > The draft implies cwnd would be reduced twice: > > A DCTCP sender MUST deal with loss episodes in the same way as > conventional TCP. In case of a timeout or fast retransmit or any > change in delay (for delay based congestion control), the cwnd and > other state variables like ssthresh must be changed in the same way > that a conventional TCP would have changed them. > > AFAICT Linux's implementation for both DCTCP and RFC3168 would only reduce > cwnd once on ECN + loss. Since this is a common scenario, it'd be nice to > be explicit in the DCTCP draft. > > > > > > > > > > > > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng > > Sent: Tuesday, February 28, 2017 3:03 PM > > To: tcpm@ietf.org > > Cc: Abdul Kabbani > > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04 > > > > > > > > The wordings on cwnd adjustment in section 3.3 can be more clear: > > > > > > > > """ > > > > Rather than always halving the congestion window as described in > > > > [RFC3168], when the sender receives an indication of congestion > > > > (ECE), the sender MUST update cwnd as follows: > > > > > > > > cwnd = cwnd * (1 - DCTCP.Alpha / 2) > > > > > > > > Thus, when no sent byte experienced congestion, DCTCP.Alpha equals > > > > zero, and cwnd is left unchanged. When all sent bytes experienced > > > > congestion, DCTCP.Alpha equals one, and cwnd is reduced by half. > > > > Lower levels of congestion will result in correspondingly smaller > > > > reductions to cwnd. > > > > """ > > > > > > > > AFAICT DCTCP paper only adjusts cwnd at most every round trip (which is > also how Linux implements it). But the text implies the cwnd reduction can > happen for every ECE mark? > > > > > > > > > > > > On Tue, Feb 14, 2017 at 8:31 AM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > > > Hi, > > > > TCPM chairs are not aware of outstanding issues in > draft-ietf-tcpm-dctcp-04 "Datacenter TCP (DCTCP): TCP Congestion Control > for Datacenters". > > > > Therefore, this e-mail starts a working group last call for > draft-ietf-tcpm-dctcp-04. > > > > The WGLC runs until Friday March 3. Please send any comments to the TCPM > mailing list by then. Statements supporting the publication of the document > are also helpful. > > > > We assume that TCPM working group is aware of the IPR disclosure related > to draft-bensley-tcpm-dctcp-00 (https://datatracker.ietf.org/ipr/2319/). > A separate note will be sent out to confirm that all IPR has already been > disclosed, in conformance with BCPs 78 and 79. > > > > The draft is available at > > https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-04 > > > > Thanks > > > > Michael > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > --001a1145f2fa097df3054aa4026f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 13, 2017 at 9:38 AM, Praveen Balasubramanian <pravb@micr= osoft.com> wrote:
> Thanks for clarification. I notice the draft is also less cle= ar about the window reduction on packet losses. For example, if sender expe= riences ECE and then losses in the same window of > data. Does DCTCP red= uces the window twice (once on ECN, then again on Loss)?

DCTCP will reduce the window only once per window of data for the lo= ss signals of ECN and duplicate ACKs. On a timeout cwnd will be uncondition= ally reduced to 1 MSS even if there was a preceding cwnd reduction due to a= loss signal in a given window of data.

> The draft implies cwnd would be reduced twice:

> A DCTCP sender MUST deal with loss episodes in the same way as
>=C2=A0 =C2=A0 conventional TCP.=C2=A0 In case of a timeout or fast retr= ansmit or any
>=C2=A0 =C2=A0 change in delay (for delay based congestion control), the= cwnd and
>=C2=A0 =C2=A0 other state variables like ssthresh must be changed in th= e same way
>=C2=A0 =C2=A0 that a conventional TCP would have changed them.

This wording comes from the fact that in Windows at least DCTCP is i= mplemented as an extension to NewReno, in the sense that only the ECN handl= er behaves differently. I will change this wording to explicitly mention th= e above behavior of handling other loss events.
Thanks= for the clarification. I assume you mean Reno not NewReno. NewReno is not = a congestion control... okay I really need to start a thread to correct thi= s.

=C2=A0

> AFAICT Linux's implementation for both DCTCP and RFC3168 would onl= y reduce cwnd once on ECN + loss. Since this is a common scenario, it'd= be nice to be explicit in the DCTCP draft.

Yes agreed. We will publish an update soon.

Thanks


-----Original Message-----
From: Yuchung Cheng [mailto:ycheng@goo= gle.com]
Sent: Sunday, March 5, 2017 8:34 AM
To: Praveen Balasubramanian <prav= b@microsoft.com>
Cc: tcpm@ietf.org; Abdul Kabbani <<= a href=3D"mailto:akabbani@google.com">akabbani@google.com>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04

On Fri, Mar 3, 2017 at 4:41 PM, Praveen Balasubramanian <pravb@microsoft.com> wrote:
>
> Yes DCTCP adjusts cwnd at most once every round trip.
>
>
>
> See step 4:
>
>
>
> If the acknowledgment number is less than or equal to
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 DCTCP.WindowEnd, stop processing.=C2=A0 Oth= erwise, the end of the
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 observation window has been reached, so pro= ceed to update the
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 congestion estimate as follows:
>
>
>
> So steps 5 through 8 are conditional and only executed once per round.= What is a bit confusing is that the cwnd calculation is not indicated as s= tep 9. I will fix this in an update to the draft.
>
>
>
> Other than this we also have the following clarifying sentence:
>
> Just as specified in [RFC3168], DCTCP does not react to congestion
>
>=C2=A0 =C2=A0 indications more than once for every window of data.
Thanks for clarification. I notice the draft is also less clear about the w= indow reduction on packet losses. For example, if sender experiences ECE an= d then losses in the same window of data. Does DCTCP reduces the window twi= ce (once on ECN, then again on Loss)?

The draft implies cwnd would be reduced twice:

A DCTCP sender MUST deal with loss episodes in the same way as
=C2=A0 =C2=A0conventional TCP.=C2=A0 In case of a timeout or fast retransmi= t or any
=C2=A0 =C2=A0change in delay (for delay based congestion control), the cwnd= and
=C2=A0 =C2=A0other state variables like ssthresh must be changed in the sam= e way
=C2=A0 =C2=A0that a conventional TCP would have changed them.

AFAICT Linux's implementation for both DCTCP and RFC3168 would only red= uce cwnd once on ECN + loss. Since this is a common scenario, it'd be n= ice to be explicit in the DCTCP draft.

>
>
>
>
>
> From: tcpm [mailto:tcpm-bounc= es@ietf.org] On Behalf Of Yuchung Cheng
> Sent: Tuesday, February 28, 2017 3:03 PM
> To: tcpm@ietf.org
> Cc: Abdul Kabbani <akabbani@= google.com>
> Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-dctcp-04
>
>
>
> The wordings on cwnd adjustment in section 3.3 can be more clear:
>
>
>
> """
>
> Rather than always halving the congestion window as described in
>
>=C2=A0 =C2=A0 [RFC3168], when the sender receives an indication of cong= estion
>
>=C2=A0 =C2=A0 (ECE), the sender MUST update cwnd as follows:
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd =3D cwnd * (1 - DCTCP.Alpha / 2)
>
>
>
>=C2=A0 =C2=A0 Thus, when no sent byte experienced congestion, DCTCP.Alp= ha equals
>
>=C2=A0 =C2=A0 zero, and cwnd is left unchanged.=C2=A0 When all sent byt= es experienced
>
>=C2=A0 =C2=A0 congestion, DCTCP.Alpha equals one, and cwnd is reduced b= y half.
>
>=C2=A0 =C2=A0 Lower levels of congestion will result in correspondingly= smaller
>
>=C2=A0 =C2=A0 reductions to cwnd.
>
> """
>
>
>
> AFAICT DCTCP paper only adjusts cwnd at most every round trip (which i= s also how Linux implements it). But the text implies the cwnd reduction ca= n happen for every ECE mark?
>
>
>
>
>
> On Tue, Feb 14, 2017 at 8:31 AM, Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> wr= ote:
>
> Hi,
>
> TCPM chairs are not aware of outstanding issues in draft-ietf-tcpm-dct= cp-04 "Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters&= quot;.
>
> Therefore, this e-mail starts a working group last call for draft-ietf= -tcpm-dctcp-04.
>
> The WGLC runs until Friday March 3. Please send any comments to the TC= PM mailing list by then. Statements supporting the publication of the docum= ent are also helpful.
>
> We assume that TCPM working group is aware of the IPR disclosure relat= ed to draft-bensley-tcpm-dctcp-00 (https://datatracker.ietf.or= g/ipr/2319/). A separate note will be sent out to confirm that all= IPR has already been disclosed, in conformance with BCPs 78 and 79.
>
> The draft is available at
> https://tools.ietf.org/html/draft-ie= tf-tcpm-dctcp-04
>
> Thanks
>
> Michael
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm >
>

--001a1145f2fa097df3054aa4026f-- From nobody Mon Mar 13 15:25:35 2017 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 EA53E129BD4 for ; Mon, 13 Mar 2017 15:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-0.001, 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 aZ9tzFBk6QkT for ; Mon, 13 Mar 2017 15:25:30 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 8C627129BDA for ; Mon, 13 Mar 2017 15:25:29 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id z13so94066975iof.2 for ; Mon, 13 Mar 2017 15:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=m7IYc6PbbAYrepi908qCDawdbIk27yctvvsPU4ve9Fg=; b=DjraHNR3RMTo6LrBAtVJ9o9jx3rpygBU32DUIvaJ3fB40aoRM6r9HTAdOZ6lMhnDNa 0BbP3V4OauPKqWdg3hmFutm8xtZoNDWQKt3yPfPc01AVRY22PpV1MgNtvWNNde+BMaXs F21E2QkeJNxTWwmBlMb4iNRt2bd3mK1ATZGE+7GHoxYME9nqTmtCzNaxUin7dxs/P/Hf hrPSjqTDvdZygFjN5MA0LU08kQayXDYCxNY5op7xlZ7CW7xyAW4i0xPDPHM7sxEkYvUD ion6rkQC3N37IQ5TkD1SXhluTi2z4YlnuxHNMdzfKMAOdH7e/BVIny5PPuHlQribVkuT PKbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=m7IYc6PbbAYrepi908qCDawdbIk27yctvvsPU4ve9Fg=; b=YIsk28xNgraW/fI6hSMrf19NoBsES/UE47ifRPtz+WTxF0oCGPmILiYEnObHe2H2wT pvRXccN1NuAiKLpbzMO5OV+a4bI6NVlfzB0z8DWkfSyDtZFlRVt40tUAYqHcTdAS6FaW 2iF/IccGyVD78OWb1IOlVeiP0dqXdlKrWFxzayTdlQvvF1eLjC7ciTVKKzWfpZOs7MgM yj/zUdD+iTI4lDRZ4qhgK0MRcRuFhRT+hs8h33xThab6rnGWuEtQvWb/Y+Zi7kN/oUAi jzxZgDH+HODwjuXpG/njFvyLLPR41Vyg3yyFTpOmf5+kkuS3HEibgVvvuuqhv6P9coOX 3sCg== X-Gm-Message-State: AMke39nXNUTqOUBIBABZYEVHrVg/qLd5cGz2QPM+3EPYm0k25kCNUq0cJotsj54agPSWDz5f0S1if6ZY1mQHdmk/ X-Received: by 10.107.172.134 with SMTP id v128mr33832297ioe.49.1489443928511; Mon, 13 Mar 2017 15:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Mon, 13 Mar 2017 15:24:48 -0700 (PDT) From: Yuchung Cheng Date: Mon, 13 Mar 2017 15:24:48 -0700 Message-ID: To: "tcpm@ietf.org Extensions" , iccrg@irtf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [tcpm] Clarification on NewReno vs Reno 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, 13 Mar 2017 22:25:32 -0000 Over the past years, I have seem many people in both academia and industry citing NewReno as a congestion control which really confuses me. I would like to attempt to ask a clarification from list. AFAIK, NewReno is NOT a congestion control. It is an improvement to loss recovery in the absence of SACK support, per the abstract in RFC6582 """ ... in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. """ In a nutshell, NewReno simply retransmits the next unacked packet when SND.UNA advances. Using NewReno impacts the congestion control which can be either Reno, Cubic, etc. But it is not a congestion control by itself. In Linux NewReno is used only if SACK is not supported which is rare. Reno in contrast is the standard AIMD defined by RFC5681. From nobody Mon Mar 13 16:13:52 2017 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 65712129BC7 for ; Mon, 13 Mar 2017 16:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zl6ytmFcHGI for ; Mon, 13 Mar 2017 16:13:44 -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 F14F3129BEE for ; Mon, 13 Mar 2017 16:13:41 -0700 (PDT) Received: from mail-ot0-f174.google.com (mail-ot0-f174.google.com [74.125.82.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id EC3FE2792C9 for ; Tue, 14 Mar 2017 08:13:38 +0900 (JST) Received: by mail-ot0-f174.google.com with SMTP id i1so123022101ota.3 for ; Mon, 13 Mar 2017 16:13:38 -0700 (PDT) X-Gm-Message-State: AMke39myVn1RUeuiH5KFJqTlwY9BsNYBrQVx8j5qNXYKNm0dTakjW8epC9FHmqUxSVwP6agDLn60054grKx0tQ== X-Received: by 10.157.61.164 with SMTP id l33mr20583434otc.274.1489446817608; Mon, 13 Mar 2017 16:13:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.82.27 with HTTP; Mon, 13 Mar 2017 16:13:37 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Mon, 13 Mar 2017 16:13:37 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Yuchung Cheng Content-Type: multipart/alternative; boundary=001a114708b279bfd9054aa4dcf8 Archived-At: Cc: "tcpm@ietf.org Extensions" , iccrg@irtf.org Subject: Re: [tcpm] [iccrg] Clarification on NewReno vs Reno 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, 13 Mar 2017 23:13:46 -0000 --001a114708b279bfd9054aa4dcf8 Content-Type: text/plain; charset=UTF-8 Hi Yuchung, This seems to be a rather philosophical question to me. So, I am not very sure if we can gain something from this.. In my personal view, congestion control in TCP is "infer network status based on feedback info, adjust amount of packet transmissions based on it" I think what newreno does fit this. It uses partial acks as feedback to do some controls. Hence, it looks congestion control to me. But, it's just my personal view and can be different from yours. Thanks, -- Yoshi On Mon, Mar 13, 2017 at 3:24 PM, Yuchung Cheng wrote: > Over the past years, I have seem many people in both academia and > industry citing NewReno as a congestion control which really confuses > me. I would like to attempt to ask a clarification from list. > > AFAIK, NewReno is NOT a congestion control. It is an improvement to > loss recovery in the absence of SACK support, per the abstract in > RFC6582 > > """ ... in the absence of SACK. This document describes a specific > algorithm for responding to partial acknowledgments, referred to as > "NewReno". This response to partial acknowledgments was first > proposed by Janey Hoe. This document obsoletes RFC 3782. > > """ > > In a nutshell, NewReno simply retransmits the next unacked packet when > SND.UNA advances. Using NewReno impacts the congestion control which > can be either Reno, Cubic, etc. But it is not a congestion control by > itself. In Linux NewReno is used only if SACK is not supported which > is rare. > > Reno in contrast is the standard AIMD defined by RFC5681. > > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg > --001a114708b279bfd9054aa4dcf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yuchung,

This seems to be a rather p= hilosophical question to me. So, I am not very sure if we can gain somethin= g from this..

In my personal view, congestion cont= rol in TCP is "infer network status based on feedback info, adjust amo= unt of packet transmissions =C2=A0based on it"=C2=A0
I think= what newreno does fit this. It uses partial acks as feedback to do some co= ntrols.
Hence, it looks congestion control to me. But, it's j= ust my personal view and can be different from yours.=C2=A0

<= /div>
Thanks,
--
Yoshi


On Mon, Mar 13, 2017 = at 3:24 PM, Yuchung Cheng <ycheng@google.com> wrote:
Over the past years, I have seem many people in = both academia and
industry citing NewReno as a congestion control which really confuses
me. I would like to attempt to ask a clarification from list.

AFAIK, NewReno is NOT a congestion control. It is an improvement to
loss recovery in the absence of SACK support, per the abstract in
RFC6582

"""=C2=A0 =C2=A0 ... in the absence of SACK. This document d= escribes a specific
=C2=A0 =C2=A0algorithm for responding to partial acknowledgments, referred = to as
=C2=A0 =C2=A0"NewReno".=C2=A0 This response to partial acknowledg= ments was first
=C2=A0 =C2=A0proposed by Janey Hoe.=C2=A0 This document obsoletes RFC 3782.=

"""

In a nutshell, NewReno simply retransmits the next unacked packet when
SND.UNA advances. Using NewReno impacts the congestion control which
can be either Reno, Cubic, etc. But it is not a congestion control by
itself. In Linux NewReno is used only if SACK is not supported which
is rare.

Reno in contrast is the standard AIMD defined by RFC5681.

_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg

--001a114708b279bfd9054aa4dcf8-- From nobody Tue Mar 14 01:03:57 2017 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 44C1E1294A6; Tue, 14 Mar 2017 01:03:50 -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, RP_MATCHES_RCVD=-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 Kqdomc6c5eXO; Tue, 14 Mar 2017 01:03:46 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 418AE126B6D; Tue, 14 Mar 2017 01:03:45 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cnhQl-0000de-PV; Tue, 14 Mar 2017 09:03:43 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx01.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cnhQk-0008IJ-U8; Tue, 14 Mar 2017 09:03:43 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Tue, 14 Mar 2017 09:03:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <679D39B6-F435-4C3B-8F55-53B51F34F255@ifi.uio.no> References: To: Yuchung Cheng X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 52658 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.010, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F859B5F277A131A861E1263C4B35773A52817998 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12575 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org Extensions" , iccrg@irtf.org Subject: Re: [tcpm] [iccrg] Clarification on NewReno vs Reno 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, 14 Mar 2017 08:03:50 -0000 Hi Yuchung, I'm completely with you - I noticed the same mis-use and found it = annoying. However, I have meanwhile given in and also use "NewReno" in = papers. There are two reasons: 1) I once had a reviewer point out that we worked with the old Reno = instead of NewReno, because I used the name "Reno" in a paper. I know = that's a horrible reason, but pragmatically I don't want to risk paper = failure because of a reviewer who makes that mistake. Of course I wouldn't write truly wrong things into a paper on that = basis, but saying "NewReno" instead of "Reno" strikes me as harmless... = misleading, indeed, and somewhat annoying, but what can we do when = people don't get it. Blame the name! It should have been "TCP with = partial ACK support", or something like that. 2) When I write something like "We did tests on FreeBSD, choosing = newreno congestion control", then that's actually correct because that's = the name given to the default Reno-type CC. in FreeBSD's pluggable = congestion control. The name isn't really wrong either, it really does = implement NewReno, but it's a bit awkward as a naming choice (could have = just as well been "TCP Reno with SACK support and Limited Transmit and = ABC and the following spurious timeout detection / recovery algorithms = and ... and ..." ). Oh well. My suggestion is to accept that Reno is now called NewReno, because Reno = is old and NewReno is new. Cheers, Michael > On 13 Mar 2017, at 23:24, Yuchung Cheng wrote: >=20 > Over the past years, I have seem many people in both academia and > industry citing NewReno as a congestion control which really confuses > me. I would like to attempt to ask a clarification from list. >=20 > AFAIK, NewReno is NOT a congestion control. It is an improvement to > loss recovery in the absence of SACK support, per the abstract in > RFC6582 >=20 > """ ... in the absence of SACK. This document describes a specific > algorithm for responding to partial acknowledgments, referred to as > "NewReno". This response to partial acknowledgments was first > proposed by Janey Hoe. This document obsoletes RFC 3782. >=20 > """ >=20 > In a nutshell, NewReno simply retransmits the next unacked packet when > SND.UNA advances. Using NewReno impacts the congestion control which > can be either Reno, Cubic, etc. But it is not a congestion control by > itself. In Linux NewReno is used only if SACK is not supported which > is rare. >=20 > Reno in contrast is the standard AIMD defined by RFC5681. >=20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From nobody Tue Mar 14 08:57:55 2017 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 95EB5129659 for ; Tue, 14 Mar 2017 08:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcpshy7LdHpj for ; Tue, 14 Mar 2017 08:57:53 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F5412960D for ; Tue, 14 Mar 2017 08:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VjZ4DuUeZX/Ex8oVHF1x2tkYlXl2yidQiPZ0fIJkOco=; b=ijyljAMeqT8ew2AaneytLDHHoHCAGwN1K2pwjuoZrnEww5NZPxxTpKO3ILrdvwISl3MWjzU1xTEJC+ZG6aP72rymefngpBxs28Qy7MM7E+vv+zFo0lH1ffcZweQDJ6dZ06IrR7AJ3AZBbAtJtCrZDwOuaAS2EWbh3STQwfRe5eQ= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0279.namprd21.prod.outlook.com (10.173.193.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Tue, 14 Mar 2017 15:57:51 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0991.002; Tue, 14 Mar 2017 15:57:51 +0000 From: Praveen Balasubramanian To: Michael Welzl , Yuchung Cheng CC: "tcpm@ietf.org Extensions" , "iccrg@irtf.org" Thread-Topic: [tcpm] [iccrg] Clarification on NewReno vs Reno Thread-Index: AQHSnJmOdRXM37adH0KEZIwLSTO3sKGUfdPQ Date: Tue, 14 Mar 2017 15:57:51 +0000 Message-ID: References: <679D39B6-F435-4C3B-8F55-53B51F34F255@ifi.uio.no> In-Reply-To: <679D39B6-F435-4C3B-8F55-53B51F34F255@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ifi.uio.no; dkim=none (message not signed) header.d=none;ifi.uio.no; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::584] x-microsoft-exchange-diagnostics: 1; CY4PR21MB0279; 7:Fv6yI0N3M9cbs36uBBLQVWe6mjJpHTIt1TVITRe9/KqTVywgDaIv7VEwUitVef+bvEx0nohsETQdQJoqj1NkA5o7gTiMEhutQg78DNKqVkX+I2TGGMrcAk3PT4YOiD4IwatVL/AN14F4rXbdkwiL8CMV3C9ntDQdt6a7foL4iqBOsP7E1WztcxtTmxrpxSTEETsmbUSwoxkqsM4pJOpI/F41qc7Fpc1ULj29f0iBjiPNSPmUkDphmsdC1d0CgT2eoJidUMvYbPa7ZEP9bQuqrr45tDLKhaIIj8+JiljKhfx5OE8AGpBj/WHa/iDwBAk1c/CZ3P5rZniX2GNPUG8jDo7w4WRh8uUsEYOd1hG+64s= x-ms-office365-filtering-correlation-id: 1018d853-63c4-4c66-d725-08d46af2deab x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254015)(48565401081); SRVR:CY4PR21MB0279; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:CY4PR21MB0279; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0279; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39860400002)(39840400002)(39450400003)(24454002)(13464003)(377454003)(10290500002)(5005710100001)(10090500001)(55016002)(99286003)(106116001)(25786008)(86612001)(8936002)(86362001)(3280700002)(53546007)(8676002)(81166006)(6116002)(102836003)(122556002)(189998001)(33656002)(4326008)(54356999)(229853002)(2906002)(76176999)(50986999)(2900100001)(305945005)(6436002)(2950100002)(5660300001)(53936002)(38730400002)(74316002)(6506006)(77096006)(3660700001)(7736002)(6306002)(6246003)(7696004)(9686003)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0279; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 15:57:51.4574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0279 Archived-At: Subject: Re: [tcpm] [iccrg] Clarification on NewReno vs Reno X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 15:57:54 -0000 >> When I write something like "We did tests on FreeBSD, choosing newreno c= ongestion control", then that's actually correct because that's the name gi= ven to the default Reno-type CC This is true of Windows as well - code as well as the config surface. -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Michael Welzl Sent: Tuesday, March 14, 2017 1:04 AM To: Yuchung Cheng Cc: tcpm@ietf.org Extensions ; iccrg@irtf.org Subject: Re: [tcpm] [iccrg] Clarification on NewReno vs Reno Hi Yuchung, I'm completely with you - I noticed the same mis-use and found it annoying.= However, I have meanwhile given in and also use "NewReno" in papers. There= are two reasons: 1) I once had a reviewer point out that we worked with the old Reno instead= of NewReno, because I used the name "Reno" in a paper. I know that's a hor= rible reason, but pragmatically I don't want to risk paper failure because = of a reviewer who makes that mistake. Of course I wouldn't write truly wrong things into a paper on that basis, b= ut saying "NewReno" instead of "Reno" strikes me as harmless... misleading,= indeed, and somewhat annoying, but what can we do when people don't get it= . Blame the name! It should have been "TCP with partial ACK support", or so= mething like that. 2) When I write something like "We did tests on FreeBSD, choosing newreno c= ongestion control", then that's actually correct because that's the name gi= ven to the default Reno-type CC. in FreeBSD's pluggable congestion control.= The name isn't really wrong either, it really does implement NewReno, but = it's a bit awkward as a naming choice (could have just as well been "TCP Re= no with SACK support and Limited Transmit and ABC and the following spuriou= s timeout detection / recovery algorithms and ... and ..." ). Oh well. My suggestion is to accept that Reno is now called NewReno, because Reno is= old and NewReno is new. Cheers, Michael > On 13 Mar 2017, at 23:24, Yuchung Cheng wrote: >=20 > Over the past years, I have seem many people in both academia and=20 > industry citing NewReno as a congestion control which really confuses=20 > me. I would like to attempt to ask a clarification from list. >=20 > AFAIK, NewReno is NOT a congestion control. It is an improvement to=20 > loss recovery in the absence of SACK support, per the abstract in > RFC6582 >=20 > """ ... in the absence of SACK. This document describes a specific > algorithm for responding to partial acknowledgments, referred to as > "NewReno". This response to partial acknowledgments was first > proposed by Janey Hoe. This document obsoletes RFC 3782. >=20 > """ >=20 > In a nutshell, NewReno simply retransmits the next unacked packet when=20 > SND.UNA advances. Using NewReno impacts the congestion control which=20 > can be either Reno, Cubic, etc. But it is not a congestion control by=20 > itself. In Linux NewReno is used only if SACK is not supported which=20 > is rare. >=20 > Reno in contrast is the standard AIMD defined by RFC5681. >=20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Mar 14 10:21:31 2017 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 9855B1329CC for ; Tue, 14 Mar 2017 10:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 z6B7ptTb_TUK for ; Tue, 14 Mar 2017 10:21:27 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 A36DD1329D2 for ; Tue, 14 Mar 2017 10:21:27 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id m27so51449165iti.0 for ; Tue, 14 Mar 2017 10:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uUPBdv8Gl6ysNPh1GMb/oA9Bd3TyyISoC7FqesVd2u8=; b=THJUq0+X8B8fQM9bawakQMxvV6n6CG/V4xGSfjkp5ndCBt3nZ+y5STh+rKHS5umnTE sjieB9zZ56mQUTje7yaRnk77mhW5qQBT1E9FcdAiDsh56VmNYzPPqzzuu2C5LQvlzQNh DeQga3TSZjB55wjLUSnzaI7iwP9Mn6rD/URDQQ049qHgxFlrO4IHt024Y5fq0PUXzmfj dggQHrOQhQ+Tnume65HYvkoGhNFn4lbaKEhLaHgMKdX6zIaYerMNYB540xNCOPrCLOti lE2AwbUdkTzb3ZGLVoccWOZBc0qtlbErgHRHb50S95inUz6eA+374GeD0rjejjoZdT9d IDKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uUPBdv8Gl6ysNPh1GMb/oA9Bd3TyyISoC7FqesVd2u8=; b=YPEOCFWT+yDFvzCUO8aCe+KoDMnDx9zc76nBtgsBnyQwpqZvX9sQBY4VeqkutSIPia Cr8Ovv20Y6Gm1mgSjp4kZvWLsx+GmTbAmHEwALkAuvhSk3i+yT7Y3NB1et9UndhNpUS6 VT1y0S3/ugUfGuoJ2VRtGl3CGBn/Mdq98nsQYABU5q9cY4wfYoXiJ40eFLJpb7WL4Adv +IbCy+21nfWM0HqHmmOJzh/kk+YBiEXW4LxrRl1s2yGO4DiZG6ak+TyIqx+DMHA/Vh7J cBUk0O394AIPWig92tj5W1/V1SElW4x8923psymOZbWkVHa/lDpbPLs7mzdC4SCFBFc1 5/xg== X-Gm-Message-State: AFeK/H3spscwLSr5cJVs7mn/hxOTH3wHNdU/XjQamHhzNVmdknx/UlqQydLzQQU4lJH7L4sWM1bn+ytCwnyh/a0m X-Received: by 10.36.73.135 with SMTP id e7mr970431itd.105.1489512086836; Tue, 14 Mar 2017 10:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.133.100 with HTTP; Tue, 14 Mar 2017 10:20:46 -0700 (PDT) In-Reply-To: References: <679D39B6-F435-4C3B-8F55-53B51F34F255@ifi.uio.no> From: Yuchung Cheng Date: Tue, 14 Mar 2017 10:20:46 -0700 Message-ID: To: Praveen Balasubramanian Cc: Michael Welzl , "tcpm@ietf.org Extensions" , "iccrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [iccrg] Clarification on NewReno vs Reno X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 17:21:29 -0000 Thanks for the replies: now I know why people use NewReno it's b/c of implementation misnomer. On Tue, Mar 14, 2017 at 8:57 AM, Praveen Balasubramanian wrote: >>> When I write something like "We did tests on FreeBSD, choosing newreno = congestion control", then that's actually correct because that's the name g= iven to the default Reno-type CC > This is true of Windows as well - code as well as the config surface. > > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Michael Welzl > Sent: Tuesday, March 14, 2017 1:04 AM > To: Yuchung Cheng > Cc: tcpm@ietf.org Extensions ; iccrg@irtf.org > Subject: Re: [tcpm] [iccrg] Clarification on NewReno vs Reno > > Hi Yuchung, > > I'm completely with you - I noticed the same mis-use and found it annoyin= g. However, I have meanwhile given in and also use "NewReno" in papers. The= re are two reasons: > > 1) I once had a reviewer point out that we worked with the old Reno inste= ad of NewReno, because I used the name "Reno" in a paper. I know that's a h= orrible reason, but pragmatically I don't want to risk paper failure becaus= e of a reviewer who makes that mistake. > Of course I wouldn't write truly wrong things into a paper on that basis,= but saying "NewReno" instead of "Reno" strikes me as harmless... misleadin= g, indeed, and somewhat annoying, but what can we do when people don't get = it. Blame the name! It should have been "TCP with partial ACK support", or = something like that. > > 2) When I write something like "We did tests on FreeBSD, choosing newreno= congestion control", then that's actually correct because that's the name = given to the default Reno-type CC. in FreeBSD's pluggable congestion contro= l. The name isn't really wrong either, it really does implement NewReno, bu= t it's a bit awkward as a naming choice (could have just as well been "TCP = Reno with SACK support and Limited Transmit and ABC and the following spuri= ous timeout detection / recovery algorithms and ... and ..." ). Oh well. > > My suggestion is to accept that Reno is now called NewReno, because Reno = is old and NewReno is new. > > Cheers, > Michael > > > >> On 13 Mar 2017, at 23:24, Yuchung Cheng wrote: >> >> Over the past years, I have seem many people in both academia and >> industry citing NewReno as a congestion control which really confuses >> me. I would like to attempt to ask a clarification from list. >> >> AFAIK, NewReno is NOT a congestion control. It is an improvement to >> loss recovery in the absence of SACK support, per the abstract in >> RFC6582 >> >> """ ... in the absence of SACK. This document describes a specific >> algorithm for responding to partial acknowledgments, referred to as >> "NewReno". This response to partial acknowledgments was first >> proposed by Janey Hoe. This document obsoletes RFC 3782. >> >> """ >> >> In a nutshell, NewReno simply retransmits the next unacked packet when >> SND.UNA advances. Using NewReno impacts the congestion control which >> can be either Reno, Cubic, etc. But it is not a congestion control by >> itself. In Linux NewReno is used only if SACK is not supported which >> is rare. >> >> Reno in contrast is the standard AIMD defined by RFC5681. >> >> _______________________________________________ >> iccrg mailing list >> iccrg@irtf.org >> https://www.irtf.org/mailman/listinfo/iccrg > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Mar 14 16:01:13 2017 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 186BA129B8D; Tue, 14 Mar 2017 16:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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=nokia.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 WmYO8s6A1qu2; Tue, 14 Mar 2017 16:01:07 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20121.outbound.protection.outlook.com [40.107.2.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AAB129440; Tue, 14 Mar 2017 16:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=81k3soxzrh5gBEd2YMRIW5WJE+Sj4K/rRF9OcBYANz4=; b=SJarKUOH2vQANGbceshLIo4utdqJj6ySNU0IJknoZSvqZ4UPJXKQUeau6LLPjLZdtatQiICuTHxAqfqE2ccogAYioat081+sRgqq5B42i80g7OLSuupfpew3cTl8qJDBc7wpFQ8FIjoC8Y16Vl4M//wS/zEkqSUlsS6WnwlmWtw= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2548.eurprd07.prod.outlook.com (10.173.92.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 23:01:04 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 23:01:04 +0000 From: "Scharf, Michael (Nokia - DE)" To: Carles Gomez Montenegro CC: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" Thread-Topic: [Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-01.txt] Thread-Index: AQHSM3N8XbK/bgtr5USLkNUwp0et86DPv4NwgMBbiwCABaUBhg== Date: Tue, 14 Mar 2017 23:01:04 +0000 Message-ID: References: <563cd49c505340a559cded05282a3dc6.squirrel@webmail.entel.upc.edu> <655C07320163294895BBADA28372AF5D48B68E11@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <31c0efd99c203beeb3115f5900341326.squirrel@webmail.entel.upc.edu> In-Reply-To: <31c0efd99c203beeb3115f5900341326.squirrel@webmail.entel.upc.edu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [25.160.207.132] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2548; 7:2kBfVvhBpV5tOIqz9j7EjBGpKYDpfsRpwT18TkD3t+ZKiQir4rbWuK1JTFVIGfJbemB7MQnvDYCMbkoj4G/fqFLeYGJoCaig7JYuz18qicWQ3+NKQw2tGlG937RLevAe7tQ+QLGxJEMsuhDGVyHtFIvUl6qtA6DfAz5OOosGIz6DA3zl/21bMaGMLrmHDlX/A9wK8r2hVMIbmtIz1lb7OFsYNXIXpjxm7JFa5ceVdB6nOKlcHAT9aP5dDzyUF9OLBH4UAvJqrbjrGWOZXSx4Jnv/tn1/5pxBOAE1+FIAhg8Ev62Sd2Pgfb4W/U44GbI8jT1KuY+CrhSX0GOEGxzVnA== x-ms-office365-filtering-correlation-id: 3a6e2803-8cb5-4776-9ea0-08d46b2dfddc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM5PR0701MB2548; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:AM5PR0701MB2548; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2548; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39840400002)(39860400002)(39850400002)(86362001)(122556002)(33656002)(2900100001)(9686003)(77096006)(229853002)(54906002)(99286003)(55016002)(6436002)(6506006)(8676002)(25786008)(81166006)(2171002)(38730400002)(110136004)(6246003)(53936002)(15650500001)(3660700001)(3280700002)(4326008)(189998001)(2906002)(230783001)(3846002)(102836003)(6116002)(2950100002)(6916009)(305945005)(8936002)(74316002)(7736002)(5660300001)(66066001)(7696004)(54356999)(76176999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2548; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 23:01:04.1165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2548 Archived-At: Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-01.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Mar 2017 23:01:08 -0000 Hi Carles, Thanks a lot for the update. The version -02 indeed reads better from my po= int of view. Also making this document informational is IMHO appropriate. I still have one comment on Section 4.7. "TCP options": A TCP implementation needs to support options 0, 1 and 2 [RFC793]. A TCP implementation for a constrained device that uses a single-MSS TCP receive or transmit window size may not benefit from supporting the following TCP options: Window scale [RFC1323], TCP Timestamps [RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted [RFC2018]. Other TCP options should not be used, in keeping with the principle of lightweight operation. Other TCP options should not be supported by a constrained device, in keeping with the principle of lightweight implementation and operation. I think the last two sentences are still not perfect even if the RFC 2119 l= anguage is now removed. This sort of statement can easily get outdated, sin= ce there continues to be innovation on TCP extensions and they typically us= e options. I think a more future-proof wording would be something of the fo= rm "At the time of publication, lightweight TCP implementations on constrain= ed devices do not have to use other TCP options." As a side note, the inconsistency regarding the TFO option still exist in t= his wording. And the last two sentences also have quite a bit of repetition= . In addition, it is not clear to me whether the different wording ("use" v= s. "support") in the last two sentences is intentional. For some TCP option= s, it is up to the active opener to decide whether to send the option, and = it could refrain from doing so by default even if the option is actually "s= upported" (i.e., implemented in the stack). This may be a reasonable TCP st= ack configuration in some deployment scenarios, e.g., if window scale is no= t needed for sensor data but would help for firmware updates. Thanks Michael= From nobody Wed Mar 15 04:11:33 2017 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 C596A129B84; Wed, 15 Mar 2017 04:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 0Ddr89tcM8iy; Wed, 15 Mar 2017 04:11:29 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0122.outbound.protection.outlook.com [104.47.1.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF43129B81; Wed, 15 Mar 2017 04:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2DVYLdPSPyZz36EsIlz8EIJN4Y+ZBbhRwfq2IGN0BPM=; b=OcpCJK1paW2ojJVmWFD1j3LZ5r6Pymd+tkGH66NxX1QH0fsmOlzVqyRNbkSkLD3qeX82Ro0TmiqN3pvIxJyf2tuh9QOiVf0qtZ4NtMe55X3GjwhjGUQ4Dq7VY/PoDD2dAGSfU1rMJleW0wLSRx3/bxXLcE5dv+van/F3ZkyhUGA= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 11:11:21 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.0977.010; Wed, 15 Mar 2017 11:11:20 +0000 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Agenda draft Thread-Index: AdKdfNtnnsK28939QvqOx7TUxAH9WQ== Date: Wed, 15 Mar 2017 11:11:20 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.3] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2546; 7:jINR9xXuDuTY2sj1D1SzDYBGymRBs4GmpU+ZJV8FxTsuGrVq54KbvOB4oIrF+wza0P8SBIPy6yyfjvt8V0oymXu5wy1cTlUIj24oEdHhgiiUZIv0bIe3qXFe9T65KtxDpSLlaRTJkSYi0udDHU3ElUpXzvGRzuctTIbHqzcnzYM7aW4pjL+nIuvqt3BN8/1S1WlhPv3JqSMRlRHMpO1+ZCGkvwC4UYy2LYvhWDvCb2GMhIOEkCzuTmin9sUjQIbMuQbH9eoVyfkpQjmu/jIsl4X8glQPBGUBxX1BF3cu6GJCrQM5f7OPDhmjmVWa5bIgCqEJTplcjxRzfMto/igzPg== x-ms-office365-filtering-correlation-id: 5be8ed8d-2174-4bf3-ddd3-08d46b9402a7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM5PR0701MB2546; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM5PR0701MB2546; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2546; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39850400002)(39840400002)(39410400002)(53754006)(54356999)(50986999)(189998001)(53936002)(8936002)(7116003)(2900100001)(5660300001)(558084003)(122556002)(6916009)(7906003)(74316002)(7736002)(2351001)(7696004)(3480700004)(1730700003)(8676002)(221733001)(2906002)(3280700002)(3660700001)(77096006)(38730400002)(66066001)(110136004)(4326008)(450100002)(5630700001)(2501003)(6306002)(55016002)(54896002)(25786008)(6506006)(606005)(99286003)(236005)(9686003)(3846002)(6116002)(790700001)(33656002)(86362001)(102836003)(81166006)(6436002)(5640700003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2546; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25478EBC5655838AADC9EEA093270AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 11:11:20.8779 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2546 Archived-At: Subject: [tcpm] Agenda draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 11:11:32 -0000 --_000_AM5PR0701MB25478EBC5655838AADC9EEA093270AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We have uploaded a first draft agenda to https://datatracker.ietf.org/meeti= ng/98/agenda/tcpm/ It is a draft and not final, so feel free to bash ;-) Michael --_000_AM5PR0701MB25478EBC5655838AADC9EEA093270AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We have uploaded a first draft agenda to https://datatracker.ietf.org/meeting/98/agenda/tcpm/

 

It is a draft and not final, so feel free to bash ;-= )

 

Michael

 

--_000_AM5PR0701MB25478EBC5655838AADC9EEA093270AM5PR0701MB2547_-- From nobody Wed Mar 15 06:17:13 2017 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 559F6131494 for ; Wed, 15 Mar 2017 06:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43TmKzdTodFy for ; Wed, 15 Mar 2017 06:17:09 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82795129C00 for ; Wed, 15 Mar 2017 06:17:09 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id d188so8184798vka.0 for ; Wed, 15 Mar 2017 06:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YSQh6WiCZm3gVxexy5OtZOUxm6LqvWzNtEOfej1N9jc=; b=RyEE04vKApYI6ok+Mqc22EPNSh8xN0bGDn5ev/vRW76UhqaKwg4KlG2QdFU56sfO05 8tC5uGAvOAsrEl0YYSzctKhoGHvpn/UsjF5kpZZ3tRNOwwYqSNNd3oTGO1rIo5nRf8r0 HP8ulRxb0SxvLSnjDvWUdoqunTzhRfzuf8B5eRJX5qGefdayus0R7Ia9WpjaQeuyrFEN i1vIHCypv3273yvZZRhTsGNaxTKCAAHWizYMANBBm7mljL2ezFrQVqSB2+vFIeNA/8mR fAvNX/4ihCSf1w0k16hBKJLplOFZ1S0Ge1ZOs2R/jEo9yF/XvKYZaS5zWJqyJsGYDGO2 2f+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YSQh6WiCZm3gVxexy5OtZOUxm6LqvWzNtEOfej1N9jc=; b=CzO1FCcVeP6iybHFkv1AYQMzmrtAu7GvYtX1Ej4mh+1BHqrsuL3I1Od73Tk92Ious2 VfWDnkpy0pe/Rdqb6nt7V1XLLxa40S5QypsMgJ9XqyJqYUK+1Ag7U3vH61x0UtyG2HJ9 aE/5aUm/PzQsq3oYP0DbNbkvAtlxpXW4oxLtespGvlnE2P8KgGTkJN82DjbX5gtv7hR3 zrlV0l0mUwtHwqqeqcLjwF2CKyAroJ56d7L/kp+WrgZWh1Nykm8TnLwJVAgy8hJaprcK 9brFI9bztx7aEZoXvKN6J7JZdZFSPwMy9NBaCufBaGq13RHrc7JsG+s5/End+oZMhdmC iW4Q== X-Gm-Message-State: AFeK/H10se/oUsM5LRNwMqjIl5nPtDcMQTGM235qVFp6/jwyvRiK/ogJgyDed+YXzgsUXltBSCM2EI5GioG1zg== X-Received: by 10.31.230.198 with SMTP id d189mr1321674vkh.138.1489583828485; Wed, 15 Mar 2017 06:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.69 with HTTP; Wed, 15 Mar 2017 06:17:08 -0700 (PDT) From: Jonathan Looney Date: Wed, 15 Mar 2017 09:17:08 -0400 Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=94eb2c092b64f5cda6054ac4c23c Archived-At: Subject: [tcpm] 64-bit sequence numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 13:17:11 -0000 --94eb2c092b64f5cda6054ac4c23c Content-Type: text/plain; charset=UTF-8 Hi all, At the Seoul meeting, we saw two proposals for making TCP perform better on high-speed networks: increasing the maximum window size to 2**31 bits and increasing the precision of timestamps to the microsecond or nanosecond level. As I said in the meeting at Seoul, the combination of these two proposals led me to believe that we need to begin planning for 64-bit sequence numbers. Given that it takes years to rollout new TCP features (especially something as fundamental as changing sequence numbers), it seems like it is time to begin thinking about how we will do this. I submitted the below I-D with a proposal for 64-bit sequence numbers. I'm sure the proposal isn't perfect. The draft itself highlights some challenges. I asked the chairs to allocate a few minutes in Chicago to discuss this topic. Even if we decide to go in a different direction than this draft, I think it is important that we begin to think about 64-bit sequence numbers. Jonathan ---------- Forwarded message ---------- From: Date: Mon, Mar 13, 2017 at 7:32 PM Subject: New Version Notification for draft-looney-tcpm-64-bit-seqnos-00.txt To: Jonathan Looney A new version of I-D, draft-looney-tcpm-64-bit-seqnos-00.txt has been successfully submitted by Jonathan Looney and posted to the IETF repository. Name: draft-looney-tcpm-64-bit-seqnos Revision: 00 Title: 64-bit Sequence Numbers for TCP Document date: 2017-03-13 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-looney-tcpm-64- bit-seqnos-00.txt Status: https://datatracker.ietf.org/doc/draft-looney-tcpm-64-bit- seqnos/ Htmlized: https://tools.ietf.org/html/draft-looney-tcpm-64-bit- seqnos-00 Abstract: This draft updates RFC 793 to allow the optional use of 64-bit sequence numbers. It also updates other standards to support the extended sequence number space. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --94eb2c092b64f5cda6054ac4c23c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

At the Seoul meeting, we saw tw= o proposals for making TCP perform better on high-speed networks: increasin= g the maximum window size to 2**31 bits and increasing the precision of tim= estamps to the microsecond or nanosecond level. As I said in the meeting at= Seoul, the combination of these two proposals led me to believe that we ne= ed to begin planning for 64-bit sequence numbers.

<= div>Given that it takes years to rollout new TCP features (especially somet= hing as fundamental as changing sequence numbers), it seems like it is time= to begin thinking about how we will do this.

I su= bmitted the below I-D with a proposal for 64-bit sequence numbers. I'm = sure the proposal isn't perfect. The draft itself highlights some chall= enges. I asked the chairs to allocate a few minutes in Chicago to discuss t= his topic. Even if we decide to go in a different direction than this draft= , I think it is important that we begin to think about 64-bit sequence numb= ers.

Jonathan

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Mar 13, 2017 at = 7:32 PM
Subject: New Version Notification for draft-looney-tcpm-64-bit-s= eqnos-00.txt
To: Jonathan Looney <jtl.ietf@gmail.com>



A new version of I-D, draft-looney-tcpm-64-bit-seqnos-00.txt
has been successfully submitted by Jonathan Looney and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-looney-tcpm-64-bit-seqnos
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 64-bit Sequence Numbers for TCP Document date:=C2=A0 2017-03-13
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-looney= -tcpm-64-bit-seqnos-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-looney-tcpm-64-bit-s= eqnos/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-looney-tcpm-64-bit-seqnos-00<= br>

Abstract:
=C2=A0 =C2=A0This draft updates RFC 793 to allow the optional use of 64-bit=
=C2=A0 =C2=A0sequence numbers.=C2=A0 It also updates other standards to sup= port the
=C2=A0 =C2=A0extended sequence number space.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c092b64f5cda6054ac4c23c-- From nobody Wed Mar 15 06:32:03 2017 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 736FE1314AB for ; Wed, 15 Mar 2017 06:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hws1Nnq1Tzo1 for ; Wed, 15 Mar 2017 06:32:01 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69AD61314B4 for ; Wed, 15 Mar 2017 06:32:01 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v2FDW0Ge015135; Wed, 15 Mar 2017 06:32:00 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 394F77260AC4; Wed, 15 Mar 2017 09:32:00 -0400 (EDT) To: Jonathan Looney From: Mark Allman Reply-To: mallman@icir.org cc: tcpm@ietf.org In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Can't Get Enough X-URL-0: https://www.icir.org/mallman-files/Document14093.jpg X-URL-1: https://www.icir.org/mallman-files/Document72673.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 15 Mar 2017 09:32:00 -0400 Message-ID: <4961.1489584720@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] 64-bit sequence numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 13:32:02 -0000 --=-------459435943823349593450 Content-Type: text/plain I haven't read your document (although I'm putting it on my list of things to look at). But, I am going to leave this 11 year old piece of tripe here ... https://www.icir.org/mallman/share/draft-allman-tcpx2-hack-00.txt (At one point I had a student implement this and it isn't all that difficult and can in fact co-exist with current TCP and largely use the same code path for both "versions" of TCP. Alas, it wasn't properly finished and written up / code released / etc.---which is clearly my fault.) allman -- https://www.icir.org/mallman/ @mallman_icsi --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljJQk8ACgkQWyrrWs4yIs79JwCfWZ6zMxYYQoZkmlgEBBhK7F0u jCcAni1KIfoOUts3J2pKI9T4vNQwNo6G =xZcQ -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Mar 15 13:26:20 2017 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 968F513181F for ; Wed, 15 Mar 2017 13:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 IF36DSgJCoAw for ; Wed, 15 Mar 2017 13:26:17 -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 7D785131827 for ; Wed, 15 Mar 2017 13:26:17 -0700 (PDT) Received: from [128.9.184.222] ([128.9.184.222]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2FKPQcA011213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Mar 2017 13:25:27 -0700 (PDT) To: Jonathan Looney , tcpm@ietf.org References: From: Joe Touch Message-ID: Date: Wed, 15 Mar 2017 13:25:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 64-bit sequence numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 20:26:19 -0000 Hi, Jonathan (et al.), A few issues: 1) why do you want to use all 64 bits for the TCP-AO MAC, but only the low 32 bits for the KDF? The latter won't help with backward compatibility, so why do this? FWIW, one mode of TCP-AO ignores options; I don't see how you can say "ignore options" (experimental - RFC6978). This doc probably needs to explain what happens when "ignore options" is set (for NAT traversal), i.e., the sequence number extensions will be ignored completely for TCP-AO in that case, AFAICT. 2) the doc should address how to handle RSTs, esp. if the state goes away. It seems like a connection negotiated with 64-bit sequence numbers can't ever be reset if the connection state is lost (all the RSTs will be treated as out of window 3) there are more things than just TCP-AO that use ISNs as input; it seems like you need a blanket statement on how they're handled. This also then seems to kill automatic fall-back, AFAICT. 4) the doc needs to explain the impact of using this feature on each segment on the TCP option space 5) the doc should probably address the impact of odd middleboxes, e.g., that split or splice segments or change sequence numbers That's just scratching the surface; I fear this is a Gordian knot of issues for which there is no simple sword. Joe From nobody Wed Mar 15 13:31:41 2017 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 5D27613182C for ; Wed, 15 Mar 2017 13:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBDs7nH307Q0 for ; Wed, 15 Mar 2017 13:31:37 -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 D34AA13182A for ; Wed, 15 Mar 2017 13:31:37 -0700 (PDT) Received: from [128.9.184.222] ([128.9.184.222]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2FKUuUR012116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Mar 2017 13:30:57 -0700 (PDT) To: mallman@icir.org, Jonathan Looney References: <4961.1489584720@lawyers.icir.org> Cc: tcpm@ietf.org From: Joe Touch Message-ID: Date: Wed, 15 Mar 2017 13:30:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4961.1489584720@lawyers.icir.org> Content-Type: multipart/alternative; boundary="------------56CD12282424689B5B0AAA1B" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 64-bit sequence numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 20:31:39 -0000 This is a multi-part message in MIME format. --------------56CD12282424689B5B0AAA1B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi, Mark (et al.), I was thinking about this too, but as I recall the challenge was legacy fallback. I'm not convinced the proposed approach has safe fallback either, though. Joe On 3/15/2017 6:32 AM, Mark Allman wrote: > I haven't read your document (although I'm putting it on my list of > things to look at). But, I am going to leave this 11 year old piece > of tripe here ... > > https://www.icir.org/mallman/share/draft-allman-tcpx2-hack-00.txt > > (At one point I had a student implement this and it isn't all that > difficult and can in fact co-exist with current TCP and largely use > the same code path for both "versions" of TCP. Alas, it wasn't > properly finished and written up / code released / etc.---which is > clearly my fault.) > > allman > > > -- > https://www.icir.org/mallman/ > @mallman_icsi > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------56CD12282424689B5B0AAA1B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi, Mark (et al.),

I was thinking about this too, but as I recall the challenge was legacy fallback.

I'm not convinced the proposed approach has safe fallback either, though.

Joe


On 3/15/2017 6:32 AM, Mark Allman wrote:
I haven't read your document (although I'm putting it on my list of
things to look at).  But, I am going to leave this 11 year old piece
of tripe here ...

    https://www.icir.org/mallman/share/draft-allman-tcpx2-hack-00.txt

(At one point I had a student implement this and it isn't all that
difficult and can in fact co-exist with current TCP and largely use
the same code path for both "versions" of TCP.  Alas, it wasn't
properly finished and written up / code released / etc.---which is
clearly my fault.)

allman


--
https://www.icir.org/mallman/
@mallman_icsi






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

--------------56CD12282424689B5B0AAA1B-- From nobody Wed Mar 15 19:52:57 2017 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 356BB12FEEB; Wed, 15 Mar 2017 19:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxtYasOEiVj1; Wed, 15 Mar 2017 19:52:53 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0136.outbound.protection.outlook.com [104.47.37.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A099A129C68; Wed, 15 Mar 2017 19:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pvpxm0MMKlbmZHGfd14vFEiJb6tWekoBa/MTrSnxmPE=; b=aRvAl7QcKliPIgfDwCBwpxSz708SwjUbSMVjFc1qPLFm0OfYdUTsNK47DyszVVK/96NegSwqxVflm3D6A2JIpWE54OfZPuhzJWgNch12wWj5ieAFoXrXYL5Cf5AufVWYLH3BnXTr+FMV7KRIG+LxnEqKIA5Dx9sWoFapxolyBfY= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0278.namprd21.prod.outlook.com (10.173.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Thu, 16 Mar 2017 02:52:52 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0991.003; Thu, 16 Mar 2017 02:52:52 +0000 From: Praveen Balasubramanian To: "gorry@erg.abdn.ac.uk" , "tcpm@ietf.org" CC: "draft-ietf-tcpm-dctcp@ietf.org" Thread-Topic: WGLC comments for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSm9+CcGtvXn3gd0aQAvDPuOHIZKGWlixQ Date: Thu, 16 Mar 2017 02:52:52 +0000 Message-ID: References: <58C66BB3.1000003@erg.abdn.ac.uk> In-Reply-To: <58C66BB3.1000003@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: erg.abdn.ac.uk; dkim=none (message not signed) header.d=none;erg.abdn.ac.uk; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:6::584] x-microsoft-exchange-diagnostics: 1; CY4PR21MB0278; 7:3dUcMUPPaL0s2c8EF8Sn/lYIgO2tVxO5ExtUdJhnbMSEVzOx2pCXn/wrh9j7N+ZcDVUHpduEIiV52vGKC1v/jE+Lppa3nIrgKAdqiC0vaqpNo9tNU91WNvHkIXbGMFN7Zx7GhffvW8tbcW0fYsGH6qxMmyux6fCdhXRLoBsiV+0T+umGNcNga6Id4aQLZWsR3hHHyYnxq2s9y3VKpLwu+KrmRn3ji/LCcE2dlwpXPEKOR2jXZQu9WHf8v7fYGGFgNPi87yrILAKQvsV6t7IJBe/69cyaqvIE54G4c1wHVsb5x7laBfcYxpN7suPwsybEPpk1z/uZuMRZd0AruT5MkKEMcFDSNao4ki2y/qAc/Jg= x-ms-office365-filtering-correlation-id: c8e6f54c-bd04-47a8-a3a9-08d46c178a23 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254029)(48565401081); SRVR:CY4PR21MB0278; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:CY4PR21MB0278; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0278; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39410400002)(39850400002)(39450400003)(377454003)(13464003)(122556002)(54356999)(50986999)(76176999)(2900100001)(189998001)(38730400002)(53546007)(6246003)(53936002)(55016002)(86362001)(99286003)(9686003)(6506006)(86612001)(77096006)(6436002)(7696004)(4326008)(25786008)(33656002)(7736002)(10090500001)(3660700001)(8990500004)(8676002)(10290500002)(230783001)(5005710100001)(8936002)(81166006)(2906002)(2950100002)(2501003)(3280700002)(229853002)(74316002)(102836003)(5660300001)(6116002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0278; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 02:52:52.1399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0278 Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 02:52:56 -0000 Inline prefixed by >> -----Original Message----- From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]=20 Sent: Monday, March 13, 2017 2:52 AM To: tcpm@ietf.org Cc: draft-ietf-tcpm-dctcp@ietf.org Subject: WGLC comments for draft-ietf-tcpm-dctcp-04 I think this document looks in good shape. I have two sets of WG comments r= elating to the language used in the current draft: (1) I think the language surrounding loss treatment needs to be still stren= gthened. >> This is fixed in the next update per the other comments in the mailing l= ist. (2) I would like to see the contradition with RFC3168 reworked to avoid thi= s INFO docuemnt attempting to over-ride that PS. >> Sure Best wishes, Gorry --- In section 1: " This protocol is not meant for uncontrolled deployment in the global Inte= rnet. " - To me this statement seems far too opn, and the draft has alreday found a= clearer recommendations that I would agree to, as cited in the abstract: "DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it MUST NOT be deployed over the public Internet without additional measures" - Is it possible to re-use this statement in place of the one quoted above = at the end of the conclusion? >> Fixed --- I'd also really like to see a statement about loss-treatment in the introdu= ction. (see my comemt on section 5, but calling-out from the start that los= s triggers standard TCP congestion control measures is I think a very impor= tant thing to make the reader aware about. Especially when the introduction= (quite correctly) points to the merits of ECN reacting faster than loss-ba= sed methods. >> Fair enough. Added a statement: " DCTCP is a modification to the process= ing of ECN by a conventional TCP and requires that standard TCP congestion = control be used for handling packet loss." --- In section 3: "A DCTCP sender MUST deal with loss episodes in the same way as conventional TCP." - I agree. Could we replace "deal with" perhaps with something like "react = to" >> Yes, replaced. Much better choice of words thanks. --- 3.4. Handling of SYN, SYN-ACK, RST Packets " The switching fabric can drop TCP packets that do not have the ECT set in the IP header. If SYN and SYN-ACK packets for DCTCP connections do not have ECT set, they will be dropped with high probability. For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets." - I'd take the position that the fabric can and will drop any packets under= overload, as per RFC7567. I'd prefer to explicitly state that to avoid a m= isconception that ECT eliminates all drop (rather than nearly all drops). >> Change this to : " If SYN and SYN-ACK packets for DCTCP connections do n= ot have ECT set in the IP header, they will likely be dropped by the switch= ing fabric under load. For DCTCP connections, the sender SHOULD set ECT for= SYN, SYN-ACK and RST packets." --- Section 4: "It is RECOMMENDED that an implementation provide a configuration knob that will cause ECT to be set on such control packes" - please correct typo /packes" >> Fixed - I'm not a fan of an informational document over-riding a PS. I do not thi= nk this is appropriate. - I suggest once way to help, could be to say that "future versions of this protocol provide a configuration knob that will= cause ECT to be set on such control packets [xx]." and then cite "draft-ietf-tsvwg-ecn-experimentation". >> Adding the citation to the "draft-ietf-tsvwg-ecn-experimentation" draft = in the next update. Given that the document clearly limits the scope of dep= loyment, I don't think this is at odds with the PS. Referencing the draft w= ill provide enough context. - The present text is clearly at odds with the RFC series. --- In section 5: The following statement is correct, in as much as SCTP needs to go back los= s-based CC, but I'd prefer personally to see this expressed as "reverts to = loss-based congestion control" - to make this a little more clear, and I'd = much rather it said when it encounters loss, rather than perhaps suggesting= this is only drop-tail: "DCTCP will degrade to loss-based congestion control when transiting a cong= ested drop-tail link." - e.g. something like this: "DCTCP will revert to loss-based congestion control when packet loss is exp= erienced (e.g. when transiting a congested drop-tail link, or a link with a= n AQM drop behaviour). >> Yes the intention is better captured with your suggested text. Fixed. --- In section 6: This statement could be better written: "If the estimation gain is small relative to the packet loss rate, the esti= mate may not be too inaccurate." - First, I think the loss rate noted, may be the loss rate for the return p= ath (i.e., the opposite direction to the packets bing CE-marked?) - Second, may not be too inacurrate sounds odd - do you think the accuracy = is acceptable for normal use? If this relates to ACK loss, the following statement isn't necessarily true= . And especially wculd be far from true for an internet with asymmetric rou= ting: "o If packet loss mostly occurs under heavy congestion, most drops will occur during an unbroken string of CE packets, and the estimate will be unaffected. " >> Yes these considerations are for the case where ACKs are lost reducing t= he accuracy of Alpha. The further sentence says that the impact of such los= s has not been measured so its hard for me to say whether it will be "accep= table for normal use". Also, none of this applies to the internet and AFAIK= routing is symmetric in the datacenter. I propose that we leave this text = as is. From nobody Thu Mar 16 01:26:13 2017 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 DEAC3126D74 for ; Thu, 16 Mar 2017 01:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 9oMsa5uqArAr for ; Thu, 16 Mar 2017 01:26:09 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 74EF41250B8 for ; Thu, 16 Mar 2017 01:26:09 -0700 (PDT) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1coQjX-0004kO-Ax for tcpm@ietf.org; Thu, 16 Mar 2017 09:26:07 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx06.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1coQjW-0006z6-LK; Thu, 16 Mar 2017 09:26:07 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Thu, 16 Mar 2017 09:26:05 +0100 Cc: " Fairhurst" , "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0B589CBD-EE0D-46CD-88EC-9569ABECDED0@ifi.uio.no> References: <58C66BB3.1000003@erg.abdn.ac.uk> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 6 sum msgs/h 3 total rcpts 52763 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.044, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AB1EDB53F94706D5D0755E0A285EC5C46E202FA1 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 12630 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 08:26:12 -0000 Hi, I haven't read the draft since long ago (one of the first versions), but = I just read this dialogue and I have only one comment, so I'm removing = everything else: > --- >=20 > 3.4. Handling of SYN, SYN-ACK, RST Packets >=20 > " The switching fabric can drop TCP packets that do not have the ECT > set in the IP header. If SYN and SYN-ACK packets for DCTCP > connections do not have ECT set, they will be dropped with high > probability. For DCTCP connections, the sender SHOULD set ECT for > SYN, SYN-ACK and RST packets." >=20 > - I'd take the position that the fabric can and will drop any packets = under overload, as per RFC7567. I'd prefer to explicitly state that to = avoid a misconception that ECT eliminates all drop (rather than nearly = all drops). >=20 >=20 >>> Change this to : " If SYN and SYN-ACK packets for DCTCP connections = do not have ECT set in the IP header, they will likely be dropped by the = switching fabric under load. For DCTCP connections, the sender SHOULD = set ECT for SYN, SYN-ACK and RST packets." To me, "will likely be dropped by the switching fabric under load" = doesn't sound quite right - as if they would most probably be dropped = whenever there is any form of load (no matter how much). I would suggest = to change this to "...they are more likely to be dropped by the = switching fabric under load." Cheers, Michael From nobody Thu Mar 16 01:52:59 2017 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 9172A127076; Thu, 16 Mar 2017 01:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 mFH7nAAoiUbe; Thu, 16 Mar 2017 01:52:56 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8052512704B; Thu, 16 Mar 2017 01:52:56 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 9D01F1B017DA; Thu, 16 Mar 2017 10:49:58 +0000 (GMT) Message-ID: <58CA5242.4050802@erg.abdn.ac.uk> Date: Thu, 16 Mar 2017 08:52:18 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Welzl CC: Praveen Balasubramanian , "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" References: <58C66BB3.1000003@erg.abdn.ac.uk> <0B589CBD-EE0D-46CD-88EC-9569ABECDED0@ifi.uio.no> In-Reply-To: <0B589CBD-EE0D-46CD-88EC-9569ABECDED0@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 08:52:57 -0000 On 16/03/2017, 08:26, Michael Welzl wrote: > Hi, > > I haven't read the draft since long ago (one of the first versions), but I just read this dialogue and I have only one comment, so I'm removing everything else: > > >> --- >> >> 3.4. Handling of SYN, SYN-ACK, RST Packets >> >> " The switching fabric can drop TCP packets that do not have the ECT >> set in the IP header. If SYN and SYN-ACK packets for DCTCP >> connections do not have ECT set, they will be dropped with high >> probability. For DCTCP connections, the sender SHOULD set ECT for >> SYN, SYN-ACK and RST packets." >> >> - I'd take the position that the fabric can and will drop any packets under overload, as per RFC7567. I'd prefer to explicitly state that to avoid a misconception that ECT eliminates all drop (rather than nearly all drops). >> >> >>>> Change this to : " If SYN and SYN-ACK packets for DCTCP connections do not have ECT set in the IP header, they will likely be dropped by the switching fabric under load. For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets." > To me, "will likely be dropped by the switching fabric under load" doesn't sound quite right - as if they would most probably be dropped whenever there is any form of load (no matter how much). I would suggest to change this to "...they are more likely to be dropped by the switching fabric under load." > > Cheers, > Michael I agree with Michael, but also I don't see it is correct for transport protocolsto need a very specific network behaviour. The choice of which packets are dropped is a design choice of the AQM: If we were to see FQ-Codel or FQ-PIE (for exmaple) deployed, then a common behaviour would be to separately queue new flows (even if non-ECT) - Switch design can change - I therefore think we should not be assuming a specific switch behaviour, but also I do think the ID does not need to go there .... because I suspect the clause could perhaps be written differently... - I'd suggest to change to: "SYN and SYN-ACK packets for DCTCP connections set the ECT(0) codepoint in the IP header, this ensures they receive the same treatment as other DCTP packets when forwarded by a switching fabric under load. For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets." Gorry From nobody Thu Mar 16 01:58:02 2017 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 146BB12709D; Thu, 16 Mar 2017 01:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 akfaJpo65ja9; Thu, 16 Mar 2017 01:57:59 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 7A88C127076; Thu, 16 Mar 2017 01:57:59 -0700 (PDT) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1coREL-0000fz-Sg; Thu, 16 Mar 2017 09:57:57 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx02.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1coREL-000F3l-0b; Thu, 16 Mar 2017 09:57:57 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <58CA5242.4050802@erg.abdn.ac.uk> Date: Thu, 16 Mar 2017 09:57:56 +0100 Cc: Praveen Balasubramanian , "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <733029B7-2373-446A-8269-309AC421FA43@ifi.uio.no> References: <58C66BB3.1000003@erg.abdn.ac.uk> <0B589CBD-EE0D-46CD-88EC-9569ABECDED0@ifi.uio.no> <58CA5242.4050802@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 18 msgs/h 11 sum rcpts/h 19 sum msgs/h 12 total rcpts 52776 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.010, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 16098758921EEC4830192B66ECFB45869D4EAA93 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 11 total 12639 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 08:58:01 -0000 > On 16 Mar 2017, at 09:52, Gorry Fairhurst = wrote: >=20 > On 16/03/2017, 08:26, Michael Welzl wrote: >> Hi, >>=20 >> I haven't read the draft since long ago (one of the first versions), = but I just read this dialogue and I have only one comment, so I'm = removing everything else: >>=20 >>=20 >>> --- >>>=20 >>> 3.4. Handling of SYN, SYN-ACK, RST Packets >>>=20 >>> " The switching fabric can drop TCP packets that do not have the = ECT >>> set in the IP header. If SYN and SYN-ACK packets for DCTCP >>> connections do not have ECT set, they will be dropped with high >>> probability. For DCTCP connections, the sender SHOULD set ECT = for >>> SYN, SYN-ACK and RST packets." >>>=20 >>> - I'd take the position that the fabric can and will drop any = packets under overload, as per RFC7567. I'd prefer to explicitly state = that to avoid a misconception that ECT eliminates all drop (rather than = nearly all drops). >>>=20 >>>=20 >>>>> Change this to : " If SYN and SYN-ACK packets for DCTCP = connections do not have ECT set in the IP header, they will likely be = dropped by the switching fabric under load. For DCTCP connections, the = sender SHOULD set ECT for SYN, SYN-ACK and RST packets." >> To me, "will likely be dropped by the switching fabric under load" = doesn't sound quite right - as if they would most probably be dropped = whenever there is any form of load (no matter how much). I would suggest = to change this to "...they are more likely to be dropped by the = switching fabric under load." >>=20 >> Cheers, >> Michael > I agree with Michael, but also I don't see it is correct for transport = protocolsto need a very specific network behaviour. The choice of which = packets are dropped is a design choice of the AQM: If we were to see = FQ-Codel or FQ-PIE (for exmaple) deployed, then a common behaviour would = be to separately queue new flows (even if non-ECT) - Switch design can = change - I therefore think we should not be assuming a specific switch = behaviour, but also I do think the ID does not need to go there .... = because I suspect the clause could perhaps be written differently... >=20 > - I'd suggest to change to: > "SYN and SYN-ACK packets for DCTCP connections set the ECT(0) = codepoint in the IP header, this ensures they receive the same treatment = as other DCTP packets when forwarded by a switching fabric under load. = For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and = RST packets." This is just an ACK to say that I agree. Cheers, Michael From nobody Thu Mar 16 02:01:49 2017 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 69111126DD9; Thu, 16 Mar 2017 02:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 V7rGYusXd9sh; Thu, 16 Mar 2017 02:01:47 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2640112709D; Thu, 16 Mar 2017 02:01:47 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 54D151B01809; Thu, 16 Mar 2017 10:59:01 +0000 (GMT) Message-ID: <58CA5461.9010108@erg.abdn.ac.uk> Date: Thu, 16 Mar 2017 09:01:21 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Praveen Balasubramanian CC: "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" References: <58C66BB3.1000003@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 09:01:48 -0000 I wonder if the following could be easily also resolved, see suggestion below. On 16/03/2017, 02:52, Praveen Balasubramanian wrote: > In section 6: > > This statement could be better written: > > "If the estimation gain is small relative to the packet loss rate, the estimate may not be too inaccurate." > > - First, I think the loss rate noted, may be the loss rate for the return path (i.e., the opposite direction to the packets bing CE-marked?) > - Second, may not be too inacurrate sounds odd - do you think the accuracy is acceptable for normal use? > > If this relates to ACK loss, the following statement isn't necessarily true. And especially wculd be far from true for an internet with asymmetric routing: > > "o If packet loss mostly occurs under heavy congestion, most drops > will occur during an unbroken string of CE packets, and the > estimate will be unaffected. > " > >>> >> Yes these considerations are for the case where ACKs are lost reducing the accuracy of Alpha. The further sentence says that the impact of such loss has not been measured so its hard for me to say whether it will be "acceptable for normal use". Also, none of this applies to the internet and AFAIK routing is symmetric in the datacenter. I propose that we leave this text as is. - Is it worth inserting "ACK" in the following, to disambiguate packet loss from ACK loss. "o If ACK packet loss mostly occurs under heavy congestion, most drops will occur during an unbroken string of CE packets, and the estimate will be unaffected. Gorry From nobody Thu Mar 16 11:30:22 2017 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 5C6831297CD; Thu, 16 Mar 2017 11:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.012 X-Spam-Level: X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, 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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR23NrWT4iJj; Thu, 16 Mar 2017 11:30:17 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0135.outbound.protection.outlook.com [104.47.37.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E345A1297E6; Thu, 16 Mar 2017 11:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jK6XtJYyHwKxFX+XnVZsm7k7alpfXNO+B99TDtvWCMU=; b=EPgPFRXpbOdyZh8Tey5rUfB4Lv1ZImI1mef44uv4HKqHqsC92wcI4hu5ISevfTOKx0YZsz4Lad27lQLtKz7M4JEePMQhGbyR1hmZoQh9zIbVNuJp+cC6tZ6BmoTds6iMp1ZIAWHfl7RnZ/mWVKZJDvE5hiQDCrraT+MvV8NQl/0= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0279.namprd21.prod.outlook.com (10.173.193.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Thu, 16 Mar 2017 18:30:15 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0991.007; Thu, 16 Mar 2017 18:30:15 +0000 From: Praveen Balasubramanian To: "gorry@erg.abdn.ac.uk" CC: "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" Thread-Topic: WGLC comments for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSm9+CcGtvXn3gd0aQAvDPuOHIZKGWlixQgACZ14CAAJ5EAA== Date: Thu, 16 Mar 2017 18:30:15 +0000 Message-ID: References: <58C66BB3.1000003@erg.abdn.ac.uk> <58CA5461.9010108@erg.abdn.ac.uk> In-Reply-To: <58CA5461.9010108@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: erg.abdn.ac.uk; dkim=none (message not signed) header.d=none;erg.abdn.ac.uk; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::584] x-microsoft-exchange-diagnostics: 1; CY4PR21MB0279; 7:heeOyxWemsT8EotyljRHJXolH+mUCutwdszb+xCLpxnAXA+ekr5dypHWIh9LE5+b36yRMB3ZRaWSz28w1BW5+vLTr0d6zjCt4xU9rztR1k6CIvxCBOBYv9qIA3Kqa3sD9Vn/RRwilkG+KqxLMQMFNH+vgLHKJ1d7QxrZSbKA4zw0BVKS8gCq4dCvKAwusH9wLZqEOhPipX1aeZOvDLzYlHE2h6Q2Yls4D3DztqVN0q6FgsxkLzRNOY1gqFdm1AnLcucHV2q2Xs1w60DYaXIlzCmlHUtK+kpWG1lMGW5BIxPr6PYrGuWuS2rieWqKFr2/8dFWTyptnjWjqNlB67g6IZAGhSfbfYvZZW/lbrLUwIs= x-ms-office365-filtering-correlation-id: 3f16759e-663b-48d7-2365-08d46c9a7dad x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254036)(48565401081); SRVR:CY4PR21MB0279; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:CY4PR21MB0279; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0279; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(377454003)(13464003)(24454002)(54094003)(2501003)(5660300001)(230783001)(3660700001)(7696004)(3280700002)(2351001)(5005710100001)(10290500002)(50986999)(229853002)(2900100001)(86362001)(77096006)(2906002)(6506006)(10090500001)(6916009)(2950100002)(6436002)(102836003)(6116002)(53936002)(4326008)(33656002)(6246003)(5640700003)(55016002)(99286003)(25786008)(305945005)(54906002)(76176999)(54356999)(9686003)(38730400002)(110136004)(74316002)(53546007)(189998001)(1730700003)(8676002)(8936002)(122556002)(81166006)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0279; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 18:30:15.3172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0279 Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 18:30:19 -0000 It is pretty clear that all the considerations are for ACK packet loss: " However, if one or more ACK packets are dropped, it is possible that a su= bsequent ACK will cumulatively acknowledge a mix of CE and non-CE segments. This will, of course, result in a le= ss accurate congestion estimate. There are some potential considerations:" The fact that CE is being set also implies this is a response packet.=20 "If packet loss mostly occurs under heavy congestion, most drops will occur= during an unbroken string of CE packets, and the estimate will be unaffected." I wasn't sure this needed further qualification but I don't see the harm ad= ding ACK to qualify the packet loss, so fixed. -----Original Message----- From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]=20 Sent: Thursday, March 16, 2017 2:01 AM To: Praveen Balasubramanian Cc: tcpm@ietf.org; draft-ietf-tcpm-dctcp@ietf.org Subject: Re: WGLC comments for draft-ietf-tcpm-dctcp-04 I wonder if the following could be easily also resolved, see suggestion bel= ow. On 16/03/2017, 02:52, Praveen Balasubramanian wrote: > In section 6: > > This statement could be better written: > > "If the estimation gain is small relative to the packet loss rate, the es= timate may not be too inaccurate." > > - First, I think the loss rate noted, may be the loss rate for the=20 > return path (i.e., the opposite direction to the packets bing=20 > CE-marked?) > - Second, may not be too inacurrate sounds odd - do you think the accurac= y is acceptable for normal use? > > If this relates to ACK loss, the following statement isn't necessarily tr= ue. And especially wculd be far from true for an internet with asymmetric r= outing: > > "o If packet loss mostly occurs under heavy congestion, most drops > will occur during an unbroken string of CE packets, and the > estimate will be unaffected. > " > >>> >> Yes these considerations are for the case where ACKs are lost reduc= ing the accuracy of Alpha. The further sentence says that the impact of suc= h loss has not been measured so its hard for me to say whether it will be "= acceptable for normal use". Also, none of this applies to the internet and = AFAIK routing is symmetric in the datacenter. I propose that we leave this = text as is. - Is it worth inserting "ACK" in the following, to disambiguate packet loss= from ACK loss. "o If ACK packet loss mostly occurs under heavy congestion, most drops will occur during an unbroken string of CE packets, and the estimate will be unaffected. Gorry From nobody Thu Mar 16 11:37:16 2017 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 1779F12984B; Thu, 16 Mar 2017 11:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gTH81uAQyn6; Thu, 16 Mar 2017 11:37:13 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0115.outbound.protection.outlook.com [104.47.36.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2ACD1297CB; Thu, 16 Mar 2017 11:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zQ8pR2rRkXm1dR7A9tMXorUrqvjbRkrixR6VONNCDc0=; b=OeMAvt3xp7EXMvRSLZODmECT/BMf5ZHscLLEPBMT+NPaZfBB2LSuWlWVHSx5bCGB1ZllUjsndCFwhUakjZdv79hTzEHNUEQFgmRue2UWrhhexT0WhoImKZdceXFj40zk1t7EHHnHJjukCXfDykjpax1xVi+KiXbAFjrvjBxHWaw= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0280.namprd21.prod.outlook.com (10.173.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Thu, 16 Mar 2017 18:37:11 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0991.007; Thu, 16 Mar 2017 18:37:11 +0000 From: Praveen Balasubramanian To: Michael Welzl , " Fairhurst" CC: "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" Thread-Topic: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSm9+CcGtvXn3gd0aQAvDPuOHIZKGWlixQgACP/YCAAAdTAIAAAZMAgACguvA= Date: Thu, 16 Mar 2017 18:37:11 +0000 Message-ID: References: <58C66BB3.1000003@erg.abdn.ac.uk> <0B589CBD-EE0D-46CD-88EC-9569ABECDED0@ifi.uio.no> <58CA5242.4050802@erg.abdn.ac.uk> <733029B7-2373-446A-8269-309AC421FA43@ifi.uio.no> In-Reply-To: <733029B7-2373-446A-8269-309AC421FA43@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ifi.uio.no; dkim=none (message not signed) header.d=none;ifi.uio.no; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::584] x-microsoft-exchange-diagnostics: 1; CY4PR21MB0280; 7:1Pb/JnudTx1sDfgN0f3PuMkFa7093Eo72fEZXoKVB1JIKmg/waliKMH8SoquQtzZ6Moz3hRtld21s1Rh5AvJMx+V/wFOpCfgUFgIvs7Obe6K1zRwRIuPHRgZoXbViKMs7gFja4HaMQvL3lFtP1+UnZRRhHKfo+x/3h+HNxjuJ9YQ69sJdcPM76zN5SL5FWPuwLAeBzBQZV4xexiog0zqOGCdKVNpVkpYE9lQDYtrTQLsbMYDr2SBnT9ljowUxMVIJNMeLvdrEyqx/CwXyp1Pw4Qv/OXJfZk6rI51C8ZVXdvhppObP09i/en12gIY716Jqp0o6GvIGgVsR4f45UdMVMXqfGHv2HWW4u5z5TqKYEI= x-ms-office365-filtering-correlation-id: b605d672-950d-41f9-39fb-08d46c9b7587 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254036)(48565401081); SRVR:CY4PR21MB0280; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:CY4PR21MB0280; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0280; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(13464003)(24454002)(377454003)(76176999)(53936002)(81166006)(8936002)(25786008)(53546007)(54906002)(93886004)(99286003)(230783001)(55016002)(6436002)(9686003)(189998001)(229853002)(8676002)(6506006)(50986999)(77096006)(4326008)(54356999)(2900100001)(5005710100001)(10290500002)(7696004)(5660300001)(86362001)(3660700001)(6116002)(2906002)(6246003)(2950100002)(10090500001)(74316002)(102836003)(7736002)(38730400002)(305945005)(122556002)(3280700002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0280; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 18:37:11.2498 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0280 Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 18:37:15 -0000 Changed to : " If SYN , SYN-ACK and RST packets for DCTCP connections have = ECT set in the IP header, they will receive the same treatment as other DCT= CP packets when forwarded by a switching fabric under load. Lack of ECT in = these packets may result in a higher drop rate depending on the switching f= abric configuration. Hence for DCTCP connections, the sender SHOULD set ECT= for SYN, SYN-ACK and RST packets." -----Original Message----- From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 Sent: Thursday, March 16, 2017 1:58 AM To: Fairhurst Cc: Praveen Balasubramanian ; tcpm@ietf.org; draft-iet= f-tcpm-dctcp@ietf.org Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 > On 16 Mar 2017, at 09:52, Gorry Fairhurst wrote: >=20 > On 16/03/2017, 08:26, Michael Welzl wrote: >> Hi, >>=20 >> I haven't read the draft since long ago (one of the first versions), but= I just read this dialogue and I have only one comment, so I'm removing eve= rything else: >>=20 >>=20 >>> --- >>>=20 >>> 3.4. Handling of SYN, SYN-ACK, RST Packets >>>=20 >>> " The switching fabric can drop TCP packets that do not have the ECT >>> set in the IP header. If SYN and SYN-ACK packets for DCTCP >>> connections do not have ECT set, they will be dropped with high >>> probability. For DCTCP connections, the sender SHOULD set ECT for >>> SYN, SYN-ACK and RST packets." >>>=20 >>> - I'd take the position that the fabric can and will drop any packets u= nder overload, as per RFC7567. I'd prefer to explicitly state that to avoid= a misconception that ECT eliminates all drop (rather than nearly all drops= ). >>>=20 >>>=20 >>>>> Change this to : " If SYN and SYN-ACK packets for DCTCP connections d= o not have ECT set in the IP header, they will likely be dropped by the swi= tching fabric under load. For DCTCP connections, the sender SHOULD set ECT = for SYN, SYN-ACK and RST packets." >> To me, "will likely be dropped by the switching fabric under load" doesn= 't sound quite right - as if they would most probably be dropped whenever t= here is any form of load (no matter how much). I would suggest to change th= is to "...they are more likely to be dropped by the switching fabric under = load." >>=20 >> Cheers, >> Michael > I agree with Michael, but also I don't see it is correct for transport pr= otocolsto need a very specific network behaviour. The choice of which packe= ts are dropped is a design choice of the AQM: If we were to see FQ-Codel or= FQ-PIE (for exmaple) deployed, then a common behaviour would be to separat= ely queue new flows (even if non-ECT) - Switch design can change - I theref= ore think we should not be assuming a specific switch behaviour, but also I= do think the ID does not need to go there .... because I suspect the clau= se could perhaps be written differently... >=20 > - I'd suggest to change to: > "SYN and SYN-ACK packets for DCTCP connections set the ECT(0) codepoint i= n the IP header, this ensures they receive the same treatment as other DCTP= packets when forwarded by a switching fabric under load. For DCTCP connect= ions, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets." This is just an ACK to say that I agree. Cheers, Michael From nobody Thu Mar 16 11:45:43 2017 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 EC4DA1298CC; Thu, 16 Mar 2017 11:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARS8_T6ujT82; Thu, 16 Mar 2017 11:45:38 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0110.outbound.protection.outlook.com [104.47.42.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A32E12975C; Thu, 16 Mar 2017 11:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qAMZBwZ2QtKg0oSwX0YfKX8aOitvKVj7TJ8clAoMk2Q=; b=ixh8OjhV3jbbgtCFQaI2rvdJo+PdvbKaJDczrIuDqnzSwX8OEc7q15uwtRUJOfGnQvJ4j+8Vyn0/30I3K6Zz/+h5plmz+h/w0OpqP/AG2NPHwm/XMaHjGNsD3kUl6dZWL6OoaZ6sM7pD5OTDozLSP9XwKrshv5sg0qf14m7b7D0= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Thu, 16 Mar 2017 18:45:37 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.01.0991.007; Thu, 16 Mar 2017 18:45:37 +0000 From: Praveen Balasubramanian To: Praveen Balasubramanian , Michael Welzl , " Fairhurst" CC: "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" Thread-Topic: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 Thread-Index: AQHSm9+CcGtvXn3gd0aQAvDPuOHIZKGWlixQgACP/YCAAAdTAIAAAZMAgACguvCAAAKBQA== Date: Thu, 16 Mar 2017 18:45:37 +0000 Message-ID: References: <58C66BB3.1000003@erg.abdn.ac.uk> <0B589CBD-EE0D-46CD-88EC-9569ABECDED0@ifi.uio.no> <58CA5242.4050802@erg.abdn.ac.uk> <733029B7-2373-446A-8269-309AC421FA43@ifi.uio.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::584] x-microsoft-exchange-diagnostics: 1; CY4PR21MB0277; 7:CaqNbl6KJPvYDg+T/bqkIiFmBqxzB10+XJhSfPoZ9W1kmoxMwsvPoUPMAGW0VYji70zRlM7nkxe9Il+SjzG4BkefbsDysK0zNvD+LuZ7AG1/ju10/U5F0PummSZGLOfiqSpl5uFIS4KQ5Zh9rHwAu3AgzXwUDE/PEThFqdKNEQvwV6IpEv3piTZtCNKeBmhVuvTotvS40krIN7tnb9qB6bkj/pv6eGHjFKjuvMcU0NyV1PnZgBh98LwRBVuBv7WfKn8vmbMaZQwRJGNvMb7z6qlthoRVdB3laWR9nLEBYublqOrkMHcYj2iCLcYFh03K0gyTx0Vq787rGn+b8wdebzhXy970vtj4bqko6N9xtYw= x-ms-office365-filtering-correlation-id: 9c68a322-f5a1-4419-70c4-08d46c9ca321 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254036)(48565401081); SRVR:CY4PR21MB0277; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR21MB0277; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0277; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39450400003)(24454002)(13464003)(69224002)(377454003)(33656002)(3660700001)(189998001)(50986999)(230783001)(6246003)(38730400002)(5005710100001)(10290500002)(4326008)(74316002)(102836003)(6116002)(10090500001)(122556002)(8936002)(2906002)(81166006)(305945005)(8676002)(7736002)(2900100001)(6436002)(229853002)(25786008)(99286003)(55016002)(93886004)(54356999)(76176999)(86362001)(9686003)(54906002)(53936002)(3280700002)(53546007)(5660300001)(1511001)(77096006)(6506006)(2950100002)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0277; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 18:45:37.1156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0277 Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 18:45:41 -0000 We are way past the deadline for WGLC which was March 3rd :). Since the com= ments can be never ending and I have limited time, henceforth I will only f= ix feedback that is critical in nature - i.e. something blatantly wrong or = very unclear language. Thanks for all the feedback so far, I think the docu= ment is in great shape now. You can expect to see the 05 revision being pos= ted soon.=20 -----Original Message----- From: Praveen Balasubramanian [mailto:pravb@microsoft.com]=20 Sent: Thursday, March 16, 2017 11:37 AM To: Michael Welzl ; Fairhurst Cc: tcpm@ietf.org; draft-ietf-tcpm-dctcp@ietf.org Subject: RE: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 Changed to : " If SYN , SYN-ACK and RST packets for DCTCP connections have = ECT set in the IP header, they will receive the same treatment as other DCT= CP packets when forwarded by a switching fabric under load. Lack of ECT in = these packets may result in a higher drop rate depending on the switching f= abric configuration. Hence for DCTCP connections, the sender SHOULD set ECT= for SYN, SYN-ACK and RST packets." -----Original Message----- From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 Sent: Thursday, March 16, 2017 1:58 AM To: Fairhurst Cc: Praveen Balasubramanian ; tcpm@ietf.org; draft-iet= f-tcpm-dctcp@ietf.org Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 > On 16 Mar 2017, at 09:52, Gorry Fairhurst wrote: >=20 > On 16/03/2017, 08:26, Michael Welzl wrote: >> Hi, >>=20 >> I haven't read the draft since long ago (one of the first versions), but= I just read this dialogue and I have only one comment, so I'm removing eve= rything else: >>=20 >>=20 >>> --- >>>=20 >>> 3.4. Handling of SYN, SYN-ACK, RST Packets >>>=20 >>> " The switching fabric can drop TCP packets that do not have the ECT >>> set in the IP header. If SYN and SYN-ACK packets for DCTCP >>> connections do not have ECT set, they will be dropped with high >>> probability. For DCTCP connections, the sender SHOULD set ECT for >>> SYN, SYN-ACK and RST packets." >>>=20 >>> - I'd take the position that the fabric can and will drop any packets u= nder overload, as per RFC7567. I'd prefer to explicitly state that to avoid= a misconception that ECT eliminates all drop (rather than nearly all drops= ). >>>=20 >>>=20 >>>>> Change this to : " If SYN and SYN-ACK packets for DCTCP connections d= o not have ECT set in the IP header, they will likely be dropped by the swi= tching fabric under load. For DCTCP connections, the sender SHOULD set ECT = for SYN, SYN-ACK and RST packets." >> To me, "will likely be dropped by the switching fabric under load" doesn= 't sound quite right - as if they would most probably be dropped whenever t= here is any form of load (no matter how much). I would suggest to change th= is to "...they are more likely to be dropped by the switching fabric under = load." >>=20 >> Cheers, >> Michael > I agree with Michael, but also I don't see it is correct for transport pr= otocolsto need a very specific network behaviour. The choice of which packe= ts are dropped is a design choice of the AQM: If we were to see FQ-Codel or= FQ-PIE (for exmaple) deployed, then a common behaviour would be to separat= ely queue new flows (even if non-ECT) - Switch design can change - I theref= ore think we should not be assuming a specific switch behaviour, but also I= do think the ID does not need to go there .... because I suspect the clau= se could perhaps be written differently... >=20 > - I'd suggest to change to: > "SYN and SYN-ACK packets for DCTCP connections set the ECT(0) codepoint i= n the IP header, this ensures they receive the same treatment as other DCTP= packets when forwarded by a switching fabric under load. For DCTCP connect= ions, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets." This is just an ACK to say that I agree. Cheers, Michael From nobody Thu Mar 16 12:07:06 2017 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 CC9F0129A0B; Thu, 16 Mar 2017 12:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wP6u2_bsmGWm; Thu, 16 Mar 2017 12:07:01 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C62CC129A08; Thu, 16 Mar 2017 12:07:01 -0700 (PDT) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:5cab:ac90:959:b802]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B38081B016DE; Thu, 16 Mar 2017 21:04:39 +0000 (GMT) Reply-To: gorry@erg.abdn.ac.uk References: <58C66BB3.1000003@erg.abdn.ac.uk> <58CA5461.9010108@erg.abdn.ac.uk> To: Praveen Balasubramanian Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-dctcp@ietf.org" From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <7c765760-b36f-69af-46dc-e53d4a56a699@erg.abdn.ac.uk> Date: Thu, 16 Mar 2017 19:06:59 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 19:07:05 -0000 Thanks, Gorry On 16/03/2017 18:30, Praveen Balasubramanian wrote: > It is pretty clear that all the considerations are for ACK packet loss: > > " However, if one or more ACK packets are dropped, it is possible that a subsequent ACK will cumulatively acknowledge > a mix of CE and non-CE segments. This will, of course, result in a less accurate congestion estimate. There are some potential considerations:" > > The fact that CE is being set also implies this is a response packet. > > "If packet loss mostly occurs under heavy congestion, most drops will occur during an unbroken string of CE packets, > and the estimate will be unaffected." > > I wasn't sure this needed further qualification but I don't see the harm adding ACK to qualify the packet loss, so fixed. > > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Thursday, March 16, 2017 2:01 AM > To: Praveen Balasubramanian > Cc: tcpm@ietf.org; draft-ietf-tcpm-dctcp@ietf.org > Subject: Re: WGLC comments for draft-ietf-tcpm-dctcp-04 > > I wonder if the following could be easily also resolved, see suggestion below. > > On 16/03/2017, 02:52, Praveen Balasubramanian wrote: >> In section 6: >> >> This statement could be better written: >> >> "If the estimation gain is small relative to the packet loss rate, the estimate may not be too inaccurate." >> >> - First, I think the loss rate noted, may be the loss rate for the >> return path (i.e., the opposite direction to the packets bing >> CE-marked?) >> - Second, may not be too inacurrate sounds odd - do you think the accuracy is acceptable for normal use? >> >> If this relates to ACK loss, the following statement isn't necessarily true. And especially wculd be far from true for an internet with asymmetric routing: >> >> "o If packet loss mostly occurs under heavy congestion, most drops >> will occur during an unbroken string of CE packets, and the >> estimate will be unaffected. >> " >> >>>>>> Yes these considerations are for the case where ACKs are lost reducing the accuracy of Alpha. The further sentence says that the impact of such loss has not been measured so its hard for me to say whether it will be "acceptable for normal use". Also, none of this applies to the internet and AFAIK routing is symmetric in the datacenter. I propose that we leave this text as is. > - Is it worth inserting "ACK" in the following, to disambiguate packet loss from ACK loss. > > "o If ACK packet loss mostly occurs under heavy congestion, most drops > will occur during an unbroken string of CE packets, and the > estimate will be unaffected. > > Gorry > From nobody Mon Mar 20 11:12:37 2017 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 694F81315BA for ; Mon, 20 Mar 2017 11:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9pYkgRO_qcF for ; Mon, 20 Mar 2017 11:12:31 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 5E67C13158E for ; Mon, 20 Mar 2017 11:12:31 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 72so80589793uaf.3 for ; Mon, 20 Mar 2017 11:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=prN4ANU+CjsTjhZNskTWb0+GGbBobtGMiKwWfqYb3e4=; b=Gp24+P8cR/QFVLkISTo1HZJ8FKwyuSPcabvG/uxnR+6hgL2gg37NKNaCDEW1aSDxz4 ltzGHWSL59uclXkE9uqH7g7JRF3WhqHzO2pl+8DdIOAy0KGxj7jkQYuLVN/ucqfBCsuv YE/RCwzljZksTCuUpyotsj8EWqTZ+7VKyXqgFpmhq0WYAWvJDVcB76odd+9+J2P5xAIq N/wyTLPDe2GoqRA4vqduiE6K7CmF+hNmeVFDPHtM7Z+ar1cENUriqOrlVl4Qiegluuod RtnSnNDxAQZ1DsLpd4Q3ClYb1hvCl2+BA8Btgso1evRIasBmOd7yiq1xoeluhVm3kJDT ILBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=prN4ANU+CjsTjhZNskTWb0+GGbBobtGMiKwWfqYb3e4=; b=qQio9BMPyC5lOVAlWhiOOZ0m4gYE8hqttRg/t7LoiC7FiPHwOnZO8JeaGoF/+NtQUu VOcc6pptISjqSXOXPoXJspV5HQDf/ahcSSPDYEgN/0CwmxUbnEUae+RJKPwBTqogDHeP 5mF9xq8x4AYB74kAlKXMrJZ8sAnXsgLo4smbXLbh1e7DNhKYC+lCbFIqxHB4ArhRgR44 L1z3IpLjm9QygCoiQXXeuBl5QUqd/ew/glfg9AXIfHoT6G3ff7ATJZLa5eScsncNFR5L LXbQ0DVyzoKS3Dh16mS3YCtSQUGjFUy6BXzg2cm0XikurL5eDV9RyhBnCfl9fU+1J5W1 b2zQ== X-Gm-Message-State: AFeK/H14XATp4iMucUpNaJoRQTGQpSim6EDUTI5+S5xams7J7LvfJN39DDs01OHTTxTBeDP5Y0yOhEWvR01plQ== X-Received: by 10.159.33.144 with SMTP id 16mr4979549uac.28.1490033550398; Mon, 20 Mar 2017 11:12:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.69 with HTTP; Mon, 20 Mar 2017 11:12:30 -0700 (PDT) In-Reply-To: References: From: Jonathan Looney Date: Mon, 20 Mar 2017 14:12:30 -0400 Message-ID: To: Joe Touch Cc: tcpm@ietf.org Content-Type: multipart/alternative; boundary=001a113e8788799bc4054b2d78bf Archived-At: Subject: Re: [tcpm] 64-bit sequence numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 18:12:36 -0000 --001a113e8788799bc4054b2d78bf Content-Type: text/plain; charset=UTF-8 Dear Joe, Thanks for taking the time to provide feedback! On Wed, Mar 15, 2017 at 4:25 PM, Joe Touch wrote: > Hi, Jonathan (et al.), > > A few issues: > > 1) why do you want to use all 64 bits for the TCP-AO MAC, but only the > low 32 bits for the KDF? The latter won't help with backward > compatibility, so why do this? FWIW, one mode of TCP-AO ignores options; > I don't see how you can say "ignore options" (experimental - RFC6978). > This doc probably needs to explain what happens when "ignore options" is > set (for NAT traversal), i.e., the sequence number extensions will be > ignored completely for TCP-AO in that case, AFAICT. > Because the KDFs are expected to take 32-bit sequence numbers, it seemed to make sense to only use 32-bit sequence numbers as input to these functions. If there is a desire to take 64-bit sequence numbers as input to the KDFs, we could certainly specify this; however, I believe this would require modifying the specifications for KDFs, and I wanted to avoid going farther than necessary in this draft. The MAC only takes 64-bit sequence numbers once we are reasonably sure that the session supports 64-bit sequence numbers. Because the MAC already used a 64-bit sequence number, there were not the same concerns with MACs as the KDF. I don't see an automatic conflict between ignoring TCP options while constructing the MAC on the one hand, and using 64-bit sequence numbers in the MAC on the other hand. Can you explain why you think this is a conflict? > 2) the doc should address how to handle RSTs, esp. if the state goes > away. It seems like a connection negotiated with 64-bit sequence numbers > can't ever be reset if the connection state is lost (all the RSTs will > be treated as out of window > I'm not sure I understand this comment. If the host sending the RST understands 64-bit sequence numbers, it can use full 64-bit sequence numbers in the RST. If the host doesn't understand 64-bit sequence numbers, it will use 32-bit sequence numbers and (after the three-way handshake) that RST will be ignored. While that *may* result in ignoring "legitimate" RSTs from middleboxes that don't understand 64-bit sequence numbers, I'm not sure this is a fatal flaw. After all, in today's Internet, it seems better to err on the side of ignoring legitimate RSTs rather than accepting illegitimate RSTs. > 3) there are more things than just TCP-AO that use ISNs as input; it > seems like you need a blanket statement on how they're handled. This > also then seems to kill automatic fall-back, AFAICT. > I'm not sure which features you are referring to. If you can provide specifics, I can try to provide a more specific answer. The general principal is to use 32-bit sequence numbers until you are sure you can successfully negotiate 64-bit sequence numbers. So, if a feature needs to use ISNs in the three-way handshake, it will need to use 32-bit sequence numbers. If a feature uses ISNs after that point, it can use 64-bit sequence numbers. More details may be needed. (e.g. Does a feature switch to using 64-bit sequence numbers as soon as it detects support?) A general rule will need to be conservative (if you need to use ISNs in the three-way handshake, you need to always use 32-bit sequence numbers); however, specific rules can be more tailored to the specific feature. If there are features that would benefit from the use of 64-bit sequence numbers, we should be sure to specify how they can use them. If this is not explained thoroughly enough in the document, I would be happy to modify it to explain the general rule in more detail. (Again, more specific examples will help, since there are limits to how specific you can be in a "general rule".) 4) the doc needs to explain the impact of using this feature on each > segment on the TCP option space > I'm not sure what you mean by this. Can you elaborate? 5) the doc should probably address the impact of odd middleboxes, e.g., > that split or splice segments or change sequence numbers > Fair enough. IMHO, such middleboxes are already broken, since they can't possibly know how to properly modify the TCP options. However, it is a good point that the document should consider this. That's just scratching the surface; I fear this is a Gordian knot of > issues for which there is no simple sword. > It may be that there are challenges to using 64-bit sequence numbers. However, I think it is important to find a way forward on this. Otherwise, I fear we will "soon" (in TCP modification timelines) run into performance limitations. Thanks! Jonathan --001a113e8788799bc4054b2d78bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear= Joe,

= Thanks for taking the time to provide feedback!

On Wed, Mar 15, 2017 at 4:25 PM, = Joe Touch <touch@isi.edu> wrote:
Hi, Jonathan (et al.),

A few issues:

1) why do you want to use all 64 bits for the TCP-AO MAC, but only the
low 32 bits for the KDF? The latter won't help with backward
compatibility, so why do this? FWIW, one mode of TCP-AO ignores options; I don't see how you can say "ignore options" (experimental - = RFC6978).
This doc probably needs to explain what happens when "ignore options&q= uot; is
set (for NAT traversal), i.e., the sequence number extensions will be
ignored completely for TCP-AO in that case, AFAICT.
Because the KDFs are expected to take 32-bit sequence numbers,= it seemed to make sense to only use 32-bit sequence numbers as input to th= ese functions. If there is a desire to take 64-bit sequence numbers as inpu= t to the KDFs, we could certainly specify this; however, I believe this wou= ld require modifying the specifications for KDFs, and I wanted to avoid goi= ng farther than necessary in this draft.

The MAC o= nly takes 64-bit sequence numbers once we are reasonably sure that the sess= ion supports 64-bit sequence numbers. Because the MAC already used a 64-bit= sequence number, there were not the same concerns with MACs as the KDF.

I don't see an automatic conflict between ignori= ng TCP options while constructing the MAC on the one hand, and using 64-bit= sequence numbers in the MAC on the other hand. Can you explain why you thi= nk this is a conflict?

=C2=A0
2) the doc should address how to handle RSTs, esp. if the state goes
away. It seems like a connection negotiated with 64-bit sequence numbers can't ever be reset if the connection state is lost (all the RSTs will<= br> be treated as out of window

I'm not= sure I understand this comment. If the host sending the RST understands 64= -bit sequence numbers, it can use full 64-bit sequence numbers in the RST. = If the host doesn't understand 64-bit sequence numbers, it will use 32-= bit sequence numbers and (after the three-way handshake) that RST will be i= gnored. While that *may* result in ignoring "legitimate" RSTs fro= m middleboxes that don't understand 64-bit sequence numbers, I'm no= t sure this is a fatal flaw. After all, in today's Internet, it seems b= etter to err on the side of ignoring legitimate RSTs rather than accepting = illegitimate RSTs.

=C2=A0
3) there are more things than just TCP-AO that use ISNs as input; it
seems like you need a blanket statement on how they're handled. This also then seems to kill automatic fall-back, AFAICT.
<= br>
I'm not sure which features you are referring to. If you = can provide specifics, I can try to provide a more specific answer.
=C2=A0
The general principal is to use 32-bit sequence numbers= until you are sure you can successfully negotiate 64-bit sequence numbers.= So, if a feature needs to use ISNs in the three-way handshake, it will nee= d to use 32-bit sequence numbers. If a feature uses ISNs after that point, = it can use 64-bit sequence numbers.

More details m= ay be needed. (e.g. Does a feature switch to using 64-bit sequence numbers = as soon as it detects support?) A general rule will need to be conservative= (if you need to use ISNs in the three-way handshake, you need to always us= e 32-bit sequence numbers); however, specific rules can be more tailored to= the specific feature. If there are features that would benefit from the us= e of 64-bit sequence numbers, we should be sure to specify how they can use= them.

If this is not explained thoroughly enough = in the document, I would be happy to modify it to explain the general rule = in more detail. (Again, more specific examples will help, since there are l= imits to how specific you can be in a "general rule".)
=

4) the doc needs to explain the impact of using this feature on each
segment on the TCP option space

I'm= not sure what you mean by this. Can you elaborate?=C2=A0


5) the doc should probably address the impact of odd middleboxes, e.g.,
that split or splice segments or change sequence numbers

Fair enough. IMHO, such middleboxes are already broken, s= ince they can't possibly know how to properly modify the TCP options. H= owever, it is a good point that the document should consider this.
=C2=A0

That's just scratching the surface; I fear this is a Gordian knot of issues for which there is no simple sword.

<= div>It may be that there are challenges to using 64-bit sequence numbers. H= owever, I think it is important to find a way forward on this. Otherwise, I= fear we will "soon" (in TCP modification timelines) run into per= formance limitations.

Thanks!

=
Jonathan=C2=A0
--001a113e8788799bc4054b2d78bf-- From nobody Mon Mar 20 11:31:49 2017 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 DB43D131650 for ; Mon, 20 Mar 2017 11:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 WwoMuUMK2oPB for ; Mon, 20 Mar 2017 11:31:44 -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 1DFB0131647 for ; Mon, 20 Mar 2017 11:31:44 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2KIUcSH018500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Mar 2017 11:30:40 -0700 (PDT) To: Jonathan Looney References: Cc: tcpm@ietf.org From: Joe Touch Message-ID: <4a8cfeac-e453-a70d-716d-dd2a41fb2777@isi.edu> Date: Mon, 20 Mar 2017 11:30:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------72171B8D55E90B5DA483F794" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 64-bit sequence numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 18:31:47 -0000 This is a multi-part message in MIME format. --------------72171B8D55E90B5DA483F794 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable See below... Joe On 3/20/2017 11:12 AM, Jonathan Looney wrote: > Dear Joe, > > Thanks for taking the time to provide feedback! > > On Wed, Mar 15, 2017 at 4:25 PM, Joe Touch > wrote: > > Hi, Jonathan (et al.), > > A few issues: > > 1) why do you want to use all 64 bits for the TCP-AO MAC, but only = the > low 32 bits for the KDF? The latter won't help with backward > compatibility, so why do this? FWIW, one mode of TCP-AO ignores > options; > I don't see how you can say "ignore options" (experimental - RFC697= 8). > This doc probably needs to explain what happens when "ignore > options" is > set (for NAT traversal), i.e., the sequence number extensions will = be > ignored completely for TCP-AO in that case, AFAICT. > > > Because the KDFs are expected to take 32-bit sequence numbers, it > seemed to make sense to only use 32-bit sequence numbers as input to > these functions. If there is a desire to take 64-bit sequence numbers > as input to the KDFs, we could certainly specify this; however, I > believe this would require modifying the specifications for KDFs, and > I wanted to avoid going farther than necessary in this draft. I don't see a rationale for treating the two differently... (see the next note) > The MAC only takes 64-bit sequence numbers once we are reasonably sure > that the session supports 64-bit sequence numbers. Because the MAC > already used a 64-bit sequence number, there were not the same > concerns with MACs as the KDF. The MAC uses an *internal* SNE; you're overriding that by using the extension in the option. That's a change too. > > I don't see an automatic conflict between ignoring TCP options while > constructing the MAC on the one hand, and using 64-bit sequence > numbers in the MAC on the other hand. Can you explain why you think > this is a conflict? I don't think you should be say two conflicting things to the protocol - "ignore options" means ignore them all, not "ignore all except this one".= > =20 > > 2) the doc should address how to handle RSTs, esp. if the state goe= s > away. It seems like a connection negotiated with 64-bit sequence > numbers > can't ever be reset if the connection state is lost (all the RSTs w= ill > be treated as out of window > > > I'm not sure I understand this comment. If the host sending the RST > understands 64-bit sequence numbers, it can use full 64-bit sequence > numbers in the RST. If the host doesn't understand 64-bit sequence > numbers, it will use 32-bit sequence numbers and (after the three-way > handshake) that RST will be ignored. While that *may* result in > ignoring "legitimate" RSTs from middleboxes that don't understand > 64-bit sequence numbers, I'm not sure this is a fatal flaw. It means you can't reset a connection. Remember that TCP state doesn't go away by itself. So you'll accumulate dead connections that will interfere with new ones - and the new one won't reset the old one away either. This can be handled, but requires timeouts to cleanup dead connections, which are not part of the TCP spec. This was discussed in TCP-AO. > After all, in today's Internet, it seems better to err on the side of > ignoring legitimate RSTs rather than accepting illegitimate RSTs. Agreed, but you need to discuss it and find a way to reset connections when state is lost. > 3) there are more things than just TCP-AO that use ISNs as input; it > > seems like you need a blanket statement on how they're handled. Thi= s > also then seems to kill automatic fall-back, AFAICT. > > > I'm not sure which features you are referring to. If you can provide > specifics, I can try to provide a more specific answer. Search the RFCs for ISNs. Some crypto algs use ISNs as a source or "randomness" (incorrectly, of course). There are also RFCs that talk about generating ISNs. A scrub of these will give you a list of what to address. > =20 > The general principal is to use 32-bit sequence numbers until you are > sure you can successfully negotiate 64-bit sequence numbers. So, if a > feature needs to use ISNs in the three-way handshake, it will need to > use 32-bit sequence numbers. If a feature uses ISNs after that point, > it can use 64-bit sequence numbers. If that's true, then TCP-AO MAC cannot use the 64-bit ISNs in MAC calculations until after the handshake completes! Otherwise, you can't fall-back. > > More details may be needed. (e.g. Does a feature switch to using > 64-bit sequence numbers as soon as it detects support?) A general rule > will need to be conservative (if you need to use ISNs in the three-way > handshake, you need to always use 32-bit sequence numbers); however, > specific rules can be more tailored to the specific feature. If there > are features that would benefit from the use of 64-bit sequence > numbers, we should be sure to specify how they can use them. This is a dangerous pit. TCP should have one set of assumptions at the start of a connection, and another after the TWHS completes. Doing changes at any other time is perilous and ill-defined. > If this is not explained thoroughly enough in the document, I would be > happy to modify it to explain the general rule in more detail. (Again, > more specific examples will help, since there are limits to how > specific you can be in a "general rule".) > > > 4) the doc needs to explain the impact of using this feature on eac= h > segment on the TCP option space > > > I'm not sure what you mean by this. Can you elaborate? You're using bytes for this option, and option space is very limited. See the discussion of option space in TCP-AO. > > 5) the doc should probably address the impact of odd middleboxes, > e.g., > that split or splice segments or change sequence numbers > > > Fair enough. IMHO, such middleboxes are already broken, since they > can't possibly know how to properly modify the TCP options. However, > it is a good point that the document should consider this. Right - the issue is whether you give false positives and whether you can detect these and fall back (or should). > =20 > > That's just scratching the surface; I fear this is a Gordian knot o= f > issues for which there is no simple sword. > > > It may be that there are challenges to using 64-bit sequence numbers. > However, I think it is important to find a way forward on this. > Otherwise, I fear we will "soon" (in TCP modification timelines) run > into performance limitations. "Important" doesn't mean "possible". Don't get ahead of that issue, pleas= e. Joe --------------72171B8D55E90B5DA483F794 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

See below...

Joe


On 3/20/2017 11:12 AM, Jonathan Looney wrote:
Dear Joe,

Thanks for taking the time to provide feedback!

On Wed, Mar 15, 2017 at 4:25 PM, Joe Touch <touch@isi.edu> wrote:
Hi, Jonathan (et al.),

A few issues:

1) why do you want to use all 64 bits for the TCP-AO MAC, but only the
low 32 bits for the KDF? The latter won't help with backward
compatibility, so why do this? FWIW, one mode of TCP-AO ignores options;
I don't see how you can say "ignore options" (experimental - RFC6978).
This doc probably needs to explain what happens when "ignore options" is
set (for NAT traversal), i.e., the sequence number extensions will be
ignored completely for TCP-AO in that case, AFAICT.

Because the KDFs are expected to take 32-bit sequence numbers, it seemed to make sense to only use 32-bit sequence numbers as input to these functions. If there is a desire to take 64-bit sequence numbers as input to the KDFs, we could certainly specify this; however, I believe this would require modifying the specifications for KDFs, and I wanted to avoid going farther than necessary in this draft.
I don't see a rationale for treating the two differently... (see the next note)

The MAC only takes 64-bit sequence numbers once we are reasonably sure that the session supports 64-bit sequence numbers. Because the MAC already used a 64-bit sequence number, there were not the same concerns with MACs as the KDF.
The MAC uses an *internal* SNE; you're overriding that by using the extension in the option. That's a change too.


I don't see an automatic conflict between ignoring TCP options while constructing the MAC on the one hand, and using 64-bit sequence numbers in the MAC on the other hand. Can you explain why you think this is a conflict?

I don't think you should be say two conflicting things to the protocol - "ignore options" means ignore them all, not "ignore all except this one".

 
2) the doc should address how to handle RSTs, esp. if the state goes
away. It seems like a connection negotiated with 64-bit sequence numbers
can't ever be reset if the connection state is lost (all the RSTs will
be treated as out of window

I'm not sure I understand this comment. If the host sending the RST understands 64-bit sequence numbers, it can use full 64-bit sequence numbers in the RST. If the host doesn't understand 64-bit sequence numbers, it will use 32-bit sequence numbers and (after the three-way handshake) that RST will be ignored. While that *may* result in ignoring "legitimate" RSTs from middleboxes that don't understand 64-bit sequence numbers, I'm not sure this is a fatal flaw.

It means you can't reset a connection. Remember that TCP state doesn't go away by itself. So you'll accumulate dead connections that will interfere with new ones - and the new one won't reset the old one away either. This can be handled, but requires timeouts to cleanup dead connections, which are not part of the TCP spec. This was discussed in TCP-AO.

After all, in today's Internet, it seems better to err on the side of ignoring legitimate RSTs rather than accepting illegitimate RSTs.

Agreed, but you need to discuss it and find a way to reset connections when state is lost.

 3) there are more things than just TCP-AO that use ISNs as input; it
seems like you need a blanket statement on how they're handled. This
also then seems to kill automatic fall-back, AFAICT.

I'm not sure which features you are referring to. If you can provide specifics, I can try to provide a more specific answer.
Search the RFCs for ISNs. Some crypto algs use ISNs as a source or "randomness" (incorrectly, of course). There are also RFCs that talk about generating ISNs. A scrub of these will give you a list of what to address.

 
The general principal is to use 32-bit sequence numbers until you are sure you can successfully negotiate 64-bit sequence numbers. So, if a feature needs to use ISNs in the three-way handshake, it will need to use 32-bit sequence numbers. If a feature uses ISNs after that point, it can use 64-bit sequence numbers.

If that's true, then TCP-AO MAC cannot use the 64-bit ISNs in MAC calculations until after the handshake completes! Otherwise, you can't fall-back.


More details may be needed. (e.g. Does a feature switch to using 64-bit sequence numbers as soon as it detects support?) A general rule will need to be conservative (if you need to use ISNs in the three-way handshake, you need to always use 32-bit sequence numbers); however, specific rules can be more tailored to the specific feature. If there are features that would benefit from the use of 64-bit sequence numbers, we should be sure to specify how they can use them.

This is a dangerous pit. TCP should have one set of assumptions at the start of a connection, and another after the TWHS completes. Doing changes at any other time is perilous and ill-defined.

If this is not explained thoroughly enough in the document, I would be happy to modify it to explain the general rule in more detail. (Again, more specific examples will help, since there are limits to how specific you can be in a "general rule".)


4) the doc needs to explain the impact of using this feature on each
segment on the TCP option space

I'm not sure what you mean by this. Can you elaborate?

You're using bytes for this option, and option space is very limited. See the discussion of option space in TCP-AO.


5) the doc should probably address the impact of odd middleboxes, e.g.,
that split or splice segments or change sequence numbers

Fair enough. IMHO, such middleboxes are already broken, since they can't possibly know how to properly modify the TCP options. However, it is a good point that the document should consider this.

Right - the issue is whether you give false positives and whether you can detect these and fall back (or should).

 
That's just scratching the surface; I fear this is a Gordian knot of
issues for which there is no simple sword.

It may be that there are challenges to using 64-bit sequence numbers. However, I think it is important to find a way forward on this. Otherwise, I fear we will "soon" (in TCP modification timelines) run into performance limitations.

"Important" doesn't mean "possible". Don't get ahead of that issue, please.

Joe
--------------72171B8D55E90B5DA483F794-- From nobody Tue Mar 21 05:16:21 2017 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 6188B1297F7 for ; Tue, 21 Mar 2017 05:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 2JBzuXZ49QYn for ; Tue, 21 Mar 2017 05:16:17 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA561297F1 for ; Tue, 21 Mar 2017 05:16:17 -0700 (PDT) Received: from [192.168.1.121] (p57BB46B4.dip0.t-ipconnect.de [87.187.70.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id EC092721E280C for ; Tue, 21 Mar 2017 13:16:14 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Tue, 21 Mar 2017 13:16:13 +0100 To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [tcpm] Comments draft-touch-tcpm-2140bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 12:16:19 -0000 Dear all, I just read the document and have two comments: 1. In section 2 the usage of ">>" is specified but ">>" is never used. I = guess the paragraph can be removed. 2. It is stated two times: Additionally, TCB interdependence can be applied to any protocol with congestion state, including SCTP [RFC4960] and DCCP [RFC434], as well as for individual subflows in Multipath TCP [RFC6824]. I think it should be made clear that information can also be shared between protocols. I also don't see why you can only do this between protocols having a congestion control. You might even want to share PMTU, MMS_S, MMS_R, RTT, RTTvar with protocols not providing a congestion control. Best regards Michael, as an individual= From nobody Tue Mar 21 10:30:47 2017 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 47B90129BF9 for ; Tue, 21 Mar 2017 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 DbJ-R0EI0Nfu for ; Tue, 21 Mar 2017 10:30:46 -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 EDA63129B88 for ; Tue, 21 Mar 2017 10:30:45 -0700 (PDT) Received: from [128.9.184.179] ([128.9.184.179]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2LHTx0Q018373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Mar 2017 10:29:59 -0700 (PDT) To: Michael Tuexen , "tcpm@ietf.org Extensions" References: From: Joe Touch Message-ID: <940777dd-2e8b-0600-f439-8473a085e509@isi.edu> Date: Tue, 21 Mar 2017 10:30:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.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] Comments draft-touch-tcpm-2140bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 17:30:47 -0000 Hi, Michael, On 3/21/2017 5:16 AM, Michael Tuexen wrote: > Dear all, > > I just read the document and have two comments: > > 1. In section 2 the usage of ">>" is specified but ">>" is never used. I guess > the paragraph can be removed. We'll wait on that for now. If we go BCP, then this might be useful. > 2. It is stated two times: > Additionally, TCB interdependence can be applied to any protocol > with congestion state, including SCTP [RFC4960] and DCCP [RFC434], > as well as for individual subflows in Multipath TCP [RFC6824]. > I think it should be made clear that information can also be > shared between protocols. I also don't see why you can only do > this between protocols having a congestion control. You might > even want to share PMTU, MMS_S, MMS_R, RTT, RTTvar with protocols > not providing a congestion control. We'll check. This is complicated by policy routing, of course. Also, we need to check which of these values are truly transport, or merely derived from network values already shared. Thanks for the suggestion! Joe From ietf@weinrank.net Tue Mar 21 15:53:04 2017 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 08ED8129A93 for ; Tue, 21 Mar 2017 15:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 y7GcWOkZBe-G for ; Tue, 21 Mar 2017 15:53:02 -0700 (PDT) Received: from mail.xb6.serverdomain.org (mail.xb6.serverdomain.org [89.107.188.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63271293F4 for ; Tue, 21 Mar 2017 15:53:01 -0700 (PDT) Received: from Idefix3.local (unknown [178.251.15.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: xb6251p1) by mail.xb6.serverdomain.org (mail.xb6.serverdomain.org) with ESMTPSA id ADB7FC01A68 for ; Tue, 21 Mar 2017 23:52:59 +0100 (CET) To: "tcpm@ietf.org Extensions" From: Felix Weinrank Message-ID: <38ddb175-86b2-46af-ac56-cd2b9aee5e3a@weinrank.net> Date: Tue, 21 Mar 2017 23:53:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B89A9BC1984E11EC964DBEDD" Content-Language: de-DE Archived-At: Subject: [tcpm] draft-ietf-tcpm-rack-02 - TLP algorithm question X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 22:55:02 -0000 This is a multi-part message in MIME format. --------------B89A9BC1984E11EC964DBEDD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hey all, I have a question regarding the TLP algorithm in draft-ietf-tcpm-rack-02 In 6.2.1. Phase 1: Scheduling a loss probe: > If an SRTT estimate is available: > PTO = 2 * SRTT > Else: > PTO = initial RTO of 1 sec > If FlightSize = 1: > PTO = max(PTO, 1.5 * SRTT + WCDelAckT) > PTO = max(10ms, PTO) > PTO = max(RTO, PTO) The last line "PTO = max(RTO, PTO)" makes no sense to me. It has been changed from "min" to "max" in the 02 version. The explaining paragraph below also hints for "min" > If RTO is smaller than the computed value for PTO, then a probe is scheduled to be sent > at the RTO time. Greetings Felix Weinrank --------------B89A9BC1984E11EC964DBEDD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hey all,

I have a question regarding the TLP algorithm in draft-ietf-tcpm-rack-02
In 6.2.1.  Phase 1: Scheduling a loss probe:

       If an SRTT estimate is available:
           PTO = 2 * SRTT
       Else:
           PTO = initial RTO of 1 sec
       If FlightSize = 1:
           PTO = max(PTO, 1.5 * SRTT + WCDelAckT)
       PTO = max(10ms, PTO)
       PTO = max(RTO, PTO)
The last line "PTO = max(RTO, PTO)" makes no sense to me.
It has been changed from "min" to "max" in the 02 version.

The explaining paragraph below also hints for "min"
If RTO is smaller than the computed value for PTO, then a probe is scheduled to be sent
at the RTO time.

Greetings
Felix Weinrank
--------------B89A9BC1984E11EC964DBEDD-- From nobody Tue Mar 21 16:51:50 2017 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 252DB1300BC for ; Tue, 21 Mar 2017 16:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LjQA2DAHduX0 for ; Tue, 21 Mar 2017 16:51:47 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 3DF72129496 for ; Tue, 21 Mar 2017 16:51:38 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id r203so40014321oib.3 for ; Tue, 21 Mar 2017 16:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1WO/47LMsOizdVCc1KzllO/2trciIojzsKNlZBmYyzc=; b=oVBc3yDSlwsS5azR+MiDW3u1JkD/F706gFSgVUNh4EtqEOPcsEvIFZ3FNLo0Cr6nrL G1lNUceuGaBITCqpn85H/5fCulNcJ10yoQbxrqmqtKcFSR9x8d+d0p8Kq687b7giLitY AouLIqmY6SxST7Ve4QrrDjyCCfeWiR70LBKGmzkGdmtioDSyurjclRtGOS9d3pVGJq0+ aEh0fP0wtt6ZZ2AGIvRWl74n+IIEgGMINlc03YchHjKVNz795XuBwOVX1MLmZ9gY6XV8 t99Ojx7JJYyHVto2z4hu0cP8s4KSucygBqkLhOA25IjQXVGsOY0zDSGHDsGB0+MnOPOH A2vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1WO/47LMsOizdVCc1KzllO/2trciIojzsKNlZBmYyzc=; b=TT6QcnIKafy4aD+JC4UmYB4jebzXlPmjedR6yY4GugFd8qTbShaOAlpkVRSjKuNUYG GDvLuES3jpVe/tonoUuJN5lOE7/SpU95Pq++/AnT3Rt10XfoVUpHIeDfISFRqP61GD+O 5LBRzbzjFZLocRcU1n0OAOe9INy+gkvtwRd3AeBidA0IsdTJW3ljsVm9/H4auybMzZRx LzhgT/UDoFL21xbirjkvzVJY82pvU2RKbuPSreLeAjqqdjNHfi4Tp1Lfvv1ti4PidNB1 eRRsxI0VYJhgU26wi6Y3/dIfJvWGipGg4FGsZW5lURb5nr5iBpVNhYRYiZ7dT/eB5q0T ph7A== X-Gm-Message-State: AFeK/H3YEyIvAcudLBw9k3eyAjlZl3Z5fU/N7L3IhHiMSrre1Z+auQeN3DL/fPA/HSYf6szo2hPde7ZCuIfoxcb+ X-Received: by 10.202.93.10 with SMTP id r10mr10320184oib.7.1490140297506; Tue, 21 Mar 2017 16:51:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.170.74 with HTTP; Tue, 21 Mar 2017 16:51:07 -0700 (PDT) In-Reply-To: <38ddb175-86b2-46af-ac56-cd2b9aee5e3a@weinrank.net> References: <38ddb175-86b2-46af-ac56-cd2b9aee5e3a@weinrank.net> From: Neal Cardwell Date: Tue, 21 Mar 2017 19:51:07 -0400 Message-ID: To: Felix Weinrank Cc: "tcpm@ietf.org Extensions" , Yuchung Cheng , Nandita Dukkipati Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-rack-02 - TLP algorithm question X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 23:51:49 -0000 On Tue, Mar 21, 2017 at 6:53 PM, Felix Weinrank wrote: > > Hey all, > > I have a question regarding the TLP algorithm in draft-ietf-tcpm-rack-02 > In 6.2.1. Phase 1: Scheduling a loss probe: ... > PTO = max(10ms, PTO) > PTO = max(RTO, PTO) > > The last line "PTO = max(RTO, PTO)" makes no sense to me. > It has been changed from "min" to "max" in the 02 version. Yes, I believe you are right that a bug crept in between draft-ietf-tcpm-rack-01 and draft-ietf-tcpm-rack-02. I have reverted to: PTO = min(RTO, PTO) in our internal copy, so this fix should be reflected in the next version of the RACK Internet Draft. Thanks for catching that! neal From nobody Thu Mar 23 14:23:37 2017 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 CC40E13168C; Thu, 23 Mar 2017 14:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBeBXLUlvXtm; Thu, 23 Mar 2017 14:23:33 -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 3684B129A4A; Thu, 23 Mar 2017 14:23:33 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C99EB29C0E2; Fri, 24 Mar 2017 06:23:31 +0900 (JST) Received: by mail-oi0-f43.google.com with SMTP id f193so13179494oib.2; Thu, 23 Mar 2017 14:23:31 -0700 (PDT) X-Gm-Message-State: AFeK/H1ukxuN1lbfsVAjIyJdOtbvHVfAVG/njG5qnwpb+9xHjpNZGmMLns70foR8GBQlAM1VTh8KNQK34ugUqw== X-Received: by 10.202.91.132 with SMTP id p126mr2730795oib.168.1490304208230; Thu, 23 Mar 2017 14:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.137 with HTTP; Thu, 23 Mar 2017 14:23:27 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Thu, 23 Mar 2017 14:23:27 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Cc: "tcpm-chairs@ietf.org" Content-Type: multipart/alternative; boundary=001a113d4a58f0647d054b6c7c8a Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-cubic-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 23 Mar 2017 21:23:36 -0000 --001a113d4a58f0647d054b6c7c8a Content-Type: text/plain; charset=UTF-8 Hello, The WGLC for this draft has already finished, but we haven't seen many comments on this draft. We are trying to interpret this is an indication that people are satisfied with the current draft, but we just would like to be sure. Please let us know in case you have very last minute comments. We'll do similar final check at the venue. If nothing happens, we will try to proceed the doc after reviewing the updated version. Thanks, -- tcpm co-chairs On Wed, Feb 15, 2017 at 1:13 AM, Yoshifumi Nishida wrote: > Hello, > > In addition to the dctcp draft, TCP chairs conclude that > draft-ietf-tcpm-cubic-04 is ready for WGLC as well and decided to initiate > the call. > > The WGLC for this draft runs until * Friday March 3 *. > Please send your feedback to the ML. > > BTW, the intended status of the draft is Informational. > The draft is available from the following URL. > https://tools.ietf.org/html/draft-ietf-tcpm-cubic-04 > > Thanks, > -- > Yoshi > --001a113d4a58f0647d054b6c7c8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
The WGLC for this dr= aft has already finished, but we haven't seen many comments on this dra= ft.
We are trying to interpret this is an i= ndication that people are satisfied with the current draft, but we just wou= ld like to be sure.=C2=A0
Please let us kno= w in case you have very last minute comments.
We'll do similar final check at the venue. If nothing happens, we wi= ll try to proceed the doc after reviewing the updated version.

Thanks,
<= div class=3D"gmail_extra">--
tcpm co-chairs=

On Wed, Feb= 15, 2017 at 1:13 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp&g= t; wrote:
Hello,<= div>
In addition to the dctcp draft, TCP chairs conclude that= draft-ietf-tcpm-cubic-04 is ready for WGLC as well and decided to initiate= the call.

The WGLC for this draft runs until * Fr= iday March 3 *.=C2=A0
Please send your feedback to the ML.

BTW, the intended status of the draft is Inform= ational.=C2=A0
The draft is available from the following URL.

Thanks,
--
= Yoshi

--001a113d4a58f0647d054b6c7c8a-- From nobody Fri Mar 24 14:59:45 2017 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 472B812894E for ; Fri, 24 Mar 2017 14:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 Gzmra9TtfHgM for ; Fri, 24 Mar 2017 14:59:42 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3863128CB9 for ; Fri, 24 Mar 2017 14:59:41 -0700 (PDT) Received: from [IPv6:2003:cd:6bd7:7400:f4f5:7a06:c266:2974] (p200300CD6BD77400F4F57A06C2662974.dip0.t-ipconnect.de [IPv6:2003:cd:6bd7:7400:f4f5:7a06:c266:2974]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AB60B721E281C; Fri, 24 Mar 2017 22:59:38 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <3A98CB0D-5985-4EBD-8317-4F1E74697535@lurchi.franken.de> Date: Fri, 24 Mar 2017 22:59:37 +0100 Cc: "tcpm@ietf.org Extensions" To: mallman@icir.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [tcpm] Comments for draft-ietf-tcpm-rto-consider-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2017 21:59:44 -0000 Hi Mark, I read the ID with a special focus on SCTP and have three comments: 1. S.3 states: Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that communicate in a unicast fashion with multiple specific endpoints can leverage the requirements in this document provided they track state and follow the requirements for each endpoint independently. SCTP requires this and I think MP-TCP also for its subflows. So it seems strange that you restrict the statement to SCTP implementations fulfilling a requirement which has to be true. 2. S.3 states: I.e., if host A communicates with hosts B and C, A must use independent RTOs for traffic sent to B and C. SCTP association are between two hosts. Each host can have multiple IP-addresses. But you can't have an SCTP association between host A on one side and multiple hosts (B and C) on the other side. I think the same applies to MP-TCP. SO you might want to use a term different from host. 3. S.5 states: E.g., a protocol like SCTP [RFC4960] could leverage the requirements for data that is sent only "partially reliably". It might be useful to add a reference to RFC 3758. Best regards Michael (as an individual) From nobody Fri Mar 24 19:48:18 2017 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 BDE9A12947D for ; Fri, 24 Mar 2017 19:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MW-OTpGvRMtj for ; Fri, 24 Mar 2017 19:48:15 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42B41126C7B for ; Fri, 24 Mar 2017 19:48:15 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v2P2mD56022304; Fri, 24 Mar 2017 19:48:14 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id DA2BE7343E36; Fri, 24 Mar 2017 22:48:13 -0400 (EDT) To: Michael Tuexen From: Mark Allman Reply-To: mallman@icir.org cc: "tcpm\@ietf.org Extensions" In-Reply-To: <3A98CB0D-5985-4EBD-8317-4F1E74697535@lurchi.franken.de> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Panama X-URL-0: https://www.icir.org/mallman-files/Document85749.docx X-URL-1: https://www.icir.org/mallman-files/Document21406.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 24 Mar 2017 22:48:13 -0400 Message-ID: <74855.1490410093@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] Comments for draft-ietf-tcpm-rto-consider-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 25 Mar 2017 02:48:17 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > I read the ID with a special focus on SCTP and have three comments: Many thanks! > 1. S.3 states: > Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that > communicate in a unicast fashion with multiple specific > endpoints can leverage the requirements in this document > provided they track state and follow the requirements for each > endpoint independently. >=20 > SCTP requires this and I think MP-TCP also for its subflows. > So it seems strange that you restrict the statement to > SCTP implementations fulfilling a requirement which has to be true.=20 The statement is meant to be general not really specific to SCTP or MP-TCP. That is, this is not normatively saying something that SCTP already says, somehow. The "such as" was meant to indicate these are just two examples. I can reword this to more explicitly indicate these are exemplars that follow the guidance, but the guidance is general. Make sense? > 2. S.3 states: > I.e., if host A communicates with hosts B and C, A must use > independent RTOs for traffic sent to B and C. >=20=20=20=20 > SCTP association are between two hosts. Each host can have > multiple IP-addresses. But you can't have an SCTP association > between host A on one side and multiple hosts (B and C) on the > other side. I think the same applies to MP-TCP. SO you might want > to use a term different from host. Do you have a favorite word? "Endpoint"? > 3. S.5 states: > E.g., a protocol like SCTP [RFC4960] could leverage the > requirements for data that is sent only "partially reliably". >=20 > It might be useful to add a reference to RFC 3758. Will do. Many thanks! allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljV2msACgkQWyrrWs4yIs7kUQCeL+kIQDVXvJ4nc3tNmay3k1aw 6H4AnjqtmCYGhdn9iEBQBWrqnSDxS388 =zmI0 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Sat Mar 25 05:47:31 2017 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 E175D127010; Sat, 25 Mar 2017 05:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 DmRgna4F38X8; Sat, 25 Mar 2017 05:47:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 1FF0E126D74; Sat, 25 Mar 2017 05:47:21 -0700 (PDT) X-AuditID: c1b4fb2d-275fe70000005be8-dc-58d666d5e8f1 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id CD.2A.23528.5D666D85; Sat, 25 Mar 2017 13:47:20 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 25 Mar 2017 13:47:17 +0100 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=sv/9ggK5km4UWQ9QwufPEPyHwOAPsFxWfP7cHuhEECA=; b=M0hxAv5mw17AzwnHwVW+IZXARm3wTW3yokBvv0JW0CSVVWzaaQig0J2uLi+u/4m8P8Lkki8c/7tUMQZlQH0sz5mlSGL3x+EHjbzAFFJf+86zeRNsgTjcj8DdZECOV/WChTNqjMoVl2yvx63eznFHHEDTWj61g0OXLL+pAq/ua00= 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_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Sat, 25 Mar 2017 12:47:14 +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.0991.018; Sat, 25 Mar 2017 12:47:14 +0000 From: Ingemar Johansson S To: tcpm IETF list , "quic@ietf.org" Thread-Topic: On ACK rate issues and remedies in transport protocols Thread-Index: AdKlZTVrEpGJm/8LQESxP6miBqrqQA== Date: Sat, 25 Mar 2017 12:47:14 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [62.109.35.143] x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:B6LGDQEk7yjk0HftcwyZIVmlnU0ko3/TH/i+8DRH0kLwMzH7rW7Mwt7EDTqGI7CpQjCmP3pVt3IfBfFCoBnsVQtUboB6aUGBN9gNrU2eHm7zwdeX2zf0/78Zf8fFT02DGtRn0ntF9Xw6AMy2KPVb1ObQW6/gq5YGqrG4hR/v9iwqVhZRalTa9t/O1GWwhJzB8r8JmwpzfpdeITBSrzmEJgIg789WBi+Htmc3GQQj7G0azLNnB9bQxTkshrxYDxzLryxV/IhD5Jk3FCaAFw5eQnEXa94C4qq2fbc3yl2iO+RnxygEAe0mIFjg3Owxdj6uAP7EMqOPWT37sY3h280gvQ== x-ms-office365-filtering-correlation-id: a7f81aeb-3eab-4467-a196-08d4737d1060 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39850400002)(39410400002)(8676002)(81166006)(9326002)(8936002)(74316002)(7736002)(33656002)(2501003)(450100002)(5660300001)(86362001)(77096006)(54356999)(50986999)(25786009)(6506006)(38730400002)(9686003)(6116002)(3846002)(102836003)(790700001)(236005)(2906002)(189998001)(54896002)(2900100001)(55016002)(99286003)(19609705001)(122556002)(6306002)(3660700001)(6436002)(3280700002)(53936002)(66066001)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348D65A3427C583F9D91FF0C2310DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2017 12:47:14.7394 (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: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUyM2K7iu6NtGsRBp8fKln0LOC22HZyPpMD k8eSJT+ZAhijuGxSUnMyy1KL9O0SuDKmHgsomGJa0XP9OXMD4wKDLkZODgkBE4md10+zdTFy cQgJrGOU+HJnDjuEc4JR4v2Ke2AZFoFeZonlR2awgrQICUxlkuhoU4eoOsYo0fzsGDtIgk3A RmLloe+MILaIgLPExI+fwWxhAXuJd0/aoeIuEr/3rwCaygFk60lsPSgCYrIIqEpc/u0AUsEr ECWx/cxMsFWMArIS97/fYwGxmQXEJW49mc8EcbWAxJI955khbFGJl4//sYKcwyjQzSjxYd41 qCJFiY6u04wgCQmBbmaJwy1boDp8Jdb+eMECYUdLzL/TChXPlFg+axszTHzKsS42CHsGk8S1 83EQtoxEy4cJzBBDb7JIPH07gwXiSSmJu1c6oR6WkXhxZy8rxNn5Es/a7rJCvCYocXLmE6jF ARLzJy9nn8CoOgvJd7OQtMxC0gIR15O4MXUKG4StLbFs4WtmCFtXYsa/QyzI4gsY2Vcxihan FhfnphsZ66UWZSYXF+fn6eWllmxiBCacg1t+6+5gXP3a8RCjAAejEg/vhyVXI4RYE8uKK3MP MUpwMCuJ8LLPAArxpiRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TB KdXAmFjau3+28GtjzVVbZ91ZJPbUcOHi6P93v9Yv3XDwwYN5OyQ054eKbspoOBjYJrT/ZxPH TovrMyKsWf+auPfcDfHIUb7QN3v1qmee1dcbTef2Nl6QZj1r+2VRudC0aVdumPBLHL9fVZfO 39KytOTQ8Wq53bXqLAo7fytHxZfYPPO7YNndG71ioxJLcUaioRZzUXEiAD2lcJw0AwAA Archived-At: Subject: [tcpm] On ACK rate issues and remedies in transport protocols X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 25 Mar 2017 12:47:24 -0000 --_000_DB4PR07MB348D65A3427C583F9D91FF0C2310DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have asked for a slot at TSVWG for a presentation on issued with transpor= t protocol ACKs. What I am in interested is to know what earlier work such = as RFC5690 exist and also if there are possibilities to reduce the ACK rate= in light of recent additions such as RACK and packet pacing. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB348D65A3427C583F9D91FF0C2310DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

I have asked for a slot at TSVWG for a presentation = on issued with transport protocol ACKs. What I am in interested is to know = what earlier work such as RFC5690 exist and also if there are possibilities= to reduce the ACK rate in light of recent additions such as RACK and packet pacing.

 

/Ingemar

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

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB348D65A3427C583F9D91FF0C2310DB4PR07MB348eurprd_-- From nobody Sat Mar 25 13:25:40 2017 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 874E1127011 for ; Sat, 25 Mar 2017 13:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXihsT0dtBBr for ; Sat, 25 Mar 2017 13:25:36 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF93126D05 for ; Sat, 25 Mar 2017 13:25:35 -0700 (PDT) Received: from [IPv6:2003:cd:6bd7:7400:52d:a70:b965:3ecf] (p200300CD6BD77400052D0A70B9653ECF.dip0.t-ipconnect.de [IPv6:2003:cd:6bd7:7400:52d:a70:b965:3ecf]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 3C17E721E280D; Sat, 25 Mar 2017 21:25:32 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: <74855.1490410093@lawyers.icir.org> Date: Sat, 25 Mar 2017 21:25:31 +0100 Cc: "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: References: <74855.1490410093@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [tcpm] Comments for draft-ietf-tcpm-rto-consider-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 25 Mar 2017 20:25:38 -0000 > On 25 Mar 2017, at 03:48, Mark Allman wrote: >=20 >=20 >> I read the ID with a special focus on SCTP and have three comments: >=20 > Many thanks! >=20 >> 1. S.3 states: >> Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that >> communicate in a unicast fashion with multiple specific >> endpoints can leverage the requirements in this document >> provided they track state and follow the requirements for each >> endpoint independently. >>=20 >> SCTP requires this and I think MP-TCP also for its subflows. >> So it seems strange that you restrict the statement to >> SCTP implementations fulfilling a requirement which has to be true.=20= >=20 > The statement is meant to be general not really specific to SCTP or > MP-TCP. That is, this is not normatively saying something that SCTP > already says, somehow. The "such as" was meant to indicate these > are just two examples. I can reword this to more explicitly > indicate these are exemplars that follow the guidance, but the > guidance is general. Make sense? Yepp. Something like Protocols that communicate in a unicast fashion with multiple specific transport addresses (pairs of an IP address and a port = number) can leverage the requirements in this document provided they track = state and follow the requirements for each transport address independently. Therefore, SCTP [RFC4960] and MP-TCP [RFC6182] can leverage the = requirements in this document. >=20 >> 2. S.3 states: >> I.e., if host A communicates with hosts B and C, A must use >> independent RTOs for traffic sent to B and C. >>=20 >> SCTP association are between two hosts. Each host can have >> multiple IP-addresses. But you can't have an SCTP association >> between host A on one side and multiple hosts (B and C) on the >> other side. I think the same applies to MP-TCP. SO you might want >> to use a term different from host. >=20 > Do you have a favorite word? "Endpoint"? Transport address? Something like I.e., if an endpoint with transport address A communicates with an endpoint having transport addresses B and C, it must use independent RTOs for traffic sent to B and C. >=20 >> 3. S.5 states: >> E.g., a protocol like SCTP [RFC4960] could leverage the >> requirements for data that is sent only "partially reliably". >>=20 >> It might be useful to add a reference to RFC 3758. >=20 > Will do. Great. >=20 > Many thanks! You are welcome! Best regards Michael >=20 > allman >=20 >=20 >=20 From nobody Mon Mar 27 08:58:12 2017 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 DDFEB12945F; Mon, 27 Mar 2017 08:58:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149063028987.30595.1391977269872616582@ietfa.amsl.com> Date: Mon, 27 Mar 2017 08:58:09 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:58:10 -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 : Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters Authors : Stephen Bensley Dave Thaler Praveen Balasubramanian Lars Eggert Glenn Judd Filename : draft-ietf-tcpm-dctcp-05.txt Pages : 15 Date : 2017-03-27 Abstract: This informational memo describes Datacenter TCP (DCTCP), an improvement to TCP congestion control for datacenter traffic. DCTCP uses improved Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow-buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it MUST NOT be deployed over the public Internet without additional measures, as detailed in Section 5. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-05 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-dctcp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-dctcp-05 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 Tue Mar 28 07:11:44 2017 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 A784C129436; Tue, 28 Mar 2017 07:11:43 -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=nokia.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 g6UAMtzTdfIP; Tue, 28 Mar 2017 07:11:42 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00102.outbound.protection.outlook.com [40.107.0.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CE0128656; Tue, 28 Mar 2017 07:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rVtW4FcqvD8KQqAWxzz6s86ywPvmMcd6du9qz9NimnQ=; b=P4arq8UnIVUqcYF+scgmAYe4lokItjs8+fN/Ubk3sHC/CtFoMIaF+WW3QhqbXGzckrSOWWHzGa7BLQK/X5ZrTqiZ6J6YpS0TgL7ZuYOZO7F5OUXrQH0Ku9Zk3bH5j8tuAFo43ezhvmwi6Ire7oKPQBoGIKXlHxeDJ4Mqe4RydHs= Received: from VI1PR0701MB2558.eurprd07.prod.outlook.com (10.173.85.11) by VI1PR0701MB2559.eurprd07.prod.outlook.com (10.173.85.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 14:11:39 +0000 Received: from VI1PR0701MB2558.eurprd07.prod.outlook.com ([10.173.85.11]) by VI1PR0701MB2558.eurprd07.prod.outlook.com ([10.173.85.11]) with mapi id 15.01.1005.009; Tue, 28 Mar 2017 14:11:39 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Notetakers? Thread-Index: AdKnzSE4citqjUZsRo6GAvN85hUb/Q== Date: Tue, 28 Mar 2017 14:11:38 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [31.133.141.145] x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2559; 7:uXyBUmMBlc0WnsOD20AL/MOexOjv1sxXNzsTAV/UdhUIi6Xt2iQQ/FMBoBLgo2AZQZZS9epAJQomcAA0rT5nfesMPAOXKzKjmAAt2IQpOxIBgBpRGKiiucNr9O1GN/j7ZCrbS0U0xFvmlBwiiF5ZhXMnR1qJKYiyyvczWDgYmr0OhIJgeFn/sBT0+hsmuEg8BTxPr375KWoj4DlbO0u8vWlFwVitZ7uj5re0Yqin35o5V4A8U56Pbcqa/eLi39MouWBZPzlsaBha3sugWqcILtrRk4o7WYXnv70S1gZ7ANAlNS07Z4dpi3nZn0UlxBo5IbtI3ADUjp92dRHI0A1r6w== x-ms-office365-filtering-correlation-id: 9e6b70a6-fc48-43c2-5636-08d475e45a27 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423061)(201703031133067); SRVR:VI1PR0701MB2559; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040436)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(201703131423061)(201702281528061)(201703061421061)(201703061406061)(20161123564025)(6072148); SRVR:VI1PR0701MB2559; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2559; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39860400002)(39400400002)(39450400003)(39410400002)(53754006)(99286003)(189998001)(33656002)(790700001)(50986999)(6116002)(3846002)(110136004)(4326008)(7736002)(77096006)(8936002)(53936002)(25786009)(54356999)(38730400002)(3280700002)(7696004)(450100002)(102836003)(55016002)(122556002)(6436002)(5660300001)(7116003)(3660700001)(8676002)(54896002)(558084003)(2351001)(3480700004)(6306002)(66066001)(5630700001)(5640700003)(2906002)(9686003)(2900100001)(6916009)(97736004)(6506006)(86362001)(81166006)(1730700003)(81156014)(2501003)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2559; H:VI1PR0701MB2558.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB2558D641BBFDC1444FC0893B93320VI1PR0701MB2558_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 14:11:38.8951 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2559 Archived-At: Subject: [tcpm] Notetakers? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 14:11:44 -0000 --_000_VI1PR0701MB2558D641BBFDC1444FC0893B93320VI1PR0701MB2558_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Would somebody volunteer to take notes in TCPM tomorrow? It seems that more and more groups rely collaborative note-taking on Etherp= ad - but we only have seldomly used it in TCPM. Are thoughts on moving to E= therpad? Help would be greatly appreciated! Thanks Michael --_000_VI1PR0701MB2558D641BBFDC1444FC0893B93320VI1PR0701MB2558_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Would somebody volunteer to take notes in TCPM tomor= row?

 

It seems that more and more groups rely collaborativ= e note-taking on Etherpad – but we only have seldomly used it in TCPM. Are thoughts on moving to Ethe= rpad?

 

Help would be greatly appreciated!

 

Thanks

 

Michael

--_000_VI1PR0701MB2558D641BBFDC1444FC0893B93320VI1PR0701MB2558_-- From nobody Tue Mar 28 13:22:51 2017 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 62F9C12955E for ; Tue, 28 Mar 2017 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 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_H2=-2.796, 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=nokia.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 Sp-9H94VLN5X for ; Tue, 28 Mar 2017 13:22:48 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50097.outbound.protection.outlook.com [40.107.5.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9FF1293EE for ; Tue, 28 Mar 2017 13:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Iz9ADUiy55v1tK99BpUZi9Tw9BYJvppn+8phIicpVNU=; b=rTrrdxVlqASPm7dSg4y38wK0bfOPEhhWUqPBjhDzPo1fZSEr9ZyHuXk5umqgZfVnheuG3B1kAGIzfXD5Z3ngk7Bz/X2puDd+5IHx9U9+x5kg+dwA2Bdc/ynG888h3soL8WQsCbZJgOy1cJaRcyMGvbsqnkmnoG2cW3eATagHVJw= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2548.eurprd07.prod.outlook.com (10.173.92.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 20:22:45 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1005.009; Tue, 28 Mar 2017 20:22:44 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" Thread-Topic: WGLC completion of DCTCP Thread-Index: AdKoAOpFqxvZRxQhQ2WhqISEktry0A== Date: Tue, 28 Mar 2017 20:22:44 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [31.133.141.145] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2548; 7:Ydt1ch4TWeB13pSvwtpmVtmr3cSP/tR+00hDKvNWTrhPQgT2hI8conui0dozaXHgB31j8lLm+1QCusCoED+E7/bxbm3MgTgSuDilxtlNlq4pYgcgujMKYbufaRBya1skUt2vZ3UgaGZLv7xtC/yrF94GTCNRQHYbEhJsRLiczqA0EeQS9d4pX4e80q6urXIkGtHAW63Etsdomdare0t7HNMFFOlstJvr+8u1Tf2oJf19ghU2HVNOSJalvQPksvHqZHHkDY9suWPBU05XEkPsPK9IjSZ/kVeZGwhNdRMt16c/+7k9aTiCZlLcrGl5jQXvTtju7aHRtEH0nshnWSXkjQ== x-ms-office365-filtering-correlation-id: 767b61af-affd-4a81-73a7-08d476183183 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423065)(201703031133071); SRVR:AM5PR0701MB2548; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040440)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(201703131423065)(201702281528065)(201703061421065)(201703061406065)(6072148); SRVR:AM5PR0701MB2548; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2548; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(377424004)(13464003)(6306002)(66066001)(9686003)(3280700002)(8936002)(74316002)(81166006)(110136004)(1730700003)(6916009)(5640700003)(2501003)(7696004)(38730400002)(86362001)(6116002)(102836003)(3846002)(189998001)(7736002)(8676002)(2906002)(305945005)(55016002)(5660300001)(99286003)(3660700001)(3480700004)(25786009)(53546009)(122556002)(6436002)(2900100001)(53936002)(2351001)(77096006)(54356999)(33656002)(6506006)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2548; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 20:22:44.6812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2548 Archived-At: Subject: [tcpm] WGLC completion of DCTCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 20:22:50 -0000 Folks, Could the contributors who have commented during the WGLC please have a loo= k at -05 and let us know if the comments are sufficiently addressed? Thanks Michael -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Montag, 27. M=E4rz 2017 17:58 To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions of th= e IETF. Title : Datacenter TCP (DCTCP): TCP Congestion Control fo= r Datacenters Authors : Stephen Bensley Dave Thaler Praveen Balasubramanian Lars Eggert Glenn Judd Filename : draft-ietf-tcpm-dctcp-05.txt Pages : 15 Date : 2017-03-27 Abstract: This informational memo describes Datacenter TCP (DCTCP), an improvement to TCP congestion control for datacenter traffic. DCTCP uses improved Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow-buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it MUST NOT be deployed over the public Internet without additional measures, as detailed in Section 5. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-05 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-dctcp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-dctcp-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Mar 28 14:50:55 2017 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 E3C761200A0; Tue, 28 Mar 2017 14:50:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149073784890.1172.13660402558896010585@ietfa.amsl.com> Date: Tue, 28 Mar 2017 14:50:48 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 21:50:49 -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 : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-05.txt Pages : 95 Date : 2017-03-28 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793 and several other RFCs (TODO: list all actual RFCs when finished). RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-05 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-05 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 Tue Mar 28 15:02:03 2017 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 66BDF12968A for ; Tue, 28 Mar 2017 15:02:02 -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 961gBQscPscj for ; Tue, 28 Mar 2017 15:02:00 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33127129684 for ; Tue, 28 Mar 2017 15:02:00 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id y18so30442566itc.1 for ; Tue, 28 Mar 2017 15:02: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=lfZQizboY+wpSnOljJfQFRCoVqcqI+Jzq0Dgitp+39E=; b=nOv0jgU5/7N9BPpWvCsxQB5Yv76cQICWwwezPs/iUXefabO6v40w9qTEgeZpTVfIMu +9xswViRgc1L17e8WCKNo8icOsdp9Lb57yatRpY7c+KDNVjg0iaEASOqrEYPbac9XZI2 Wy3Ti/Z+6Mf49AQ9vj+sGCbUjFyUSKudlfGGDkR7ESjIZwt1YcNw9Ty2GPZw5uH4iv8Q YRWaXPzOfXY3yqEg8nThXh8Br/y99I003T6SLtlVPATb0Gn7t/MF7uOho9szejKbAt6H +3EIBv0jXsAQifyjVAvE/xJ+lcUjGuvZ7Lp/3MjzAU91jyPDKOpCY9S/CTQsT72TsgfL tLzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lfZQizboY+wpSnOljJfQFRCoVqcqI+Jzq0Dgitp+39E=; b=ss3bS2SeODgSSFgsoAoNLTY8Do1gKgrnzpslI7Gx/hThQ/VOFaUd78ivFo9C3Xe5kT 2CFEeqqmEEEoU1qH2+hbDE9SfIr+J2kkNW+aSbwnmPDKbz0ati/tPCe1J+0Szdje1sem 5nbH7hKiDU5psYQTEmChApVfwn06NJaUr6vMV73eIYg/QEqX01DdxmD5Cwf/mPapweVf cXLWBAYRYmUulEGpKN7ZQvU1hZsqgLvNodnxh1SGJLbVd5ummhnbXerB/C33756SLT8L pkmF55kTYN79Q3wpNWZFVMUNBFgMCxE/R575FyAWJexRZ36ZbVE5/BB2JQFxakqPfeB8 Nyzw== X-Gm-Message-State: AFeK/H0nwaq9oKw8BtZw3IVqWktRRM05jJqU0QPb+2BMpbXSifuEl1Mdmxk+XJL5nV58JA== X-Received: by 10.36.33.73 with SMTP id e70mr17260238ita.9.1490738519276; Tue, 28 Mar 2017 15:01:59 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:a4c3:52ae:aaad:fec6? (t2001067c03700128a4c352aeaaadfec6.v6.meeting.ietf.org. [2001:67c:370:128:a4c3:52ae:aaad:fec6]) by smtp.gmail.com with ESMTPSA id r203sm2217753itc.5.2017.03.28.15.01.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 15:01:58 -0700 (PDT) To: tcpm@ietf.org References: <149073784890.1172.13660402558896010585@ietfa.amsl.com> From: Wesley Eddy Message-ID: <17d266a1-2119-ed67-79ec-581294dbde64@mti-systems.com> Date: Tue, 28 Mar 2017 18:01:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149073784890.1172.13660402558896010585@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 22:02:02 -0000 There are some changes in this update that the WG should review. A summary of what to look for is below, but I also recommend scanning the diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-05.txt 1. added CWR and ECE bits from ECN to the header format diagram, and reference to 3168 for definitions 2. instead of RFC1122 requirement MUST implement slowstart + congestion avoidance, added "MUST implement RFC 5681" ---- please review this! 3. added "SHOULD implement ECN" --- please review this! This is outside what 1122 or other documents say, but I think it is the intent of publishing 3168 on standards track and having it update 793. 4. updated 1122 text about source quench to reflect that 6633 deprecated it 5. modified text on ICMP messages to also mention ICMPv6 (not covered by 1122) -- please check this! 6. split 1122 discussion of ICMP handling into soft and hard errors per 5461, and added notes to reference other discussion in 5461 about widespread implementation behavior On 3/28/2017 5:50 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. > > Title : Transmission Control Protocol Specification > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-05.txt > Pages : 95 > Date : 2017-03-28 > > Abstract: > This document specifies the Internet's Transmission Control Protocol > (TCP). TCP is an important transport layer protocol in the Internet > stack, and has continuously evolved over decades of use and growth of > the Internet. Over this time, a number of changes have been made to > TCP as it was specified in RFC 793, though these have only been > documented in a piecemeal fashion. This document collects and brings > those changes together with the protocol specification from RFC 793. > This document obsoletes RFC 793 and several other RFCs (TODO: list > all actual RFCs when finished). > > RFC EDITOR NOTE: If approved for publication as an RFC, this should > be marked additionally as "STD: 7" and replace RFC 793 in that role. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-05 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Mar 28 15:06:48 2017 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 A0AF5129686; Tue, 28 Mar 2017 15:06:46 -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, RP_MATCHES_RCVD=-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 V0mcLXO3PBNa; Tue, 28 Mar 2017 15:06:45 -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 5AB1012967B; Tue, 28 Mar 2017 15:06:45 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2SM6bPT002663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 15:06:37 -0700 (PDT) To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <149073784890.1172.13660402558896010585@ietfa.amsl.com> Cc: tcpm@ietf.org From: Joe Touch Message-ID: Date: Tue, 28 Mar 2017 15:06:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149073784890.1172.13660402558896010585@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v2SM6bPT002663 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 22:06:47 -0000 Some observations: 3.1 currently defined options this either needs to be the complete current list or indicate that the list is elsewhere (the latter seems better to me) if list elsewhere, the discussion should be clear that this doc defines only the following options; others are defined elsewhere is there any notion of the minimum required options? if so, is this that set? (it might be useful to say so) throughout the discussion of PMTU and MSS might benefit from an update as per draft-iett-intarea-tunnels key points: PMTU discovery assumes TCP set IP to prevent both on-path (for IPv4) and source fragmentation (IPv4 and IPv6), otherwise it optimizes source fragment size rather than avoiding source fragmentation MSS is defined in terms of EMTU_R, which is independent of PMTU there are two effective MTUs - EMTU_S and EMTU_R. The former is set and may or may not be limited by PMTU. I can coordinate off-list on both if useful. Joe From nobody Tue Mar 28 15:18:49 2017 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 446E21270B4 for ; Tue, 28 Mar 2017 15:18:48 -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 rOQ4jHBn5ju2 for ; Tue, 28 Mar 2017 15:18:46 -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 0E86A1294E0 for ; Tue, 28 Mar 2017 15:18:44 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id e75so72968802itd.1 for ; Tue, 28 Mar 2017 15:18:44 -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=+hAe4RWat+Irt14ajL4i0jgiFLu6/zRpzDJHUOeDPpU=; b=jqJ5+gCXoGqZQdz88+ZPZ3Ct5IXqLgVx1g6M6XyS1qXdAbCd1dmMOpE1rILa0sPSUY DfdVOZxT/y4yA5ymGQ+aCSyR7ZEP9qegdcnACYSWuRBzxaMmW1Jq2iMWgnm4oqTEsaP6 B8ekhQrsiYpgbRU8yHgKPdfuYKEcUPOzTJTmb0U62M94Tgxb2I67s1p+TSsLM/U1MRdT 6DWSuKw57jTOvcENOBf4yadU4EMSVa4aEnKqNibv84PVOHe1lvzx6uyr6+7avi1z+SaB hwHJwww9m0YfhYvOGEChHGjaq53yC8Afi77NhAFphY8EZWQlKQf1gj7anDXJdDjy04R7 w6Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+hAe4RWat+Irt14ajL4i0jgiFLu6/zRpzDJHUOeDPpU=; b=r8TNefvbc/w2+7M/iJLijzL3UkSak/DzJRqOnozUyWYT9e3KeR6GMrruEMMfCds/tI Zs31Ok1Mjikybx0xY1VyenVEojV2uSTWbBsbQ6tyml3+SLAMiZSEmSdRp7gblVC82sRB qpwzoF976lTVPFtiY8iLDXQ7XEjETvFfXoZHLrl1HbWhubE1VK5iMcOidlVic+ZGVVXG mGF8AQ8qEvifFTW7Mz1lhmyRuqZNdmHyNWb4dOxxTNQBrssklnb0metqI2OyNbk4ugJI +Do/UkPRcNtIP1HfRs1/78TgDFRbCaIwT6Nva4gCY4vWx0m9FlRq0TCYLGVkLTzbUfIP gnNw== X-Gm-Message-State: AFeK/H1YFTM9qCnb4jFo9bl9FQHyjMw2ehWq9579EH3vRCAYuZBstQSmtSjRJDcRRNiOrw== X-Received: by 10.36.31.138 with SMTP id d132mr18657479itd.52.1490739523207; Tue, 28 Mar 2017 15:18:43 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:a4c3:52ae:aaad:fec6? (t2001067c03700128a4c352aeaaadfec6.v6.meeting.ietf.org. [2001:67c:370:128:a4c3:52ae:aaad:fec6]) by smtp.gmail.com with ESMTPSA id m71sm2239278itg.14.2017.03.28.15.18.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 15:18:42 -0700 (PDT) To: tcpm@ietf.org References: <149073784890.1172.13660402558896010585@ietfa.amsl.com> From: Wesley Eddy Message-ID: Date: Tue, 28 Mar 2017 18:18:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 22:18:48 -0000 On 3/28/2017 6:06 PM, Joe Touch wrote: > Some observations: > > 3.1 currently defined options > this either needs to be the complete current list or indicate that > the list is elsewhere (the latter seems better to me) > if list elsewhere, the discussion should be clear that this doc > defines only the following options; others are defined elsewhere > is there any notion of the minimum required options? if so, is this > that set? (it might be useful to say so) I propose that this should be described as the minimum required set, and that we add pointer to the IANA registry of TCP Option Kind Numbers for the complete set: https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml > throughout > the discussion of PMTU and MSS might benefit from an update as per > draft-iett-intarea-tunnels > key points: > PMTU discovery assumes TCP set IP to prevent both on-path (for > IPv4) and source fragmentation (IPv4 and IPv6), otherwise it optimizes > source fragment size rather than avoiding source fragmentation > MSS is defined in terms of EMTU_R, which is independent of PMTU > there are two effective MTUs - EMTU_S and EMTU_R. The former is > set and may or may not be limited by PMTU. If clarity can be improved in 793bis, that sounds good to me. The text currently is patched together from bits of many other RFCs. > I can coordinate off-list on both if useful. I think on-list is preferable to make sure everyone else agrees with us :) From nobody Wed Mar 29 05:42:44 2017 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 813261294FE for ; Wed, 29 Mar 2017 05:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkdFafOAndsX for ; Wed, 29 Mar 2017 05:42:39 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 41EB81296C9 for ; Wed, 29 Mar 2017 05:42:38 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctCvr-0005hK-OP for tcpm@ietf.org; Wed, 29 Mar 2017 14:42:35 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctCvq-0005Nw-LE for tcpm@ietf.org; Wed, 29 Mar 2017 14:42:35 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 29 Mar 2017 07:42:33 -0500 References: <149073784890.1172.13660402558896010585@ietfa.amsl.com> To: tcpm IETF list In-Reply-To: <149073784890.1172.13660402558896010585@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 53350 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.050, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9910B381953B81CAEFC3E90073BB9DCA1B580D3C X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 83 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 12:42:43 -0000 Hi, I have a question / concern that=E2=80=99s different from the things Wes = mentioned about this diff: for both the old and new RFC, if I want to implement a TCP that is able = to send data on the first SYN (not TFO-style, but as allowed by this = spec), how do I make this possible using the API in section 3.9? This needs application data to be handed over before the handshake is = completed. I think this could only be done with =E2=80=9CSEND=E2=80=9D = triggering =E2=80=9COPEN=E2=80=9D, as described in this text:=20 *** Some implementations may allow users to SEND first; in which case, an automatic OPEN would be done. If the calling process is not authorized to use this connection, an error is returned. *** As it stands, when I read this, it makes me think =E2=80=9Cwhy would = anyone do this?=E2=80=9D. I believe there should be some clarification = there regarding the point of this - to explain that this can make it = possible to send data together with the SYN. Cheers, Michael > On Mar 28, 2017, at 4:50 PM, Internet-Drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the TCP Maintenance and Minor Extensions = of the IETF. >=20 > Title : Transmission Control Protocol Specification > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-05.txt > Pages : 95 > Date : 2017-03-28 >=20 > Abstract: > This document specifies the Internet's Transmission Control Protocol > (TCP). TCP is an important transport layer protocol in the Internet > stack, and has continuously evolved over decades of use and growth = of > the Internet. Over this time, a number of changes have been made to > TCP as it was specified in RFC 793, though these have only been > documented in a piecemeal fashion. This document collects and = brings > those changes together with the protocol specification from RFC 793. > This document obsoletes RFC 793 and several other RFCs (TODO: list > all actual RFCs when finished). >=20 > RFC EDITOR NOTE: If approved for publication as an RFC, this should > be marked additionally as "STD: 7" and replace RFC 793 in that role. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-05 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Mar 29 07:43:01 2017 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 A87DD1296C7 for ; Wed, 29 Mar 2017 07:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJmfYr7P3r8B for ; Wed, 29 Mar 2017 07:42:46 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 870DF127449 for ; Wed, 29 Mar 2017 07:42:44 -0700 (PDT) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctEo6-000CTG-V7 for tcpm@ietf.org; Wed, 29 Mar 2017 16:42:42 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctEo4-0002cL-Hn for tcpm@ietf.org; Wed, 29 Mar 2017 16:42:42 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_BE676EDC-CC91-4D07-980D-237B9495DBC1" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 29 Mar 2017 09:42:38 -0500 References: To: "tcpm@ietf.org" In-Reply-To: Message-Id: <7817D595-3712-466D-94CF-B900EE22B2C5@ifi.uio.no> X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 4 sum msgs/h 3 total rcpts 53355 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.008, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F6E56E87E23A71D792507F534BFD61A4694F42D4 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 88 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-cubic-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 14:42:56 -0000 --Apple-Mail=_BE676EDC-CC91-4D07-980D-237B9495DBC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I have a comment: When we did tests with Cubic in a local testbed, it exhibited nonlinear = behavior as we varied the BDP (e.g. changing capacity or RTT). We found the =E2=80=9CFast convergence=E2=80=9D mechanism in section 4.6 = to be the culprit: it assumes that, when W_max < W_last_max, new flows = have joined and Cubic should make room for them. However, when doing tests of only a single flow in a controlled = environment, and the BDP is e.g. around 10.5 packets, in reality, a flow = may get W_max of 10, 11, 10, 11, =E2=80=A6 etc. This means that the = mechanism keeps kicking in. Next, you do a test with a BDP of 0.5 = packets more, and then W_max is statically 11 =E2=80=A6 so the behavior = fluctuates quite a bit as a result of small changes to the BDP. When testing flows in controlled condition and in isolation, I think = this mechanism doesn=E2=80=99t make sense to use anyway. So I think it = would be useful to insert a comment about this in section 4.6 for people = doing such experiments. Besides, I think the last paragraph of section 4.6 is hard to = understand. It just doesn=E2=80=99t seem clear to say that flows with = smaller shares can better increase their windows because flows with = larger shares =E2=80=9Cspend more time around the plateau=E2=80=9D. The comments in the code snippet are also confusing: =E2=80=9Ccheck = downward trend=E2=80=9D and =E2=80=9Ccheck upward trend=E2=80=9D, what = is that supposed to mean? I think =E2=80=9Ccheck downward trend=E2=80=9D = could be =E2=80=9Cshould we make room for other flows?=E2=80=9D or = something like that. Cheers, Michael > On Mar 23, 2017, at 4:23 PM, Yoshifumi Nishida = wrote: >=20 > Hello, > The WGLC for this draft has already finished, but we haven't seen many = comments on this draft. > We are trying to interpret this is an indication that people are = satisfied with the current draft, but we just would like to be sure.=20 > Please let us know in case you have very last minute comments. > We'll do similar final check at the venue. If nothing happens, we will = try to proceed the doc after reviewing the updated version. >=20 > Thanks, > -- > tcpm co-chairs >=20 > On Wed, Feb 15, 2017 at 1:13 AM, Yoshifumi Nishida = > wrote: > Hello, >=20 > In addition to the dctcp draft, TCP chairs conclude that = draft-ietf-tcpm-cubic-04 is ready for WGLC as well and decided to = initiate the call. >=20 > The WGLC for this draft runs until * Friday March 3 *.=20 > Please send your feedback to the ML. >=20 > BTW, the intended status of the draft is Informational.=20 > The draft is available from the following URL. > https://tools.ietf.org/html/draft-ietf-tcpm-cubic-04 = >=20 > Thanks, > -- > Yoshi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_BE676EDC-CC91-4D07-980D-237B9495DBC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

I = have a comment:

When we did tests with Cubic in a local testbed, it exhibited = nonlinear behavior as we varied the BDP (e.g. changing capacity or = RTT).

We found = the =E2=80=9CFast convergence=E2=80=9D mechanism in section 4.6 to be = the culprit: it assumes that, when W_max < W_last_max, new flows have = joined and Cubic should make room for them.
However, = when doing tests of only a single flow in a controlled environment, and = the BDP is e.g. around 10.5 packets, in reality, a flow may get W_max of = 10, 11, 10, 11, =E2=80=A6 etc. This means that the mechanism keeps = kicking in. Next, you do a test with a BDP of 0.5 packets more, and then = W_max is statically 11 =E2=80=A6 so the behavior fluctuates quite a bit = as a result of small changes to the BDP.

When testing flows in controlled = condition and in isolation, I think this mechanism doesn=E2=80=99t make = sense to use anyway. So I think it would be useful to insert a comment = about this in section 4.6 for people doing such experiments.

Besides, I think the = last paragraph of section 4.6 is hard to understand. It just doesn=E2=80=99= t seem clear to say that flows with smaller shares can better increase = their windows because flows with larger shares =E2=80=9Cspend more time = around the plateau=E2=80=9D.

The comments in the code snippet are = also confusing: =E2=80=9Ccheck downward trend=E2=80=9D and =E2=80=9Ccheck = upward trend=E2=80=9D, what is that supposed to mean? I think =E2=80=9Cche= ck downward trend=E2=80=9D could be =E2=80=9Cshould we make room for = other flows?=E2=80=9D or something like that.

Cheers,
Michael


On Mar 23, 2017, at 4:23 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

Hello,
The WGLC for = this draft has already finished, but we haven't seen many comments on = this draft.
We are trying to interpret = this is an indication that people are satisfied with the current draft, = but we just would like to be sure. 
Please let us know in case you have very last = minute comments.
We'll do similar final = check at the venue. If nothing happens, we will try to proceed the doc = after reviewing the updated version.

Thanks,
--
tcpm co-chairs

On Wed, Feb 15, 2017 at 1:13 AM, = Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hello,

In = addition to the dctcp draft, TCP chairs conclude that = draft-ietf-tcpm-cubic-04 is ready for WGLC as well and decided to = initiate the call.

The WGLC for this draft runs until * Friday March 3 = *. 
Please send your feedback = to the ML.

BTW, the intended status of the draft is = Informational. 
The draft is available from = the following URL.
https://tools.ietf.org/html/draft-ietf-tcpm-cubic-04

Thanks,
--
Yoshi

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

= --Apple-Mail=_BE676EDC-CC91-4D07-980D-237B9495DBC1-- From nobody Wed Mar 29 12:44:59 2017 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 2183712975C for ; Wed, 29 Mar 2017 12:44:57 -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=nokia.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 t-2FI5DnUOR6 for ; Wed, 29 Mar 2017 12:44:54 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0114.outbound.protection.outlook.com [104.47.1.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513441270FC for ; Wed, 29 Mar 2017 12:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FIvrOu3DP+ZLxBDnVzSY6zSfaHjqL9gfQ2TJk8ClXww=; b=BuYp5/mOFUZpFeGdlRo+yS7xQ6DJjCKMFp2e+myVN1yL3/UF4vYBpXDgsZJFW4nSwpyreMR53CJmHDorkMZvbn+g7Y4s6PBoRboFPFaVVptbwI4DyATZm1+tOffeU7R73D2He828b0e6dOaG/d7l7UcZo5RlEuUe0RW1/4W6fE8= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 19:44:51 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 19:44:51 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" Thread-Topic: RFC 793 (bis) vs. rto-consider Thread-Index: AdKowj/uHBlAvttmR5O5bK3orMhOog== Date: Wed, 29 Mar 2017 19:44:51 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [31.133.141.145] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2546; 7:90ycuuqWTJ06Ke+a0KOhjZfloYBlD94JYJadCPl6lMmlpYhQGE1UZs/UUT3KFeSGmaqOjGWUnLFXsaJ4mJbTcsNGYesJktbHW6JWC6uhbEOtCTT/aEW2e/j2X2EGZ5CI4Gn7jkcmWWdV26wGcalzijnkwUNivOyNBttMhlQ6hRXtidnxJhzKAjsGP03Gxk7/yp6c5nnlJVOQr/z8KDeB3PF2f2h28OawpwR2SYvwJwc5VxhHTbGoqYWRTZXxo1P93Elpuad+kbcmhjUEDm6m9+5NXqQJPEbCAKM6G+VvWgDJOyvx4UhQY15Q2UHBr4HGPUgoWIhXVdZIcqPmDIOxHw== x-ms-office365-filtering-correlation-id: acd61a06-f28c-400d-c149-08d476dc10e3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM5PR0701MB2546; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123560025)(20161123564025)(20161123558025)(20161123555025)(20161123562025)(6072148); SRVR:AM5PR0701MB2546; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2546; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39840400002)(39410400002)(39450400003)(39400400002)(54094003)(55016002)(790700001)(6116002)(189998001)(7696004)(77096006)(102836003)(7736002)(2351001)(3846002)(2501003)(6436002)(6506006)(5640700003)(106356001)(53936002)(66066001)(86362001)(5660300001)(99286003)(74316002)(25786009)(81156014)(33656002)(8936002)(6916009)(9686003)(6306002)(122556002)(8676002)(81166006)(1730700003)(54896002)(2906002)(3660700001)(3280700002)(2900100001)(38730400002)(110136004)(50986999)(54356999)(5630700001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2546; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2547E912E0AC4D656EB9408B93350AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 19:44:51.1824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2546 Archived-At: Subject: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 19:44:57 -0000 --_000_AM5PR0701MB2547E912E0AC4D656EB9408B93350AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe I should expand on what I have orally mentioned in the meeting: draft-ietf-tcpm-rfc793bis-05 states: Because of the variability of the networks that compose an internetwork system and the wide range of uses of TCP connections the retransmission timeout (RTO) must be dynamically determined. The RTO MUST be computed according to the algorithm in [8], including Karn's algorithm for taking RTT samples. The first sentence with "must" is taken from RFC 793. The second sentence w= ith "MUST" seems to follow from the MUST in RFC 6298. In my reading of the = standards, the current wording in 793bis correctly reflects the wording of = TCP PS standards. draft-ietf-tcpm-rto-consider-05 states: (a) In steady state the RTO SHOULD be set based on recent observations of both the FT and the variance of the FT. In other words, the RTO should be based on a reasonable amount of time that the sender should wait for delivery confirmation before retransmitting the given data. (b) FT observations SHOULD be taken regularly. To me, this wording seems compatible with RFC 8085, i.e., the BCP for UDP. When rto-consider was approved as TCPM WG item, both (a) and (b) was a MUST= . As individual contributor, I struggle with accepting a SHOULD in (a) and (b= ) as best current practice requirement for TCP. In TCP, the well-defined pr= otocol mechanisms IMHO allow a MUST for both cases, and this is how I read = the "must" in RFC 793. Also, I believe that in this case the requirements for TCP can (well, must)= be tighter than for UDP protocols. The difference is that for UDP protocol= s it cannot be guaranteed that the protocol allows regular FT observations.= In TCP we know that this is possible. So why allowing a SHOULD for TCP? So, I wonder if there could be a reasoning for applying these two SHOULD to= TCP? Most notably, could there be any reason why a TCP implementation woul= d not measure RTT "regularly"? Any thoughts? Michael --_000_AM5PR0701MB2547E912E0AC4D656EB9408B93350AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<chair hat off>

 

Maybe I should expand on what I have orally mentione= d in the meeting:

 

draft-ietf-tcpm-rfc793bis-05 states:

 

   Because of the variability of the networks that compose a=
n
   internetwork system and the wide range of uses of TCP con=
nections the
   retransmission timeout (RTO) must be dynamically determin=
ed.

 

   The RTO MUST be computed according to the alg= orithm in [8], including

   Karn's algorithm for taking RTT samples.=

 

The first sentence with “must” is taken from RFC 793. The second sentence with “MUST”<= /span> seems to follow from the MUST in RFC 6298. In my reading of the stan= dards, the current wording in 793bis correctly reflects the wording of TCP PS standards.

 

draft-ietf-tcpm-rto-consider-05 states:

 

        (a) In steady state the RTO=
 SHOULD be set based on recent
            obs=
ervations of both the FT and the variance of the FT.
 
            In =
other words, the RTO should be based on a reasonable
            amo=
unt of time that the sender should wait for delivery
            con=
firmation before retransmitting the given data.
 
        (b) FT observations SHOULD =
be taken regularly.

 

To me, this wording seems compatible with RFC 8085, = i.e., the BCP for UDP.

 

When rto-consider was approved as TCPM WG item, both= (a) and (b) was a MUST.

 

As individual contributor, I struggle with accepting= a SHOULD in (a) and (b) as best current practice requirement for TCP. In T= CP, the well-defined protocol mechanisms IMHO allow a MUST for both cases, = and this is how I read the “must”<= /span> in RFC 793.

 

Also, I believe that in this case the requirements f= or TCP can (well, must) be tighter than for UDP protocols. The difference i= s that for UDP protocols it cannot be guaranteed that the protocol allows r= egular FT observations. In TCP we know that this is possible. So why allowing a SHOULD for TCP?

 

So, I wonder if there could be a reasoning for apply= ing these two SHOULD to TCP? Most notably, could there be any reason why a = TCP implementation would not measure RTT “regularly= 221;?

 

Any thoughts?

 

Michael

--_000_AM5PR0701MB2547E912E0AC4D656EB9408B93350AM5PR0701MB2547_-- From nobody Wed Mar 29 13:33:23 2017 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 741AD12996E for ; Wed, 29 Mar 2017 13:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aChTMvx7czyP for ; Wed, 29 Mar 2017 13:33:20 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86D61294D3 for ; Wed, 29 Mar 2017 13:33:20 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v2TKXJqR016105; Wed, 29 Mar 2017 13:33:20 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C3F6A73AE7D5; Wed, 29 Mar 2017 16:33:19 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\/Stuttgart\)" From: Mark Allman Reply-To: mallman@icir.org cc: "tcpm\@ietf.org" In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lodi X-URL-0: https://www.icir.org/mallman-files/Document58521.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 29 Mar 2017 16:33:19 -0400 Message-ID: <9237.1490819599@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 20:33:22 -0000 --=-------459435943823349593450 Content-Type: text/plain I think this is all a little too pedantic for me. To my eye the difference between a "MUST" and a "SHOULD" is a good reason. That is, a "SHOULD" is in fact a "MUST" except when there is a good reason to do something else. So, do I have a handy (good) reason why TCP would not take an RTT sample once per RTT? No, not really. So, I think it basically must do so. That said, we have done enough work tweaking the TCP RTO to know that the world would not end if a sample was taken every other RTT (in fact, this often happens naturally during periods of loss because of Karn's algorithm). And, in fact, the RTO performance would be pretty much the same. Is that my druthers? No, not really. I'd like to see the once per RTT sampling in TCP. But, if someone came to me and said "for efficiency reasons in my lightbulb TCP implementation I only take an RTT every other RTT" I would probably shrug and go "seems fine". Document wording aside: Do you think the once-per-RTT sampling in TCP is so crucial that if an implementation did not adhere to it that it would cause big problems (for the network or that implementation)? allman -- https://www.icir.org/mallman/ @mallman_icsi --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljcGg8ACgkQWyrrWs4yIs7D9QCeOdSJJ4ntoEmUXTDseYIJMLBj nEkAnRLSh4kTTbdMKELo+iboKMI8V1rP =N1HH -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Mar 29 14:06:45 2017 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 4ACAA126DDF for ; Wed, 29 Mar 2017 14:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 JaGefYxaWBsD for ; Wed, 29 Mar 2017 14:06:41 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0110.outbound.protection.outlook.com [104.47.0.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6384C124217 for ; Wed, 29 Mar 2017 14:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xETRKAhT22U38A7VLUDabEenqi/Efeo2UI2hyhffH8k=; b=B23SIRXGQnD2w8e8xayIgct28rLH5bZgJqC0s/T6/zT1gqWyFxHzkmY6zZloqZ11qShTFNOeX1oj2yyGK8OSNZzKjVW9sPEzFM45uFgvwKmGPpUCqrU1IS5+xywFl2AKPQgfdIKfKM6aPeVDVxpj4jBecCDEkGzdIKRvwyaO4qs= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 21:06:38 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 21:06:37 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "mallman@icir.org" CC: "tcpm@ietf.org" Thread-Topic: [tcpm] RFC 793 (bis) vs. rto-consider Thread-Index: AQHSqMu2Gdbmj+USPEKtHeXoxtlk/6GsSo6Q Date: Wed, 29 Mar 2017 21:06:37 +0000 Message-ID: References: <9237.1490819599@lawyers.icir.org> In-Reply-To: <9237.1490819599@lawyers.icir.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: icir.org; dkim=none (message not signed) header.d=none;icir.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [31.133.141.145] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2546; 7:9nN3eEiGfxm4TCaxsjS0QhYEOqX1pcZSmPn9rnIZCm6cCLHHqOmfukntpvCWwBWGsvxpoBpAKq++ZM7NaS9yOmAvR/O22UYteFF6QgFFZVghf/F1O4EdMR3AZ9+38SE6Ou3TRUBat4aadBbhzpvMzJj2QEiFa7PlBvlwgEnGY+pZX0Smoh88M1iHwGT4LtORzEPD0CpckON0rRzZNKn+0WoIcLPlcmfItg8rVrr0X0TWesMXPKx61Id9gUZdfZn7oPDIzJVHKqlny5n9QG86o8fiqi+2ecn+Bu60SCD2eCmX+xi+BNcQUNGi65knicoKl3Qv/F7eTY0WhCVnT0+9qg== x-ms-office365-filtering-correlation-id: 0fd81a63-c8b9-48c7-586f-08d476e77d4b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2546; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM5PR0701MB2546; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2546; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39400400002)(39840400002)(39860400002)(39850400002)(13464003)(2906002)(3660700001)(3280700002)(2950100002)(8936002)(33656002)(53546009)(25786009)(81166006)(1730700003)(9686003)(6306002)(6916009)(8676002)(122556002)(76176999)(50986999)(4326008)(54356999)(2900100001)(38730400002)(6246003)(229853002)(6436002)(2501003)(6506006)(305945005)(55016002)(102836003)(3846002)(2351001)(7736002)(6116002)(7696004)(77096006)(189998001)(53936002)(66066001)(5660300001)(99286003)(74316002)(86362001)(5640700003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2546; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 21:06:37.5243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2546 Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 21:06:43 -0000 The RFC 2119 wording is SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I really wonder if there would exist *any* valid reason for a TCP implement= ation not to measure the FT "regularly".=20 The opposite to "regularly" is "not regularly". "not regularly" would e.g. = to only measure the FT once during the lifetime of a connection. I cannot r= eally think of particular circumstances where this would make sense in TCP. For TCP, I think the SHOULD in rto-consider is not the right guidance (let = alone that it clearly contradicts RFC 6298). But for UDP the SHOULD is prob= ably appropriate as per RFC 8085. So it seems that I run into an inconsiste= ncy between my opinion for TCP and UDP, which in turn causes more formal fo= llow-up issues. Note that my comment is not about the measurement frequency and the MUST fo= r once-per-RTT in RFC 6298. I would review this wording in a RFC6298bis. Michael =20 > -----Original Message----- > From: mallman@icir.org [mailto:mallman@icir.org] > Sent: Mittwoch, 29. M=E4rz 2017 22:33 > To: Scharf, Michael (Nokia - DE/Stuttgart) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider >=20 >=20 > I think this is all a little too pedantic for me. >=20 > To my eye the difference between a "MUST" and a "SHOULD" is a good > reason. That is, a "SHOULD" is in fact a "MUST" except when there is a g= ood > reason to do something else. >=20 > So, do I have a handy (good) reason why TCP would not take an RTT sample > once per RTT? No, not really. So, I think it basically must do so. >=20 > That said, we have done enough work tweaking the TCP RTO to know that > the world would not end if a sample was taken every other RTT (in fact, t= his > often happens naturally during periods of loss because of Karn's algorith= m). > And, in fact, the RTO performance would be pretty much the same. Is that > my druthers? No, not really. I'd like to see the once per RTT sampling = in TCP. > But, if someone came to me and said "for efficiency reasons in my lightbu= lb > TCP implementation I only take an RTT every other RTT" I would probably > shrug and go "seems fine". >=20 > Document wording aside: Do you think the once-per-RTT sampling in TCP is > so crucial that if an implementation did not adhere to it that it would c= ause > big problems (for the network or that implementation)? >=20 > allman >=20 >=20 > -- > https://www.icir.org/mallman/ > @mallman_icsi >=20 >=20 From nobody Wed Mar 29 14:33:36 2017 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 7F4231294B3 for ; Wed, 29 Mar 2017 14:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoiGzcvb0jjZ for ; Wed, 29 Mar 2017 14:33:32 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 96D3512957B for ; Wed, 29 Mar 2017 14:33:31 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctLDe-0001ed-0U for tcpm@ietf.org; Wed, 29 Mar 2017 23:33:30 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctLDd-0004kX-67 for tcpm@ietf.org; Wed, 29 Mar 2017 23:33:29 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <206AB840-99C4-46FD-A36D-27927E3A6C42@ifi.uio.no> Date: Wed, 29 Mar 2017 16:33:27 -0500 To: tcpm@ietf.org X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 5 sum rcpts/h 7 sum msgs/h 6 total rcpts 53364 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.044, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 64FDF58388408F7F5079BF1802EDBA8D3BC40BAB X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 94 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tcpm] About CUBIC and buffer draining X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 21:33:35 -0000 Hi, In Praveen=E2=80=99s very interesting presentation on TCP in Windows, = today: = https://www.ietf.org/proceedings/98/slides/slides-98-tcpm-tcp-improvements= -in-windows-01.pdf he stated that =E2=80=9CCUBIC builds up large buffer in absence of = AQM=E2=80=9D (slide 4). In the absence of an AQM algorithm, even a single Reno flow alone will = not let a queue drain when it=E2=80=99s (for several practical reasons, = slightly more than) a BDP in length. To allow a BDP worth of queuing to = drain, the sender needs a backoff factor of 0.5 or less. CUBIC=E2=80=99s = backoff (multiplication) factor is 0.7, so it can even produce a = standing queue when the queue is smaller than a BDP. For reasonably configured networks, and with background load = fluctuations, that=E2=80=99s maybe not such a huge problem (after all, = the Internet still works ;-) ). However, CUBIC=E2=80=99s backoff factor choice is =E2=80=9Cblind=E2=80=9D = - CUBIC has no idea of the length of the queue. That=E2=80=99s what we=E2=80=99re trying to fix with ABE = (draft-khademi-tcpm-alternativebackoff-ecn): because ECN is a hint that = the queue was probably small, we can use a larger backoff factor (i.e. = reduce by less). =3D> if the whole Internet would support ECN, and ABE = was implemented as a way to back off, I would wonder: should CUBIC use = 0.5 when it reacts to loss? These are researchy futuristic musings. Getting back down to earth, I = think it may be good to add a sentence to the CUBIC draft, where the = backoff factor of 0.7 is introduced (last paragraph of section 3). = There, the text now only says: *** CUBIC sets the multiplicative window decrease factor to 0.7 while Standard TCP uses 0.5. While this improves the scalability of the protocol, a side effect of this decision is slower convergence especially under low statistical multiplexing environments. *** =E2=80=A6 but I think the fact that it is more likely to produce a = standing queue is a bigger issue, and worth mentioning here. Cheers, Michael From nobody Wed Mar 29 19:22:58 2017 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 D5AC3128B44 for ; Wed, 29 Mar 2017 19:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hJcjqq0XeIrZ for ; Wed, 29 Mar 2017 19:22:55 -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 30CC2126BFD for ; Wed, 29 Mar 2017 19:22:55 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 190so67374115itm.0 for ; Wed, 29 Mar 2017 19:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=L8y1fjDtac0WYAxKf6jnc9YzLsmijcp57s3jU2JRWKs=; b=CWz1GXR7N469fhGwvBTn4WagmgKeMgULZkldqQMh4wkYicFP85kH3XD151WdTUzTeG PGKEF2NdxT5WlEF13CHgIDjKFHb/v20Ux9l24BnAB7E5Snz9vzMIXamQ6NtkeiOJs3vl AHe+eI1xkBmD6Mullo8xmw5firdaRHPnYHknY705lCiI7uuHAQFWbYaUyVDyTWa5Rtec ftnfcUTWNyBUOP0hLksrgiRL7sZCNjzTGVYhacpwo16gPYPX/6013y2d3/2rwIeDn9d/ oD+bjPSZnGY2RWGttCXsg4JTUCDKTUSxcBzWH/AFIgpMu4FD/HTH8v4eVrQQQZ2y2juF RDSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=L8y1fjDtac0WYAxKf6jnc9YzLsmijcp57s3jU2JRWKs=; b=XzruRgfAyn6F1vpDCs27VL1xl9+SdOTw29f0LY7ShJQ9hQGgDSvdmIlDE3jDGIDJmC tK3lQoqKtT+E7SOWk9+WdkMgegaEX3vvxi3oFDa+IqMR68cj6wOktsS6GpedHeXrILbq 902PrbvZ0UwmAMKCuxVXejipYSNRlPJa18E1EHrh3ZclJXrAvOH+bRvUzUYrRn5jIR3V skPDoLLsZATT3DNzGmD9+XS2Px2/ey73MNHB4t1giE31PFgK4zLqy+KsLp2EWsKSfCcb SgCUalrKq697pP43msRvo7qumycmAMt2+O96QG72nt55nfQBLI8Z5rhXhoYd0kljmgh8 CSvA== X-Gm-Message-State: AFeK/H1zCnEbPSWOFH8wljz8F6Gh78ECIjZaDeqYxU59oXI9y3aPw1XOIL822rdDDRZ64mNEMbC24AoSw9s9MHV1 X-Received: by 10.36.196.8 with SMTP id v8mr1818783itf.115.1490840574288; Wed, 29 Mar 2017 19:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.24 with HTTP; Wed, 29 Mar 2017 19:22:13 -0700 (PDT) From: Yuchung Cheng Date: Wed, 29 Mar 2017 21:22:13 -0500 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=94eb2c05d0d4d962a0054be95e74 Archived-At: Subject: [tcpm] on resetting backoff in rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 02:22:57 -0000 --94eb2c05d0d4d962a0054be95e74 Content-Type: text/plain; charset=UTF-8 (3) Each time the RTO is used to detect a loss and a retransmission is scheduled, the value of the RTO MUST be exponentially backed off such that the next firing requires a longer interval. The backoff SHOULD be removed after the successful repair of the lost data and subsequent transmission of non-retransmitted data. I wanted to ask in mic but we ran out of time: AFAIK, the backoff is reset whenever a new RTT sample is obtained, not necessarily the segment being repaired, either via new data being acked or TS-opt approach. The rationale that is exp-backoff is not necessary if ack clocking has been restored. Since we are talking about wiggle rooms: I would propose we just say backoff SHOULD be removed once a new FT is obtained. Is this critical? probably not. But I just want to finish my questions. --94eb2c05d0d4d962a0054be95e74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 


    (3) Eac=
h time the RTO is used to detect a loss and a retransmission
        is scheduled, the value of the RTO MUST be exponentially backed
        off such that the next firing requires a longer interval.  The
        backoff SHOULD be removed after the successful repair of the
        lost data and subsequent transmission of non-retransmitted data.


I wanted to ask in mic but we ran = out of time: AFAIK, the backoff is reset whenever a new RTT sample is obtai= ned, not necessarily the segment being repaired, either via new data being = acked or TS-opt approach. The rationale that is exp-backoff is not necessar= y if ack clocking has been restored.

Since we are = talking about wiggle rooms: I would propose we just say backoff SHOULD be r= emoved once a new FT is obtained.

Is this critical= ? probably not. But I just want to finish my questions.
--94eb2c05d0d4d962a0054be95e74-- From nobody Wed Mar 29 19:47:22 2017 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 0701512709D for ; Wed, 29 Mar 2017 19:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 TIGJs-O37vyx for ; Wed, 29 Mar 2017 19:47:18 -0700 (PDT) Received: from magic.dirtside.com (magics.dirtside.com [199.33.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 807801286B2 for ; Wed, 29 Mar 2017 19:47:16 -0700 (PDT) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id v2U2lB4j002858 for ; Wed, 29 Mar 2017 22:47:11 -0400 X-Really-To: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 51649EC58B for ; Wed, 29 Mar 2017 22:47:11 -0400 (EDT) Received: by mail-wr0-f170.google.com with SMTP id l43so41235131wre.1 for ; Wed, 29 Mar 2017 19:47:11 -0700 (PDT) X-Gm-Message-State: AFeK/H2JvokgwkfCDiBLtM+I0yXz30rYLI02DOirGkC7m14/QZ9MclsP46OIiekCDIUV9gtUDzUsmkUYtSxgIA== X-Received: by 10.223.152.43 with SMTP id v40mr3012805wrb.60.1490842030167; Wed, 29 Mar 2017 19:47:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.139 with HTTP; Wed, 29 Mar 2017 19:46:49 -0700 (PDT) From: William Herrin Date: Wed, 29 Mar 2017 22:46:49 -0400 X-Gmail-Original-Message-ID: Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=f403045f583c9fe245054be9b5d9 X-Spam-Checker: magic.dirtside.com Archived-At: Subject: [tcpm] Anycast TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 02:47:20 -0000 --f403045f583c9fe245054be9b5d9 Content-Type: text/plain; charset=UTF-8 http://bill.herrin.us/network/anycasttcp.html Enjoy! -Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: --f403045f583c9fe245054be9b5d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-Bill Herrin

--
William Herrin ................ herrin@dirtside.com =C2=A0bill@herrin.us
Dirtsid= e Systems ......... Web: <http://www.dirtside.com/>
--f403045f583c9fe245054be9b5d9-- From nobody Wed Mar 29 19:48:24 2017 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 D54F2128796 for ; Wed, 29 Mar 2017 19:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qgGO_kWELALC for ; Wed, 29 Mar 2017 19:48:22 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C60F12709D for ; Wed, 29 Mar 2017 19:48:22 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v2U2mLF3020360; Wed, 29 Mar 2017 19:48:21 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6D75673B079A; Wed, 29 Mar 2017 22:48:21 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\/Stuttgart\)" From: Mark Allman Reply-To: mallman@icir.org cc: "tcpm\@ietf.org" In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lodi X-URL-0: https://www.icir.org/mallman-files/Document62702.doc X-URL-1: https://www.icir.org/mallman-files/Document73733.docx X-URL-2: https://www.icir.org/mallman-files/Document24098.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 29 Mar 2017 22:48:21 -0400 Message-ID: <70508.1490842101@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 02:48:24 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > The RFC 2119 wording is >=20 > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. Right... like I said: the difference between a MUST and a SHOULD is a good reason. (At least when we're talking about things that don't involve interoperability.) > I really wonder if there would exist *any* valid reason for a TCP > implementation not to measure the FT "regularly".=20=20 >=20 > The opposite to "regularly" is "not regularly". "not regularly" > would e.g. to only measure the FT once during the lifetime of a > connection. I cannot really think of particular circumstances > where this would make sense in TCP.=20 Look, that is just another point in the tradeoff space. We looked at it in [AP99]. It turns out this sort of "take first" approach reduces the waiting time for needed retransmissions compared to 6298. It also follows the fundamental tradeoff and does this at the expense of increasing spurious retransmissions. But, that is no different than many changes one can make---and have been made in running code (e.g., hacking at the EWMA gains or the variance multiplier or whatever). And, the take-first approach is sort of middling. It isn't particularly good or bad in either direction. It certainly isn't ludicrous by any stretch. Do I think this is a great spot in the tradeoff space? Not really. Would I want to say that implementations "MAY take a single RTT measurement per connection"? No, not really. I think RTOs benefit From=20taking regular RTT measurements and feeding those into an RTO estimator. But, will the world end if they don't? Nope. I would certainly not make some categorical statement like there could never be any valid reason to do this. Certainly it'd be a simpler implementation. And, maybe for some things that is an over-riding concern. But, whether Michael or I or anyone would do this is absolutely beside the point. To me the question is whether we think the impact of doing this is so egregiously bad that we are compelled to say "never do it" it the strongest possible way. Maybe Michael has evidence I haven't seen, but I don't think we're anywhere even close to that point. > (let alone that it clearly contradicts RFC 6298) I think "contradict" is the wrong word here. It is different to be sure. But, the **POINT** of rto-consider is to be different and to loosen things up. If it wasn't different than 6298 then there wouldn't be any point. If you want things nice and tight then rto-consider probably runs counter to your thinking for the entire nine pages. And, if consensus is that we want precise and tight algorithms that are well specified in formal language but divorced from reality, OK (which is where we're at now, BTW). I'll accept that. I don't agree with that notion. But, I've been on the wrong side of consensus before. However, that is not at all my read of consensus. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljccfIACgkQWyrrWs4yIs7tlACaAnwlUzUGzJEsdfDAnuIjZd/P uEEAnRoKVKNBv5SswIkiIM97fU164LUv =RQuY -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Mar 29 23:33:31 2017 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 A4989129570 for ; Wed, 29 Mar 2017 23:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-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 DW6pqcjN1CqA for ; Wed, 29 Mar 2017 23:33:28 -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 EC55312955E for ; Wed, 29 Mar 2017 23:33:27 -0700 (PDT) Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2U6XDN9020998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2017 23:33:15 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B1942DCD-BF71-44B0-ADBF-1D299A601CC7 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14D27) In-Reply-To: Date: Wed, 29 Mar 2017 23:33:12 -0700 Cc: "tcpm@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: "Scharf, Michael (Nokia - DE/Stuttgart)" X-MailScanner-ID: v2U6XDN9020998 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 06:33:29 -0000 --Apple-Mail-B1942DCD-BF71-44B0-ADBF-1D299A601CC7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Mar 29, 2017, at 12:44 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >=20 > So, I wonder if there could be a reasoning for applying these two SHOULD t= o TCP? Most notably, could there be any reason why a TCP implementation woul= d not measure RTT =E2=80=9Cregularly=E2=80=9D? Overhead and complexity for small footprint devices. IMO SHOULD is sufficien= t. MUST needs to be reserved for protocol correctness or behavior truly haza= rdous to others. Joe= --Apple-Mail-B1942DCD-BF71-44B0-ADBF-1D299A601CC7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Mar 2= 9, 2017, at 12:44 PM, Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com> wrote:
=
So, I wonder if there could be a re= asoning for applying these two SHOULD to TCP? Most notably, could there be a= ny reason why a TCP implementation would not measure RTT =E2=80=9Cregularly=E2= =80=9D?

Overhead and complexity for small f= ootprint devices. IMO SHOULD is sufficient. MUST needs to be reserved for pr= otocol correctness or behavior truly hazardous to others.

Joe
= --Apple-Mail-B1942DCD-BF71-44B0-ADBF-1D299A601CC7-- From nobody Thu Mar 30 02:59:40 2017 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 F33F112945A for ; Thu, 30 Mar 2017 02:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 jWYLJ0Rs5XGZ for ; Thu, 30 Mar 2017 02:59:36 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 28924129521 for ; Thu, 30 Mar 2017 02:59:36 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctWre-0002sY-Ht for tcpm@ietf.org; Thu, 30 Mar 2017 11:59:34 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctWrd-0005Zl-Oz for tcpm@ietf.org; Thu, 30 Mar 2017 11:59:34 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 30 Mar 2017 04:59:35 -0500 References: <206AB840-99C4-46FD-A36D-27927E3A6C42@ifi.uio.no> To: tcpm@ietf.org In-Reply-To: <206AB840-99C4-46FD-A36D-27927E3A6C42@ifi.uio.no> Message-Id: X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 3 sum rcpts/h 4 sum msgs/h 4 total rcpts 53368 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.046, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A27092948309F98AB20E40BA829F1F46DE447985 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 97 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] About CUBIC and buffer draining X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 09:59:39 -0000 Sigh, copy + paste error fix, sorry - in line: > On Mar 29, 2017, at 4:33 PM, Michael Welzl wrote: >=20 > Hi, >=20 > In Praveen=E2=80=99s very interesting presentation on TCP in Windows, = today: > = https://www.ietf.org/proceedings/98/slides/slides-98-tcpm-tcp-improvements= -in-windows-01.pdf > he stated that =E2=80=9CCUBIC builds up large buffer in absence of = AQM=E2=80=9D (slide 4). >=20 > In the absence of an AQM algorithm, even a single Reno flow alone will = not let a queue drain when it=E2=80=99s (for several practical reasons, = slightly more than) a BDP in length. To allow a BDP worth of queuing to = drain, the sender needs a backoff factor of 0.5 or less. CUBIC=E2=80=99s = backoff (multiplication) factor is 0.7, so it can even produce a = standing queue when the queue is smaller than a BDP. >=20 > For reasonably configured networks, and with background load = fluctuations, that=E2=80=99s maybe not such a huge problem (after all, = the Internet still works ;-) ). > However, CUBIC=E2=80=99s backoff factor choice is =E2=80=9Cblind=E2=80=9D= - CUBIC has no idea of the length of the queue. >=20 > That=E2=80=99s what we=E2=80=99re trying to fix with ABE = (draft-khademi-tcpm-alternativebackoff-ecn): That should be: draft-ietf-tcpm-alternativebackoff-ecn-00 Cheers, Michael > because ECN is a hint that the queue was probably small, we can use a = larger backoff factor (i.e. reduce by less). =3D> if the whole Internet = would support ECN, and ABE was implemented as a way to back off, I would = wonder: should CUBIC use 0.5 when it reacts to loss? >=20 > These are researchy futuristic musings. Getting back down to earth, I = think it may be good to add a sentence to the CUBIC draft, where the = backoff factor of 0.7 is introduced (last paragraph of section 3). = There, the text now only says: >=20 > *** > CUBIC sets the multiplicative window decrease factor to 0.7 while > Standard TCP uses 0.5. While this improves the scalability of the > protocol, a side effect of this decision is slower convergence > especially under low statistical multiplexing environments. > *** >=20 > =E2=80=A6 but I think the fact that it is more likely to produce a = standing queue is a bigger issue, and worth mentioning here. >=20 > Cheers, > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Mar 30 04:41:44 2017 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 644211294B1 for ; Thu, 30 Mar 2017 04:41:42 -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=nokia.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 GMhGWqzdRtro for ; Thu, 30 Mar 2017 04:41:39 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50120.outbound.protection.outlook.com [40.107.5.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68780129467 for ; Thu, 30 Mar 2017 04:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JMDy83rZHt7gbdLAkLFxV1iq1ZlM44rivphzcBM+G84=; b=ZkHSUBr1bcUdt+ZRtJlkIU5vMFeUoMQDeJA9jN4aJ35SPZzVtB0wxsJQcZJKAsJSE7Qa9S1VBisD/UWK9tS5aeG2icn5ElmtgLr3drO3yKCw4jhK4LY5fLI+iFvxBv5E8XB6J6Fvyrw56bCMh2eVBY7CvBvX1MFOiLU1wMkeaec= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2548.eurprd07.prod.outlook.com (10.173.92.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Thu, 30 Mar 2017 11:41:36 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1005.010; Thu, 30 Mar 2017 11:41:36 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch CC: "tcpm@ietf.org" Thread-Topic: [tcpm] RFC 793 (bis) vs. rto-consider Thread-Index: AdKowj/uHBlAvttmR5O5bK3orMhOogAXUEIAAAnLLSA= Date: Thu, 30 Mar 2017 11:41:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isi.edu; dkim=none (message not signed) header.d=none;isi.edu; dmarc=none action=none header.from=nokia.com; x-originating-ip: [12.205.206.2] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2548; 7:XEZ6YiFd+GD+5DQPrEbWqsUo0WL4viZLf+RTuiVBkZ3XlD1boSIajhwNJkwwk+gFMmmFw/gyLnGFfeCzk+1akQOkQlMr0sPJemiO/52iLNXhD9jLxWExjD0ZT19erInYt0vN5NUEflIWZ6TYbbZWbBi5VMoitNStxAiYuUR7cabKZcXTSTjHk0isN4ACarlbKfvncCIHJdPTgFOve6I4zNix8ECJBQJPYuV5CXH4hB+95i/+nJhIT2J+ElGW0AclGsYFReK2dZKvnA5yv1/saQxi/FBfYaFrfUn87Dd2L2vGs8FSQP9XeHPl1mIKyHtcMSO6cKOs/gPvqWWTZsICcg== x-ms-office365-filtering-correlation-id: 0eeba935-2485-4a4a-479b-08d47761b932 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2548; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006067)(93001067)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:AM5PR0701MB2548; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2548; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(39400400002)(24454002)(377454003)(99286003)(55016002)(2171002)(54896002)(6436002)(3280700002)(6506006)(6306002)(3660700001)(77096006)(2900100001)(6246003)(76176999)(236005)(54356999)(50986999)(53936002)(33656002)(9686003)(2906002)(7696004)(53546009)(25786009)(81166006)(6916009)(19609705001)(122556002)(2950100002)(8936002)(3846002)(189998001)(790700001)(102836003)(6116002)(5660300001)(38730400002)(110136004)(4326008)(74316002)(7736002)(8676002)(66066001)(229853002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2548; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2547B5D6A7330B40C2D3FCD193340AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 11:41:36.7244 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2548 Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 11:41:42 -0000 --_000_AM5PR0701MB2547B5D6A7330B40C2D3FCD193340AM5PR0701MB2547_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgdGhlIGNvbnRleHQgaXMgYSBzbWFsbCBmb290cHJpbnQgZGV2aWNlIChJb1QgYW5kIHRo ZSBsaWtl4oCmKTogV2hhdCBoYXBwZW5zIGlmIHRoZSBkZXZpY2UgaGFzIGEgcmVsYXRpdmVseSBz aW1wbHkgVENQIHN0YWNrIChubyBTQUNL4oCmKSBhbmQgcnVucyBvbiBhIGxvdy1iYW5kd2lkdGgg c2hhcmVkIG1lZGl1bSBjaGFubmVsICh3aXJlbGVzcykgdGhhdCBoYXMgaGlnaGx5IHZhcmlhYmxl IFJUVD8NCg0KSWYgaXQgbWVhc3VyZXMgdGhlIFJUVCBvbmNlICh0byByZWR1Y2UgY29tcGxleGl0 eSkgYW5kIGlmIHRoYXQgc2FtcGxlIGhhcHBlbnMgdG8gYmUgd2F5IGJlbG93IHRoZSBhdmVyYWdl IFJUVCwgaXQgY2FuIHJ1biByZXBlYXRlZGx5IGludG8gc3B1cmlvdXMgdGltZW91dHMsIG5vPyBU aGVuIHRoZSBleHBvbmVudGlhbCBiYWNrb2ZmIGFuZCBjb25nZXN0aW9uIGNvbnRyb2wga2lja3Mg aW4sIGJ1dCBpZiB0aGVyZSBhcmUgbWFueSBvZiB0aGVzZSBkZXZpY2VzIChzZW5zb3Jz4oCmKSBv biB0aGUgbWVkaXVtLCB0cmFuc21pdHRpbmcgZXZlcnkgbWVzc2FnZSBtdWx0aXBsZSB0aW1lcyBj b3VsZCBiZSBoYXphcmRvdXMsIG5vPw0KDQpJIHRoaW5rIGl0IGNvbWVzIGRvd24gdG8gdGhlIHF1 ZXN0aW9uIGlmIG1lYXN1cmluZyB0aGUgUlRUIG1vcmUgdGhhbiBvbmNlIGR1cmluZyBhIGNvbm5l Y3Rpb24gaXMgbmVlZGVkIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgcHVycG9zZXMsIG9yIG5vdC4N Cg0KU2luY2UgdGhlcmUgaGFzIGFsd2F5cyBiZWVuIHRoZSDigJxtdXN04oCdIHdvcmRpbmcgaW4g UkZDIDc5MyAoYW5kIGl0IGhhcyBiZWVuIGEgTVVTVCBpbiBydG8tY29uc2lkZXIgaW4gbWFueSBy ZXZpc2lvbnMgYXMgd2VsbCksIEkgYW0gbm90IHN1cmUgaWYgd2UgY2FuIGRvd25ncmFkZSB0aGlz IG5vdyB0byBTSE9VTEQsIGUuZy4sIHdpdGhvdXQgZXhwZXJpbWVudGFsIGRhdGEuDQoNCkkgdGhp bmsgaXQgaXMgc29tZWhvdyBpbmhlcmVudGx5IG5vbi10cml2aWFsIHRvIGZvcm1hbGx5IGFwcGx5 IDIxMTkgbGFuZ3VhZ2Ugd2hlbiB0aGUgc3RhdGVtZW50IGlzIG5vdCByZWFsbHkgYWJvdXQgcHJv dG9jb2wgY29ycmVjdG5lc3MgYW5kIGludGVyb3BlcmFiaWxpdHkuDQoNCk1pY2hhZWwNCg0KRnJv bTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NClNlbnQ6IERvbm5lcnN0YWcsIDMw LiBNw6RyeiAyMDE3IDA4OjMzDQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0 Z2FydCkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4NCkNjOiB0Y3BtQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3RjcG1dIFJGQyA3OTMgKGJpcykgdnMuIHJ0by1jb25zaWRlcg0KDQoNCg0KT24g TWFyIDI5LCAyMDE3LCBhdCAxMjo0NCBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0 dXR0Z2FydCkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5zY2hhcmZA bm9raWEuY29tPj4gd3JvdGU6DQpTbywgSSB3b25kZXIgaWYgdGhlcmUgY291bGQgYmUgYSByZWFz b25pbmcgZm9yIGFwcGx5aW5nIHRoZXNlIHR3byBTSE9VTEQgdG8gVENQPyBNb3N0IG5vdGFibHks IGNvdWxkIHRoZXJlIGJlIGFueSByZWFzb24gd2h5IGEgVENQIGltcGxlbWVudGF0aW9uIHdvdWxk IG5vdCBtZWFzdXJlIFJUVCDigJxyZWd1bGFybHnigJ0/DQoNCk92ZXJoZWFkIGFuZCBjb21wbGV4 aXR5IGZvciBzbWFsbCBmb290cHJpbnQgZGV2aWNlcy4gSU1PIFNIT1VMRCBpcyBzdWZmaWNpZW50 LiBNVVNUIG5lZWRzIHRvIGJlIHJlc2VydmVkIGZvciBwcm90b2NvbCBjb3JyZWN0bmVzcyBvciBi ZWhhdmlvciB0cnVseSBoYXphcmRvdXMgdG8gb3RoZXJzLg0KDQpKb2UNCg== --_000_AM5PR0701MB2547B5D6A7330B40C2D3FCD193340AM5PR0701MB2547_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlNpbmNlIHRoZSBjb250ZXh0IGlzIGEgc21hbGwgZm9vdHByaW50IGRldmlj ZSAoSW9UIGFuZCB0aGUgbGlrZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ 4oCmPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KToNCiBXaGF0IGhhcHBlbnMgaWYgdGhlIGRldmlj ZSBoYXMgYSByZWxhdGl2ZWx5IHNpbXBseSBUQ1Agc3RhY2sgKG5vIFNBQ0s8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKApjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPikgYW5k IHJ1bnMgb24gYSBsb3ctYmFuZHdpZHRoIHNoYXJlZCBtZWRpdW0gY2hhbm5lbCAod2lyZWxlc3Mp IHRoYXQgaGFzIGhpZ2hseQ0KIHZhcmlhYmxlIFJUVD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWYgaXQgbWVh c3VyZXMgdGhlIFJUVCBvbmNlICh0byByZWR1Y2UgY29tcGxleGl0eSkgYW5kIGlmIHRoYXQgc2Ft cGxlIGhhcHBlbnMgdG8gYmUgd2F5IGJlbG93IHRoZSBhdmVyYWdlIFJUVCwgaXQgY2FuIHJ1biBy ZXBlYXRlZGx5IGludG8gc3B1cmlvdXMgdGltZW91dHMsIG5vPyBUaGVuIHRoZSBleHBvbmVudGlh bA0KIGJhY2tvZmYgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBraWNrcyBpbiwgYnV0IGlmIHRoZXJl IGFyZSBtYW55IG9mIHRoZXNlIGRldmljZXMgKHNlbnNvcnM8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPuKApjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPikgb24gdGhlIG1lZGl1 bSwgdHJhbnNtaXR0aW5nIGV2ZXJ5IG1lc3NhZ2UgbXVsdGlwbGUgdGltZXMNCiBjb3VsZCBiZSBo YXphcmRvdXMsIG5vPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIGl0IGNvbWVzIGRvd24gdG8gdGhl IHF1ZXN0aW9uIGlmIG1lYXN1cmluZyB0aGUgUlRUIG1vcmUgdGhhbiBvbmNlIGR1cmluZyBhIGNv bm5lY3Rpb24gaXMgbmVlZGVkIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgcHVycG9zZXMsIG9yIG5v dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+U2luY2UgdGhlcmUgaGFzIGFsd2F5cyBiZWVuIHRoZQ0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5tdXN0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJ08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gd29yZGluZyBpbiBSRkMgNzkzIChhbmQgaXQgaGFzIGJlZW4NCiBhIE1V U1QgaW4gcnRvLWNvbnNpZGVyIGluIG1hbnkgcmV2aXNpb25zIGFzIHdlbGwpLCBJIGFtIG5vdCBz dXJlIGlmIHdlIGNhbiBkb3duZ3JhZGUgdGhpcyBub3cgdG8gU0hPVUxELCBlLmcuLCB3aXRob3V0 IGV4cGVyaW1lbnRhbCBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIGl0IGlzIHNvbWVob3cg aW5oZXJlbnRseSBub24tdHJpdmlhbCB0byBmb3JtYWxseSBhcHBseSAyMTE5IGxhbmd1YWdlIHdo ZW4gdGhlIHN0YXRlbWVudCBpcyBub3QgcmVhbGx5IGFib3V0IHByb3RvY29sIGNvcnJlY3RuZXNz IGFuZCBpbnRlcm9wZXJhYmlsaXR5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1pY2hhZWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1 XQ0KPGJyPg0KPGI+U2VudDo8L2I+IERvbm5lcnN0YWcsIDMwLiBNw6RyeiAyMDE3IDA4OjMzPGJy Pg0KPGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSAmbHQ7 bWljaGFlbC5zY2hhcmZAbm9raWEuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGNwbUBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RjcG1dIFJGQyA3OTMgKGJpcykgdnMuIHJ0by1j b25zaWRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWFyIDI5LCAyMDE3 LCBhdCAxMjo0NCBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgJmx0 OzxhIGhyZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iPm1pY2hhZWwuc2NoYXJm QG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgSSB3b25kZXIgaWYgdGhlcmUgY291bGQgYmUgYSBy ZWFzb25pbmcgZm9yIGFwcGx5aW5nIHRoZXNlIHR3byBTSE9VTEQgdG8gVENQPyBNb3N0IG5vdGFi bHksIGNvdWxkIHRoZXJlIGJlIGFueSByZWFzb24gd2h5IGEgVENQIGltcGxlbWVudGF0aW9uIHdv dWxkIG5vdCBtZWFzdXJlIFJUVCDigJxyZWd1bGFybHnigJ0/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk92ZXJoZWFkIGFuZCBjb21wbGV4aXR5 IGZvciBzbWFsbCBmb290cHJpbnQgZGV2aWNlcy4gSU1PIFNIT1VMRCBpcyBzdWZmaWNpZW50LiBN VVNUIG5lZWRzIHRvIGJlIHJlc2VydmVkIGZvciBwcm90b2NvbCBjb3JyZWN0bmVzcyBvciBiZWhh dmlvciB0cnVseSBoYXphcmRvdXMgdG8gb3RoZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM5PR0701MB2547B5D6A7330B40C2D3FCD193340AM5PR0701MB2547_-- From nobody Thu Mar 30 07:52:36 2017 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 4DB8912950E for ; Thu, 30 Mar 2017 07:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 v8D0G_CRU-LL for ; Thu, 30 Mar 2017 07:52:33 -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 9B57B1296AD for ; Thu, 30 Mar 2017 07:52:21 -0700 (PDT) Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2UEprPv006564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Mar 2017 07:51:54 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-CA17C088-92D9-4784-99D2-7CE9362B3F21 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14D27) In-Reply-To: Date: Thu, 30 Mar 2017 07:51:53 -0700 Cc: "tcpm@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: "Scharf, Michael (Nokia - DE/Stuttgart)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 14:52:35 -0000 --Apple-Mail-CA17C088-92D9-4784-99D2-7CE9362B3F21 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It comes down to what "regularly" means, e.g. vs "occasionally" or "more tha= n just once". There is no measurement method that ensures avoiding false rep= orting except "continuous", could be excessive. If you have a lot of iot devices and they all measure once, they would only c= ause a storm on spurious timeouts if they all got it wrong. I think the law o= f large numbers ought to work in your favor as long as you assume that the r= tts measurements don't coincide - I.e., it's useful to decorrelate to avoid s= ynchronization after a power recovery. The issue of downgrading may drive this, but we should be clear that we don'= t know that MUST is really required. Joe > On Mar 30, 2017, at 4:41 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >=20 > Since the context is a small footprint device (IoT and the like=E2=80=A6):= What happens if the device has a relatively simply TCP stack (no SACK=E2=80= =A6) and runs on a low-bandwidth shared medium channel (wireless) that has h= ighly variable RTT? > =20 > If it measures the RTT once (to reduce complexity) and if that sample happ= ens to be way below the average RTT, it can run repeatedly into spurious tim= eouts, no? Then the exponential backoff and congestion control kicks in, but= if there are many of these devices (sensors=E2=80=A6) on the medium, transm= itting every message multiple times could be hazardous, no? > =20 > I think it comes down to the question if measuring the RTT more than once d= uring a connection is needed for congestion control purposes, or not. > =20 > Since there has always been the =E2=80=9Cmust=E2=80=9D wording in RFC 793 (= and it has been a MUST in rto-consider in many revisions as well), I am not s= ure if we can downgrade this now to SHOULD, e.g., without experimental data.= > =20 > I think it is somehow inherently non-trivial to formally apply 2119 langua= ge when the statement is not really about protocol correctness and interoper= ability. > =20 > Michael > =20 > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Donnerstag, 30. M=C3=A4rz 2017 08:33 > To: Scharf, Michael (Nokia - DE/Stuttgart) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider > =20 > =20 >=20 > On Mar 29, 2017, at 12:44 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >=20 > So, I wonder if there could be a reasoning for applying these two SHOULD t= o TCP? Most notably, could there be any reason why a TCP implementation woul= d not measure RTT =E2=80=9Cregularly=E2=80=9D? > =20 > Overhead and complexity for small footprint devices. IMO SHOULD is suffici= ent. MUST needs to be reserved for protocol correctness or behavior truly ha= zardous to others. > =20 > Joe --Apple-Mail-CA17C088-92D9-4784-99D2-7CE9362B3F21 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It comes down to what "regu= larly" means, e.g. vs "occasionally" or "more than just once". There is no m= easurement method that ensures avoiding false reporting except "continuous",= could be excessive.

If you have a lot of iot devic= es and they all measure once, they would only cause a storm on spurious time= outs if they all got it wrong. I think the law of large numbers ought to wor= k in your favor as long as you assume that the rtts measurements don't coinc= ide - I.e., it's useful to decorrelate to avoid synchronization after a powe= r recovery.

The issue of downgrading may drive this= , but we should be clear that we don't know that MUST is really required.

Joe

On Mar 30, 2017, at 4:41 AM, Scharf= , Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com> wrote:

Since the context is a small footprint device (IoT an= d the like=E2=80=A6): What happens if the device has a relatively simply TCP stack (no SACK=E2=80=A6) and runs on a low-bandwi= dth shared medium channel (wireless) that has highly variable RTT?

 

If it measures the RTT once (to reduce complexity) an= d if that sample happens to be way below the average RTT, it can run repeate= dly into spurious timeouts, no? Then the exponential backoff and congestion control kicks in, but if there are many of these dev= ices (sensors=E2=80=A6) on th= e medium, transmitting every message multiple times could be hazardous, no?

 

I think it comes down to the question if measuring th= e RTT more than once during a connection is needed for congestion control pu= rposes, or not.

 

Since there has always been the =E2=80=9Cmust=E2=80=9D wording in RFC 793 (and it has been= a MUST in rto-consider in many revisions as well), I am not sure if we can d= owngrade this now to SHOULD, e.g., without experimental data.

 

I think it is somehow inherently non-trivial to forma= lly apply 2119 language when the statement is not really about protocol corr= ectness and interoperability.

 

Michael

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Donnerstag, 30. M=C3=A4rz 2017 08:33
To: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider<= /p>

 

 


On Mar 29, 2017, at 12:44 PM, Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com> wro= te:

So, I wonder if there could be a reasoning for applyi= ng these two SHOULD to TCP? Most notably, could there be any reason why a TC= P implementation would not measure RTT =E2=80=9Cregularly=E2=80=9D?

 

Overhead and complexity for small footprint devices. I= MO SHOULD is sufficient. MUST needs to be reserved for protocol correctness o= r behavior truly hazardous to others.

 

Joe

= --Apple-Mail-CA17C088-92D9-4784-99D2-7CE9362B3F21-- From nobody Thu Mar 30 13:22:30 2017 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 4D42E126B72; Thu, 30 Mar 2017 13:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 TdaJGZsSnFWu; Thu, 30 Mar 2017 13:22:25 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC0212945E; Thu, 30 Mar 2017 13:22:24 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2UKMMda064808; Thu, 30 Mar 2017 22:22:22 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 4A6771D53C1; Thu, 30 Mar 2017 22:22:21 +0200 (CEST) Received: from 31.133.130.113 by webmail.entel.upc.edu with HTTP; Thu, 30 Mar 2017 23:22:15 +0200 Message-ID: In-Reply-To: References: Date: Thu, 30 Mar 2017 23:22:15 +0200 From: "Carles Gomez Montenegro" To: "Scharf, Michael (Nokia - DE/Stuttgart)" Cc: "Joe Touch" , "tcpm@ietf.org" , draft-ietf-core-cocoa@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Thu, 30 Mar 2017 22:22:22 +0200 (CEST) Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 20:22:28 -0000 Hi, (CC'ing the authors of CoCoA [1]...) Hoping not to deviate too much from the main topic, I just wanted to explain that in our work with CoCoA (which is used for CoAP over UDP), we encountered issues in IoT experimental testbeds such as those described by Michael. RTT may experience high variance in different types of "typical" IoT scenarios. Wireless links used in IoT are typically error-prone (due to radio impairments such as multipath fading, interference, etc.) which may lead to link layer retries that increase the RTT. Even wired links in IoT, such as Power Line Communication ones, offer similar performance (for different reasons). In mesh networks, which are common in IoT, RTT variability increases. Furthermore, some traffic patterns in IoT may complicate the scenario. Quite often, packet transmission is relatively infrequent. However, several sensors may simultaneously detect some global event which needs to be communicated, and a burst of messages will take place as a result (increasing network load during that interval). For these reasons, in CoCoA we have an "aging" mechanism for RTO estimates that have not been updated for a while. (We even have a 'weak' estimator in addition to a 'strong' estimator, which may actually help improving the sometimes limited knowledge that a 'strong' estimator may obtain.) Thanks, Carles [1] https://tools.ietf.org/html/draft-ietf-core-cocoa-01 > Since the context is a small footprint device (IoT and the likeâ€Ĥ): What > happens if the device has a relatively simply TCP stack (no SACKâ€Ĥ) and > runs on a low-bandwidth shared medium channel (wireless) that has highly > variable RTT? > > If it measures the RTT once (to reduce complexity) and if that sample > happens to be way below the average RTT, it can run repeatedly into > spurious timeouts, no? Then the exponential backoff and congestion control > kicks in, but if there are many of these devices (sensorsâ€Ĥ) on the > medium, transmitting every message multiple times could be hazardous, no? > > I think it comes down to the question if measuring the RTT more than once > during a connection is needed for congestion control purposes, or not. > > Since there has always been the “must” wording in RFC 793 (and it has > been a MUST in rto-consider in many revisions as well), I am not sure if > we can downgrade this now to SHOULD, e.g., without experimental data. > > I think it is somehow inherently non-trivial to formally apply 2119 > language when the statement is not really about protocol correctness and > interoperability. > > Michael > > From: Joe Touch [mailto:touch@isi.edu] > Sent: Donnerstag, 30. M¤rz 2017 08:33 > To: Scharf, Michael (Nokia - DE/Stuttgart) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider > > > > On Mar 29, 2017, at 12:44 PM, Scharf, Michael (Nokia - DE/Stuttgart) > > wrote: > So, I wonder if there could be a reasoning for applying these two SHOULD > to TCP? Most notably, could there be any reason why a TCP implementation > would not measure RTT “regularly”? > > Overhead and complexity for small footprint devices. IMO SHOULD is > sufficient. MUST needs to be reserved for protocol correctness or behavior > truly hazardous to others. > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Mar 30 14:03:58 2017 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 99B6A124B0A for ; Thu, 30 Mar 2017 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 ZUyEcPsyB-Wm for ; Thu, 30 Mar 2017 14:03:54 -0700 (PDT) Received: from magic.dirtside.com (magics.dirtside.com [199.33.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFAA1292CE for ; Thu, 30 Mar 2017 14:03:54 -0700 (PDT) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id v2UL3nS3025013 for ; Thu, 30 Mar 2017 17:03:49 -0400 X-Really-To: Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com [74.125.83.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 5118DEBD55 for ; Thu, 30 Mar 2017 17:03:49 -0400 (EDT) Received: by mail-pg0-f44.google.com with SMTP id 21so50336162pgg.1 for ; Thu, 30 Mar 2017 14:03:49 -0700 (PDT) X-Gm-Message-State: AFeK/H2VWGcBtCIKY1zgCWGafrjUIiwIp7y9y0WEGgcbs4xy4PeitWAWVnYg6di0KVQVDVX24HmnIoVGjmkZXQ== X-Received: by 10.98.100.88 with SMTP id y85mr1094241pfb.112.1490907828495; Thu, 30 Mar 2017 14:03:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.12 with HTTP; Thu, 30 Mar 2017 14:03:28 -0700 (PDT) In-Reply-To: References: From: William Herrin Date: Thu, 30 Mar 2017 17:03:28 -0400 X-Gmail-Original-Message-ID: Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0533a482c25c054bf90746 X-Spam-Checker: magic.dirtside.com Archived-At: Subject: Re: [tcpm] Anycast TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 21:03:57 -0000 --94eb2c0533a482c25c054bf90746 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 10:46 PM, William Herrin wrote: > > http://bill.herrin.us/network/anycasttcp.html > > Enjoy! > > -Bill Herrin > Greetings, If there's a more appropriate WG to introduce this to, I sure would appreciate a pointer. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: --94eb2c0533a482c25c054bf90746 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 29, 2017 at 10:46 PM, William Herrin <bill@herrin.us> = wrote:


Greetings,

<= /div>
If there's a more appropriate WG to int= roduce this to, I sure would appreciate a pointer.

Regards,
Bill Herrin

--
William Herrin .........= ....... herrin@dir= tside.com =C2=A0bil= l@herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>
--94eb2c0533a482c25c054bf90746-- From nobody Thu Mar 30 14:28:42 2017 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 771EB12785F for ; Thu, 30 Mar 2017 14:28:36 -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, RP_MATCHES_RCVD=-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 bHGHnWWvqGV7 for ; Thu, 30 Mar 2017 14:28:32 -0700 (PDT) Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33003127B31 for ; Thu, 30 Mar 2017 14:28:32 -0700 (PDT) Received: from dlang-laptop ([10.2.0.162]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id v2ULSK6J026956; Thu, 30 Mar 2017 13:28:25 -0800 Date: Thu, 30 Mar 2017 14:28:20 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: William Herrin cc: tcpm@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [tcpm] Anycast TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 21:28:37 -0000 you should list an optimization flood D, which is has a relationship to C like B does to A no manipulation of sequence numbers, when you get something unknown, send it to all peers, but a peer can respond and say "I own that connection", eliminating future floods for that connection. As a further optimization (of B and D), let the peers that you flood to send a nack, not just an ack, if you get a nack from all peers, you reset the connection. It may be worth the slowdown to have the "do you own this connection" query be explicit, not implicit by forwarding the packets. This increases delays when something needs to be forwarded (at least one more round trip between the peers), but should greatly simplify the logic needed to communicate the status. One question, if you use the "flood when not a known connection" procedure, do you still need all the kernel hooks? It seems to me that most of them could go away if you accepted the potential for a collision if multiple machines pick the same starting sequence number. On Linux, IPTables already has a hook that can send packets to userspace. If you have a rule that accepts packets with known connections, and then follow that with a rule that forwards non-syn packets to the userspace program, do you still need a hook? The conntrack hooks allow you to manipulate the connection tables (so that you can take over a TCP connection that is on a cluster peer, very similar to this use case). So it seems to me that you may be able to implement a PoC of this on existing systems. Then measure where the bottlenecks are and what the 'miss rate' really is in the real world David Lang On Wed, 29 Mar 2017, William Herrin wrote: > Date: Wed, 29 Mar 2017 22:46:49 -0400 > From: William Herrin > To: tcpm@ietf.org > Subject: [tcpm] Anycast TCP > > http://bill.herrin.us/network/anycasttcp.html > > Enjoy! > > -Bill Herrin > > From nobody Thu Mar 30 14:31:21 2017 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 24E511294D3 for ; Thu, 30 Mar 2017 14:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=netapp.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 VeYmA_6oNqy1 for ; Thu, 30 Mar 2017 14:31:11 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBDD1294B8 for ; Thu, 30 Mar 2017 14:31:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,248,1486454400"; d="asc'?scan'208";a="184655733" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx143-out.netapp.com with ESMTP; 30 Mar 2017 14:18:53 -0700 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 14:30:30 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 30 Mar 2017 14:30:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DPKnLHPotN1AOdCf0SUOSMJ92TdvPAbsRN20p/38Nn4=; b=qTFlK88GL3e1yzZ7zeX1yymCtTBoa+bdxMnNGMhmQw85v8bMOxzMyRX9MjIT9pOOJEzHhBAdO12XcTo2YYXatWzLlc6LqJeaEzKbtiNGMGddLucrJhyJ8O242cQG5dBh8vwjsgsa43nDrveJJVaFih3xhuibNJnrtIrFxRtuoxI= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1156.namprd06.prod.outlook.com (10.160.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 30 Mar 2017 21:30:30 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0991.021; Thu, 30 Mar 2017 21:30:30 +0000 From: "Eggert, Lars" To: William Herrin CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Anycast TCP Thread-Index: AQHSqQAEQjyXZFrJw0S4GdvMD5Qe86Gt4CgAgAAHioA= Date: Thu, 30 Mar 2017 21:30:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: herrin.us; dkim=none (message not signed) header.d=none;herrin.us; dmarc=none action=none header.from=netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:128:d952:a840:4187:c391] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1156; 7:gjAvR1xxmfXbZpIXFxJ2hsjk6WYZxAl420G/3oPgqnCTVVKvOLWRIawlZvV0vvquGQVxPcC6q9mHikM7rkDSAeN6G9tvkc6LK5cLzglwdlOeK50KvHqmQQap4XhPs2MgbzsgfGJ5RFUN4mf725WoV6lK+3J4V4MbCZyWO1bP0QJUhQOzIkp7lGULhxq7rvXlALKPQJ5fMLWqsgTERU135tjU5ocVSFvmO3GkhgT44aee9iZNnp3+UYISujuNGYKPEs82wGUytxnFrgKdwQTWTjos1O2YSLYEAfv5zMJJuvrmpH6STaxGMEnUhCqYlXytGk/osFzqPL8u96xH4MoI1Q== x-ms-office365-filtering-correlation-id: 8afbd60a-2e43-4b64-e22d-08d477b3fdcf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN3PR0601MB1156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006074)(93001074)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BN3PR0601MB1156; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1156; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(377424004)(24454002)(7736002)(122556002)(2900100001)(6436002)(50226002)(76176999)(53546009)(50986999)(99936001)(6512007)(77096006)(6486002)(25786009)(6506006)(86362001)(57306001)(2906002)(53936002)(36756003)(558084003)(102836003)(305945005)(33656002)(99286003)(5660300001)(83716003)(189998001)(2950100002)(6916009)(8936002)(6116002)(3280700002)(3660700001)(110136004)(81166006)(6246003)(8676002)(4326008)(229853002)(82746002)(38730400002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1156; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_23851B8A-4C64-462F-B5D7-B2BED538F836"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 21:30:30.5892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1156 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] Anycast TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 21:31:19 -0000 --Apple-Mail=_23851B8A-4C64-462F-B5D7-B2BED538F836 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-3-30, at 16:03, William Herrin wrote: > If there's a more appropriate WG to introduce this to, I sure would = appreciate a pointer. Until you submit an ID, which with it carries an obligation to disclose = IPR, I expect you will not be able to engage in a discussion with many. Lars --Apple-Mail=_23851B8A-4C64-462F-B5D7-B2BED538F836 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY3XjzAAoJEFS1wwm/cMFXoNIP/0quvGx2+zx4zfs3nQ2g5IyH I8OxON9U1dWBJh7IYt/cJ+h8ZOObv3gIpEuWXL599VvZ5pAGFndrywHpJnoY5A2l ZnwjufcgiZAyRYcKmhjV6OjslFKM2jvLs4RxGA2m+yfXBIGh02NAjgXnS78tS/Er FSkqR++GQ1xz1Q/S9N8/DeZU7/id0I8NTHuNsvnxxt1e6x3Q6FVSMC/i6KPpYYGG IyMwSwpo9Qeox/AMJPM5A6ENWz/9tCQU/LcAY+Bro378u7TVd16zDhfg1PP7W3DG tKNMBaeG6rvJ8Hgk+zcMFyvQwZzXuKJrt5KciOc+F5fOXavSm7GaXpTbZ2Tm8523 aEKsc0XCBb/QZb71uDNqwUyDhizX5bm0YMUU/8txDV4GwvyvxjlyHx4w6X/t+iM8 Szt5PZoz/hC0O+HZKajX9gpzf3DF+uD/xfKKiJd+JgVWNP2RUmtTibGMU+YpY/yw QAbgMmhlATzvS8wYRQpHMJiD+H8gFWZXoKNr6oc1l2IjLNdrI/lR/398zfByWJm4 hwsbEO32vQOlxWBetdbyM6HxDYWkxLKgXxBzTyrB5oitUlEaf92Rm6k/HAymlpH6 Y+5KuBpzZiW9IvaSgUzFtHu6NsffDtiFnXOSdnushZZOLmu3wU/TR6CsT7mctWxj MUtdESH650t1DKdg93oh =yAGN -----END PGP SIGNATURE----- --Apple-Mail=_23851B8A-4C64-462F-B5D7-B2BED538F836-- From nobody Thu Mar 30 15:17:23 2017 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 ECD48129672 for ; Thu, 30 Mar 2017 15:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fECmMg4gYmef for ; Thu, 30 Mar 2017 15:17:18 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF6C12426E for ; Thu, 30 Mar 2017 15:17:18 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id l7so28977551ioe.3 for ; Thu, 30 Mar 2017 15:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hl6ATgXMPHOtz7ksrTW3Sn8j7usHTyZ+a/eTBDC1pG8=; b=fiiBiuSRw/um+wiYDjZZvB7ynpD+OV81XFyG3C5N0j20gqTUu8LRbU9bJDLKFMvx5v S0NyeBAHrX8x9UyURgCx44yoVSv/XDW9ltdhbxLWQ8gYgCKx468HmNRFavlC2kxGztqH MuxeHRDrOjcbl1NHcpy7/zpk7E04HzZzMrD7mAf4puzHbl00UKWlAX8lWiZvyKRFNdzb vhFvThbktJfe0uFRmbgb3KkhIWPksvEYeFNKry9ZRhgrnGCzef0O02HCotRvjN3Q7Y5v B5CC85JdfVRv8v2wEasXRRTO+hoO0LYByMJL4H/gO/uFIQbKUZAUPXEnhBfEK2sAy78Q dT5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hl6ATgXMPHOtz7ksrTW3Sn8j7usHTyZ+a/eTBDC1pG8=; b=N8jBtNPDiupkGXMy/1+88A/j45PmlRYbpCS7lsHmlcZRxOm0wCAqKyP7n0NXXA414Z SclRhz0CnkEjZWydcMPtl2oqTrXMIo6LgEGAl9Un/Gz169SajKpo8qCpEo5WuoosyvRf 4zOQ+kTLOydfseO4sQoo3YbThLzJ7eEtt05/3DQHezgHVtn4Y1/Z1aV2OinR12GM/pIM lih0OBrumceb/pNhIM3ZEwhrbq3OFXNUnAeerlEAD5hI9OIilXNdHTzakSTp++b7X96/ L/vIVwmTCf9qGpHu+MKVbrSMFlLkniFDkIgMGbIDL/feHahbTW66lLhhj9xlw34IpOE5 nf9w== X-Gm-Message-State: AFeK/H39mebtMD8EeiCynq+nS5IntFZ29uYuI5gymKTmpJoGIDq0xCK5ZiCD30ZGv1d9KLYo+e8dGqtn5kZc3xNV X-Received: by 10.107.164.36 with SMTP id n36mr3253110ioe.103.1490912237981; Thu, 30 Mar 2017 15:17:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.24 with HTTP; Thu, 30 Mar 2017 15:16:37 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Thu, 30 Mar 2017 15:16:37 -0700 Message-ID: To: Michael Welzl Cc: Ingemar Johansson S , tsvwg IETF list , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=001a114220ac567be4054bfa0e23 Archived-At: Subject: Re: [tcpm] [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 22:17:21 -0000 --001a114220ac567be4054bfa0e23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable regarding the question in the slide 5. "Is immediate ACK needed for out of order segments if RACK is used ?" The answer is both yes and no: a timely feedback is appreciated (yes). But RACK does not need 100 DUPACKs each telling one more packet is delivered out of order (no). In other words if the ACK is timely and precise about the delivery process, RACK would work well (so does BBR). However this can go terribly wrong if the middle-box sends only the last ACK/SACK. It has happened in one major cloud platform. On Thu, Mar 30, 2017 at 2:14 PM, Michael Welzl wrote: > Hi, > > Thanks Ingemar for your interesting presentation today: > https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-s > essb-7-transport-protocol-feedback-overhead-issues-and-solutions-00.pdf > > I wanted to share with you, and the list, that David Ros (one of the > original authors of ACK-CC, RFC 5690) and I once advised a master student > to: > - implement ACK-CC > - test it > - analyze all RFC 2119 - style keywords in RFC 5690, to see how they > should be changed (if at all) in a possible update > > Back then, our thinking was that we could write a paper about it, and try > to get this deployed as a way of doing the Experiment and moving this to = PS > status. > However, we were less and less sure about the real value of this - whethe= r > actual networks need this? Then, we had less and less time available and = at > some point dropped the ball. > I of course found it interesting to hear that it *is* a real problem, eve= n > today. > > Anyway: this master thesis is available here: > http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/ > mastersthesis-mariusno.pdf > and I think I can safely say on behalf of David, Marius (the master > student who did this) and myself that we=E2=80=99re happy if someone pick= s this up > and continues the work. > It would require some digging, but I might also still have the code lying > around somewhere - for some outdated version of Linux=E2=80=A6 > > Cheers, > Michael > > --001a114220ac567be4054bfa0e23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
regarding the question in the slide 5.
"Is immedi= ate ACK needed for out of order segments if RACK is used ?"
=
The answer is both yes and no: a timely feedback is apprecia= ted (yes). But RACK does not need 100 DUPACKs each telling one more packet = is delivered out of order (no). In other words if the ACK is timely and pre= cise about the delivery process, RACK would work well (so does BBR). Howeve= r this can go terribly wrong if the middle-box sends only the last ACK/SACK= . It has happened in one major cloud platform.

On = Thu, Mar 30, 2017 at 2:14 PM, Michael Welzl <michawe@ifi.uio.no>= wrote:
Hi,
Thanks Ingemar for your interesting presentation today:

I wanted to share with = you, and the list, that David Ros =C2=A0(one of the original authors of ACK= -CC, RFC 5690) and I once advised a master student to:
- implemen= t ACK-CC
- test it
- analyze all RFC 2119 - style keywo= rds in RFC 5690, to see how they should be changed (if at all) in a possibl= e update

Back then, our thinking was that we could= write a paper about it, and try to get this deployed as a way of doing the= Experiment and moving this to PS status.
However, we were less a= nd less sure about the real value of this - whether actual networks need th= is? Then, we had less and less time available and at some point dropped the= ball.
I of course found it interesting to hear that it *is* a re= al problem, even today.

and I think I can safely say on behalf of David,= Marius (the master student who did this) and myself that we=E2=80=99re hap= py if someone picks this up and continues the work.
It would requ= ire some digging, but I might also still have the code lying around somewhe= re - for some outdated version of Linux=E2=80=A6

C= heers,
Michael


<= /div>
--001a114220ac567be4054bfa0e23-- From nobody Thu Mar 30 20:01:02 2017 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 2A04C126BFD for ; Thu, 30 Mar 2017 20:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 426JeQnvNhAW for ; Thu, 30 Mar 2017 20:00:58 -0700 (PDT) Received: from magic.dirtside.com (magics.dirtside.com [199.33.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id C29B9127B52 for ; Thu, 30 Mar 2017 20:00:57 -0700 (PDT) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id v2V30qld031355 for ; Thu, 30 Mar 2017 23:00:52 -0400 X-Really-To: Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com [74.125.83.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 26B7CEBE56 for ; Thu, 30 Mar 2017 23:00:52 -0400 (EDT) Received: by mail-pg0-f42.google.com with SMTP id 81so57117687pgh.2 for ; Thu, 30 Mar 2017 20:00:52 -0700 (PDT) X-Gm-Message-State: AFeK/H376+Q7owbvesOg6vt2PRmF43m5lvsay/aNVM+EAXaGoY2axEBzoEuXszkQDorbZi7nh/HbagVQTIVv6Q== X-Received: by 10.84.135.34 with SMTP id 31mr784213pli.50.1490929251196; Thu, 30 Mar 2017 20:00:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.12 with HTTP; Thu, 30 Mar 2017 20:00:30 -0700 (PDT) In-Reply-To: References: From: William Herrin Date: Thu, 30 Mar 2017 23:00:30 -0400 X-Gmail-Original-Message-ID: Message-ID: To: David Lang Cc: tcpm@ietf.org Content-Type: multipart/alternative; boundary=94eb2c11ac32672d7a054bfe04ef X-Spam-Checker: magic.dirtside.com Archived-At: Subject: Re: [tcpm] Anycast TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 03:01:01 -0000 --94eb2c11ac32672d7a054bfe04ef Content-Type: text/plain; charset=UTF-8 On Thu, Mar 30, 2017 at 5:28 PM, David Lang wrote: > you should list an optimization flood D, which is has a relationship to C > like B does to A > > no manipulation of sequence numbers, when you get something unknown, send > it to all peers, but a peer can respond and say "I own that connection", > eliminating future floods for that connection. > Hi David, Agreed. I didn't flesh out the flood versions because they all suffer from a trivial attack vector: forged payload packets with randomized source addresses and ports get flooded everywhere. That escalates a DOS against one node into a DOS against all of them. If you see a way to mitigate the problem then I think it'll be worth diving deeper in to the flood approach. > As a further optimization (of B and D), let the peers that you flood to > send a nack, not just an ack, if you get a nack from all peers, you reset > the connection. > For completeness. I agree that would restore an ability to send a rst in the flood case at the cost of briefly holding some discardable state. It may be worth the slowdown to have the "do you own this connection" query > be explicit, not implicit by forwarding the packets. This increases delays > when something needs to be forwarded (at least one more round trip between > the peers), but should greatly simplify the logic needed to communicate the > status. > I don't follow how that would simplify the logic. Would you clarify? One question, if you use the "flood when not a known connection" procedure, > do you still need all the kernel hooks? It seems to me that most of them > could go away if you accepted the potential for a collision if multiple > machines pick the same starting sequence number. > Some of the flood versions need only the RST hook, as noted in Flood C. > On Linux, IPTables already has a hook that can send packets to userspace. > If you have a rule that accepts packets with known connections, and then > follow that with a rule that forwards non-syn packets to the userspace > program, do you still need a hook? Outside a test harness, yes. Conntrack doubles the state information kept for the TCP connections. However, that could be a reasonable shortcut for prototyping and proving out the variants that don't adjust the sequence number. > The conntrack hooks allow you to manipulate the connection tables (so that > you can take over a TCP connection that is on a cluster peer, very similar > to this use case). So it seems to me that you may be able to implement a > PoC of this on existing systems. Good idea. Something like this: sysctl net.netfilter.nf_conntrack_tcp_loose=0 sysctl net.netfilter.nf_conntrack_helper=0 iptables -A INPUT -p tcp --dport 80 -m conntrack \ --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j NFQUEUE --queue-num 0 --queue-bypass And then use libnetfilter_queue to catch the packets in userspace. However, that only simulates the RST hook so could only be used to evaluate the flood versions. Then measure where the bottlenecks are and what the 'miss rate' really is > in the real world > We already have pretty good miss-rate numbers from research that's been done for anycast DNS. I don't have a link handy but the short version is that better than 99% of clients consistently hit the same anycast node. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: --94eb2c11ac32672d7a054bfe04ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 30, 2017 at 5:28 PM, David Lang <david@lang.hm> wrote:
you should list an opti= mization flood D, which is has a relationship to C like B does to A

no manipulation of sequence numbers, when you get something unknown, send i= t to all peers, but a peer can respond and say "I own that connection&= quot;, eliminating future floods for that connection.
=
Hi David,

Agreed. I didn't flesh out t= he flood versions because they all suffer from a trivial attack vector: for= ged payload packets with randomized source addresses and ports get flooded = everywhere. That escalates a DOS against one node into a DOS against all of= them. If you see a way to mitigate the problem then I think it'll be w= orth diving deeper in to the flood approach.

=C2=A0
=
As a further optimization (of B and D), let the peers that you flood to sen= d a nack, not just an ack, if you get a nack from all peers, you reset the = connection.

For completeness. I agree t= hat would restore an ability to send a rst in the flood case at the cost of= briefly holding some discardable state.


It may be worth the slowdown to have the "do you own this connection&q= uot; query be explicit, not implicit by forwarding the packets. This increa= ses delays when something needs to be forwarded (at least one more round tr= ip between the peers), but should greatly simplify the logic needed to comm= unicate the status.

I don't follow = how that would simplify the logic. Would you clarify?
=C2=A0<= br>
One question, if you use the "flood when not a known connection" = procedure, do you still need all the kernel hooks? It seems to me that most= of them could go away if you accepted the potential for a collision if mul= tiple machines pick the same starting sequence number.

Some of the flood versions need only the RST hook, as noted= in Flood C.

=C2=A0
On Linux, IPTables already has a hook that can send packets to userspace. I= f you have a rule that accepts packets with known connections, and then fol= low that with a rule that forwards non-syn packets to the userspace program= , do you still need a hook?

Outside a test= harness, yes. Conntrack doubles the state information kept for the TCP con= nections. However, that could be a reasonable shortcut for prototyping and = proving out the variants that don't adjust the sequence number.
=C2=A0
The c= onntrack hooks allow you to manipulate the connection tables (so that you c= an take over a TCP connection that is on a cluster peer, very similar to th= is use case). So it seems to me that you may be able to implement a PoC of = this on existing systems.

Good idea. Something like th= is:

sysctl net.netfilter.nf_conntrack_tcp_loose=3D0
sysctl net.ne= tfilter.nf_conntrack_helper=3D0
iptables -A INPUT -p tcp --dport 80 -m c= onntrack \
=C2=A0 --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INP= UT -p tcp --dport 80 -j NFQUEUE --queue-num 0 --queue-bypass

An= d then use libnetfilter_queue to catch the packets in userspace.

However, that only simulates the RST hook so could only be used to evalu= ate the flood versions.


Then measure where the bottlenecks are and what the 'm= iss rate' really is in the real world
<= br>
We already have pretty good miss-rate numbers from research t= hat's been done for anycast DNS. I don't have a link handy but the = short version is that better than 99% of clients consistently hit the same = anycast node.

Regards,
Bill Herrin



--
William Herrin ................ herrin@dirtside.com =C2=A0bill@herrin.us
Dirtside Systems ...= ...... Web: <http= ://www.dirtside.com/>
--94eb2c11ac32672d7a054bfe04ef-- From nobody Thu Mar 30 20:02:09 2017 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 B0D2A129705 for ; Thu, 30 Mar 2017 20:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlqO6TnRahl1 for ; Thu, 30 Mar 2017 20:02:06 -0700 (PDT) Received: from magic.dirtside.com (magics.dirtside.com [199.33.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 147DA126BFD for ; Thu, 30 Mar 2017 20:02:05 -0700 (PDT) Received: from minoc.dirtside.com (minoc.dirtside.com [70.184.240.82]) by magic.dirtside.com (8.14.3/) with ESMTP id v2V321Kx031395 for ; Thu, 30 Mar 2017 23:02:01 -0400 X-Really-To: Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 51500EBE56 for ; Thu, 30 Mar 2017 23:02:01 -0400 (EDT) Received: by mail-pg0-f49.google.com with SMTP id g2so56428312pge.3 for ; Thu, 30 Mar 2017 20:02:01 -0700 (PDT) X-Gm-Message-State: AFeK/H3sXrGC8WNFu1P1160xtT+bC1TAlW15rvwWUvJHktZ7qlM/v7QOLLV4DLQL3DhRY8tEHXoFSGKYo9KWGA== X-Received: by 10.98.100.88 with SMTP id y85mr609396pfb.112.1490929320560; Thu, 30 Mar 2017 20:02:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.12 with HTTP; Thu, 30 Mar 2017 20:01:40 -0700 (PDT) In-Reply-To: References: From: William Herrin Date: Thu, 30 Mar 2017 23:01:40 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Eggert, Lars" Cc: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0533a4899714054bfe082d X-Spam-Checker: magic.dirtside.com Archived-At: Subject: Re: [tcpm] Anycast TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 03:02:08 -0000 --94eb2c0533a4899714054bfe082d Content-Type: text/plain; charset=UTF-8 On Thu, Mar 30, 2017 at 5:30 PM, Eggert, Lars wrote: > On 2017-3-30, at 16:03, William Herrin wrote: > > If there's a more appropriate WG to introduce this to, I sure would > appreciate a pointer. > > Until you submit an ID, which with it carries an obligation to disclose > IPR, I expect you will not be able to engage in a discussion with many. > Hi Lars, That would be a discouraging shift from the open flow of ideas the last time I participated in a WG. For the record, while I've integrated constructive criticism from a couple very generous individuals, the design is mine alone. I assert no IP rights though I'd certainly appreciate being invited to join as an author of any IDs that eventually result. To the best of my knowledge, there is no comparable work which would allow another to assert IP rights. Certainly I did not find any when I searched. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: --94eb2c0533a4899714054bfe082d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 30, 2017 at 5:30 PM, Eggert, Lars <lars@netapp.com> wr= ote:
On 2017-3-30, at 16:03, Willia= m Herrin <bill@herri= n.us> wrote:
> If there's a more appropriate WG to introduce this to, I sure woul= d appreciate a pointer.

Until you submit an ID, which with it carries an obligation to discl= ose IPR, I expect you will not be able to engage in a discussion with many.=

Hi Lars,

That would = be a discouraging shift from the open flow of ideas the last time I partici= pated in a WG.

For the record, while I've integrated = constructive criticism from a couple very generous individuals, the design = is mine alone. I assert no IP rights though I'd certainly appreciate be= ing invited to join as an author of any IDs that eventually result. To the = best of my knowledge, there is no comparable work which would allow another= to assert IP rights. Certainly I did not find any when I searched.

=
Regards,
Bill Herrin


--
William Herrin ................ herrin@dirtside.com =C2=A0bill@herrin.us
Dir= tside Systems ......... Web: <http://www.dirtside.com/>
--94eb2c0533a4899714054bfe082d-- From nobody Thu Mar 30 20:09:05 2017 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 F0162126BFD; Thu, 30 Mar 2017 20:09:03 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8oPguv57VSa; Thu, 30 Mar 2017 20:09:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384E2127333; Thu, 30 Mar 2017 20:08:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJZ75589; Fri, 31 Mar 2017 03:08:55 +0000 (GMT) Received: from DGGEMA403-HUB.china.huawei.com (10.3.20.44) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 31 Mar 2017 04:08:54 +0100 Received: from DGGEMA501-MBX.china.huawei.com ([169.254.1.85]) by DGGEMA403-HUB.china.huawei.com ([10.3.20.44]) with mapi id 14.03.0301.000; Fri, 31 Mar 2017 11:08:49 +0800 From: "Gengxuesong (Geng Xuesong)" To: Carles Gomez Montenegro CC: "tcpm@ietf.org" , "draft-ietf-core-cocoa@ietf.org" Thread-Topic: [tcpm] RFC 793 (bis) vs. rto-consider Thread-Index: AdKowj/uHBlAvttmR5O5bK3orMhOogAGjLkAAArFUAAAFEdqgAAcvmsA Date: Fri, 31 Mar 2017 03:08:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58DDC848.0097, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.85, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 77698b326be2596d5a76fe651cd88bda Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 03:09:04 -0000 U28gQ2FybGVzLA0KDQpJbiBtYW55IElPVCBzY2VuYXJpb3MsIGl0IGlzIGEgIm11c3QiIHRvIG1l YXN1cmUgUlRUICJmcmVxdWVudGx5IiwgZXZlbiBtb3JlIGZyZXF1ZW50IHRoYW4gb3RoZXIgc2Nl bmFyaW9zLg0KRG8gSSBnZXQgaXQgcmlnaHQ/DQoNClRoYW5rcywNCg0KRW1tYSAoWHVlc29uZykN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRjcG0gW21haWx0bzp0Y3BtLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJsZXMgR29tZXogTW9udGVuZWdybw0KU2Vu dDogRnJpZGF5LCBNYXJjaCAzMSwgMjAxNyA1OjIyIEFNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChO b2tpYSAtIERFL1N0dXR0Z2FydCkNCkNjOiB0Y3BtQGlldGYub3JnOyBkcmFmdC1pZXRmLWNvcmUt Y29jb2FAaWV0Zi5vcmc7IEpvZSBUb3VjaA0KU3ViamVjdDogUmU6IFt0Y3BtXSBSRkMgNzkzIChi aXMpIHZzLiBydG8tY29uc2lkZXINCg0KSGksDQoNCihDQydpbmcgdGhlIGF1dGhvcnMgb2YgQ29D b0EgWzFdLi4uKQ0KDQpIb3Bpbmcgbm90IHRvIGRldmlhdGUgdG9vIG11Y2ggZnJvbSB0aGUgbWFp biB0b3BpYywgSSBqdXN0IHdhbnRlZCB0byBleHBsYWluIHRoYXQgaW4gb3VyIHdvcmsgd2l0aCBD b0NvQSAod2hpY2ggaXMgdXNlZCBmb3IgQ29BUCBvdmVyIFVEUCksIHdlIGVuY291bnRlcmVkIGlz c3VlcyBpbiBJb1QgZXhwZXJpbWVudGFsIHRlc3RiZWRzIHN1Y2ggYXMgdGhvc2UgZGVzY3JpYmVk IGJ5IE1pY2hhZWwuDQoNClJUVCBtYXkgZXhwZXJpZW5jZSBoaWdoIHZhcmlhbmNlIGluIGRpZmZl cmVudCB0eXBlcyBvZiAidHlwaWNhbCIgSW9UIHNjZW5hcmlvcy4gV2lyZWxlc3MgbGlua3MgdXNl ZCBpbiBJb1QgYXJlIHR5cGljYWxseSBlcnJvci1wcm9uZSAoZHVlIHRvIHJhZGlvIGltcGFpcm1l bnRzIHN1Y2ggYXMgbXVsdGlwYXRoIGZhZGluZywgaW50ZXJmZXJlbmNlLCBldGMuKSB3aGljaCBt YXkgbGVhZCB0byBsaW5rIGxheWVyIHJldHJpZXMgdGhhdCBpbmNyZWFzZSB0aGUgUlRULiBFdmVu IHdpcmVkIGxpbmtzIGluIElvVCwgc3VjaCBhcyBQb3dlciBMaW5lIENvbW11bmljYXRpb24gb25l cywgb2ZmZXIgc2ltaWxhciBwZXJmb3JtYW5jZSAoZm9yIGRpZmZlcmVudCByZWFzb25zKS4NCg0K SW4gbWVzaCBuZXR3b3Jrcywgd2hpY2ggYXJlIGNvbW1vbiBpbiBJb1QsIFJUVCB2YXJpYWJpbGl0 eSBpbmNyZWFzZXMuDQoNCkZ1cnRoZXJtb3JlLCBzb21lIHRyYWZmaWMgcGF0dGVybnMgaW4gSW9U IG1heSBjb21wbGljYXRlIHRoZSBzY2VuYXJpby4gDQpRdWl0ZSBvZnRlbiwgcGFja2V0IHRyYW5z bWlzc2lvbiBpcyByZWxhdGl2ZWx5IGluZnJlcXVlbnQuIEhvd2V2ZXIsIHNldmVyYWwgc2Vuc29y cyBtYXkgc2ltdWx0YW5lb3VzbHkgZGV0ZWN0IHNvbWUgZ2xvYmFsIGV2ZW50IHdoaWNoIG5lZWRz IHRvIGJlIGNvbW11bmljYXRlZCwgYW5kIGEgYnVyc3Qgb2YgbWVzc2FnZXMgd2lsbCB0YWtlIHBs YWNlIGFzIGEgcmVzdWx0IChpbmNyZWFzaW5nIG5ldHdvcmsgbG9hZCBkdXJpbmcgdGhhdCBpbnRl cnZhbCkuDQoNCkZvciB0aGVzZSByZWFzb25zLCBpbiBDb0NvQSB3ZSBoYXZlIGFuICJhZ2luZyIg bWVjaGFuaXNtIGZvciBSVE8gZXN0aW1hdGVzIHRoYXQgaGF2ZSBub3QgYmVlbiB1cGRhdGVkIGZv ciBhIHdoaWxlLg0KDQooV2UgZXZlbiBoYXZlIGEgJ3dlYWsnIGVzdGltYXRvciBpbiBhZGRpdGlv biB0byBhICdzdHJvbmcnIGVzdGltYXRvciwgd2hpY2ggbWF5IGFjdHVhbGx5IGhlbHAgaW1wcm92 aW5nIHRoZSBzb21ldGltZXMgbGltaXRlZCBrbm93bGVkZ2UgdGhhdCBhICdzdHJvbmcnIGVzdGlt YXRvciBtYXkgb2J0YWluLikNCg0KVGhhbmtzLA0KDQpDYXJsZXMNCg0KWzFdIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29jb2EtMDENCg0KDQo+IFNpbmNlIHRo ZSBjb250ZXh0IGlzIGEgc21hbGwgZm9vdHByaW50IGRldmljZSAoSW9UIGFuZCB0aGUgbGlrZcOi 4oKswqYpOiANCj4gV2hhdCBoYXBwZW5zIGlmIHRoZSBkZXZpY2UgaGFzIGEgcmVsYXRpdmVseSBz aW1wbHkgVENQIHN0YWNrIChubyANCj4gU0FDS8Oi4oKswqYpIGFuZCBydW5zIG9uIGEgbG93LWJh bmR3aWR0aCBzaGFyZWQgbWVkaXVtIGNoYW5uZWwgKHdpcmVsZXNzKSANCj4gdGhhdCBoYXMgaGln aGx5IHZhcmlhYmxlIFJUVD8NCj4NCj4gSWYgaXQgbWVhc3VyZXMgdGhlIFJUVCBvbmNlICh0byBy ZWR1Y2UgY29tcGxleGl0eSkgYW5kIGlmIHRoYXQgc2FtcGxlIA0KPiBoYXBwZW5zIHRvIGJlIHdh eSBiZWxvdyB0aGUgYXZlcmFnZSBSVFQsIGl0IGNhbiBydW4gcmVwZWF0ZWRseSBpbnRvIA0KPiBz cHVyaW91cyB0aW1lb3V0cywgbm8/IFRoZW4gdGhlIGV4cG9uZW50aWFsIGJhY2tvZmYgYW5kIGNv bmdlc3Rpb24gDQo+IGNvbnRyb2wga2lja3MgaW4sIGJ1dCBpZiB0aGVyZSBhcmUgbWFueSBvZiB0 aGVzZSBkZXZpY2VzIChzZW5zb3Jzw6LigqzCpikgDQo+IG9uIHRoZSBtZWRpdW0sIHRyYW5zbWl0 dGluZyBldmVyeSBtZXNzYWdlIG11bHRpcGxlIHRpbWVzIGNvdWxkIGJlIGhhemFyZG91cywgbm8/ DQo+DQo+IEkgdGhpbmsgaXQgY29tZXMgZG93biB0byB0aGUgcXVlc3Rpb24gaWYgbWVhc3VyaW5n IHRoZSBSVFQgbW9yZSB0aGFuIA0KPiBvbmNlIGR1cmluZyBhIGNvbm5lY3Rpb24gaXMgbmVlZGVk IGZvciBjb25nZXN0aW9uIGNvbnRyb2wgcHVycG9zZXMsIG9yIG5vdC4NCj4NCj4gU2luY2UgdGhl cmUgaGFzIGFsd2F5cyBiZWVuIHRoZSDDouKCrMWTbXVzdMOi4oKswp0gd29yZGluZyBpbiBSRkMg NzkzIChhbmQgaXQgDQo+IGhhcyBiZWVuIGEgTVVTVCBpbiBydG8tY29uc2lkZXIgaW4gbWFueSBy ZXZpc2lvbnMgYXMgd2VsbCksIEkgYW0gbm90IA0KPiBzdXJlIGlmIHdlIGNhbiBkb3duZ3JhZGUg dGhpcyBub3cgdG8gU0hPVUxELCBlLmcuLCB3aXRob3V0IGV4cGVyaW1lbnRhbCBkYXRhLg0KPg0K PiBJIHRoaW5rIGl0IGlzIHNvbWVob3cgaW5oZXJlbnRseSBub24tdHJpdmlhbCB0byBmb3JtYWxs eSBhcHBseSAyMTE5IA0KPiBsYW5ndWFnZSB3aGVuIHRoZSBzdGF0ZW1lbnQgaXMgbm90IHJlYWxs eSBhYm91dCBwcm90b2NvbCBjb3JyZWN0bmVzcyANCj4gYW5kIGludGVyb3BlcmFiaWxpdHkuDQo+ DQo+IE1pY2hhZWwNCj4NCj4gRnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0N Cj4gU2VudDogRG9ubmVyc3RhZywgMzAuIE3Dg8KkcnogMjAxNyAwODozMw0KPiBUbzogU2NoYXJm LCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNv bT4NCj4gQ2M6IHRjcG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0Y3BtXSBSRkMgNzkzIChi aXMpIHZzLiBydG8tY29uc2lkZXINCj4NCj4NCj4NCj4gT24gTWFyIDI5LCAyMDE3LCBhdCAxMjo0 NCBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgDQo+IDxtaWNoYWVs LnNjaGFyZkBub2tpYS5jb208bWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4+IHdyb3Rl Og0KPiBTbywgSSB3b25kZXIgaWYgdGhlcmUgY291bGQgYmUgYSByZWFzb25pbmcgZm9yIGFwcGx5 aW5nIHRoZXNlIHR3byANCj4gU0hPVUxEIHRvIFRDUD8gTW9zdCBub3RhYmx5LCBjb3VsZCB0aGVy ZSBiZSBhbnkgcmVhc29uIHdoeSBhIFRDUCANCj4gaW1wbGVtZW50YXRpb24gd291bGQgbm90IG1l YXN1cmUgUlRUIMOi4oKsxZNyZWd1bGFybHnDouKCrMKdPw0KPg0KPiBPdmVyaGVhZCBhbmQgY29t cGxleGl0eSBmb3Igc21hbGwgZm9vdHByaW50IGRldmljZXMuIElNTyBTSE9VTEQgaXMgDQo+IHN1 ZmZpY2llbnQuIE1VU1QgbmVlZHMgdG8gYmUgcmVzZXJ2ZWQgZm9yIHByb3RvY29sIGNvcnJlY3Ru ZXNzIG9yIA0KPiBiZWhhdmlvciB0cnVseSBoYXphcmRvdXMgdG8gb3RoZXJzLg0KPg0KPiBKb2UN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNw bSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0K From nobody Thu Mar 30 21:30:51 2017 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 0B3B712949F for ; Thu, 30 Mar 2017 21:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhf8pK3Psp8j for ; Thu, 30 Mar 2017 21:30:45 -0700 (PDT) Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B04212949A for ; Thu, 30 Mar 2017 21:30:45 -0700 (PDT) Received: from dlang-laptop ([10.2.0.162]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id v2V4URTd030008; Thu, 30 Mar 2017 20:30:32 -0800 Date: Thu, 30 Mar 2017 21:30:27 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: William Herrin cc: tcpm@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [tcpm] Anycast TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 04:30:48 -0000 On Thu, 30 Mar 2017, William Herrin wrote: > On Thu, Mar 30, 2017 at 5:28 PM, David Lang wrote: > >> you should list an optimization flood D, which is has a relationship to C >> like B does to A >> >> no manipulation of sequence numbers, when you get something unknown, send >> it to all peers, but a peer can respond and say "I own that connection", >> eliminating future floods for that connection. >> > > Hi David, > > Agreed. I didn't flesh out the flood versions because they all suffer from > a trivial attack vector: forged payload packets with randomized source > addresses and ports get flooded everywhere. That escalates a DOS against > one node into a DOS against all of them. If you see a way to mitigate the > problem then I think it'll be worth diving deeper in to the flood approach. I think that the nack capability is a significant limit in the damage a flood can do (since the nacks will quickly shutdown the multiplication) > > >> As a further optimization (of B and D), let the peers that you flood to >> send a nack, not just an ack, if you get a nack from all peers, you reset >> the connection. >> > > For completeness. I agree that would restore an ability to send a rst in > the flood case at the cost of briefly holding some discardable state. > > > It may be worth the slowdown to have the "do you own this connection" query >> be explicit, not implicit by forwarding the packets. This increases delays >> when something needs to be forwarded (at least one more round trip between >> the peers), but should greatly simplify the logic needed to communicate the >> status. >> > > I don't follow how that would simplify the logic. Would you clarify? In your example, you were talking about sending the traffic out through tunnels to the nodes, and they would have to watch the traffic in the tunnel to detect that something new was showing up and send an ack. If instead the node receiving the unknown traffic has an 'out of band' request to the other nodes "do you have connection X" with an explicit ack/nack, the other nodes don't have to watch the gre tunnel and decide if they need to send an ack based on that. this involves a round-trip to the other nodes, but you are only sending the connection info (which can be packed many to a packet) and you don't send the actual payload packets out unless you get an ack back from someone. This would also cut down on the dos multiplication factor as each malicious datastream isn't replicated in full, only it only generates a small chunk of traffic to the other nodes. It wouldn't completely eliminate the vulnerability, but it would greatly reduce it. > > One question, if you use the "flood when not a known connection" procedure, >> do you still need all the kernel hooks? It seems to me that most of them >> could go away if you accepted the potential for a collision if multiple >> machines pick the same starting sequence number. >> > > Some of the flood versions need only the RST hook, as noted in Flood C. if you can create a raw IP packet, can't you create one that is a rst for a particular connection? >> On Linux, IPTables already has a hook that can send packets to userspace. >> If you have a rule that accepts packets with known connections, and then >> follow that with a rule that forwards non-syn packets to the userspace >> program, do you still need a hook? > > > Outside a test harness, yes. Conntrack doubles the state information kept > for the TCP connections. However, that could be a reasonable shortcut for > prototyping and proving out the variants that don't adjust the sequence > number. > > >> The conntrack hooks allow you to manipulate the connection tables (so that >> you can take over a TCP connection that is on a cluster peer, very similar >> to this use case). So it seems to me that you may be able to implement a >> PoC of this on existing systems. > > > Good idea. Something like this: > > sysctl net.netfilter.nf_conntrack_tcp_loose=0 > sysctl net.netfilter.nf_conntrack_helper=0 > iptables -A INPUT -p tcp --dport 80 -m conntrack \ > --ctstate NEW,ESTABLISHED -j ACCEPT > iptables -A INPUT -p tcp --dport 80 -j NFQUEUE --queue-num 0 --queue-bypass > > And then use libnetfilter_queue to catch the packets in userspace. > > However, that only simulates the RST hook so could only be used to evaluate > the flood versions. true, but that may be enough to show the value of the concept and evaluate if the flood versions can be tamed enough to be useful. along similar lines, I'll point out multicast-mac (in linux, it's known as CLUSTERIP) that lets you put a number of boxes in one place with the same IP address and have each of them handle a subset of the traffic (the nic still sees the full load on each machine, but userspace only sees a subset. so you have big_pipe -> switch (multiple ->) server nic -> clusterip (traffic reduced to 1/servers at location) -> conntrack -> new/established (normal userspace handling) netfilter -> userspace, check nak list -> if on nak list, reset else send query to peers -> if ack, send data to peer through gre else add to nak list reset connection It may be possible to do some trickery with conntrack to have the kernel send the naks (thinking out loud, if you set the conntrack state for the connection to fin, will it send the nak for you before the iptables new/established check?) I don't like ideas that require any flags get set on packets that end up going to clients. Good firewalls block unknown flags (as we saw when ecn was introduced), so keeping all the tweaks local to the networks where the anycast servers are is a far better option. David Lang From nobody Fri Mar 31 08:02:38 2017 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 9E8F61296B2; Fri, 31 Mar 2017 08:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 1r-AqHMzYYA9; Fri, 31 Mar 2017 08:02:34 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0133.outbound.protection.outlook.com [104.47.2.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E9A1294D4; Fri, 31 Mar 2017 08:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uKc2zFFNwDcVMo/TFEhxOaS7AYm8zl5rVObf0cNEk6Y=; b=lgG53aeHnzGVcUGH929y0fQ/Rm+gwbvorq2EBPIwTd0XTNszUTgPAZyNQF0GPBr/zt87627u1M5fdBO35hIt1iweVxZarAz0UTRuXmsmxs8KB8+mn+SXAN3qi6jFjXpWcR5jBHI1vUjlepJJXsHOnb5HcGv6/bENyiwXqO8BkKE= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2545.eurprd07.prod.outlook.com (10.173.92.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 15:02:30 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1005.015; Fri, 31 Mar 2017 15:02:30 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "Gengxuesong (Geng Xuesong)" , "Carles Gomez Montenegro" CC: "tcpm@ietf.org" , "draft-ietf-core-cocoa@ietf.org" Thread-Topic: [tcpm] RFC 793 (bis) vs. rto-consider Thread-Index: AdKowj/uHBlAvttmR5O5bK3orMhOogAXUEIAAAnLLSAAFUGNgAAMGoyAABgCz+A= Date: Fri, 31 Mar 2017 15:02:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [31.133.141.145] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2545; 7:XBpYDADZNEb4kIMKTnOB0DmP1NYZJyA4c2b2VvQiAby9tl62a49zvmIgWSKcIG07y6PNWgDelXUNUraVUNnr7Uo//kBRPdH07UToaXRxBYogibOKe+bcistr6WBlFpArrC8MsNBTDw6s0X5ql0z3n0Ol8glXp4frTtMPZ6GyVLcGQEuq9yJR7GdRzs6f0IK9pCkhMNYOkDWtUBPx4C+tZrDK3ZXf8XsPuvN1yX1W5bLhZK2TnmyaRaHthg/KMAPVN6KZYk0/wRMcLNKxAsWNl6SmWaC9JtjhuRihhfdC626IVQulwgrqGZM0+nJytAnJOtTXba1kHWKgdw4NByUAWw== x-ms-office365-filtering-correlation-id: d83c2602-b571-4a03-55f1-08d47846f45a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2545; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(6072148); SRVR:AM5PR0701MB2545; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2545; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39410400002)(39850400002)(39400400002)(39450400003)(51694002)(54094003)(24454002)(13464003)(377454003)(54906002)(2950100002)(6306002)(86362001)(9686003)(122556002)(3280700002)(25786009)(7696004)(2906002)(77096006)(53936002)(6436002)(6506006)(53546009)(38730400002)(99286003)(4326008)(55016002)(2171002)(2900100001)(6246003)(6116002)(3846002)(8936002)(189998001)(3660700001)(8676002)(54356999)(76176999)(81166006)(93886004)(305945005)(50986999)(33656002)(66066001)(102836003)(5660300001)(74316002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2545; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 15:02:30.6435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2545 Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 15:02:36 -0000 Rm9yIHdoYXQgaXQgaXMgd29ydGgsIEkgaGF2ZSBkb3VidHMgdGhhdCBpbiBJb1QgYW4gUlRUIG1l YXN1cmVtZW50IGhhcyB0byBiZSBwZXJmb3JtZWQgKm1vcmUqIGZyZXF1ZW50bHkgdGhhbiBtYW5k YXRlZCBieSB0aGUgVENQIHN0YW5kYXJkcywgd2hpY2ggcmVxdWlyZSBhIG1lYXN1cmVtZW50IHJv dWdobHkgb25jZSBwZXIgUlRULiBCdXQgSSBoYXZlIG5vIGRhdGEgZm9yIHRoaXMuDQoNCkhvd2V2 ZXIsIHRoZSBkaXNjdXNzaW9uIGlzIHdoZXRoZXIgdGhlcmUgY291bGQgYmUgYSByZWFzb25hYmxl IHVzZSBjYXNlIGZvciBtZWFzdXJpbmcgdGhlIFJUVCAqbGVzcyogZnJlcXVlbnRseS4gRXhhbXBs ZXMgZm9yICpsZXNzKiB3b3VsZCBiZSB0byBzYW1wbGUgb25jZS1wZXItY29ubmVjdGlvbiwgb25j ZSBwZXIgbWludXRlLCBvbmNlIHBlciBob3VyLCBldGMuIEkgaGF2ZSBzb21lIGRvdWJ0cyB3aGV0 aGVyIHN1Y2ggYSBsb3cgZnJlcXVlbmN5IHdvdWxkIGJlIHJvYnVzdCBpbiB0aGUgSW50ZXJuZXQs IGFuZCBJIHNwZWN1bGF0ZSB0aGF0IHRoaXMgdmlvbGF0aW9uIG9mIHRoZSBUQ1Agc3RhbmRhcmRz IG1pZ2h0IG5vdCB3b3JrIHdlbGwgaW4gY2VydGFpbiBJb1Qgc2NlbmFyaW9zLiBJIGFsc28gZG91 YnQgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIHRoaXMgZXZlbiBvbiBsb3ctZW5kIFRDUCBzdGFj a3MsIHNpbmNlIFJUVCBtZWFzdXJlbWVudCBtb3N0bHkgY29tZXMgZm9yIGZyZWUgaW4gVENQLiBO b3RlIHRoYXQgZm9yIFVEUCBwcm90b2NvbHMgUlRUIG1lYXN1cmVtZW50cyBjYW4gYmUgbW9yZSBj aGFsbGVuZ2luZyBkZXBlbmRpbmcgb24gdGhlIHByb3RvY29sIGRlc2lnbi4NCg0KVGhlIGlzc3Vl IGlzIHRoYXQgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgSS1EIHJ0by1jb25zaWRlciBhbGxv d3MgYSBsb3dlciBmcmVxdWVuY3kgZHVlIHRvIHRoZSB1c2Ugb2YgdGhlIFNIT1VMRC4gQW5kIHRo aXMgaXMgZGlmZmVyZW50IHRvIG15IHJlYWRpbmcgb2YgUkZDIDc5MyBhbmQgdGhlIHN0YW5kYXJk cy10cmFjayBzcGVjaWZpY2F0aW9uIG9mIFRDUCwgaS5lLiwgaXQgaXMgbm90IGNvbnNpc3RlbnQg d2l0aCB0aGUgVENQIHN0YW5kYXJkcy4gSSBhZG1pdCB0aGF0IHRoaXMgaXMgc29ydCBvZiB0aGUg YnVyZWF1Y3JhdGljIGRpc2N1c3Npb24gYnV0IGl0IG1hdHRlcnMgc3BlY2lmaWNhbGx5IHNpbmNl IHdlIGhhdmUgd29yZGluZyBvbiB0aGlzIGluIDc5M2JpcyBhcyB3ZWxsLg0KDQpNaWNoYWVsDQoN Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRjcG0gW21haWx0bzp0 Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHZW5neHVlc29uZw0KPiAoR2VuZyBY dWVzb25nKQ0KPiBTZW50OiBGcmVpdGFnLCAzMS4gTcOkcnogMjAxNyAwNTowOQ0KPiBUbzogQ2Fy bGVzIEdvbWV6IE1vbnRlbmVncm8gPGNhcmxlc2dvQGVudGVsLnVwYy5lZHU+DQo+IENjOiB0Y3Bt QGlldGYub3JnOyBkcmFmdC1pZXRmLWNvcmUtY29jb2FAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFt0Y3BtXSBSRkMgNzkzIChiaXMpIHZzLiBydG8tY29uc2lkZXINCj4gDQo+IFNvIENhcmxlcywN Cj4gDQo+IEluIG1hbnkgSU9UIHNjZW5hcmlvcywgaXQgaXMgYSAibXVzdCIgdG8gbWVhc3VyZSBS VFQgImZyZXF1ZW50bHkiLCBldmVuIG1vcmUNCj4gZnJlcXVlbnQgdGhhbiBvdGhlciBzY2VuYXJp b3MuDQo+IERvIEkgZ2V0IGl0IHJpZ2h0Pw0KPiANCj4gVGhhbmtzLA0KPiANCj4gRW1tYSAoWHVl c29uZykNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRjcG0gW21h aWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJsZXMgR29tZXoNCj4g TW9udGVuZWdybw0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDMxLCAyMDE3IDU6MjIgQU0NCj4gVG86 IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpDQo+IENjOiB0Y3BtQGlldGYu b3JnOyBkcmFmdC1pZXRmLWNvcmUtY29jb2FAaWV0Zi5vcmc7IEpvZSBUb3VjaA0KPiBTdWJqZWN0 OiBSZTogW3RjcG1dIFJGQyA3OTMgKGJpcykgdnMuIHJ0by1jb25zaWRlcg0KPiANCj4gSGksDQo+ IA0KPiAoQ0MnaW5nIHRoZSBhdXRob3JzIG9mIENvQ29BIFsxXS4uLikNCj4gDQo+IEhvcGluZyBu b3QgdG8gZGV2aWF0ZSB0b28gbXVjaCBmcm9tIHRoZSBtYWluIHRvcGljLCBJIGp1c3Qgd2FudGVk IHRvIGV4cGxhaW4NCj4gdGhhdCBpbiBvdXIgd29yayB3aXRoIENvQ29BICh3aGljaCBpcyB1c2Vk IGZvciBDb0FQIG92ZXIgVURQKSwgd2UNCj4gZW5jb3VudGVyZWQgaXNzdWVzIGluIElvVCBleHBl cmltZW50YWwgdGVzdGJlZHMgc3VjaCBhcyB0aG9zZSBkZXNjcmliZWQgYnkNCj4gTWljaGFlbC4N Cj4gDQo+IFJUVCBtYXkgZXhwZXJpZW5jZSBoaWdoIHZhcmlhbmNlIGluIGRpZmZlcmVudCB0eXBl cyBvZiAidHlwaWNhbCIgSW9UDQo+IHNjZW5hcmlvcy4gV2lyZWxlc3MgbGlua3MgdXNlZCBpbiBJ b1QgYXJlIHR5cGljYWxseSBlcnJvci1wcm9uZSAoZHVlIHRvIHJhZGlvDQo+IGltcGFpcm1lbnRz IHN1Y2ggYXMgbXVsdGlwYXRoIGZhZGluZywgaW50ZXJmZXJlbmNlLCBldGMuKSB3aGljaCBtYXkg bGVhZCB0bw0KPiBsaW5rIGxheWVyIHJldHJpZXMgdGhhdCBpbmNyZWFzZSB0aGUgUlRULiBFdmVu IHdpcmVkIGxpbmtzIGluIElvVCwgc3VjaCBhcyBQb3dlcg0KPiBMaW5lIENvbW11bmljYXRpb24g b25lcywgb2ZmZXIgc2ltaWxhciBwZXJmb3JtYW5jZSAoZm9yIGRpZmZlcmVudCByZWFzb25zKS4N Cj4gDQo+IEluIG1lc2ggbmV0d29ya3MsIHdoaWNoIGFyZSBjb21tb24gaW4gSW9ULCBSVFQgdmFy aWFiaWxpdHkgaW5jcmVhc2VzLg0KPiANCj4gRnVydGhlcm1vcmUsIHNvbWUgdHJhZmZpYyBwYXR0 ZXJucyBpbiBJb1QgbWF5IGNvbXBsaWNhdGUgdGhlIHNjZW5hcmlvLg0KPiBRdWl0ZSBvZnRlbiwg cGFja2V0IHRyYW5zbWlzc2lvbiBpcyByZWxhdGl2ZWx5IGluZnJlcXVlbnQuIEhvd2V2ZXIsIHNl dmVyYWwNCj4gc2Vuc29ycyBtYXkgc2ltdWx0YW5lb3VzbHkgZGV0ZWN0IHNvbWUgZ2xvYmFsIGV2 ZW50IHdoaWNoIG5lZWRzIHRvIGJlDQo+IGNvbW11bmljYXRlZCwgYW5kIGEgYnVyc3Qgb2YgbWVz c2FnZXMgd2lsbCB0YWtlIHBsYWNlIGFzIGEgcmVzdWx0IChpbmNyZWFzaW5nDQo+IG5ldHdvcmsg bG9hZCBkdXJpbmcgdGhhdCBpbnRlcnZhbCkuDQo+IA0KPiBGb3IgdGhlc2UgcmVhc29ucywgaW4g Q29Db0Egd2UgaGF2ZSBhbiAiYWdpbmciIG1lY2hhbmlzbSBmb3IgUlRPDQo+IGVzdGltYXRlcyB0 aGF0IGhhdmUgbm90IGJlZW4gdXBkYXRlZCBmb3IgYSB3aGlsZS4NCj4gDQo+IChXZSBldmVuIGhh dmUgYSAnd2VhaycgZXN0aW1hdG9yIGluIGFkZGl0aW9uIHRvIGEgJ3N0cm9uZycgZXN0aW1hdG9y LCB3aGljaA0KPiBtYXkgYWN0dWFsbHkgaGVscCBpbXByb3ZpbmcgdGhlIHNvbWV0aW1lcyBsaW1p dGVkIGtub3dsZWRnZSB0aGF0IGEgJ3N0cm9uZycNCj4gZXN0aW1hdG9yIG1heSBvYnRhaW4uKQ0K PiANCj4gVGhhbmtzLA0KPiANCj4gQ2FybGVzDQo+IA0KPiBbMV0gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2NvYS0wMQ0KPiANCj4gDQo+ID4gU2luY2UgdGhl IGNvbnRleHQgaXMgYSBzbWFsbCBmb290cHJpbnQgZGV2aWNlIChJb1QgYW5kIHRoZSBsaWtlw6Li gqzCpik6DQo+ID4gV2hhdCBoYXBwZW5zIGlmIHRoZSBkZXZpY2UgaGFzIGEgcmVsYXRpdmVseSBz aW1wbHkgVENQIHN0YWNrIChubw0KPiA+IFNBQ0vDouKCrMKmKSBhbmQgcnVucyBvbiBhIGxvdy1i YW5kd2lkdGggc2hhcmVkIG1lZGl1bSBjaGFubmVsICh3aXJlbGVzcykNCj4gPiB0aGF0IGhhcyBo aWdobHkgdmFyaWFibGUgUlRUPw0KPiA+DQo+ID4gSWYgaXQgbWVhc3VyZXMgdGhlIFJUVCBvbmNl ICh0byByZWR1Y2UgY29tcGxleGl0eSkgYW5kIGlmIHRoYXQgc2FtcGxlDQo+ID4gaGFwcGVucyB0 byBiZSB3YXkgYmVsb3cgdGhlIGF2ZXJhZ2UgUlRULCBpdCBjYW4gcnVuIHJlcGVhdGVkbHkgaW50 bw0KPiA+IHNwdXJpb3VzIHRpbWVvdXRzLCBubz8gVGhlbiB0aGUgZXhwb25lbnRpYWwgYmFja29m ZiBhbmQgY29uZ2VzdGlvbg0KPiA+IGNvbnRyb2wga2lja3MgaW4sIGJ1dCBpZiB0aGVyZSBhcmUg bWFueSBvZiB0aGVzZSBkZXZpY2VzIChzZW5zb3Jzw6LigqzCpikNCj4gPiBvbiB0aGUgbWVkaXVt LCB0cmFuc21pdHRpbmcgZXZlcnkgbWVzc2FnZSBtdWx0aXBsZSB0aW1lcyBjb3VsZCBiZQ0KPiBo YXphcmRvdXMsIG5vPw0KPiA+DQo+ID4gSSB0aGluayBpdCBjb21lcyBkb3duIHRvIHRoZSBxdWVz dGlvbiBpZiBtZWFzdXJpbmcgdGhlIFJUVCBtb3JlIHRoYW4NCj4gPiBvbmNlIGR1cmluZyBhIGNv bm5lY3Rpb24gaXMgbmVlZGVkIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgcHVycG9zZXMsIG9yDQo+ IG5vdC4NCj4gPg0KPiA+IFNpbmNlIHRoZXJlIGhhcyBhbHdheXMgYmVlbiB0aGUgw6LigqzFk211 c3TDouKCrMKdIHdvcmRpbmcgaW4gUkZDIDc5MyAoYW5kIGl0DQo+ID4gaGFzIGJlZW4gYSBNVVNU IGluIHJ0by1jb25zaWRlciBpbiBtYW55IHJldmlzaW9ucyBhcyB3ZWxsKSwgSSBhbSBub3QNCj4g PiBzdXJlIGlmIHdlIGNhbiBkb3duZ3JhZGUgdGhpcyBub3cgdG8gU0hPVUxELCBlLmcuLCB3aXRo b3V0IGV4cGVyaW1lbnRhbA0KPiBkYXRhLg0KPiA+DQo+ID4gSSB0aGluayBpdCBpcyBzb21laG93 IGluaGVyZW50bHkgbm9uLXRyaXZpYWwgdG8gZm9ybWFsbHkgYXBwbHkgMjExOQ0KPiA+IGxhbmd1 YWdlIHdoZW4gdGhlIHN0YXRlbWVudCBpcyBub3QgcmVhbGx5IGFib3V0IHByb3RvY29sIGNvcnJl Y3RuZXNzDQo+ID4gYW5kIGludGVyb3BlcmFiaWxpdHkuDQo+ID4NCj4gPiBNaWNoYWVsDQo+ID4N Cj4gPiBGcm9tOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiA+IFNlbnQ6IERv bm5lcnN0YWcsIDMwLiBNw4PCpHJ6IDIwMTcgMDg6MzMNCj4gPiBUbzogU2NoYXJmLCBNaWNoYWVs IChOb2tpYSAtIERFL1N0dXR0Z2FydCkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4NCj4gPiBD YzogdGNwbUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbdGNwbV0gUkZDIDc5MyAoYmlzKSB2 cy4gcnRvLWNvbnNpZGVyDQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gTWFyIDI5LCAyMDE3LCBhdCAx Mjo0NCBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkNCj4gPiA8bWlj aGFlbC5zY2hhcmZAbm9raWEuY29tPG1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+PiB3 cm90ZToNCj4gPiBTbywgSSB3b25kZXIgaWYgdGhlcmUgY291bGQgYmUgYSByZWFzb25pbmcgZm9y IGFwcGx5aW5nIHRoZXNlIHR3bw0KPiA+IFNIT1VMRCB0byBUQ1A/IE1vc3Qgbm90YWJseSwgY291 bGQgdGhlcmUgYmUgYW55IHJlYXNvbiB3aHkgYSBUQ1ANCj4gPiBpbXBsZW1lbnRhdGlvbiB3b3Vs ZCBub3QgbWVhc3VyZSBSVFQgw6LigqzFk3JlZ3VsYXJsecOi4oKswp0/DQo+ID4NCj4gPiBPdmVy aGVhZCBhbmQgY29tcGxleGl0eSBmb3Igc21hbGwgZm9vdHByaW50IGRldmljZXMuIElNTyBTSE9V TEQgaXMNCj4gPiBzdWZmaWNpZW50LiBNVVNUIG5lZWRzIHRvIGJlIHJlc2VydmVkIGZvciBwcm90 b2NvbCBjb3JyZWN0bmVzcyBvcg0KPiA+IGJlaGF2aW9yIHRydWx5IGhhemFyZG91cyB0byBvdGhl cnMuDQo+ID4NCj4gPiBKb2UNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4gdGNwbUBpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+DQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g dGNwbSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg== From nobody Fri Mar 31 08:18:08 2017 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 71ADC1298B7; Fri, 31 Mar 2017 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 aP3p79mCGay6; Fri, 31 Mar 2017 08:18:05 -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 081251294E1; Fri, 31 Mar 2017 08:18:05 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2VFHMSu013517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Mar 2017 08:17:24 -0700 (PDT) To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "Gengxuesong (Geng Xuesong)" , Carles Gomez Montenegro References: Cc: "tcpm@ietf.org" , "draft-ietf-core-cocoa@ietf.org" From: Joe Touch Message-ID: Date: Fri, 31 Mar 2017 08:17:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 15:18:06 -0000 On 3/31/2017 8:02 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > For what it is worth, I have doubts that in IoT an RTT measurement has to be performed *more* frequently than mandated by the TCP standards, which require a measurement roughly once per RTT. But I have no data for this. > > However, the discussion is whether there could be a reasonable use case for measuring the RTT *less* frequently. Examples for *less* would be to sample once-per-connection, once per minute, once per hour, etc. And once per N current round-trips, or even 1/N of a round trip (for some N, e.g., 2 or 3). > The issue is that the current version of the I-D rto-consider allows a lower frequency due to the use of the SHOULD. And this is different to my reading of RFC 793 and the standards-track specification of TCP, i.e., it is not consistent with the TCP standards. I admit that this is sort of the bureaucratic discussion but it matters specifically since we have wording on this in 793bis as well. 793 didn't have 2119 language at all. It's up to us to interpret what are MAY/MUST/SHOULD from the language there, even when the language has may/must/should. I hear the argument that "793 says must, so it needs to be MUST", but that seems to be a blind decision. We ought to be making thoughtful ones, including MUSTs only where necessary. It's clear that RTTs need to be measured "frequently enough", but it also seems like requiring that to be done for EVERY packet exchanged is both very high and rarely what a minimal TCP actually does (esp. given TS support is a MAY anyway). Joe From nobody Fri Mar 31 09:09:38 2017 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 11A3812950E for ; Fri, 31 Mar 2017 09:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1G3UQnehue0 for ; Fri, 31 Mar 2017 09:09:33 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEE0129406 for ; Fri, 31 Mar 2017 09:09:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vvmfL4zSpzMs0b; Fri, 31 Mar 2017 18:09:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuUT66nXNweu; Fri, 31 Mar 2017 18:09:29 +0200 (CEST) X-MtScore: NO score=0 Received: from dhcp-8e47.meeting.ietf.org (dhcp-8e47.meeting.ietf.org [31.133.142.71]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 31 Mar 2017 18:09:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 31 Mar 2017 11:09:27 -0500 Cc: Joe Touch , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3F76FDED-F6EB-4295-AC9F-9A3A32776437@tik.ee.ethz.ch> References: To: "Scharf, Michael (Nokia - DE/Stuttgart)" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 16:09:36 -0000 Hi all, just to clarify this point: > Am 30.03.2017 um 06:41 schrieb Scharf, Michael (Nokia - DE/Stuttgart) = : >=20 > Since there has always been the =E2=80=9Cmust=E2=80=9D wording in RFC = 793 (and it has been a MUST in rto-consider in many revisions as well), = I am not sure if we can downgrade this now to SHOULD, e.g., without = experimental data. rto-cosnider does not change/update rfc793. rfc793 is still valid and is = simply giving a more constraint specification for one specific protocol = which does not contradict each other. (The other way around would but = that=E2=80=99s not the case here). However, maybe it would be good to refer to rfc793 and rfc6298 in = rto-consider and make the reader award that these docs make an even = strong recommendation for TCP. Also, given there was a discussion now if the MUST, or actually must, = for rfc793 is still appropriate, this is a question for 793bis (and not = the rto-cosnider draft). Mirja From nobody Fri Mar 31 09:27:54 2017 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 34F4212998B for ; Fri, 31 Mar 2017 09:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 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_H2=-2.796, 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=nokia.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 YZYUGFAFP5eI for ; Fri, 31 Mar 2017 09:27:49 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50136.outbound.protection.outlook.com [40.107.5.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB451296B6 for ; Fri, 31 Mar 2017 09:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5/RVg1j97HC9sA9InyuI4cqH7zPtgqGM73dG3qlxOPQ=; b=Po47TLY1w979SmZvw+KTm2p7n2DkZmSOoVwgDgHwogfMbBgG5f6oJWfHpxaIKgw+SdesKnQ6NLPukIHI/i75KEw/aZEfF7s3sWkx5ZAzo/Mtwbdjl1fSgViCsk5AMGbIp9zAKgmuPwVFdtJ5EunOfmYwbILQ1IVaTn2k07ZhLQ4= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2545.eurprd07.prod.outlook.com (10.173.92.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 16:27:46 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1005.015; Fri, 31 Mar 2017 16:27:46 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: Joe Touch , "tcpm@ietf.org" Thread-Topic: [tcpm] RFC 793 (bis) vs. rto-consider Thread-Index: AdKowj/uHBlAvttmR5O5bK3orMhOogAXUEIAAAnLLSAAPJ+BgAAAlN6w Date: Fri, 31 Mar 2017 16:27:46 +0000 Message-ID: References: <3F76FDED-F6EB-4295-AC9F-9A3A32776437@tik.ee.ethz.ch> In-Reply-To: <3F76FDED-F6EB-4295-AC9F-9A3A32776437@tik.ee.ethz.ch> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tik.ee.ethz.ch; dkim=none (message not signed) header.d=none;tik.ee.ethz.ch; dmarc=none action=none header.from=nokia.com; x-originating-ip: [31.133.141.145] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2545; 7:D7oGbpSLabqWiSaWrLzwfO4Id+JdAwI3Od67vgolT5KrokqC2Id+5nZM55H0DxPTLcOFyI4qLu6e0UyhaMx5WB6PUojv8KVAfYRvd57AQc8/HoLJc/dXZ9MLzaJL9z/FhR4wFETRlBCQMNj4AyGniyP2UP2foBuH7Xii2eiFnSxxIZkGEpeNgMzMSayJRLO4qFWG8QEFngdQbvehsnXgGRfE/Pr9gJeOqgOHm0f5xOIQ5ttClgklfYHGjI3j6zeA9K4wcZXPjnnldkfs82P9UawHCyojw9+P54JU6yiyrxpQteCKBp5zra8lT9AjSXqfVDne5ucg+fJXmMalURKaaQ== x-ms-office365-filtering-correlation-id: bcb69e36-c485-4edb-745e-08d47852ddb4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2545; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(6072148); SRVR:AM5PR0701MB2545; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2545; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39860400002)(39840400002)(39410400002)(39450400003)(6916009)(2950100002)(54906002)(86362001)(9686003)(122556002)(3280700002)(25786009)(7696004)(2906002)(53936002)(6436002)(6506006)(77096006)(110136004)(38730400002)(99286003)(55016002)(4326008)(2900100001)(6246003)(6116002)(3846002)(8936002)(189998001)(3660700001)(8676002)(76176999)(54356999)(81166006)(93886004)(305945005)(50986999)(33656002)(5660300001)(102836003)(66066001)(74316002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2545; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 16:27:46.7564 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2545 Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 16:27:51 -0000 PiA+IFNpbmNlIHRoZXJlIGhhcyBhbHdheXMgYmVlbiB0aGUg4oCcbXVzdOKAnSB3b3JkaW5nIGlu IFJGQyA3OTMgKGFuZCBpdCBoYXMNCj4gYmVlbiBhIE1VU1QgaW4gcnRvLWNvbnNpZGVyIGluIG1h bnkgcmV2aXNpb25zIGFzIHdlbGwpLCBJIGFtIG5vdCBzdXJlIGlmIHdlDQo+IGNhbiBkb3duZ3Jh ZGUgdGhpcyBub3cgdG8gU0hPVUxELCBlLmcuLCB3aXRob3V0IGV4cGVyaW1lbnRhbCBkYXRhLg0K PiANCj4gcnRvLWNvc25pZGVyIGRvZXMgbm90IGNoYW5nZS91cGRhdGUgcmZjNzkzLiByZmM3OTMg aXMgc3RpbGwgdmFsaWQgYW5kIGlzIHNpbXBseQ0KPiBnaXZpbmcgYSBtb3JlIGNvbnN0cmFpbnQg c3BlY2lmaWNhdGlvbiBmb3Igb25lIHNwZWNpZmljIHByb3RvY29sIHdoaWNoIGRvZXMgbm90DQo+ IGNvbnRyYWRpY3QgZWFjaCBvdGhlci4gKFRoZSBvdGhlciB3YXkgYXJvdW5kIHdvdWxkIGJ1dCB0 aGF04oCZcyBub3QgdGhlIGNhc2UNCj4gaGVyZSkuDQo+IA0KPiBIb3dldmVyLCBtYXliZSBpdCB3 b3VsZCBiZSBnb29kIHRvIHJlZmVyIHRvIHJmYzc5MyBhbmQgcmZjNjI5OCBpbiBydG8tDQo+IGNv bnNpZGVyIGFuZCBtYWtlIHRoZSByZWFkZXIgYXdhcmQgdGhhdCB0aGVzZSBkb2NzIG1ha2UgYW4g ZXZlbiBzdHJvbmcNCj4gcmVjb21tZW5kYXRpb24gZm9yIFRDUC4NCg0KVGhpcyB3b3VsZCB3b3Jr IGZvciBtZS4NCiANCj4gQWxzbywgZ2l2ZW4gdGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiBub3cgaWYg dGhlIE1VU1QsIG9yIGFjdHVhbGx5IG11c3QsIGZvcg0KPiByZmM3OTMgaXMgc3RpbGwgYXBwcm9w cmlhdGUsIHRoaXMgaXMgYSBxdWVzdGlvbiBmb3IgNzkzYmlzIChhbmQgbm90IHRoZSBydG8tDQo+ IGNvc25pZGVyIGRyYWZ0KS4NCg0KSSBhZ3JlZSAtIGJ1dCB3ZSBoYXZlIHRvIHN0YXJ0IHJldmll d2luZyA3OTNiaXMgYW55d2F5Lg0KDQpNaWNoYWVsDQo= From nobody Fri Mar 31 09:38:43 2017 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 E5E231296E8 for ; Fri, 31 Mar 2017 09:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gIVF-f_G-_Fr for ; Fri, 31 Mar 2017 09:38:36 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BF61297A8 for ; Fri, 31 Mar 2017 09:38:33 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v2VGcWJq029075; Fri, 31 Mar 2017 09:38:33 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id ACF9073C09B0; Fri, 31 Mar 2017 12:38:32 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\/Stuttgart\)" From: Mark Allman Reply-To: mallman@icir.org cc: Joe Touch , "tcpm\@ietf.org" In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dead Flowers X-URL-0: https://www.icir.org/mallman-files/Document10168.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 31 Mar 2017 12:38:32 -0400 Message-ID: <14467.1490978312@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 16:38:38 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > If it measures the RTT once (to reduce complexity) and if that > sample happens to be way below the average RTT, it can run > repeatedly into spurious timeouts, no? Then the exponential > backoff and congestion control kicks in, but if there are many of > these devices (sensors=E2=80=A6) on the medium, transmitting every message > multiple times could be hazardous, no? Harzardous? No. IMHO. First, we have congestion control. Nobody is suggesting we remove that. So, we will not collapse. Second, if in fact the SHOULD is followed then I doubt the course you suggest is possible because 2119 says that "the full implications must be understood and carefully weighed before choosing a different course". I doubt there is an incentive for implementers to create the situation you describe. Third, let's be clear here ... we're saying an implementation SHOULD take regular samples. We are not saying "eh, if ya want" or "it is not important to take regular samples" or any such thing. In fact, the draft explicitly calls out the case you are talking about and notes that taking a single sample per connection "results in a relatively poorly performing RTO mechanism". So, to my mind we are in fact warning people that they should be pretty careful if they take this sort of approach. Fourth, our old work on take-first doesn't suggest it is somehow completely outrageous. Fifth, the words in rto-consider say that one SHOULD not only measure the RTT, but also the variance. The variance cannot be measured when we only have one sample, but if one initializes it reasonably that helps the situation you describe. There are many places in the tradeoff space that are suboptimal. There are many ways to view "optimality". And, there are many disparate situations. We know there is no one-size-fits-all. So, it seems the question boils down to whether this would in fact cause a danger to the Internet. We are a very long ways away from that point here.=20=20 The way I look at this is that there are two MUSTs [*] in rto-consider that I would argue are critical and have to be MUSTs. Those are (a) exponential backoff and (b) taking a timeout as an indication of congestion and invoking some standard CC (unless we figure out the loss is not congestion using some standard mechanism, e.g., F-RTO). Nothing else rises anywhere close to the level of importance of these two requirements, IMO. These are the only two things that if violated would make me wince and worry a bit. This is the general vibe I got from Wednesday's meeting, as well. That doesn't mean everything else is unimportant or has no effect or we shouldn't care about it. But, it means that if we give some wiggle room and someone gets it wrong it will not be dangerous. allman [*] The other MUST in the document is that the initial RTO MUST be at least 1sec. I think after (a) and (b) above this is probably the most important thing so that flows do not start off too aggressively and also so they at least get one good RTT sample. But, this also isn't all that close to (a) and (b) in my mind and I could see making this a SHOULD, as well. This is all sort of shades of grey. And, I go back and forth on what my druthers are for the requirement level of the initial RTO, but what I have no doubt about is that it is not nearly as important as the other two bits. --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljehggACgkQWyrrWs4yIs7fTQCgmkZOCFpb+lQFFJf3VfG5Poh/ l8oAn1w/w2ufTH0R1uY6AS+qmhsBH4TW =M1N6 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Mar 31 09:41:24 2017 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 3A4D612950B; Fri, 31 Mar 2017 09:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YWsbVHjJsyJU; Fri, 31 Mar 2017 09:41:21 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CE9129474; Fri, 31 Mar 2017 09:41:21 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v2VGf71R029371; Fri, 31 Mar 2017 09:41:07 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A040F73C0A6F; Fri, 31 Mar 2017 12:41:07 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\/Stuttgart\)" From: Mark Allman Reply-To: mallman@icir.org cc: "Gengxuesong \(Geng Xuesong\)" , "Carles Gomez Montenegro" , "tcpm\@ietf.org" , "draft-ietf-core-cocoa\@ietf.org" In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Pinball Wizard X-URL-0: https://www.icir.org/mallman-files/Document88621.doc X-URL-1: https://www.icir.org/mallman-files/Document13827.docx X-URL-2: https://www.icir.org/mallman-files/Document52644.html X-URL-3: https://www.icir.org/mallman-files/Document93296.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 31 Mar 2017 12:41:07 -0400 Message-ID: <15142.1490978467@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 16:41:23 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael- > The issue is that the current version of the I-D rto-consider > allows a lower frequency due to the use of the SHOULD. And this is > different to my reading of RFC 793 and the standards-track > specification of TCP, i.e., it is not consistent with the TCP > standards. If it wasn't different we'd not need to write a new draft... But, I completely disagree with your characterization of 793. You are torturing the words. RFC 793 says: Because of the variability of the networks that compose an internetwork system and the wide range of uses of TCP connections the retransmission timeout must be dynamically determined. One procedure for determining a retransmission time out is given here as an illustration. First, the algorithm given is not **the** algorithm, but **an example**. It is called out as such. (And, don't go and quote 793bis chapter and verse on me ... that is an effin' draft and I've been around the block a few too many times to fall for that sort of crapola. We can make that say whatever is appropriate for it to say. And, that might be different than what it says at this exact moment.) Second, "must be dynamically determined" doesn't say what you claim it says. In particular it gives no time frame at all. Is that dynamic over the course of a single connection? Over a day? An hour? An RTT? Once per connection could well fit in that we are then not relying on a static timeout, but rather basing the timeout on the conditions of the network path. This is in fact dynamic. So, you're just wrong in saying that 793 somehow says we "must" sample at any particularly frequency. Even the **example** given doesn't say how often samples are taken. Third, I agree that the wording in 6298 says TCP MUST use that algorithm. We can change that sentence. I.e., to say the algorithm is one possible algorithm that follows [rto-consider]. Again, the goal is to **change** things, so this doesn't faze me one little bit. It's a sentence. In a file. It was not handed down as etchings on a stone tablet. > I admit that this is sort of the bureaucratic discussion but it > matters specifically since we have wording on this in 793bis as > well. Yes- it is pedantic and bureaucratic. I fully understand that documents like rto-consider are quite unusual for the IETF and they run counter to our collective approach and sensibilities, which generally favor crisp, formal, tight specifications. I have exactly those sensibilities, too. And, in fact, can remember writing RFC 2988 and applying some of those sensibilities at the time when, e.g., Sally Floyd was pushing for a little looser spec (although not nearly what rto-consider is). However, I think a sign of a mature organization is the ability to sometimes look around and decide that we have learned some things From=20reality and can in fact let go of tight specs and crisp formality where it is not required. I think this in fact gives us more credibility and makes, e.g., our MUSTs stronger because we are not slapping them on everything in the name of conservativeness or just-in-case. I think a bunch of us think we're at that point with the RTO. I completely understand that you are not and completely sympathize with your instincts and sensibilities. But, I don't think consensus is with you here. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljehqMACgkQWyrrWs4yIs4AXwCfSRpMwqleBJcPCWqzzY9boKqM ttoAmgLbDNQj3K4wyp/xPM3O5EAequvZ =Tysq -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Mar 31 09:46:38 2017 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 36CE9129474 for ; Fri, 31 Mar 2017 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 tst1mq7UqAlz for ; Fri, 31 Mar 2017 09:46:35 -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 0975F126DD9 for ; Fri, 31 Mar 2017 09:46:35 -0700 (PDT) Received: from [128.9.184.172] ([128.9.184.172]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2VGjsJm027151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Mar 2017 09:45:55 -0700 (PDT) To: mallman@icir.org, "Scharf, Michael (Nokia - DE/Stuttgart)" References: <14467.1490978312@lawyers.icir.org> Cc: "tcpm@ietf.org" From: Joe Touch Message-ID: <43a5742b-0987-237b-00f6-af22c7c2266e@isi.edu> Date: Fri, 31 Mar 2017 09:45:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <14467.1490978312@lawyers.icir.org> Content-Type: text/plain; charset=utf-8 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] RFC 793 (bis) vs. rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 16:46:36 -0000 On 3/31/2017 9:38 AM, Mark Allman wrote: > The way I look at this is that there are two MUSTs [*] in > rto-consider that I would argue are critical and have to be MUSTs. > Those are (a) exponential backoff and (b) taking a timeout as an > indication of congestion and invoking some standard CC (unless we > figure out the loss is not congestion using some standard mechanism, > e.g., F-RTO). Nothing else rises anywhere close to the level of > importance of these two requirements, IMO. +1 From nobody Fri Mar 31 10:35:33 2017 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 C144C12996E; Fri, 31 Mar 2017 10:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 no4Bg4Lt4Xzd; Fri, 31 Mar 2017 10:35:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B3FE212995D; Fri, 31 Mar 2017 10:35:19 -0700 (PDT) X-AuditID: c1b4fb2d-d97ff700000033e1-f2-58de935576e4 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 54.F4.13281.5539ED85; Fri, 31 Mar 2017 19:35:17 +0200 (CEST) Received: from EUR03-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.339.0; Fri, 31 Mar 2017 19:35:16 +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=cTmfPDGdesdSrDeh4g/dNJbNUy1zll4sqOXnQE9yxrc=; b=QLmVj0/4Hz9eKbpyxzI68Dv19pywEAG564Jwv6cEi0gLx1wBUXdpcQDB7i4/Efrg+0SqVZ+BKwI89/4leewkVbC+/wXu/jDiCLz73FHtwIv7qA62coHZ35q59SFX6/mE/jb5bQmjcbbvMpv4uyzHFyZRCnyFk7Ex3AQ7okNzEzk= 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_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 17:35:12 +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.1005.014; Fri, 31 Mar 2017 17:35:12 +0000 From: Ingemar Johansson S To: Yuchung Cheng , Michael Welzl CC: tsvwg IETF list , "tcpm@ietf.org Extensions" Thread-Topic: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) Thread-Index: AQHSqZq/4RHrIyBgtUCygnpI+u3trKGt82KAgAFBFtA= Date: Fri, 31 Mar 2017 17:35:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.88] x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:zP2WuGBdEMojGGfyfOLtO0MlpsqaIOgtTjgHyDBZlI4bmX7Zg5XPIbL4+RI/THyJ6ElwRDbj7d1owgmPFZhWh+DGJas3wL/SEzGySl4aufERSNNHVfl+1snbxYgP8+PmZY0kQy3zQLRKNGcAZRYxFkTFmijSA1NGM72sptQ/dxTwISd6L9hDgR3/IbYrwdH7F3q2MjTJxY9H7T8Tlq09oscxTGUhT7KJyq+T3RLNZd4BcWS31VHI6zveSM1OVyuFR2WHzotmPHF+/w3nFHFbl4ujWubUg87jaI4CjipzXo+SgdAmyYEXD9NeBee/6uIcJSUZtUPY5HUHHZ9mrAGb8w== x-ms-office365-filtering-correlation-id: 7d948de1-9004-4b6a-8d91-08d4785c4953 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB346; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39450400003)(39860400002)(39400400002)(39410400002)(39840400002)(377454003)(24454002)(6436002)(53546009)(606005)(25786009)(3280700002)(3660700001)(189998001)(8676002)(81166006)(966004)(8936002)(122556002)(6506006)(2950100002)(229853002)(2906002)(790700001)(5660300001)(102836003)(6116002)(3846002)(7906003)(66066001)(19609705001)(2900100001)(6246003)(9686003)(6306002)(99286003)(54896002)(86362001)(54906002)(77096006)(33656002)(55016002)(74316002)(38730400002)(7696004)(236005)(50986999)(54356999)(76176999)(53936002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348585F3090AF94C3234231C2370DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 17:35:12.6275 (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: H4sIAAAAAAAAA02Sa0hTYRjHeXfO2Y6jyevSfLxENRDMvGV9WCWl4Aezq4J4A3PqQcV5YUdF g2IZhpfCIDMmikYzmYYTk8zrdJK6UhyoYJrWnKKlLS1LI7s4zwK//Z7//3mf9/m/vDQhbqdc 6bTMHEaRKZNL+EJSFd1+zifywVy0v3HIW7o12kFJXxhqedLB1Vm+dMM8yQ8iQ+tac0PV6p+8 0KYmE3GViBUGJjPytDxG4Xc2QZiq6dzkZ09k5ev7DEiJjPJSZEcDPgkqzXdBKRLSYqxFULTc T3LFMIJPqsLdgsT3CKh/puRzTiUPOgbqbMUggr8mC2kdxseBoNFvolJE0474PPRo/K0ygSNg qeEtZeX9+AL0THHtjvgitLU+sfFpeLzURliZxB4wVLiKrCzCsaCxLNr260ag6lBT1vl2OByU Q/bWHoQPwvvNOZK7yxmmF2p5XDYM6u4xgmMn+Gj+Q1nnIFyOYHxlxtZ0GCw1b3bDAC4joGW7 HHHGJVgvXxNwfAPmy8w2ToOH6yMkx3GwZBkguMNjPFhUfaM4wx0s1R2IM/QU6G89suV3hdmJ EsSxOyy/66HuI8+qPatX7aQjcBYUdhdU7b6AAxhUCyQnHwVtpx/XfQQqykwCjj2hqLpGsFev Q4JG5MQyLJuREnDCl1GkJbFsVqZvJpPTina+U3/bL5+XqGklWI8wjST7RB8S5qLFlCyPLcjQ I6AJiaOIF78jiZJlBdcZRdY1Ra6cYfXIjSYlzqKgXmO0GKfIcph0hslmFP9dHm3nqkT1Dusx I7r4xL6Sudr56V6TqrHry3DeWnFY8zG/A40BXvKnpA4vNxRLX2+0sPZhp9xeSQYOpVdsf434 gW9XNp9xMyldtOhyyHNd3Ix2ozPWJSkqJj84t0x3ExemR969kzh/5fdMiP+UDodPdBWvfd7y 6BuNMk96G5zGt4ypIS0Skk2VHfciFKzsH86w9VZKAwAA Archived-At: Subject: Re: [tcpm] [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 17:35:27 -0000 --_000_DB4PR07MB348585F3090AF94C3234231C2370DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZGV0YWlscy4gSXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgaXQgY2FuIGJl IHRyaWNreSB0byBnZXQgYSBkZWNlbnQgdW5kZXJzdGFuZGluZyBvZiB3aGF0IGlzIHBvc3NpYmxl IGluIHRlcm1zIG9mIEFDSyByYXRlIHJlZHVjdGlvbiBmb3IgVENQLiBUaGUgbWlkZGxlYm94IGJl aGF2aW9yIHRvIGRpc2NhcmQgZXZlcnl0aGluZyBleGNlcHQgdGhlIGxhc3QgQUNLIGhhcyBhbHNv IGJlZW4gcHJvcG9zZWQgaW4gdGhlIFJBTjIgV0cgaW4gM0dQUC4NCg0KL0luZ2VtYXINCg0KRnJv bTogWXVjaHVuZyBDaGVuZyBbbWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tXQ0KU2VudDogZGVuIDMx IG1hcnMgMjAxNyAwMDoxNw0KVG86IE1pY2hhZWwgV2VsemwgPG1pY2hhd2VAaWZpLnVpby5ubz4N CkNjOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNv bT47IHRzdndnIElFVEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+OyB0Y3BtQGlldGYub3JnIEV4dGVu c2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBUQ1AgQUNLLUNDIChy ZTogVHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkICkNCg0KcmVnYXJkaW5nIHRo ZSBxdWVzdGlvbiBpbiB0aGUgc2xpZGUgNS4NCiJJcyBpbW1lZGlhdGUgQUNLIG5lZWRlZCBmb3Ig b3V0IG9mIG9yZGVyIHNlZ21lbnRzIGlmIFJBQ0sgaXMgdXNlZCA/Ig0KDQpUaGUgYW5zd2VyIGlz IGJvdGggeWVzIGFuZCBubzogYSB0aW1lbHkgZmVlZGJhY2sgaXMgYXBwcmVjaWF0ZWQgKHllcyku IEJ1dCBSQUNLIGRvZXMgbm90IG5lZWQgMTAwIERVUEFDS3MgZWFjaCB0ZWxsaW5nIG9uZSBtb3Jl IHBhY2tldCBpcyBkZWxpdmVyZWQgb3V0IG9mIG9yZGVyIChubykuIEluIG90aGVyIHdvcmRzIGlm IHRoZSBBQ0sgaXMgdGltZWx5IGFuZCBwcmVjaXNlIGFib3V0IHRoZSBkZWxpdmVyeSBwcm9jZXNz LCBSQUNLIHdvdWxkIHdvcmsgd2VsbCAoc28gZG9lcyBCQlIpLiBIb3dldmVyIHRoaXMgY2FuIGdv IHRlcnJpYmx5IHdyb25nIGlmIHRoZSBtaWRkbGUtYm94IHNlbmRzIG9ubHkgdGhlIGxhc3QgQUNL L1NBQ0suIEl0IGhhcyBoYXBwZW5lZCBpbiBvbmUgbWFqb3IgY2xvdWQgcGxhdGZvcm0uDQoNCk9u IFRodSwgTWFyIDMwLCAyMDE3IGF0IDI6MTQgUE0sIE1pY2hhZWwgV2VsemwgPG1pY2hhd2VAaWZp LnVpby5ubzxtYWlsdG86bWljaGF3ZUBpZmkudWlvLm5vPj4gd3JvdGU6DQpIaSwNCg0KVGhhbmtz IEluZ2VtYXIgZm9yIHlvdXIgaW50ZXJlc3RpbmcgcHJlc2VudGF0aW9uIHRvZGF5Og0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC10c3Z3Zy1zZXNz Yi03LXRyYW5zcG9ydC1wcm90b2NvbC1mZWVkYmFjay1vdmVyaGVhZC1pc3N1ZXMtYW5kLXNvbHV0 aW9ucy0wMC5wZGYNCg0KSSB3YW50ZWQgdG8gc2hhcmUgd2l0aCB5b3UsIGFuZCB0aGUgbGlzdCwg dGhhdCBEYXZpZCBSb3MgIChvbmUgb2YgdGhlIG9yaWdpbmFsIGF1dGhvcnMgb2YgQUNLLUNDLCBS RkMgNTY5MCkgYW5kIEkgb25jZSBhZHZpc2VkIGEgbWFzdGVyIHN0dWRlbnQgdG86DQotIGltcGxl bWVudCBBQ0stQ0MNCi0gdGVzdCBpdA0KLSBhbmFseXplIGFsbCBSRkMgMjExOSAtIHN0eWxlIGtl eXdvcmRzIGluIFJGQyA1NjkwLCB0byBzZWUgaG93IHRoZXkgc2hvdWxkIGJlIGNoYW5nZWQgKGlm IGF0IGFsbCkgaW4gYSBwb3NzaWJsZSB1cGRhdGUNCg0KQmFjayB0aGVuLCBvdXIgdGhpbmtpbmcg d2FzIHRoYXQgd2UgY291bGQgd3JpdGUgYSBwYXBlciBhYm91dCBpdCwgYW5kIHRyeSB0byBnZXQg dGhpcyBkZXBsb3llZCBhcyBhIHdheSBvZiBkb2luZyB0aGUgRXhwZXJpbWVudCBhbmQgbW92aW5n IHRoaXMgdG8gUFMgc3RhdHVzLg0KSG93ZXZlciwgd2Ugd2VyZSBsZXNzIGFuZCBsZXNzIHN1cmUg YWJvdXQgdGhlIHJlYWwgdmFsdWUgb2YgdGhpcyAtIHdoZXRoZXIgYWN0dWFsIG5ldHdvcmtzIG5l ZWQgdGhpcz8gVGhlbiwgd2UgaGFkIGxlc3MgYW5kIGxlc3MgdGltZSBhdmFpbGFibGUgYW5kIGF0 IHNvbWUgcG9pbnQgZHJvcHBlZCB0aGUgYmFsbC4NCkkgb2YgY291cnNlIGZvdW5kIGl0IGludGVy ZXN0aW5nIHRvIGhlYXIgdGhhdCBpdCAqaXMqIGEgcmVhbCBwcm9ibGVtLCBldmVuIHRvZGF5Lg0K DQpBbnl3YXk6IHRoaXMgbWFzdGVyIHRoZXNpcyBpcyBhdmFpbGFibGUgaGVyZTogIGh0dHA6Ly9o ZWltLmlmaS51aW8ubm8vbWljaGF3ZS90ZWFjaGluZy9kaXBscy9tYXJpdXMtb2xzZW4vbWFzdGVy c3RoZXNpcy1tYXJpdXNuby5wZGYNCmFuZCBJIHRoaW5rIEkgY2FuIHNhZmVseSBzYXkgb24gYmVo YWxmIG9mIERhdmlkLCBNYXJpdXMgKHRoZSBtYXN0ZXIgc3R1ZGVudCB3aG8gZGlkIHRoaXMpIGFu ZCBteXNlbGYgdGhhdCB3ZeKAmXJlIGhhcHB5IGlmIHNvbWVvbmUgcGlja3MgdGhpcyB1cCBhbmQg Y29udGludWVzIHRoZSB3b3JrLg0KSXQgd291bGQgcmVxdWlyZSBzb21lIGRpZ2dpbmcsIGJ1dCBJ IG1pZ2h0IGFsc28gc3RpbGwgaGF2ZSB0aGUgY29kZSBseWluZyBhcm91bmQgc29tZXdoZXJlIC0g Zm9yIHNvbWUgb3V0ZGF0ZWQgdmVyc2lvbiBvZiBMaW51eOKApg0KDQpDaGVlcnMsDQpNaWNoYWVs DQoNCg0K --_000_DB4PR07MB348585F3090AF94C3234231C2370DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgdGhlIGRldGFpbHMuIEl0IG1heSBi ZSB0aGUgY2FzZSB0aGF0IGl0IGNhbiBiZSB0cmlja3kgdG8gZ2V0IGEgZGVjZW50IHVuZGVyc3Rh bmRpbmcgb2Ygd2hhdCBpcyBwb3NzaWJsZSBpbiB0ZXJtcyBvZiBBQ0sgcmF0ZSByZWR1Y3Rpb24g Zm9yIFRDUC4gVGhlIG1pZGRsZWJveCBiZWhhdmlvcg0KIHRvIGRpc2NhcmQgZXZlcnl0aGluZyBl eGNlcHQgdGhlIGxhc3QgQUNLIGhhcyBhbHNvIGJlZW4gcHJvcG9zZWQgaW4gdGhlIFJBTjIgV0cg aW4gM0dQUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+L0luZ2VtYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gWXVjaHVuZyBDaGVuZyBbbWFpbHRvOnljaGVu Z0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAzMSBtYXJzIDIwMTcgMDA6MTc8 YnI+DQo8Yj5Ubzo8L2I+IE1pY2hhZWwgV2VsemwgJmx0O21pY2hhd2VAaWZpLnVpby5ubyZndDs8 YnI+DQo8Yj5DYzo8L2I+IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0O2luZ2VtYXIucy5qb2hhbnNz b25AZXJpY3Nzb24uY29tJmd0OzsgdHN2d2cgSUVURiBsaXN0ICZsdDt0c3Z3Z0BpZXRmLm9yZyZn dDs7IHRjcG1AaWV0Zi5vcmcgRXh0ZW5zaW9ucyAmbHQ7dGNwbUBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gVENQIEFDSy1DQyAocmU6IFRyYW5zcG9ydCBwcm90 b2NvbCBmZWVkYmFjayBvdmVyaGVhZCApPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlZ2FyZGluZyB0aGUgcXVlc3Rpb24gaW4gdGhlIHNsaWRl IDUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7SXMg aW1tZWRpYXRlIEFDSyBuZWVkZWQgZm9yIG91dCBvZiBvcmRlciBzZWdtZW50cyBpZiBSQUNLIGlz IHVzZWQgPyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgYW5zd2VyIGlzIGJvdGggeWVzIGFuZCBubzogYSB0aW1lbHkgZmVlZGJh Y2sgaXMgYXBwcmVjaWF0ZWQgKHllcykuIEJ1dCBSQUNLIGRvZXMgbm90IG5lZWQgMTAwIERVUEFD S3MgZWFjaCB0ZWxsaW5nIG9uZSBtb3JlIHBhY2tldCBpcyBkZWxpdmVyZWQgb3V0IG9mIG9yZGVy IChubykuIEluIG90aGVyIHdvcmRzIGlmIHRoZSBBQ0sgaXMgdGltZWx5IGFuZCBwcmVjaXNlIGFi b3V0IHRoZSBkZWxpdmVyeSBwcm9jZXNzLA0KIFJBQ0sgd291bGQgd29yayB3ZWxsIChzbyBkb2Vz IEJCUikuIEhvd2V2ZXIgdGhpcyBjYW4gZ28gdGVycmlibHkgd3JvbmcgaWYgdGhlIG1pZGRsZS1i b3ggc2VuZHMgb25seSB0aGUgbGFzdCBBQ0svU0FDSy4gSXQgaGFzIGhhcHBlbmVkIGluIG9uZSBt YWpvciBjbG91ZCBwbGF0Zm9ybS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMzAsIDIwMTcgYXQgMjoxNCBQTSwgTWljaGFl bCBXZWx6bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ubyIgdGFyZ2V0PSJf YmxhbmsiPm1pY2hhd2VAaWZpLnVpby5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MgSW5nZW1hciBmb3IgeW91ciBpbnRlcmVzdGluZyBwcmVzZW50YXRpb24gdG9kYXk6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4LXRz dndnLXNlc3NiLTctdHJhbnNwb3J0LXByb3RvY29sLWZlZWRiYWNrLW92ZXJoZWFkLWlzc3Vlcy1h bmQtc29sdXRpb25zLTAwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtdHN2d2ctc2Vzc2ItNy10cmFuc3BvcnQt cHJvdG9jb2wtZmVlZGJhY2stb3ZlcmhlYWQtaXNzdWVzLWFuZC1zb2x1dGlvbnMtMDAucGRmPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHdhbnRlZCB0byBzaGFyZSB3aXRoIHlvdSwgYW5kIHRoZSBsaXN0LCB0aGF0IERhdmlkIFJvcyAm bmJzcDsob25lIG9mIHRoZSBvcmlnaW5hbCBhdXRob3JzIG9mIEFDSy1DQywgUkZDIDU2OTApIGFu ZCBJIG9uY2UgYWR2aXNlZCBhIG1hc3RlciBzdHVkZW50IHRvOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBpbXBsZW1lbnQgQUNLLUNDPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHRlc3QgaXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gYW5h bHl6ZSBhbGwgUkZDIDIxMTkgLSBzdHlsZSBrZXl3b3JkcyBpbiBSRkMgNTY5MCwgdG8gc2VlIGhv dyB0aGV5IHNob3VsZCBiZSBjaGFuZ2VkIChpZiBhdCBhbGwpIGluIGEgcG9zc2libGUgdXBkYXRl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJh Y2sgdGhlbiwgb3VyIHRoaW5raW5nIHdhcyB0aGF0IHdlIGNvdWxkIHdyaXRlIGEgcGFwZXIgYWJv dXQgaXQsIGFuZCB0cnkgdG8gZ2V0IHRoaXMgZGVwbG95ZWQgYXMgYSB3YXkgb2YgZG9pbmcgdGhl IEV4cGVyaW1lbnQgYW5kIG1vdmluZyB0aGlzIHRvIFBTIHN0YXR1cy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHdlIHdlcmUgbGVz cyBhbmQgbGVzcyBzdXJlIGFib3V0IHRoZSByZWFsIHZhbHVlIG9mIHRoaXMgLSB3aGV0aGVyIGFj dHVhbCBuZXR3b3JrcyBuZWVkIHRoaXM/IFRoZW4sIHdlIGhhZCBsZXNzIGFuZCBsZXNzIHRpbWUg YXZhaWxhYmxlIGFuZCBhdCBzb21lIHBvaW50IGRyb3BwZWQgdGhlIGJhbGwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG9mIGNvdXJzZSBmb3Vu ZCBpdCBpbnRlcmVzdGluZyB0byBoZWFyIHRoYXQgaXQgKmlzKiBhIHJlYWwgcHJvYmxlbSwgZXZl biB0b2RheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW55d2F5OiB0aGlzIG1hc3RlciB0aGVzaXMgaXMgYXZhaWxhYmxlIGhlcmU6ICZuYnNw OzxhIGhyZWY9Imh0dHA6Ly9oZWltLmlmaS51aW8ubm8vbWljaGF3ZS90ZWFjaGluZy9kaXBscy9t YXJpdXMtb2xzZW4vbWFzdGVyc3RoZXNpcy1tYXJpdXNuby5wZGYiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vaGVpbS5pZmkudWlvLm5vL21pY2hhd2UvdGVhY2hpbmcvZGlwbHMvbWFyaXVzLW9sc2Vu L21hc3RlcnN0aGVzaXMtbWFyaXVzbm8ucGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIEkgdGhpbmsgSSBjYW4gc2FmZWx5IHNheSBv biBiZWhhbGYgb2YgRGF2aWQsIE1hcml1cyAodGhlIG1hc3RlciBzdHVkZW50IHdobyBkaWQgdGhp cykgYW5kIG15c2VsZiB0aGF0IHdl4oCZcmUgaGFwcHkgaWYgc29tZW9uZSBwaWNrcyB0aGlzIHVw IGFuZCBjb250aW51ZXMgdGhlIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCByZXF1aXJlIHNvbWUgZGlnZ2luZywgYnV0IEkg bWlnaHQgYWxzbyBzdGlsbCBoYXZlIHRoZSBjb2RlIGx5aW5nIGFyb3VuZCBzb21ld2hlcmUgLSBm b3Igc29tZSBvdXRkYXRlZCB2ZXJzaW9uIG9mIExpbnV44oCmPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB348585F3090AF94C3234231C2370DB4PR07MB348eurprd_--