From nobody Mon Aug 3 00:34:12 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA511A8981 for ; Mon, 3 Aug 2015 00:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=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 gSMXAKyfkrrX for ; Mon, 3 Aug 2015 00:34:06 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 5161D1A8978 for ; Mon, 3 Aug 2015 00:34:06 -0700 (PDT) Received: from [130.233.145.15] (130.233.145.15) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 552B87C9052CFF6B; Mon, 3 Aug 2015 10:33:57 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <55BBAA9D.9010907@mti-systems.com> Date: Mon, 3 Aug 2015 10:33:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <36EFC41C-1DD1-4C9A-AA78-24D8A4B0881B@iki.fi> References: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> <55BBAA9D.9010907@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2015 07:34:11 -0000 On 31 Jul 2015, at 20:04, Wesley Eddy wrote: > My only small feedback is that I think we definitely should call out > the TCPMUX part in the shepherd writeup or IETF LC text, since it has > been discussed on the IETF main list in the past, and should be > reviewed by applications-oriented people. What we did is clearly the > right thing for TCP (IMO), but someone out there may disagree, and = we'd > rather discuss with them during last call than after an RFC is out :). Right, that=92s a good point. We also discussed this in the TCPM list in = the past, but I might have missed the discussion on the main list. Will = try to reflect this appropriately in the write-up. It might be helpful to be a bit more verbose about the reasoning in that = part of the document. For example, "RFC 1078 destroys the semantics of = TCP connection establishment.=94 would benefit from a few additional = words explaining what this means. Also pointing to unspecified =93security= concerns=94 is a bit vague unless the text shortly clarifies what kind = of security concerns there are. - Pasi From nobody Mon Aug 3 01:26:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9370D1A8A95 for ; Mon, 3 Aug 2015 01:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YsPD9zWXXN1p for ; Mon, 3 Aug 2015 01:26:41 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527691A8A91 for ; Mon, 3 Aug 2015 01:26:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EA5C6D930B; Mon, 3 Aug 2015 10:26:39 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X-dlgbD9cCww; Mon, 3 Aug 2015 10:26:39 +0200 (MEST) Received: from [192.168.178.33] (x5f717ae3.dyn.telefonica.de [95.113.122.227]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 86260D9307; Mon, 3 Aug 2015 10:26:39 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 3 Aug 2015 10:26:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87B4CE79-9922-48FB-83CB-03ADF57D2963@tik.ee.ethz.ch> References: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2015 08:26:45 -0000 Hi Michael, as the doc is in very good shape, we could probably even try to find = this by the end of the year=E2=80=A6 but the authors have to decide here = I guess. Mirja > Am 24.07.2015 um 13:39 schrieb Scharf, Michael (Michael) = : >=20 > Hi all, >=20 > In the meeting on Wednesday, we had unanimous support for accepting = draft-bensley-tcpm-dctcp as new informational document in TCPM, and we = had strong consensus that the document should have the title "Datacenter = TCP (DCTCP): TCP Congestion Control for Datacenters". The scope is to = accurately document the protocol that has been implemented and deployed. >=20 > This e-mail intends to confirm that it is consensus in the TCPM = community to work on this document and to add a corresponding new = milestone to the TCPM charter. My suggestion for the charter milestone = would be:=20 >=20 > Apr 2016 Submit document on Datacenter TCP (DCTCP) to the IESG for = publication as Informational RFC >=20 > If you have any feedback or suggestions, please speak up in the next = two weeks. >=20 > Thanks >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Aug 3 01:32:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC7B1A8A95 for ; Mon, 3 Aug 2015 01:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.611 X-Spam-Level: X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CoLLZlxA6zmL for ; Mon, 3 Aug 2015 01:32:49 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CCC1A8A71 for ; Mon, 3 Aug 2015 01:32:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,600,1432623600"; d="asc'?scan'208";a="58727037" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 03 Aug 2015 01:31:48 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 3 Aug 2015 01:31:48 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::dc1c:7054:32f6:3f6b%21]) with mapi id 15.00.1076.000; Mon, 3 Aug 2015 01:31:48 -0700 From: "Eggert, Lars" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [tcpm] WG acceptance of draft-bensley-tcpm-dctcp Thread-Index: AdDGBXHBGm9udrRFSKiDGmxBaNoikwH+10gAAAAstAA= Date: Mon, 3 Aug 2015 08:31:47 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <87B4CE79-9922-48FB-83CB-03ADF57D2963@tik.ee.ethz.ch> In-Reply-To: <87B4CE79-9922-48FB-83CB-03ADF57D2963@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_CEBF1996-7A20-4430-94A6-D71FA9A46C82"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2015 08:32:50 -0000 --Apple-Mail=_CEBF1996-7A20-4430-94A6-D71FA9A46C82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2015-08-03, at 10:26, Mirja K=C3=BChlewind = wrote: > as the doc is in very good shape, we could probably even try to find = this by the end of the year=E2=80=A6 but the authors have to decide here = I guess. Agree that we should be able to wrap this up more quickly. Praveen is = currently addressing the feedback from Prague. If anyone has other = comments, please send them - the doc is otherwise ready from our = perspective. Lars --Apple-Mail=_CEBF1996-7A20-4430-94A6-D71FA9A46C82 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlW/JvIACgkQIWcjmsUTWRr1AQCgyp5wqV64GmzkyBeva9B0CEX0 1+0An2BarR9JDFRriTfGJbUbzvkK7grJ =XAEO -----END PGP SIGNATURE----- --Apple-Mail=_CEBF1996-7A20-4430-94A6-D71FA9A46C82-- From nobody Mon Aug 3 09:35:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AF31ACE41 for ; Mon, 3 Aug 2015 09:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 u5HMDuPF37XI for ; Mon, 3 Aug 2015 09:35:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 227B11ACE36 for ; Mon, 3 Aug 2015 09:35:31 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 75295182E7106 for ; Mon, 3 Aug 2015 16:35:27 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t73GZSnC023886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Aug 2015 18:35:28 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 3 Aug 2015 18:35:28 +0200 From: "De Schepper, Koen (Koen)" To: "tcpm@ietf.org" Thread-Topic: Review of draft-bensley-tcpm-dctcp Thread-Index: AQHQzgpn3A0Vvgdqn0K/B3i5owMDXA== Date: Mon, 3 Aug 2015 16:35:27 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Review of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2015 16:35:38 -0000 Hi All, I have reviewed the draft-bensley-tcpm-dctcp-05, and have following questio= ns/remarks: 1.) A general remark is that the draft does not explicitly mention what the= response is to drop, and how it interworks with the alpha and other state = variables. I think the issues with the Linux implementation justify a clear= description. 2.) When exactly is the first window reduction applied? Is it at the end of= an observation window, or when the first mark/drop is detected. To impleme= nt the "respond to congestion only once per window" requirement, is there a= separate mark and drop window state variable? If separate, this means that= if both drop and mark are detected the window can be reduced down to 25% i= n one RTT (as per RFC3168). 3.) Bullet 4 in section 3.3 states "If the sequence number is less than or = equal to DCTCP.WindowEnd". Is there a particular reason for the "or equal"?= I would assume that if the ACKed sequence number is equal to DCTCP.WindowE= nd a window of data is sent? 4.) The last sentence of section 3.3: "The setting of the Congestion Window= Reduced (CWR) bit is also exactly as per [RFC3168]". Is there a reason to = do this, and how does the receiver respond to this? (I assume a DCTCP recei= ver ignores it and an RFC3168 receiver needs it to stop echoing CE) 5.) The second paragraph of section 4 explains when DCTCP is activated, but= does not explicitly mentions what it means to deactivate DCTCP. If ECN is = successfully negotiated (but RTT> 10ms), will it still use ECN in the class= ic way, or will it stop sending ECT(0) packets? 6.) The last sentence of section 6 states: "Much like standard TCP, DCTCP i= s biased against flows with longer RTTs. A method for improving the fairnes= s of DCTCP has been proposed in [ADCTCP], but requires additional experimen= tal evaluation". This reads as if DCTCP has an improved bias compared to st= andard TCP, but if I am correct the DCTCP bias is different than that of st= andard TCP, and the method in [ADCTCP] aligns it closer (or equal) to that = of standard TCP, right? Regards, Koen. From nobody Tue Aug 4 01:25:33 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D455B1B36FF for ; Tue, 4 Aug 2015 01:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pQNRqJRUKBDx for ; Tue, 4 Aug 2015 01:25:30 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C2C1B36FD for ; Tue, 4 Aug 2015 01:25:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,607,1432623600"; d="scan'208";a="60274124" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx144-out.netapp.com with ESMTP; 04 Aug 2015 01:20:26 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 4 Aug 2015 01:20:25 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Tue, 4 Aug 2015 01:20:25 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti , Wesley Eddy , "Zimmermann, Alexander" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 Thread-Index: AQHQy5g3D89S1bQZFE6hGaC5IkDUnJ32RBSAgAQXlACAASihEA== Date: Tue, 4 Aug 2015 08:20:24 +0000 Message-ID: <0ddbcac360c444008febaa62ba5ef5eb@hioexcmbx05-prd.hq.netapp.com> References: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> <55BBAA9D.9010907@mti-systems.com> <36EFC41C-1DD1-4C9A-AA78-24D8A4B0881B@iki.fi> In-Reply-To: <36EFC41C-1DD1-4C9A-AA78-24D8A4B0881B@iki.fi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2015 08:25:32 -0000 One additional comment to the content; There is discussion in AQM about deprecation of RFC 3540 - the TCP Nonce bi= t, used in conjunction with ECT(1). At the same time, the proposal of AccECN (where I'm a coauthor) does re-use= that bit in different, but ECN-related ways, but without any connection to= ECT(1). There seems to be building concensus that burning ECT(1) for a minor, and u= ndeployed, feature as ECN Nonce was not the best idea, OTOH, having 3 (or m= ore) flag bits in the TCP header for ECN signaling is still useful. So the question is, shall 3540 be included in this draft and made historic = at this time? Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Pasi Sarolahti > Sent: Montag, 03. August 2015 09:34 > To: Wesley Eddy > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 >=20 >=20 > On 31 Jul 2015, at 20:04, Wesley Eddy wrote: >=20 > > My only small feedback is that I think we definitely should call out > > the TCPMUX part in the shepherd writeup or IETF LC text, since it has > > been discussed on the IETF main list in the past, and should be > > reviewed by applications-oriented people. What we did is clearly the > > right thing for TCP (IMO), but someone out there may disagree, and > > we'd rather discuss with them during last call than after an RFC is out > :). >=20 > Right, that's a good point. We also discussed this in the TCPM list in th= e > past, but I might have missed the discussion on the main list. Will try t= o > reflect this appropriately in the write-up. >=20 > It might be helpful to be a bit more verbose about the reasoning in that > part of the document. For example, "RFC 1078 destroys the semantics of TC= P > connection establishment." would benefit from a few additional words > explaining what this means. Also pointing to unspecified "security > concerns" is a bit vague unless the text shortly clarifies what kind of > security concerns there are. >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Aug 4 01:29:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003A31A8A42 for ; Tue, 4 Aug 2015 01:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HbCs90Y4kk6J for ; Tue, 4 Aug 2015 01:29:40 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE3B1A1A78 for ; Tue, 4 Aug 2015 01:29:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,607,1432623600"; d="scan'208";a="58914303" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx143-out.netapp.com with ESMTP; 04 Aug 2015 01:29:24 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 4 Aug 2015 01:29:22 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Tue, 4 Aug 2015 01:29:22 -0700 From: "Scheffenegger, Richard" To: "tcpm@ietf.org" , "Praveen Balasubramanian (pravb@microsoft.com)" , "Eggert, Lars" Thread-Topic: Review of draft-bensley-tcpm-dctcp Thread-Index: AQHQzgpxT32a1G1mK0OFkdDpIUY3B537gWcg Date: Tue, 4 Aug 2015 08:29:22 +0000 Message-ID: <689c340eb92f410a81cdb2c7e6115956@hioexcmbx05-prd.hq.netapp.com> References: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Review of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2015 08:29:41 -0000 Hi, regarding to this comment by Koen, >=20 > 4.) The last sentence of section 3.3: "The setting of the Congestion > Window Reduced (CWR) bit is also exactly as per [RFC3168]". Is there a > reason to do this, and how does the receiver respond to this? (I assume a > DCTCP receiver ignores it and an RFC3168 receiver needs it to stop echoin= g > CE) There is actually a gap in the description in RFC3168 for the case that a C= WR segment is also CE marked; at least one (significant) TCP stack got that= processing in the wrong order in the past, but not anymore.=20 The expected processing is to deal with CWR first (clear ECE - for a regula= r 3168 receiver), and the IP-header CE mark second (set ECE). Just wondering if this draft want's to describe the expected (proper) behav= ior for a regular 3168 receiver - or a DCTCP receiver in 3168 mode - somewh= ere, so that we have this as an RFC? (But with some luck, all receivers will deploy AccECN anyhow, very soon (TM= ) :) ). Best regards, Richard =20 From nobody Tue Aug 4 01:36:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F54C1A8AB1 for ; Tue, 4 Aug 2015 01:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 az2QOub85JPt for ; Tue, 4 Aug 2015 01:36:03 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485B11A0061 for ; Tue, 4 Aug 2015 01:36:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,607,1432623600"; d="asc'?scan'208";a="61125333" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 04 Aug 2015 01:35:38 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 4 Aug 2015 01:35:37 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5d71:223d:8930:405%21]) with mapi id 15.00.1076.000; Tue, 4 Aug 2015 01:35:37 -0700 From: "Zimmermann, Alexander" To: "Scheffenegger, Richard" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 Thread-Index: AQHQy5g3hpMDbn/brEyReUshc0olRZ32RBSAgAQXlACAAZ9SAIAABDsA Date: Tue, 4 Aug 2015 08:35:36 +0000 Message-ID: References: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> <55BBAA9D.9010907@mti-systems.com> <36EFC41C-1DD1-4C9A-AA78-24D8A4B0881B@iki.fi> <0ddbcac360c444008febaa62ba5ef5eb@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <0ddbcac360c444008febaa62ba5ef5eb@hioexcmbx05-prd.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_85DE18C3-6A80-4FC8-835C-61F9A2EA874B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2015 08:36:05 -0000 --Apple-Mail=_85DE18C3-6A80-4FC8-835C-61F9A2EA874B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 04.08.2015 um 10:20 schrieb Scheffenegger, Richard : >=20 >=20 > One additional comment to the content; >=20 > There is discussion in AQM about deprecation of RFC 3540 - the TCP = Nonce bit, used in conjunction with ECT(1). >=20 > At the same time, the proposal of AccECN (where I'm a coauthor) does = re-use that bit in different, but ECN-related ways, but without any = connection to ECT(1). >=20 >=20 > There seems to be building concensus that burning ECT(1) for a minor, = and undeployed, feature as ECN Nonce was not the best idea, OTOH, having = 3 (or more) flag bits in the TCP header for ECN signaling is still = useful. >=20 > So the question is, shall 3540 be included in this draft and made = historic at this time? No, because the purpose of this document is completely different. From the abstract: This document reclassifies several TCP extensions and TCP-related documents that have either been superseded, never seen widespread use, or are no longer recommended for use to Historic status. And from the introduction: Section 6 and 7.1 of the TCP Roadmap document [RFC7414] already classify a number of TCP extensions as "historic" and describes the reasons for doing so, but it does not instruct the RFC Editor to change the status of these RFCs in the RFC database. The purpose of this document is to do just that. Alex >=20 > Best regards, > Richard >=20 >=20 >=20 >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Pasi Sarolahti >> Sent: Montag, 03. August 2015 09:34 >> To: Wesley Eddy >> Cc: tcpm@ietf.org Extensions >> Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 >>=20 >>=20 >> On 31 Jul 2015, at 20:04, Wesley Eddy wrote: >>=20 >>> My only small feedback is that I think we definitely should call out >>> the TCPMUX part in the shepherd writeup or IETF LC text, since it = has >>> been discussed on the IETF main list in the past, and should be >>> reviewed by applications-oriented people. What we did is clearly = the >>> right thing for TCP (IMO), but someone out there may disagree, and >>> we'd rather discuss with them during last call than after an RFC is = out >> :). >>=20 >> Right, that's a good point. We also discussed this in the TCPM list = in the >> past, but I might have missed the discussion on the main list. Will = try to >> reflect this appropriately in the write-up. >>=20 >> It might be helpful to be a bit more verbose about the reasoning in = that >> part of the document. For example, "RFC 1078 destroys the semantics = of TCP >> connection establishment." would benefit from a few additional words >> explaining what this means. Also pointing to unspecified "security >> concerns" is a bit vague unless the text shortly clarifies what kind = of >> security concerns there are. >>=20 >> - Pasi >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_85DE18C3-6A80-4FC8-835C-61F9A2EA874B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXAeVQACgkQdyiq39b9uS7AdgCgwtOn1/t7lfmPM862loelQKse 7/EAoLL6B+yskaAPN1jn3mplvrNlOYnH =GBBb -----END PGP SIGNATURE----- --Apple-Mail=_85DE18C3-6A80-4FC8-835C-61F9A2EA874B-- From nobody Tue Aug 4 01:37:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104BF1A8AB1 for ; Tue, 4 Aug 2015 01:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 nwwoYUPx2ag1 for ; Tue, 4 Aug 2015 01:37:54 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id F02211A8794 for ; Tue, 4 Aug 2015 01:37:53 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.130) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5511FF5807B4BA36; Tue, 4 Aug 2015 11:37:44 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <0ddbcac360c444008febaa62ba5ef5eb@hioexcmbx05-prd.hq.netapp.com> Date: Tue, 4 Aug 2015 11:37:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <71320D0F-C7BB-4945-B763-4CD8DB3BCCAA@iki.fi> References: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> <55BBAA9D.9010907@mti-systems.com> <36EFC41C-1DD1-4C9A-AA78-24D8A4B0881B@iki.fi> <0ddbcac360c444008febaa62ba5ef5eb@hioexcmbx05-prd.hq.netapp.com> To: Richard Scheffenegger X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2015 08:37:56 -0000 On 04 Aug 2015, at 11:20, Scheffenegger, Richard wrote: > So the question is, shall 3540 be included in this draft and made = historic at this time? Now that we are already in WGLC, I would not include it, and I don=92t = see any urgency to make it historic at this point. If AccECN = specification goes forward re-using the bit, it could obsolete RFC 3540, = if that is the consensus of the WG. - Pasi From nobody Tue Aug 4 02:08:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA041A8A8D for ; Tue, 4 Aug 2015 02:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 J0k2Tzf2WTP9 for ; Tue, 4 Aug 2015 02:08:28 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCEC1A8A82 for ; Tue, 4 Aug 2015 02:08:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,607,1432623600"; d="scan'208";a="58034661" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx142-out.netapp.com with ESMTP; 04 Aug 2015 02:03:24 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 4 Aug 2015 02:03:24 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Tue, 4 Aug 2015 02:03:24 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 Thread-Index: AQHQy5g3D89S1bQZFE6hGaC5IkDUnJ32RBSAgAQXlACAASihEIAAe4QA//+RxVA= Date: Tue, 4 Aug 2015 09:03:23 +0000 Message-ID: <0c7774cc9efe4abcb598759523c36758@hioexcmbx05-prd.hq.netapp.com> References: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> <55BBAA9D.9010907@mti-systems.com> <36EFC41C-1DD1-4C9A-AA78-24D8A4B0881B@iki.fi> <0ddbcac360c444008febaa62ba5ef5eb@hioexcmbx05-prd.hq.netapp.com> <71320D0F-C7BB-4945-B763-4CD8DB3BCCAA@iki.fi> In-Reply-To: <71320D0F-C7BB-4945-B763-4CD8DB3BCCAA@iki.fi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2015 09:08:29 -0000 Ok, sounds good to me! Thanks Alex, Pasi! > -----Original Message----- > From: Pasi Sarolahti [mailto:pasi.sarolahti@iki.fi] > Sent: Dienstag, 04. August 2015 10:38 > To: Scheffenegger, Richard > Cc: Wesley Eddy; Zimmermann, Alexander; tcpm@ietf.org Extensions > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 >=20 > On 04 Aug 2015, at 11:20, Scheffenegger, Richard wrote: >=20 > > So the question is, shall 3540 be included in this draft and made > historic at this time? >=20 > Now that we are already in WGLC, I would not include it, and I don't see > any urgency to make it historic at this point. If AccECN specification > goes forward re-using the bit, it could obsolete RFC 3540, if that is the > consensus of the WG. >=20 > - Pasi From nobody Tue Aug 4 10:22:32 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751161A891B for ; Tue, 4 Aug 2015 10:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FgAlj7q6K2tp for ; Tue, 4 Aug 2015 10:22:30 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E411A8927 for ; Tue, 4 Aug 2015 10:22:22 -0700 (PDT) Received: from [128.9.184.236] ([128.9.184.236]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t74HLRQA025958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Aug 2015 10:21:27 -0700 (PDT) To: Wesley Eddy , Pasi Sarolahti , "tcpm@ietf.org Extensions" References: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> <55BBAA9D.9010907@mti-systems.com> From: Joe Touch Message-ID: <55C0F496.3010501@isi.edu> Date: Tue, 4 Aug 2015 10:21:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55BBAA9D.9010907@mti-systems.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t74HLRQA025958 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2015 17:22:31 -0000 On 7/31/2015 10:04 AM, Wesley Eddy wrote: > My only small feedback is that I think we definitely should call out > the TCPMUX part in the shepherd writeup or IETF LC text, since it has > been discussed on the IETF main list in the past, and should be > reviewed by applications-oriented people. What we did is clearly the > right thing for TCP (IMO), but someone out there may disagree, and we'd > rather discuss with them during last call than after an RFC is out :). I heartily agree. I don't think we'll get pushback from anyone who actually uses it though; most of the confusion on the main list has been from people who either heard about it long ago or just found it and either way don't know it's been basically deprecated for decades or why. Joe From nobody Fri Aug 7 08:30:04 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1C1A923A for ; Fri, 7 Aug 2015 08:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 p1cDQbP7xPOz for ; Fri, 7 Aug 2015 08:29:55 -0700 (PDT) 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 ED5FF1A9163 for ; Fri, 7 Aug 2015 08:29:54 -0700 (PDT) Received: from [84.93.215.252] (port=52749 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZNjai-00020q-I8; Fri, 07 Aug 2015 16:29:52 +0100 Message-ID: <55C4CEEF.1040504@bobbriscoe.net> Date: Fri, 07 Aug 2015 16:29:51 +0100 From: Bob Briscoe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "SCHARF, Michael" , "SAROLAHTI, Pasi" , Yoshifumi Nishada , tcpm IETF list References: <55C4C4CB.9080302@bobbriscoe.net> In-Reply-To: <55C4C4CB.9080302@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------060201040301020000020005" 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 Archived-At: Cc: Olga Bondarenko Subject: [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2015 15:30:00 -0000 This is a multi-part message in MIME format. --------------060201040301020000020005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit tcpm chairs & list. Cross-posting this announcement to tcpm, given its about evolving TCP and its interaction with AQMs. If you were in Prague you may have seen this AQM demonstrated over a broadband Internet testbed. Here's the video (starts at about 33mins - your browser has to support HTML5). This DualQ Coupled AQM exploits ECN and scalable TCP algos like Data Centre TCP (DCTCP). In our extensive testing, it gave zero congestion loss and about 1ms queuing latency at the 98th percentile, even under high load. It is designed to allow DCTCP to co-exist with existing TCP Cubic & Reno, whether mixed within a data centre, on private networks or on the public Internet. We believe a WG will need to be found for evolution of DCTCP (there is currently a non-WG mailing list called tcpprague@ietf.org for this). Currently the list of safety mods needed in DCTCP is in an appendix, but it says that is only a temporary home. Otherwise we expect any WG activity to be in tsvwg and AQM, so for tcpm this is just an FYI email at the moment. Cheers Bob, Koen, Olga & Inton -------- Forwarded Message -------- Subject: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt Date: Fri, 07 Aug 2015 15:46:35 +0100 From: Bob Briscoe To: Scheffenegger, Richard , Wesley Eddy , AQM IETF list CC: De Schepper, Koen (Koen) , TSANG Inton , Olga Bondarenko AQM Chairs, list, My co-authors and I have just posted a draft spec of the DualQ Coupled AQM we presented and demonstrated in Prague under the title "Data Centre to the Home" (see announcement quoted below). *Invitation to reimplement / bash** *We are not asking for adoption right now. But we would be happy if others tried to reimplement it using our description and to test it independently. We are trying to get approval from employers to release it as open source, but you will see that the pseudocode is only 15 lines, so it should not be hard to reimplement. The draft refers out to our 'under-submission' DCttH paper reporting a selection of the thousands of experiments we did ourselves. We are preparing a tech report to record the rest. Cheers Bob, Koen, Olga & Inton. -------- Forwarded Message -------- Subject: New Version Notification for draft-briscoe-aqm-dualq-coupled-00.txt Date: Fri, 07 Aug 2015 06:41:15 -0700 From: internet-drafts@ietf.org To: Koen De Schepper , Ing-jyh Tsang , Bob Briscoe , Olga Bondarenko , Koen De Schepper , Olga Bondarenko , Bob Briscoe , ing-jyh.tsang@alcatel-lucent.com A new version of I-D, draft-briscoe-aqm-dualq-coupled-00.txt has been successfully submitted by Bob Briscoe and posted to the IETF repository. Name: draft-briscoe-aqm-dualq-coupled Revision: 00 Title: DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput Document date: 2015-08-07 Group: Individual Submission Pages: 22 URL:https://www.ietf.org/internet-drafts/draft-briscoe-aqm-dualq-coupled-00.txt Status:https://datatracker.ietf.org/doc/draft-briscoe-aqm-dualq-coupled/ Htmlized:https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled-00 Abstract: Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---throughput starves. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines `DualQ Coupled Active Queue Management (AQM)' to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and `Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration. 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 --------------060201040301020000020005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit tcpm chairs & list.

Cross-posting this announcement to tcpm, given its about evolving TCP and its interaction with AQMs.

If you were in Prague you may have seen this AQM demonstrated over a broadband Internet testbed. Here's the video (starts at about 33mins - your browser has to support HTML5).

This DualQ Coupled AQM exploits ECN and scalable TCP algos like Data Centre TCP (DCTCP).  In our extensive testing, it gave zero congestion loss and about 1ms queuing latency at the 98th percentile, even under high load. It is designed to allow DCTCP to co-exist with existing TCP Cubic & Reno, whether mixed within a data centre, on private networks or on the public Internet.

We believe a WG will need to be found for evolution of DCTCP (there is currently a non-WG mailing list called tcpprague@ietf.org for this). Currently the list of safety mods needed in DCTCP is in an appendix, but it says that is only a temporary home.

Otherwise we expect any WG activity to be in tsvwg and AQM, so for tcpm this is just an FYI email at the moment.


Cheers



Bob, Koen, Olga & Inton


-------- Forwarded Message --------
Subject: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt
Date: Fri, 07 Aug 2015 15:46:35 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Scheffenegger, Richard <rs@netapp.com>, Wesley Eddy <wes@mti-systems.com>, AQM IETF list <aqm@ietf.org>
CC: De Schepper, Koen (Koen) <koen.de_schepper@alcatel-lucent.com>, TSANG Inton <ing-jyh.tsang@alcatel-lucent.com>, Olga Bondarenko <olgabnd@gmail.com>


AQM Chairs, list,

My co-authors and I have just posted a draft spec of the DualQ Coupled AQM we presented and demonstrated in Prague under the title "Data Centre to the Home" (see announcement quoted below).

Invitation to reimplement / bash
We are not asking for adoption right now. But we would be happy if others tried to reimplement it using our description and to test it independently. We are trying to get approval from employers to release it as open source, but you will see that the pseudocode is only 15 lines, so it should not be hard to reimplement.

The draft refers out to our 'under-submission' DCttH paper reporting a selection of the thousands of experiments we did ourselves. We are preparing a tech report to record the rest.

Cheers



Bob, Koen, Olga & Inton.


-------- Forwarded Message --------
Subject: New Version Notification for draft-briscoe-aqm-dualq-coupled-00.txt
Date: Fri, 07 Aug 2015 06:41:15 -0700
From: internet-drafts@ietf.org
To: Koen De Schepper <koen.de_schepper@alcatel-lucent.com>, Ing-jyh Tsang <ing-jyh.tsang@alcatel-lucent.com>, Bob Briscoe <ietf@bobbriscoe.net>, Olga Bondarenko <olgabnd@gmail.com>, Koen De Schepper <koen.de_schepper@alcatel-lucent.com>, Olga Bondarenko <olgabnd@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, ing-jyh.tsang@alcatel-lucent.com <ing-jyh.tsang@alcatel-lucent.com> 


A new version of I-D, draft-briscoe-aqm-dualq-coupled-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:		draft-briscoe-aqm-dualq-coupled
Revision:	00
Title:		DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput
Document date:	2015-08-07
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-briscoe-aqm-dualq-coupled-00.txt
Status:         https://datatracker.ietf.org/doc/draft-briscoe-aqm-dualq-coupled/
Htmlized:       https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled-00


Abstract:
   Data Centre TCP (DCTCP) was designed to provide predictably low
   queuing latency, near-zero loss, and throughput scalability using
   explicit congestion notification (ECN) and an extremely simple
   marking behaviour on switches.  However, DCTCP does not co-exist with
   existing TCP traffic---throughput starves.  So, until now, DCTCP
   could only be deployed where a clean-slate environment could be
   arranged, such as in private data centres.  This specification
   defines `DualQ Coupled Active Queue Management (AQM)' to allow
   scalable congestion controls like DCTCP to safely co-exist with
   classic Internet traffic.  The Coupled AQM ensures that a flow runs
   at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but
   without inspecting transport layer flow identifiers.  When tested in
   a residential broadband setting, DCTCP achieved sub-millisecond
   average queuing delay and zero congestion loss under a wide range of
   mixes of DCTCP and `Classic' broadband Internet traffic, without
   compromising the performance of the Classic traffic.  The solution
   also reduces network complexity and eliminates network configuration.

                                                                                  


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




--------------060201040301020000020005-- From nobody Wed Aug 12 04:49:05 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EEF1A9172 for ; Wed, 12 Aug 2015 04:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 6MReN-YmTaRI for ; Wed, 12 Aug 2015 04:49:01 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 755061A916A for ; Wed, 12 Aug 2015 04:49:01 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ZPUWh-0008UL-MB; Wed, 12 Aug 2015 13:48:59 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 8B788B001BB; Wed, 12 Aug 2015 13:48:59 +0200 (CEST) Message-ID: <55CB32AB.6000207@kit.edu> Date: Wed, 12 Aug 2015 13:48:59 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1439380139. Archived-At: Cc: "Goltsman, Polina" , Mario Hock Subject: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 11:49:03 -0000 Hi, [not sure that this actually belongs to this WG, but I think it might be interesting input...] while investigating TCP streams at 10Gbit/s we saw several retransmissions without actual packet loss happen. The analysis showed that it was caused by the GRO (Generic Receive Offload) feature together with the FACK optimization (under Linux 4.1.x). The receiving side produced two larger out-of-order segments (of sizes 10k and 20k respectively), i.e., they were swapped (not on the wire, but locally). The FACK algorithm then determines that more than three segments have been reordered and (unnecessarily) starts retransmission of several segments. [Thanks to Polina Goltsman for finding this]. Turning SACK, DSACK and FACK off eliminates such retransmissions completely. This is IMHO another example of a bad feature interaction between "smart" local optimizations and protocols. Implementations get more complicated, because they have to distinguish between what's probably on the wire and what is locally optimized (if possible at all). Now the question: does anyone know the reason for the local re-ordering at the receiving side? [Presumably, it is caused by internal re-hashing of TCP flows to input queues, but that's a rough guess only.] If the implementers thought, re-ordering is no problem, because TCP will deal with it - this is a little bit short-sighted as shown above. So either the GRO implementation needs to be fixed to avoid re-ordered delivery or the TCP implementation needs to be made more GRO-aware. Regards, Roland From nobody Wed Aug 12 13:17:18 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1671AC427 for ; Wed, 12 Aug 2015 13:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 pz2DKkiqrJVW for ; Wed, 12 Aug 2015 13:17:15 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564431AC41D for ; Wed, 12 Aug 2015 13:17:15 -0700 (PDT) Received: by vkhl6 with SMTP id l6so10231647vkh.1 for ; Wed, 12 Aug 2015 13:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=m6WDkLQ6CV3fOinVPly9154FFfswJhFP4UoLRGp2fnk=; b=R4fz4c23qD8nByEsmZu9W4MI96EA/RzHoHRDthX8gNRhB/KhYfRqbFktHSMMzld5YG Ik3euG5OYi2XyIRIpX/onLww5XYJUzgSMKt3vbF8A168QXy3pzEER0nLzdBL41+SuZUv eAnvXXz1KXJ+7ThMkC7xzJRlgy4VjC2QKmT1/9JT4WXKcXwqJQ6ArKRuye0CyMATdp93 rmwaKr4ra4XvRKTf8cg1xbixMjVkMKrZTeXqRWxMTz1aLNlmhTHWsTgPzrWHQeAyYOT5 Pw02LmKJGyKdDYnauMYQxmsEgHo8oTpr6nPAkcZps9RiOVuHLaI28tfH2wrStGFzrj3m Mokw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=m6WDkLQ6CV3fOinVPly9154FFfswJhFP4UoLRGp2fnk=; b=KL2hp48Wu99zSzhQ+FJva8t9VxncIAG91OWnZZlqXD8eeEoHHvIQGoujjSwodsasXB +ziS8bCCd3fm4WEvnaynHP6sXJjFX9Iu1yUuTa9zfWGhc8TfnDQoVk52CWdAVoN4bFeR F3QUT8tbtqaEqewElzAwRWuKqEYuFYoBSNcelXIAJi/dO0gjpG5qKtWRJka1nFApkFyH GXdDJUZR+gWuveGmzLVok8DfyGJyA7rFupB4FitFmxou8HfbEELpf4MYBUFuLMKjStAh cCJlCIpLd9NX2/Rrl0I3NCINjC1w11s6TzZgn0bbykLOtpRaV50Dj2vWmvR0+5ZfUKh1 3Yfg== X-Gm-Message-State: ALoCoQlYDFy2NkrDyDGPRjLINKHIR+WOuIBxBC8p43ZXaDTRZGeZaZWzoiMql9g7iwZTcEVYLwJd X-Received: by 10.52.139.239 with SMTP id rb15mr42944746vdb.76.1439410634350; Wed, 12 Aug 2015 13:17:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Wed, 12 Aug 2015 13:16:34 -0700 (PDT) In-Reply-To: <55CB32AB.6000207@kit.edu> References: <55CB32AB.6000207@kit.edu> From: Yuchung Cheng Date: Wed, 12 Aug 2015 13:16:34 -0700 Message-ID: To: "Bless, Roland (TM)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 20:17:16 -0000 On Wed, Aug 12, 2015 at 4:48 AM, Bless, Roland (TM) wrote: > Hi, > > [not sure that this actually belongs to this WG, but I think > it might be interesting input...] > > while investigating TCP streams at 10Gbit/s we saw several > retransmissions without actual packet loss happen. The > analysis showed that it was caused by the GRO (Generic Receive > Offload) feature together with the FACK optimization > (under Linux 4.1.x). > The receiving side produced two larger out-of-order segments > (of sizes 10k and 20k respectively), i.e., they were swapped > (not on the wire, but locally). > The FACK algorithm then determines that more than three > segments have been reordered and (unnecessarily) starts > retransmission of several segments. > [Thanks to Polina Goltsman for finding this]. > Turning SACK, DSACK and FACK off eliminates > such retransmissions completely. In your case, the spurious retransmission/recovery would be detected by TCP timestamps. Subsequently Linux would 1) revert cwnd reduction, 2) raise the dupthresh and 3) disables FACK. Since cwnd is recovered the connection won't lose tput except wasting some spurious retransmits. > > This is IMHO another example of a bad feature > interaction between "smart" local optimizations and > protocols. Implementations get more complicated, because > they have to distinguish between what's probably on the > wire and what is locally optimized (if possible at all). > > Now the question: does anyone know the reason for the > local re-ordering at the receiving side? [Presumably, > it is caused by internal re-hashing of TCP flows > to input queues, but that's a rough guess only.] > > If the implementers thought, re-ordering is no problem, > because TCP will deal with it - this is a little bit > short-sighted as shown above. So either the GRO implementation > needs to be fixed to avoid re-ordered delivery or the TCP > implementation needs to be made more GRO-aware. I am skeptical GRO is the culprit of reordering. GRO does not reorder packets b/c it's single lane processing. It may be other input pathing problems not GRO. > > Regards, > Roland > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Aug 12 14:55:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449051ACE57 for ; Wed, 12 Aug 2015 14:55:48 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 6Dvug1xy1FAC for ; Wed, 12 Aug 2015 14:55:47 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 A47381ACE56 for ; Wed, 12 Aug 2015 14:55:46 -0700 (PDT) Received: by pacrr5 with SMTP id rr5so22763837pac.3 for ; Wed, 12 Aug 2015 14:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=sgN7ODLcRZsqdMqGqgWgTGoLYQEUh47i5Nq+ES5XxZ4=; b=eIuN6MH70UHQ3bYpcJKcmV9H/OwU/TU4m1y2nME06mKtt+VcPnlphvmfK3NQw+HtvS ukl3lZ1W8Z4dae9ZOFF4Kgmnz7F5RQfVYZ2FZquIPnqmqDdMi+oG9FYkJLzi2l4/X2GK D4zyFYCR3U38NgN3tgzndN/1XGuGMBhh4OcIWakVhgWipBeiW95IEaHeZvxRWZH63CCZ sqkemVF/sWNjJCBeGjciuz2+Vc3vEw2x8STKrS3rY/gBkW+simdI/VA1anpFzcTws39n TOGwpdMgSb8juV9gyM/Gqy8lnyuQrgAByMEEnRaGhTyf8ugPO+RA/8aP1PHL+v7v/ELY fYXA== X-Received: by 10.68.135.194 with SMTP id pu2mr50216353pbb.131.1439416546321; Wed, 12 Aug 2015 14:55:46 -0700 (PDT) Received: from ?IPv6:2620:0:1000:3e02:94bf:915a:93b7:7693? ([2620:0:1000:3e02:94bf:915a:93b7:7693]) by smtp.gmail.com with ESMTPSA id bx7sm95662pdb.82.2015.08.12.14.55.45 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2015 14:55:45 -0700 (PDT) Message-ID: <1439416545.29802.24.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Yuchung Cheng Date: Wed, 12 Aug 2015 14:55:45 -0700 In-Reply-To: References: <55CB32AB.6000207@kit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2015 21:55:48 -0000 On Wed, 2015-08-12 at 13:16 -0700, Yuchung Cheng wrote: > I am skeptical GRO is the culprit of reordering. GRO does not reorder > packets b/c it's single lane processing. It may be other input pathing > problems not GRO. Indeed, I am not aware of GRO being so badly broken. We had some bugs in the past, but not of this magnitude. More details are needed : - Model of NIC - RPS/RFS settings if any - Interrupt affinities My suspicion is that you use some kind of aRFS NIC (flow director), and some ACK packets reprogram the NIC to receive packets on a different RX queue. From nobody Thu Aug 13 07:58:00 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6561A6F5D for ; Thu, 13 Aug 2015 07:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 tBcniSsSYr9e for ; Thu, 13 Aug 2015 07:57:55 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 679F71A6F3C for ; Thu, 13 Aug 2015 07:57:53 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ZPtx2-00051q-MM; Thu, 13 Aug 2015 16:57:52 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 94B87B012E2; Thu, 13 Aug 2015 16:57:52 +0200 (CEST) Message-ID: <55CCB070.9000006@kit.edu> Date: Thu, 13 Aug 2015 16:57:52 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Yuchung Cheng References: <55CB32AB.6000207@kit.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1439477872. Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 14:57:57 -0000 Hi Yuchung, thanks for you quick response. Am 12.08.2015 um 22:16 schrieb Yuchung Cheng: > In your case, the spurious retransmission/recovery would be detected > by TCP timestamps. Subsequently Linux would 1) revert cwnd reduction, > 2) raise the dupthresh and 3) disables FACK. Since cwnd is recovered > the connection won't lose tput except wasting some spurious > retransmits. According to our pcap file, the reordered chunks are 2*10^-6 (2µs) apart from each other. The TCP timestamps are exactly the same in this case, so no chance to detect reordering by using timestamps. > I am skeptical GRO is the culprit of reordering. GRO does not reorder > packets b/c it's single lane processing. It may be other input pathing > problems not GRO. Maybe it's happening earlier or later in the local delivery path. We are still trying to find out the cause, currently, we are seeing the symptoms only. Regards, Roland From nobody Thu Aug 13 08:19:32 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3922A1A7D82 for ; Thu, 13 Aug 2015 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 wY-FtJR9HaXF for ; Thu, 13 Aug 2015 08:19:29 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 E05991A86E9 for ; Thu, 13 Aug 2015 08:19:11 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ZPuHd-0006Po-Ru; Thu, 13 Aug 2015 17:19:09 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id C0FE9B012E2; Thu, 13 Aug 2015 17:19:09 +0200 (CEST) Message-ID: <55CCB56D.9060903@kit.edu> Date: Thu, 13 Aug 2015 17:19:09 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Eric Dumazet , Yuchung Cheng References: <55CB32AB.6000207@kit.edu> <1439416545.29802.24.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1439416545.29802.24.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1439479149. Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 15:19:31 -0000 Hi Eric, Am 12.08.2015 um 23:55 schrieb Eric Dumazet: > On Wed, 2015-08-12 at 13:16 -0700, Yuchung Cheng wrote: > >> I am skeptical GRO is the culprit of reordering. GRO does not reorder >> packets b/c it's single lane processing. It may be other input pathing >> problems not GRO. > > Indeed, I am not aware of GRO being so badly broken. Maybe it's not caused by GRO and our first guess was wrong. We are still investingating. > We had some bugs in the past, but not of this magnitude. > > More details are needed : > - Model of NIC > - RPS/RFS settings if any > - Interrupt affinities See below... > My suspicion is that you use some kind of aRFS NIC (flow director), and > some ACK packets reprogram the NIC to receive packets on a different RX > queue. Here is what Polina says (she's not on the tcpm list): ---------------------------------------------------------------------- Our computers: each is equipped with Xeon-E5 (32cores) and four-port Intel x710 NICs (probably X710-DA4 but I am not sure) and are running Linux 4.1.2. We test it with iperf3 (v3.1b3) - single TCP flow with data going only in one direction and no additional parameters. Receive Flow Steering is off: $ cat /proc/sys/net/core/rps_sock_flow_entries 0 Receive Packet Steering is off for all queues: $cat /sys/class/net/enp2s0f0/queues/rx-*/rps_cpus 00000000 ... 00000000 As far as I can tell from /proc/interrupts and /proc/irq//smp_affinity each Rx queue is assigned to one core (TxRx queue N (i40e-eth1-TxRx-N) is assigned to core N). Currently, I can't figure out how to read flow director rules in Linux. This is what I observe when I run iperf3 experiments: At the receiver: 1. somewhere one a scale of several seconds the queue that receives packets changes (when I check stats with ethtool -S, counters of different queue rx-.rx_packets are incremented). At about the same time different CPU core processes packets (gets loaded with system or softirq process). 2. another stat that gets incremented is: port.fdir_atr_match At the sender: I observe similar queue switching behavior at the sender. The core processing the packets and the queue occasionally change, it sometimes happen every 20-30 seconds and sometimes after about 3 seconds. Time difference in tcpdump between two reordered packets is 2-3 microseconds. Both packets have the same TCP timestamp. Here are two more observations that seem strange to me: At the sender: If I send 512 segments with netperf [netperf -H 10.0.0.1 -l 180 -D 1 -- -m 512 ], CPU core gets 100% utilization and the queues/cores are not switched. At the receiver: When sender is called with netperf -H 10.0.0.1 -l 180 -D 1 -- -M 512, CPU core gets 100% utilization and the queues/cores are not switched. ---------------------------------------- Regards, Roland From nobody Thu Aug 13 08:52:03 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9699F1A88AC for ; Thu, 13 Aug 2015 08:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AxWHV_dt1Gjv for ; Thu, 13 Aug 2015 08:52:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 1CE361A88A3 for ; Thu, 13 Aug 2015 08:52:01 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id CA4DB70DBC216; Thu, 13 Aug 2015 15:51:56 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t7DFpxpH025970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Aug 2015 17:51:59 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 13 Aug 2015 17:51:58 +0200 From: "Scharf, Michael (Michael)" To: "Eggert, Lars" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [tcpm] WG acceptance of draft-bensley-tcpm-dctcp Thread-Index: AdDGBXHBGm9udrRFSKiDGmxBaNoikwHr+04AAAAs2oACCiBCEA== Date: Thu, 13 Aug 2015 15:51:58 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4845E835@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <87B4CE79-9922-48FB-83CB-03ADF57D2963@tik.ee.ethz.ch> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 15:52:02 -0000 SSBjYW4gY2hhbmdlIHRoZSBtaWxlc3RvbmUgdG8gYW4gZWFybGllciBkYXRlLiBXaGF0IGRhdGUg d291bGQgdGhlIGF1dGhvcnMgc3VnZ2VzdD8NCg0KRm9yIHBhc3QgZG9jdW1lbnRzLCBJIGhhdmUg dXN1YWxseSB0cmllZCB0byBwaWNrIGEgZGF0ZSB0aGF0IHNlZW1lZCByZWFsaXN0aWMgdG8gbWUg d2hlbiB0aGUgZG9jIHdhcyBhZG9wdGVkIGluIFRDUE0sIGFuZCBpbiBhbG1vc3QgYWxsIGNhc2Vz IHdlIGZpbmFsbHkgbWlzc2VkIHRoZSBtaWxlc3RvbmUgZGF0ZS4uLiBQcm9ncmVzcyBpbiBUQ1BN IGRlcGVuZHMgdG8gYSBsYXJnZSBleHRlbnQgb24gYXV0aG9yIGN5Y2xlcywgd2hpY2ggYXJlIG5v dCB0cml2aWFsIHRvIHByZWRpY3QuLi4NCg0KSW4gY2FzZSBvZiB0aGlzIHNwZWNpZmljIGRvY3Vt ZW50LCBJIHRoaW5rIGhhdmUgYSBudW1iZXIgb2YgY29tbWVudHMgdG8gYmUgYWRkcmVzc2VkLiBB bmQgSSBjb3VsZCBpbWFnaW5lIGZ1cnRoZXIgY29tbWVudHMgd2lsbCBmb2xsb3cgb25jZSB0aGUg bmV4dCB2ZXJzaW9uIGlzIHB1Ymxpc2hlZC4gQXQgbGVhc3QgSSB3aWxsIHByb2JhYmx5IGhhdmUg YSBsb29rIGF0IHRoZSBuZXh0IHZlcnNpb24uIFdoZW4gZG8gdGhlIGF1dGhvcnMgdGhpbmsgdGhh dCBhbGwgcmV2aWV3cyB3aWxsIGJlIGFkZHJlc3NlZD8NCg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRWdnZXJ0LCBMYXJzIFttYWlsdG86 bGFyc0BuZXRhcHAuY29tXSANClNlbnQ6IE1vbnRhZywgMy4gQXVndXN0IDIwMTUgMTA6MzINClRv OiBNaXJqYSBLw7xobGV3aW5kDQpDYzogU2NoYXJmLCBNaWNoYWVsIChNaWNoYWVsKTsgdGNwbUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0Y3BtXSBXRyBhY2NlcHRhbmNlIG9mIGRyYWZ0LWJlbnNs ZXktdGNwbS1kY3RjcA0KDQpPbiAyMDE1LTA4LTAzLCBhdCAxMDoyNiwgTWlyamEgS8O8aGxld2lu ZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4gd3JvdGU6DQo+IGFzIHRoZSBkb2Mg aXMgaW4gdmVyeSBnb29kIHNoYXBlLCB3ZSBjb3VsZCBwcm9iYWJseSBldmVuIHRyeSB0byBmaW5k IHRoaXMgYnkgdGhlIGVuZCBvZiB0aGUgeWVhcuKApiBidXQgdGhlIGF1dGhvcnMgaGF2ZSB0byBk ZWNpZGUgaGVyZSBJIGd1ZXNzLg0KDQpBZ3JlZSB0aGF0IHdlIHNob3VsZCBiZSBhYmxlIHRvIHdy YXAgdGhpcyB1cCBtb3JlIHF1aWNrbHkuIFByYXZlZW4gaXMgY3VycmVudGx5IGFkZHJlc3Npbmcg dGhlIGZlZWRiYWNrIGZyb20gUHJhZ3VlLiBJZiBhbnlvbmUgaGFzIG90aGVyIGNvbW1lbnRzLCBw bGVhc2Ugc2VuZCB0aGVtIC0gdGhlIGRvYyBpcyBvdGhlcndpc2UgcmVhZHkgZnJvbSBvdXIgcGVy c3BlY3RpdmUuDQoNCkxhcnMNCg== From nobody Thu Aug 13 09:52:13 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B91A1BDA for ; Thu, 13 Aug 2015 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NxzF89DchLHQ for ; Thu, 13 Aug 2015 09:52:10 -0700 (PDT) Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com [15.201.208.55]) (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 4CD3C1A1BEC for ; Thu, 13 Aug 2015 09:52:10 -0700 (PDT) Received: from g4t3433.houston.hp.com (g4t3433.houston.hp.com [16.210.25.219]) by g4t3427.houston.hp.com (Postfix) with ESMTP id 7105911B; Thu, 13 Aug 2015 16:52:09 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g4t3433.houston.hp.com (Postfix) with ESMTP id 69C5B68; Thu, 13 Aug 2015 16:52:07 +0000 (UTC) Message-ID: <55CCCB36.8050309@hp.com> Date: Thu, 13 Aug 2015 09:52:06 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Bless, Roland (TM)" , Eric Dumazet , Yuchung Cheng References: <55CB32AB.6000207@kit.edu> <1439416545.29802.24.camel@edumazet-glaptop2.roam.corp.google.com> <55CCB56D.9060903@kit.edu> In-Reply-To: <55CCB56D.9060903@kit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 16:52:11 -0000 On 08/13/2015 08:19 AM, Bless, Roland (TM) wrote: > Here is what Polina says (she's not on the tcpm list): > ---------------------------------------------------------------------- > Our computers: each is equipped with Xeon-E5 (32cores) and four-port > Intel x710 NICs (probably X710-DA4 but I am not sure) and are running > Linux 4.1.2. We test it with iperf3 (v3.1b3) - single TCP flow with > data going only in one direction and no additional parameters. I don't know the Intel NIC product line well enough to know what driver that NIC uses, but if the x710 uses the ixgbe driver, LRO (Large Receive Offload - done in the NIC) may be enabled. For that matter, it might be enabled by default in the driver used for the x710 even if it isn't ixgbe. For other reasons, a few months ago now I submitted an ixgbe patch to the Intel folks which would not enable LRO by default and am waiting for it to emerge from their trees. happy benchmarking, rick jones From nobody Thu Aug 13 10:49:16 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048F11A8BC5 for ; Thu, 13 Aug 2015 10:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 eYjksCskvWAP for ; Thu, 13 Aug 2015 10:49:13 -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 CB3A71A89A0 for ; Thu, 13 Aug 2015 10:49:12 -0700 (PDT) Received: by vkfi73 with SMTP id i73so20795572vkf.2 for ; Thu, 13 Aug 2015 10:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dIeB9nzOcPduj0p78VG5XKh28GDJRv4JKR2Z96Ab//M=; b=ff8ihlWKv2AUWOc8aC8b5oLjACHhn0mOxZ6tJ9cUKHoZzj3DuAIqGzeN+R/bUK/AI7 PcTsqxlnAIG5ZvVzVezje0Abc3Bmg18j93Bo94AbwROKZn2eXj+uu7M/MiP8dA//WvpS pupoURs/O5ezpRQUgQyhv4Pktf68rTjxYpBOMbQCdUeFMY57CZhs1dy6g7ASFHUprlmS QmeI0XXxDkic0imiobt/OQG8ufVJ0NkWVn79c1OOSUvFTRotL9TIQSSqnf7IEu4a4Zvi DFvkGAJ6xgEr7Rgs0FOgTgBKPKGXAhoeodvH1AwsEHbXHsudhp8Tn3zDG7/Sy9Vj7Y4c RMLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=dIeB9nzOcPduj0p78VG5XKh28GDJRv4JKR2Z96Ab//M=; b=YTnAs6JgNuPUEtSPkQjkEBxhyM0iiVyUNRxBOeTow8QOMioDlIqmxIsSFEno1wXLOS F3/OcFB9ESKwqgFZgyujid1sEXNZL4EL+3jedDQTfTjdaM6VhXi4cyvjhepTX9Vy+Y8j 9gYvYm1dJL8UCboGMM8MMU2GNm4uIiRwGHgCAde3H+q56fIjNLtKOMjBavjBjD/pj5H/ N1rK5N13wOWPPt0H1Z9pLK1YdBAFgS0+EaD8rZK+U95K1NRcfOvifxoWIm/bv6tk9qov H74PW5GiW1DGoenfIVz08A0bBEzg3TPVhbKKXvqqjO4TJZNfN9pcFKi2E4nQQH+1qcI2 Te/A== X-Gm-Message-State: ALoCoQl+PO7enDE29RPmXrorGuaX2McJb6FIW0JKoTBV7OPG1xdacLP5PBYK+RgZPL3sllvgQPKY X-Received: by 10.52.139.239 with SMTP id rb15mr49608919vdb.76.1439488151991; Thu, 13 Aug 2015 10:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Thu, 13 Aug 2015 10:48:32 -0700 (PDT) In-Reply-To: <55CCB070.9000006@kit.edu> References: <55CB32AB.6000207@kit.edu> <55CCB070.9000006@kit.edu> From: Yuchung Cheng Date: Thu, 13 Aug 2015 10:48:32 -0700 Message-ID: To: "Bless, Roland (TM)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 17:49:14 -0000 On Thu, Aug 13, 2015 at 7:57 AM, Bless, Roland (TM) wrote: > Hi Yuchung, > > thanks for you quick response. > > Am 12.08.2015 um 22:16 schrieb Yuchung Cheng: >> In your case, the spurious retransmission/recovery would be detected >> by TCP timestamps. Subsequently Linux would 1) revert cwnd reduction, >> 2) raise the dupthresh and 3) disables FACK. Since cwnd is recovered >> the connection won't lose tput except wasting some spurious >> retransmits. > > According to our pcap file, the reordered chunks are 2*10^-6 (2=C2=B5s) a= part > from each other. The TCP timestamps are exactly the same in this > case, so no chance to detect reordering by using timestamps. In that case the second level (slower) protection is DSACKs, triggered by the spurious retransmission. When Linux sender realizes all its retransmission are DSACK'd, it'll undo the cwnd reduction as well. If the spurious retransmission is bothersome you can disable FACK or raise default dupthresh. The new echo option draft can also help the timestamp resolution limitation. btw we are putting up a new recovery mechanism to deal exactly with this "tiny reordering" issue. The core idea is to replace counter-based heuristics (dupthresh or sequence delta like FACK) with a time-based approach (time delta between pending and delivered packet). We plan to submit a draft before next tcpm meeting along with linux patches. > >> I am skeptical GRO is the culprit of reordering. GRO does not reorder >> packets b/c it's single lane processing. It may be other input pathing >> problems not GRO. > > Maybe it's happening earlier or later in the local delivery path. > We are still trying to find out the cause, currently, we are > seeing the symptoms only. > > Regards, > Roland > From nobody Thu Aug 13 15:27:47 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8921B3B96 for ; Thu, 13 Aug 2015 15:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 PEYV84EJQseb for ; Thu, 13 Aug 2015 15:27:42 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 ABEC11B3B95 for ; Thu, 13 Aug 2015 15:27:41 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ZQ0yI-0002m8-Jw; Fri, 14 Aug 2015 00:27:38 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 41D8EB012E2; Fri, 14 Aug 2015 00:27:38 +0200 (CEST) Message-ID: <55CD19D9.70700@kit.edu> Date: Fri, 14 Aug 2015 00:27:37 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Rick Jones , Eric Dumazet , Yuchung Cheng References: <55CB32AB.6000207@kit.edu> <1439416545.29802.24.camel@edumazet-glaptop2.roam.corp.google.com> <55CCB56D.9060903@kit.edu> <55CCCB36.8050309@hp.com> In-Reply-To: <55CCCB36.8050309@hp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1439504858. Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 22:27:44 -0000 Hi Rick, Am 13.08.2015 um 18:52 schrieb Rick Jones: > I don't know the Intel NIC product line well enough to know what driver > that NIC uses, but if the x710 uses the ixgbe driver, LRO (Large Receive > Offload - done in the NIC) may be enabled. For that matter, it might be > enabled by default in the driver used for the x710 even if it isn't ixgbe. LRO is turned off in our setting by default and cannot be turned on (fixed), so this isn't causing trouble here. > For other reasons, a few months ago now I submitted an ixgbe patch to > the Intel folks which would not enable LRO by default and am waiting for > it to emerge from their trees. LRO doesn't seem to be the problem. Moreover, GRO probably isn't causing the *reordering* itself, but since it merges several packets together a single duplicate ack, which was caused by reordering, also triggered the retransmission. Without GRO a single DupACK wouldn't have caused the retransmission. Regards, Roland From nobody Thu Aug 13 15:33:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440B91B3BA1 for ; Thu, 13 Aug 2015 15:33:38 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 tjLuH4G-d7Ra for ; Thu, 13 Aug 2015 15:33:37 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 0A5C41B3B84 for ; Thu, 13 Aug 2015 15:33:37 -0700 (PDT) Received: by paccq16 with SMTP id cq16so2564488pac.1 for ; Thu, 13 Aug 2015 15:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=wZJR3EvJBwcuUYez/Y9XOD3a1rTQZyMJmfYbazoPSSk=; b=plaRQgMuZ03b2dpDsEJsfRwS2ktmm1oqmKSrwmVvdQvqSuzPseyfAncq4EVANcpOhd Sn4AHRkf0e+5fP7l/WS9P6RDuhr4geeKIlZ0/8kFAZ50ZswBfWcIaFwl9s4Z04G8sBTI A+3D66Ii+WDO5438PofiDmPvNJz8VTMpMkcVCANdVwLWMb+/Ad2xmMBnABDFyzIZ3Yav Sw47kYQTZNwGT3klrCCk/Rctai0Yn/8BBLzs45ZUXN+swMHuo/4rtqjwso1yLoUrOnax ClJluN/Uh1XYkDQeSkZ8+m1ixeBm5r3XRex8E/B8hXAQDBqERRv3XWvAZPr+nhPoGtbM dFkw== X-Received: by 10.66.65.205 with SMTP id z13mr82124920pas.65.1439505216768; Thu, 13 Aug 2015 15:33:36 -0700 (PDT) Received: from ?IPv6:2620:0:1000:3e02:94bf:915a:93b7:7693? ([2620:0:1000:3e02:94bf:915a:93b7:7693]) by smtp.gmail.com with ESMTPSA id i10sm3812748pdl.8.2015.08.13.15.33.35 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2015 15:33:35 -0700 (PDT) Message-ID: <1439505215.7960.30.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Roland Bless Date: Thu, 13 Aug 2015 15:33:35 -0700 In-Reply-To: <55CD19D9.70700@kit.edu> References: <55CB32AB.6000207@kit.edu> <1439416545.29802.24.camel@edumazet-glaptop2.roam.corp.google.com> <55CCB56D.9060903@kit.edu> <55CCCB36.8050309@hp.com> <55CD19D9.70700@kit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 22:33:38 -0000 On Fri, 2015-08-14 at 00:27 +0200, Roland Bless wrote: > LRO doesn't seem to be the problem. Moreover, GRO probably isn't causing > the *reordering* itself, but since it merges several packets together a > single duplicate ack, which was caused by reordering, also triggered the > retransmission. Without GRO a single DupACK wouldn't > have caused the retransmission. Sorry, I do not get it. GRO aggregates in order segments only. So no retransmits could have been avoided. ( There is some work done here at Google to experiment a reorder resilient GRO engine ) From nobody Thu Aug 13 15:41:45 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EFF1B3BA5 for ; Thu, 13 Aug 2015 15:41:44 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Y5lttMbItjNF for ; Thu, 13 Aug 2015 15:41:42 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::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 AA60E1B3BA2 for ; Thu, 13 Aug 2015 15:41:42 -0700 (PDT) Received: by pdrh1 with SMTP id h1so24378332pdr.0 for ; Thu, 13 Aug 2015 15:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=Yv8591otk/S6XtMpI8ALVejmObmWYmTjvuz3fXq9qgE=; b=ZHJP7WbOQkFyKuMHsMRrTaE4X1y43Xtun6NkvJVox8CJCeneFtJ+erVWXVzpGQiZcf GgwN+UKbqNQg8IcmzCtm08DwlB2KiHMq6qjNB0x80+3NhFAvPSFaeiHrRd7XroNO0P0B P+WsCxqepj7bXaWw6XJqQQcvXHjQdoH/Y5BoivUpco4rqpRDFcXWgfsWZ+aob495cluD z66Op7L/a9oZclbRLzV4d0957ogbCPBF8m1H8g5DiIsafyvwv+9dTgU+HtsBSWJHGqBg G4XuREcyaNKReWWtSO/qHDHvu3DimM9mfb9heIofzkDA1aZMDAQev0/oP1I4B2AuaG+c 7uyw== X-Received: by 10.70.133.133 with SMTP id pc5mr51678486pdb.134.1439505702427; Thu, 13 Aug 2015 15:41:42 -0700 (PDT) Received: from ?IPv6:2620:0:1000:3e02:94bf:915a:93b7:7693? ([2620:0:1000:3e02:94bf:915a:93b7:7693]) by smtp.gmail.com with ESMTPSA id y6sm3818524pdm.23.2015.08.13.15.41.41 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2015 15:41:42 -0700 (PDT) Message-ID: <1439505701.7960.36.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Roland Bless Date: Thu, 13 Aug 2015 15:41:41 -0700 In-Reply-To: <1439505215.7960.30.camel@edumazet-glaptop2.roam.corp.google.com> References: <55CB32AB.6000207@kit.edu> <1439416545.29802.24.camel@edumazet-glaptop2.roam.corp.google.com> <55CCB56D.9060903@kit.edu> <55CCCB36.8050309@hp.com> <55CD19D9.70700@kit.edu> <1439505215.7960.30.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 22:41:44 -0000 On Thu, 2015-08-13 at 15:33 -0700, Eric Dumazet wrote: > On Fri, 2015-08-14 at 00:27 +0200, Roland Bless wrote: > > > LRO doesn't seem to be the problem. Moreover, GRO probably isn't causing > > the *reordering* itself, but since it merges several packets together a > > single duplicate ack, which was caused by reordering, also triggered the > > retransmission. Without GRO a single DupACK wouldn't > > have caused the retransmission. > > Sorry, I do not get it. GRO aggregates in order segments only. > > So no retransmits could have been avoided. > > ( There is some work done here at Google to experiment a reorder > resilient GRO engine ) BTW, bnx2x GRO is implemented partially on the NIC. It is possible to get some reorders because of this. Here is what can happen : P1 delivered as a single MSS by bnx2x. -> Stored into GRO engine P2 delivered as a single MSS -> GRO engine appends P2 to P1 P3-P6 delivered in a 4-MSS super packet GRO engine is bypassed. P3-P6 delivered to upper stack, while P1-P2 still are on queue. Arguably this is a bnx2x bug. Following patch will deliver packets in GRO engine _before_ this bad packet. diff --git a/net/core/dev.c b/net/core/dev.c index a8e4dd430285..fbfb007bad45 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4151,9 +4151,10 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff if (!(skb->dev->features & NETIF_F_GRO)) goto normal; - if (skb_is_gso(skb) || skb_has_frag_list(skb) || skb->csum_bad) + if (skb_is_gso(skb) || skb_has_frag_list(skb) || skb->csum_bad) { + napi_gro_flush(napi, false); goto normal; - + } gro_list_prepare(napi, skb); rcu_read_lock(); From nobody Thu Aug 13 16:16:01 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83F11ACEAD for ; Thu, 13 Aug 2015 16:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 jiHHv63_PgmS for ; Thu, 13 Aug 2015 16:15:58 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 7ED2F1ACEA9 for ; Thu, 13 Aug 2015 16:15:58 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ZQ1j0-0006eJ-I2; Fri, 14 Aug 2015 01:15:54 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 337D4B012E2; Fri, 14 Aug 2015 01:15:54 +0200 (CEST) Message-ID: <55CD2529.5080107@kit.edu> Date: Fri, 14 Aug 2015 01:15:53 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Eric Dumazet References: <55CB32AB.6000207@kit.edu> <1439416545.29802.24.camel@edumazet-glaptop2.roam.corp.google.com> <55CCB56D.9060903@kit.edu> <55CCCB36.8050309@hp.com> <55CD19D9.70700@kit.edu> <1439505215.7960.30.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1439505215.7960.30.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1439507754. Archived-At: Cc: "Goltsman, Polina" , "tcpm@ietf.org Extensions" , Mario Hock Subject: Re: [tcpm] Bad GRO / TCP FACK feature interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2015 23:16:00 -0000 Hi Eric, Am 14.08.2015 um 00:33 schrieb Eric Dumazet: > On Fri, 2015-08-14 at 00:27 +0200, Roland Bless wrote: > >> LRO doesn't seem to be the problem. Moreover, GRO probably isn't causing >> the *reordering* itself, but since it merges several packets together a >> single duplicate ack, which was caused by reordering, also triggered the >> retransmission. Without GRO a single DupACK wouldn't >> have caused the retransmission. > > Sorry, I do not get it. GRO aggregates in order segments only. I'm sorry for the confusion, I'll try to provide more details below... Of course you are right that GRO aggregates in order segments only. > So no retransmits could have been avoided. No, as the subject said, it's a bad feature interaction with FACK. I've included an excerpt from the dump @ the receiver side: 1) we get ~10kBytes as a block of segments out of order (packet #11) and then ~20kBytes as a block of segments (packet # 12): 10 0.000135000 10.0.2.3 10.0.2.1 TCP 66 5201→37056 [ACK] Seq=1 Ack=191137 Win=24576 Len=0 TSval=44830005 TSecr=62231400 11 0.000152000 10.0.2.1 10.0.2.3 TCP 10202 [TCP Previous segment not captured] 37056→5201 [ACK] Seq=212857 Ack=1 Win=8192 Len=10136 TSval=62231400 TSecr=44830005 12 0.000154000 10.0.2.1 10.0.2.3 TCP 21786 [TCP Out-Of-Order] 37056→5201 [ACK] Seq=191137 Ack=1 Win=8192 Len=21720 TSval=62231400 TSecr=44830005 13 0.000156000 10.0.2.3 10.0.2.1 TCP 78 [TCP Dup ACK 10#1] 5201→37056 [ACK] Seq=1 Ack=191137 Win=24576 Len=0 TSval=44830005 TSecr=62231400 SLE=212857 SRE=222993 2) Since packet #13 is now a DupACK with SACK option, FACK is triggering a retransmission at the sender, because it sees a hole of more than 3 MSS segments. Is it now getting clearer? Regards, Roland From nobody Mon Aug 17 01:51:36 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD61A893B for ; Mon, 17 Aug 2015 01:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=ham 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 jb0CAGWa9pVP for ; Mon, 17 Aug 2015 01:51:29 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB451A8949 for ; Mon, 17 Aug 2015 01:51:29 -0700 (PDT) Received: by iods203 with SMTP id s203so143719120iod.0 for ; Mon, 17 Aug 2015 01:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=81bu/cs2DSEH27aLYG5up6TOBgq51FtHFrQ65oq8H0k=; b=IInwIiru6RVxbjlmePRaZ2pdSqPKomHDYCm+JhPeVBoUi4Ix48+r26ORle0etgaG6m 2F05Ncqx7EDor1/BHHgl3dWjYkqpPIboU7O4kmWvT6YcAn4M4vqiHXNQbULzigEOmdN+ XNJ5Nmn0F5JcS5w958GwSJ3pcud8VudDKwv+I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=81bu/cs2DSEH27aLYG5up6TOBgq51FtHFrQ65oq8H0k=; b=l0t7Kj+DbJFyuURtjrti51cvOP555STtj2tBbj81vpJ4kX0vp5ajue77x3pvSTAkP5 DASeapz8eMYkt03DkI2Zk6Qpc2pg/UzKotYJIrzETwDZsH5SZ9/pK8+ycgXqorCMVRGe kmArQz/XhUIiRwRDGHIVwQ8cYZLGlEjugRp1Xr99ueM0LT4bYbfi/VPumY0TWcdWJuPU XsihCl6Aaw0yUkWcuRAefziw9/4ElJOg7SnRxXvLIqm8HiSDBS8nEVDU0Mwfz/9u6UIY Pc+NqcoOLKgSAftK9K0W1aD/6Y1NGNwHkEt8TIcDWJ3e3rpL0xN7Jc+VI+v6xFsVOeG8 /OjQ== X-Gm-Message-State: ALoCoQnzpnVuBg/0P0P2gPmgDgMqU+EXntDo7yRv5YX/Kn02dYzNrhBN4lngHzY06MkHrrBLiv2kzea1KGlS5YpKSq3AvIRHfES3swgrPh5w0CVkGKapFzA= X-Received: by 10.107.32.147 with SMTP id g141mr281807iog.86.1439801488391; Mon, 17 Aug 2015 01:51:28 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <55C4C4CB.9080302@bobbriscoe.net> <55C4CEEF.1040504@bobbriscoe.net> In-Reply-To: <55C4CEEF.1040504@bobbriscoe.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF40EgN6bhQ58jZHJuzoIQYmo33WQFQ1uPnnrVqYoA= Date: Mon, 17 Aug 2015 10:51:27 +0200 Message-ID: <338a11745e05dd944c66be76fb925e97@mail.gmail.com> To: Bob Briscoe , "SCHARF, Michael" , "SAROLAHTI, Pasi" , Yoshifumi Nishada , tcpm IETF list Content-Type: multipart/alternative; boundary=001a1141bb8a436792051d7de855 X-DomainID: tieto.com Archived-At: Cc: Olga Bondarenko Subject: Re: [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Aug 2015 08:51:35 -0000 --001a1141bb8a436792051d7de855 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bob, To me the formulation =E2=80=9Cexisting TCP Cubic & Reno=E2=80=9D is not ex= actly clear. I would have called a TCP following existing standards RFC3168 and RFC5681 a TCP Reno implementation, but I believe that below you very explicitly mean a TCP Reno (or Cubic) implementation NOT exploiting ECN RFC3168. I think this is a crucial point. TCP Reno implementations supporting RF3168, with RFC3168 activated, are deployed (do exist) in the internet today (even if RFC3168 active don=E2=80=99t make any difference with the existing= AQMs). BR, Karen *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Bob Briscoe *Sent:* Friday, August 07, 2015 5:30 PM *To:* SCHARF, Michael; SAROLAHTI, Pasi; Yoshifumi Nishada; tcpm IETF list *Cc:* Olga Bondarenko *Subject:* [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt tcpm chairs & list. Cross-posting this announcement to tcpm, given its about evolving TCP and its interaction with AQMs. If you were in Prague you may have seen this AQM demonstrated over a broadband Internet testbed. Here's the video (starts at about 33mins - your browser has to support HTML5). This DualQ Coupled AQM exploits ECN and scalable TCP algos like Data Centre TCP (DCTCP). In our extensive testing, it gave zero congestion loss and about 1ms queuing latency at the 98th percentile, even under high load. It is designed to allow DCTCP to co-exist with existing TCP Cubic & Reno, whether mixed within a data centre, on private networks or on the public Internet. We believe a WG will need to be found for evolution of DCTCP (there is currently a non-WG mailing list called tcpprague@ietf.org for this). Currently the list of safety mods needed in DCTCP is in an appendix, but it says that is only a temporary home. Otherwise we expect any WG activity to be in tsvwg and AQM, so for tcpm this is just an FYI email at the moment. Cheers Bob, Koen, Olga & Inton -------- Forwarded Message -------- *Subject: * New I-D: draft-briscoe-aqm-dualq-coupled-00.txt *Date: * Fri, 07 Aug 2015 15:46:35 +0100 *From: * Bob Briscoe *To: * Scheffenegger, Richard , Wesley Eddy , AQM IETF list *CC: * De Schepper, Koen (Koen) , TSANG Inton , Olga Bondarenko AQM Chairs, list, My co-authors and I have just posted a draft spec of the DualQ Coupled AQM we presented and demonstrated in Prague under the title "Data Centre to the Home" (see announcement quoted below). *Invitation to reimplement / bash*We are not asking for adoption right now. But we would be happy if others tried to reimplement it using our description and to test it independently. We are trying to get approval from employers to release it as open source, but you will see that the pseudocode is only 15 lines, so it should not be hard to reimplement. The draft refers out to our 'under-submission' DCttH paper reporting a selection of the thousands of experiments we did ourselves. We are preparing a tech report to record the rest. Cheers Bob, Koen, Olga & Inton. -------- Forwarded Message -------- *Subject: * New Version Notification for draft-briscoe-aqm-dualq-coupled-00.txt *Date: * Fri, 07 Aug 2015 06:41:15 -0700 *From: * internet-drafts@ietf.org *To: * Koen De Schepper , Ing-jyh Tsang , Bob Briscoe , Olga Bondarenko , Koen De Schepper = , Olga Bondarenko , Bob Briscoe , ing-jyh.tsang@alcatel-lucent.com A new version of I-D, draft-briscoe-aqm-dualq-coupled-00.txt has been successfully submitted by Bob Briscoe and posted to the IETF repository. Name: draft-briscoe-aqm-dualq-coupled Revision: 00 Title: DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput Document date: 2015-08-07 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-briscoe-aqm-dualq-coupled-00.txt Status: https://datatracker.ietf.org/doc/draft-briscoe-aqm-dualq-coupled/ Htmlized: https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled= -00 Abstract: Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---throughput starves. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines `DualQ Coupled Active Queue Management (AQM)' to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and `Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration. 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 --001a1141bb8a436792051d7de855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Bob,

=C2=A0

To me the formulation =E2=80=9Cexisting TCP Cubic & Reno=E2=80=9D is n= ot exactly clear. I would have called a TCP following

existing standards RFC3168 and RFC56= 81 a TCP Reno implementation, but I believe that below

you very explicitly mean a TCP Re= no (or Cubic) implementation NOT

exploiting ECN RFC3168. I think this is a crucial point.<= /span>

=C2=A0

TCP Reno implementation= s supporting RF3168, with RFC3168 activated, are deployed (do exist) in the= internet today

(even if RFC3168 active don=E2=80=99t make any difference with the existin= g AQMs).

=C2=A0=

BR, Karen

=C2=A0

=C2=A0

=C2=A0

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
= Sent: Friday, August 07, 2015 5:30 PM
To: SCHARF, Michael; SA= ROLAHTI, Pasi; Yoshifumi Nishada; tcpm IETF list
Cc: Olga Bondare= nko
Subject: [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled= -00.txt

=C2=A0

tcpm chairs & list.

Cross-posting this announcement t= o tcpm, given its about evolving TCP and its interaction with AQMs.

= If you were in Prague you may have seen this AQM demonstrated over a broadb= and Internet testbed. Here's the = video (starts at about 33mins - your browser has to support HTML5).
This DualQ Coupled AQM exploits ECN and scalable TCP algos like Data C= entre TCP (DCTCP).=C2=A0 In our extensive testing, it gave zero congestion = loss and about 1ms queuing latency at the 98th percentile, even under high = load. It is designed to allow DCTCP to co-exist with existing TCP Cubic &am= p; Reno, whether mixed within a data centre, on private networks or on the = public Internet.

We believe a WG will need to be found for evolutio= n of DCTCP (there is currently a non-WG mailing list called tcpprague@ietf.org for this). Currently the list= of safety mods needed in DCTCP is in an appendix, but it says that is only= a temporary home.

Otherwise we expect any WG activity to be in tsvw= g and AQM, so for tcpm this is just an FYI email at the moment.

Cheers



Bob, Koen, Olga & Inton



-------- Forwarded Message --------

=

Subject:

New I-D: draft-briscoe-= aqm-dualq-coupled-00.txt

Date:

Fri, 07 Aug 2015 15:46:35 +0100

From:

Bob Briscoe = <ietf@bobbriscoe.net>

<= /td>
To: =

Schef= fenegger, Richard <rs@netapp.com>, Wesley Eddy <wes@mti-systems.c= om>, AQM IETF list <aqm@ietf.org&= gt;

CC:

De Schepper, Koen (Koen) <koen.de_schepper@alcatel-lucent.com>, TSANG Inton <ing-jyh.tsang@alcatel= -lucent.com>, Olga Bondarenko &= lt;olgabnd@gmail.com>


AQM Chairs, list,

My co-authors and I have just posted a draft= spec of the DualQ Coupled AQM we presented and demonstrated in Prague unde= r the title "Data Centre to the Home" (see announcement quoted be= low).

Invitation to reimplement / bash
We are not asking f= or adoption right now. But we would be happy if others tried to reimplement= it using our description and to test it independently. We are trying to ge= t approval from employers to release it as open source, but you will see th= at the pseudocode is only 15 lines, so it should not be hard to reimplement= .

The draft refers out to our 'under-submission' DCttH paper<= /a> reporting a selection of the thousands of experiments we did ourselves.= We are preparing a tech report to record the rest.

Cheers


Bob, Koen, Olga & Inton.



-= ------- Forwarded Message --------

= <= tr><= td style=3D"padding:0cm 0cm 0cm 0cm">

Koen De Scheppe= r <koen.de_schepp= er@alcatel-lucent.com>, Ing-jyh Tsang <ing-jyh.tsang@alcatel-lucent.com>, Bob Bri= scoe <ietf@bobbriscoe.net>= , Olga Bondarenko <olgabnd@gmail.co= m>, Koen De Schepper <koen.de_schepper@alcatel-lucent.com>, Olga Bondarenko <olgabnd@gmail.com>, Bob Brisc= oe <ietf@bobbriscoe.net>, = ing-jyh.tsang@alcatel-l= ucent.com <ing-j= yh.tsang@alcatel-lucent.com>

Subject:

New Version Notification for draft-bris= coe-aqm-dualq-coupled-00.txt

Date:

Fri, 07 Aug 2015 06:41:15 -0700

From:

internet-drafts@ietf.org

To:

=C2=A0

A new version of I-D, dr=
aft-briscoe-aqm-dualq-coupled-00.txt
has been successfully submit=
ted by Bob Briscoe and posted to the
IETF repository.
=
=C2=A0
Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draf=
t-briscoe-aqm-dualq-coupled
Revision:=C2=A0=C2=A0=C2=A0=C2=A0 00<=
/pre>
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DualQ Coupled AQ=
M for Low Latency, Low Loss and Scalable Throughput
Document date=
: 2015-08-07
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ind=
ividual Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 22
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-brisco=
e-aqm-dualq-coupled-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-briscoe-aqm=
-dualq-coupled/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=
=A0https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled-00
=

=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0 Dat=
a Centre TCP (DCTCP) was designed to provide predictably low
=C2=
=A0=C2=A0 queuing latency, near-zero loss, and throughput scalability using=

=C2=A0=C2=A0 explicit congestion notification (ECN) and an extre=
mely simple
=C2=A0=C2=A0 marking behaviour on switches.=C2=A0 How=
ever, DCTCP does not co-exist with
=C2=A0=C2=A0 existing TCP traf=
fic---throughput starves.=C2=A0 So, until now, DCTCP
=C2=A0=C2=A0=
 could only be deployed where a clean-slate environment could be
=
=C2=A0=C2=A0 arranged, such as in private data centres.=C2=A0 This specific=
ation
=C2=A0=C2=A0 defines `DualQ Coupled Active Queue Management=
 (AQM)' to allow
=C2=A0=C2=A0 scalable congestion controls li=
ke DCTCP to safely co-exist with
=C2=A0=C2=A0 classic Internet tr=
affic.=C2=A0 The Coupled AQM ensures that a flow runs
=C2=A0=C2=
=A0 at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but
=C2=A0=C2=A0 without inspecting transport layer flow identifiers.=C2=
=A0 When tested in
=C2=A0=C2=A0 a residential broadband setting, =
DCTCP achieved sub-millisecond
=C2=A0=C2=A0 average queuing delay=
 and zero congestion loss under a wide range of
=C2=A0=C2=A0 mixe=
s of DCTCP and `Classic' broadband Internet traffic, without
=
=C2=A0=C2=A0 compromising the performance of the Classic traffic.=C2=A0 The=
 solution
=C2=A0=C2=A0 also reduces network complexity and elimin=
ates network configuration.
=C2=A0
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 
=C2=A0
=C2=A0
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.
=C2=A0
The IETF Secret=
ariat
=C2=A0
=C2=A0

=C2=A0

=C2=A0

--001a1141bb8a436792051d7de855-- From nobody Tue Aug 18 09:45:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A991A8993 for ; Tue, 18 Aug 2015 09:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 E32s9MSP8YGL for ; Tue, 18 Aug 2015 09:45:49 -0700 (PDT) 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 D52F11A8937 for ; Tue, 18 Aug 2015 09:45:48 -0700 (PDT) Received: from 26.108.208.46.dyn.plus.net ([46.208.108.26]:37137 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZRk1B-0002L9-5k; Tue, 18 Aug 2015 17:45:45 +0100 Message-ID: <55D36138.5060106@bobbriscoe.net> Date: Tue, 18 Aug 2015 17:45:44 +0100 From: Bob Briscoe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Karen Elisabeth Egede Nielsen , Yoshifumi Nishada , tcpm IETF list References: <55C4C4CB.9080302@bobbriscoe.net> <55C4CEEF.1040504@bobbriscoe.net> <338a11745e05dd944c66be76fb925e97@mail.gmail.com> In-Reply-To: <338a11745e05dd944c66be76fb925e97@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------070201070801040104080401" 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 Archived-At: Subject: Re: [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Aug 2015 16:45:54 -0000 This is a multi-part message in MIME format. --------------070201070801040104080401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Karen, No, no. I mean Reno and Cubic whether they use RFC3168 ECN or not. The critical point is that packets sent from a 'scalable' congestion control need to be distinguishable from 'classic' traffic like Reno and Cubic (whether the latter supports ECN or not). I have suggested (on the aqm list) that, in the short term, the new L4S traffic will need to be distinguished by a combination of non-zero ECN field /and/ a local-use Diffserv codepoint. it would make sense for any classic ECN that is already deployed, or gets deployed before L4S is ready, to upgrade to L4S later. So classic ECN should disappear over time. Then, in the short term, operators can sell L4S for local-network only. While in the longer term, operators would be able to classify just on the ECN field. So we would reach the Nirvana of an e2e L4S service for all traffic, without all the interconnection mess of Diffserv. Cheers Bob Terminology (from ): * L4S = low latency, low loss, scalable throughput. * scalable = as flow rate increases, the gap between losses or ECN marks does not widen, as it does with Reno or Cubic. On 17/08/15 09:51, Karen Elisabeth Egede Nielsen wrote: > > Hi Bob, > > To me the formulation “existing TCP Cubic & Reno” is not exactly > clear. I would have called a TCP following > > existing standards RFC3168 and RFC5681 a TCP Reno implementation, but > I believe that below > > you very explicitly mean a TCP Reno (or Cubic) implementation NOT > > exploiting ECN RFC3168. I think this is a crucial point. > > TCP Reno implementations supporting RF3168, with RFC3168 activated, > are deployed (do exist) in the internet today > > (even if RFC3168 active don’t make any difference with the existing AQMs). > > BR, Karen > > *From:*tcpm [mailto:tcpm-bounces@ietf.org > ] *On Behalf Of *Bob Briscoe > *Sent:* Friday, August 07, 2015 5:30 PM > *To:* SCHARF, Michael; SAROLAHTI, Pasi; Yoshifumi Nishada; tcpm IETF list > *Cc:* Olga Bondarenko > *Subject:* [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt > > tcpm chairs & list. > > Cross-posting this announcement to tcpm, given its about evolving TCP > and its interaction with AQMs. > > If you were in Prague you may have seen this AQM demonstrated over a > broadband Internet testbed. Here's the video > > (starts at about 33mins - your browser has to support HTML5). > > This DualQ Coupled AQM exploits ECN and scalable TCP algos like Data > Centre TCP (DCTCP). In our extensive testing, it gave zero congestion > loss and about 1ms queuing latency at the 98th percentile, even under > high load. It is designed to allow DCTCP to co-exist with existing TCP > Cubic & Reno, whether mixed within a data centre, on private networks > or on the public Internet. > > We believe a WG will need to be found for evolution of DCTCP (there is > currently a non-WG mailing list called tcpprague@ietf.org > for this). Currently the list of safety > mods needed in DCTCP is in an appendix, but it says that is only a > temporary home. > > Otherwise we expect any WG activity to be in tsvwg and AQM, so for > tcpm this is just an FYI email at the moment. > > > Cheers > > > > Bob, Koen, Olga & Inton > > > > -------- Forwarded Message -------- > > *Subject: * > > > > New I-D: draft-briscoe-aqm-dualq-coupled-00.txt > > *Date: * > > > > Fri, 07 Aug 2015 15:46:35 +0100 > > *From: * > > > > Bob Briscoe > > *To: * > > > > Scheffenegger, Richard , Wesley > Eddy , AQM IETF list > > > *CC: * > > > > De Schepper, Koen (Koen) > , TSANG Inton > > , Olga Bondarenko > > > > > AQM Chairs, list, > > My co-authors and I have just posted a draft spec of the DualQ Coupled > AQM we presented and demonstrated in Prague under the title "Data > Centre to the Home" (see announcement quoted below). > > *Invitation to reimplement / bash > *We are not asking for adoption right now. But we would be happy if > others tried to reimplement it using our description and to test it > independently. We are trying to get approval from employers to release > it as open source, but you will see that the pseudocode is only 15 > lines, so it should not be hard to reimplement. > > The draft refers out to our 'under-submission' DCttH paper > > reporting a selection of the thousands of experiments we did > ourselves. We are preparing a tech report to record the rest. > > Cheers > > > > Bob, Koen, Olga & Inton. > > > > -------- Forwarded Message -------- > > *Subject: * > > > > New Version Notification for draft-briscoe-aqm-dualq-coupled-00.txt > > *Date: * > > > > Fri, 07 Aug 2015 06:41:15 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Koen De Schepper > , Ing-jyh Tsang > > , Bob Briscoe > , Olga Bondarenko > , Koen De Schepper > > , Olga Bondarenko > , Bob Briscoe > , > ing-jyh.tsang@alcatel-lucent.com > > > > > A new version of I-D, draft-briscoe-aqm-dualq-coupled-00.txt > has been successfully submitted by Bob Briscoe and posted to the > IETF repository. > > Name: draft-briscoe-aqm-dualq-coupled > Revision: 00 > Title: DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput > Document date: 2015-08-07 > Group: Individual Submission > Pages: 22 > URL:https://www.ietf.org/internet-drafts/draft-briscoe-aqm-dualq-coupled-00.txt > Status:https://datatracker.ietf.org/doc/draft-briscoe-aqm-dualq-coupled/ > Htmlized:https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled-00 > > > Abstract: > Data Centre TCP (DCTCP) was designed to provide predictably low > queuing latency, near-zero loss, and throughput scalability using > explicit congestion notification (ECN) and an extremely simple > marking behaviour on switches. However, DCTCP does not co-exist with > existing TCP traffic---throughput starves. So, until now, DCTCP > could only be deployed where a clean-slate environment could be > arranged, such as in private data centres. This specification > defines `DualQ Coupled Active Queue Management (AQM)' to allow > scalable congestion controls like DCTCP to safely co-exist with > classic Internet traffic. The Coupled AQM ensures that a flow runs > at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but > without inspecting transport layer flow identifiers. When tested in > a residential broadband setting, DCTCP achieved sub-millisecond > average queuing delay and zero congestion loss under a wide range of > mixes of DCTCP and `Classic' broadband Internet traffic, without > compromising the performance of the Classic traffic. The solution > also reduces network complexity and eliminates network configuration. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available attools.ietf.org . > > The IETF Secretariat > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------070201070801040104080401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Karen,

No, no. I mean Reno and Cubic whether they use RFC3168 ECN or not.

The critical point is that packets sent from a 'scalable' congestion control need to be distinguishable from 'classic' traffic like Reno and Cubic (whether the latter supports ECN or not).

I have suggested (on the aqm list) that, in the short term, the new L4S traffic will need to be distinguished by a combination of non-zero ECN field /and/ a local-use Diffserv codepoint.

it would make sense for any classic ECN that is already deployed, or gets deployed before L4S is ready, to upgrade to L4S later. So classic ECN should disappear over time.

Then, in the short term, operators can sell L4S for local-network only. While in the longer term, operators would be able to classify just on the ECN field. So we would reach the Nirvana of an e2e L4S service for all traffic, without all the interconnection mess of Diffserv.

Cheers



Bob

Terminology (from <https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled>):
* L4S = low latency, low loss, scalable throughput.
* scalable = as flow rate increases, the gap between losses or ECN marks does not widen, as it does with Reno or Cubic.


On 17/08/15 09:51, Karen Elisabeth Egede Nielsen wrote:

Hi Bob,

 

To me the formulation “existing TCP Cubic & Reno” is not exactly clear. I would have called a TCP following

existing standards RFC3168 and RFC5681 a TCP Reno implementation, but I believe that below

you very explicitly mean a TCP Reno (or Cubic) implementation NOT

exploiting ECN RFC3168. I think this is a crucial point.

 

TCP Reno implementations supporting RF3168, with RFC3168 activated, are deployed (do exist) in the internet today

(even if RFC3168 active don’t make any difference with the existing AQMs).

 

BR, Karen

 

 

 

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
Sent: Friday, August 07, 2015 5:30 PM
To: SCHARF, Michael; SAROLAHTI, Pasi; Yoshifumi Nishada; tcpm IETF list
Cc: Olga Bondarenko
Subject: [tcpm] Fwd: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt

 

tcpm chairs & list.

Cross-posting this announcement to tcpm, given its about evolving TCP and its interaction with AQMs.

If you were in Prague you may have seen this AQM demonstrated over a broadband Internet testbed. Here's the video (starts at about 33mins - your browser has to support HTML5).

This DualQ Coupled AQM exploits ECN and scalable TCP algos like Data Centre TCP (DCTCP).  In our extensive testing, it gave zero congestion loss and about 1ms queuing latency at the 98th percentile, even under high load. It is designed to allow DCTCP to co-exist with existing TCP Cubic & Reno, whether mixed within a data centre, on private networks or on the public Internet.

We believe a WG will need to be found for evolution of DCTCP (there is currently a non-WG mailing list called tcpprague@ietf.org for this). Currently the list of safety mods needed in DCTCP is in an appendix, but it says that is only a temporary home.

Otherwise we expect any WG activity to be in tsvwg and AQM, so for tcpm this is just an FYI email at the moment.


Cheers



Bob, Koen, Olga & Inton



-------- Forwarded Message --------

Subject:

New I-D: draft-briscoe-aqm-dualq-coupled-00.txt

Date:

Fri, 07 Aug 2015 15:46:35 +0100

From:

Bob Briscoe <ietf@bobbriscoe.net>

To:

Scheffenegger, Richard <rs@netapp.com>, Wesley Eddy <wes@mti-systems.com>, AQM IETF list <aqm@ietf.org>

CC:

De Schepper, Koen (Koen) <koen.de_schepper@alcatel-lucent.com>, TSANG Inton <ing-jyh.tsang@alcatel-lucent.com>, Olga Bondarenko <olgabnd@gmail.com>



AQM Chairs, list,

My co-authors and I have just posted a draft spec of the DualQ Coupled AQM we presented and demonstrated in Prague under the title "Data Centre to the Home" (see announcement quoted below).

Invitation to reimplement / bash
We are not asking for adoption right now. But we would be happy if others tried to reimplement it using our description and to test it independently. We are trying to get approval from employers to release it as open source, but you will see that the pseudocode is only 15 lines, so it should not be hard to reimplement.

The draft refers out to our 'under-submission' DCttH paper reporting a selection of the thousands of experiments we did ourselves. We are preparing a tech report to record the rest.

Cheers



Bob, Koen, Olga & Inton.



-------- Forwarded Message --------

Subject:

New Version Notification for draft-briscoe-aqm-dualq-coupled-00.txt

Date:

Fri, 07 Aug 2015 06:41:15 -0700

From:

internet-drafts@ietf.org

To:

Koen De Schepper <koen.de_schepper@alcatel-lucent.com>, Ing-jyh Tsang <ing-jyh.tsang@alcatel-lucent.com>, Bob Briscoe <ietf@bobbriscoe.net>, Olga Bondarenko <olgabnd@gmail.com>, Koen De Schepper <koen.de_schepper@alcatel-lucent.com>, Olga Bondarenko <olgabnd@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, ing-jyh.tsang@alcatel-lucent.com <ing-jyh.tsang@alcatel-lucent.com>

 

A new version of I-D, draft-briscoe-aqm-dualq-coupled-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.
 
Name:         draft-briscoe-aqm-dualq-coupled
Revision:     00
Title:        DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput
Document date: 2015-08-07
Group:        Individual Submission
Pages:        22
URL:            https://www.ietf.org/internet-drafts/draft-briscoe-aqm-dualq-coupled-00.txt
Status:         https://datatracker.ietf.org/doc/draft-briscoe-aqm-dualq-coupled/
Htmlized:       https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled-00
 
 
Abstract:
   Data Centre TCP (DCTCP) was designed to provide predictably low
   queuing latency, near-zero loss, and throughput scalability using
   explicit congestion notification (ECN) and an extremely simple
   marking behaviour on switches.  However, DCTCP does not co-exist with
   existing TCP traffic---throughput starves.  So, until now, DCTCP
   could only be deployed where a clean-slate environment could be
   arranged, such as in private data centres.  This specification
   defines `DualQ Coupled Active Queue Management (AQM)' to allow
   scalable congestion controls like DCTCP to safely co-exist with
   classic Internet traffic.  The Coupled AQM ensures that a flow runs
   at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but
   without inspecting transport layer flow identifiers.  When tested in
   a residential broadband setting, DCTCP achieved sub-millisecond
   average queuing delay and zero congestion loss under a wide range of
   mixes of DCTCP and `Classic' broadband Internet traffic, without
   compromising the performance of the Classic traffic.  The solution
   also reduces network complexity and eliminates network configuration.
 
                                                                                  
 
 
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
 

 

 

 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------070201070801040104080401-- From nobody Mon Aug 24 01:18:56 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDED1A9048 for ; Mon, 24 Aug 2015 01:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 shcljn5OLKB1 for ; Mon, 24 Aug 2015 01:18:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 990A11A903C for ; Mon, 24 Aug 2015 01:18:52 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id C6B96E795A3F8; Mon, 24 Aug 2015 08:18:48 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t7O8IdDR031276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Aug 2015 10:18:49 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 24 Aug 2015 10:18:43 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: HTTP[1,2] and TCP Thread-Index: AQHQ3jIjw5C2579xKk+wb+e5DIBiKJ4azeoQ Date: Mon, 24 Aug 2015 08:18:42 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4846CFA1@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mnot@mnot.net" Subject: [tcpm] FW: HTTP[1,2] and TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2015 08:18:55 -0000 The link below could be of interest to TCPM... Michael -----Original Message----- From: Mark Nottingham [mailto:mnot@mnot.net]=20 Sent: Montag, 24. August 2015 07:55 To: HTTP Working Group Subject: HTTP[1,2] and TCP While there's certainly an interesting discussion to be had about UDP-based= HTTP, for the near future, we're going to be using TCP. After hearing a few people express interest about establishing best practic= es for using HTTP over TCP, experimenting, etc., I've started a wiki page: https://github.com/httpwg/wiki/wiki/TCP As you can see, it's not much now, but feel free to edit/add (it's a wiki),= or discuss here. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 25 16:41:34 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A1E1A86FF for ; Tue, 25 Aug 2015 16:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0eCkG9L1AXSr for ; Tue, 25 Aug 2015 16:41:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.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 48DD01A88EB for ; Tue, 25 Aug 2015 16:41:31 -0700 (PDT) Received: from BN1PR03MB008.namprd03.prod.outlook.com (10.255.224.38) by BN1PR03MB007.namprd03.prod.outlook.com (10.255.224.37) with Microsoft SMTP Server (TLS) id 15.1.231.11; Tue, 25 Aug 2015 23:41:28 +0000 Received: from BN1PR03MB008.namprd03.prod.outlook.com ([169.254.7.65]) by BN1PR03MB008.namprd03.prod.outlook.com ([169.254.7.65]) with mapi id 15.01.0231.011; Tue, 25 Aug 2015 23:41:30 +0000 From: Praveen Balasubramanian To: "De Schepper, Koen (Koen)" , "tcpm@ietf.org" Thread-Topic: Review of draft-bensley-tcpm-dctcp Thread-Index: AQHQzgpxmWPEVFZ4mEG6Fs9KdKR5654bmq2w Date: Tue, 25 Aug 2015 23:41:30 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:5::584] x-microsoft-exchange-diagnostics: 1; BN1PR03MB007; 5:2j3jTipC//NgSlmiwXqEC68hIO0oUvc32tO/gIJpSynJ66S0vpBVe71zqzSjGI4+n8F/yOsCLpTKLUV647zO7oT/F+Jb+kVT7Cd3nCdhNYPOANFJclEkp/t28ymvehyOpM+h8vfY4eEkRUkMFtkUQA==; 24:mnnhxOPETUwVJZ67bxKkv2QjpMPU60VzL5zSIUoQrLHXFS9/NxO/WZ6dsmcwxYmPMm6dtMdLTg8/KzKNyUybNmkxK8LWbfBrlIx0zabthVY=; 20:AaxJTU9r6i+wlQba2UquYCljaV2O+1jNbmMZfI3eH3TyAof75zOLCGjEOesIvBHo8oVSAEWjeN2SQ0HMRg8Ihw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB007; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BN1PR03MB007; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB007; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(13464003)(53754006)(377454003)(230783001)(86612001)(81156007)(46102003)(105586002)(68736005)(2656002)(101416001)(33656002)(50986999)(64706001)(97736004)(19580405001)(40100003)(54356999)(122556002)(76176999)(19580395003)(86362001)(5001860100001)(106356001)(10090500001)(5001770100001)(4001540100001)(92566002)(62966003)(8990500004)(5001830100001)(189998001)(107886002)(15975445007)(106116001)(2900100001)(74316001)(5005710100001)(77156002)(5002640100001)(87936001)(5004730100002)(5001960100002)(5003600100002)(76576001)(2950100001)(5007970100001)(2501003)(10400500002)(99286002)(10290500002)(102836002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB007; H:BN1PR03MB008.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 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: 25 Aug 2015 23:41:30.3299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB007 Archived-At: Subject: Re: [tcpm] Review of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2015 23:41:33 -0000 Thanks Koen for the detailed review. Sorry for the delay. Inline are some c= omments. -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of De Schepper, Koen (K= oen) Sent: Monday, August 3, 2015 9:35 AM To: tcpm@ietf.org Subject: [tcpm] Review of draft-bensley-tcpm-dctcp Hi All, I have reviewed the draft-bensley-tcpm-dctcp-05, and have following questio= ns/remarks: 1.) A general remark is that the draft does not explicitly mention what the= response is to drop, and how it interworks with the alpha and other state = variables. I think the issues with the Linux implementation justify a clear= description. In the Windows implementation, the TCP sender falls back to the NewReno res= ponse when there is a loss episode on a DCTCP connection. However it doesn'= t reset the value of Alpha and the other state variables. We do mention tha= t a configuration knob be provided to reset these state variables in case o= f a loss episode, as has been done in the Linux implementation. We will imp= rove the text around loss handling in the next revision under work. 2.) When exactly is the first window reduction applied? Is it at the end of= an observation window, or when the first mark/drop is detected. To impleme= nt the "respond to congestion only once per window" requirement, is there a= separate mark and drop window state variable? If separate, this means that= if both drop and mark are detected the window can be reduced down to 25% i= n one RTT (as per RFC3168). ECN alpha value is updated at the end of every send round. The window reduc= tion based on the calculated ECN alpha value is applied when an ECE is proc= essed and a round has been completed. It is correct that if both enough mar= kings happen in a round to inflate alpha to the maximum value and there is = also packet loss that the cwnd will be reduced multiple times. The goal of = DCTCP is to prevent loss, and if it fails at this goal, then its response i= s not optimal. If you have suggestions around improving this behavior we wo= uld be happy to address them in the "Implementation Issues" section.=20 3.) Bullet 4 in section 3.3 states "If the sequence number is less than or = equal to DCTCP.WindowEnd". Is there a particular reason for the "or equal"?= I would assume that if the ACKed sequence number is equal to DCTCP.WindowE= nd a window of data is sent? It should actually read " If the acknowledgement number is less than or equ= al to DCTCP.WindowEnd ". We will make this correction in the next revision.= The reason for the "or equal" check is that the Alpha value and the state = variables are updated on the receipt of the first ACK beyond the observatio= n window.=20 4.) The last sentence of section 3.3: "The setting of the Congestion Window= Reduced (CWR) bit is also exactly as per [RFC3168]". Is there a reason to = do this, and how does the receiver respond to this? (I assume a DCTCP recei= ver ignores it and an RFC3168 receiver needs it to stop echoing CE) The DCTCP receiver behaves exactly like the RFC3168 receiver when processin= g CWR. If it receives a packet with CWR set it stops echoing CE until it ge= ts the next packet with CE set. If the same packet has both CE and CWR set,= then CE trumps CWR and echoing continues. Adding text in next revision to = clarify receiver processing of CWR. 5.) The second paragraph of section 4 explains when DCTCP is activated, but= does not explicitly mentions what it means to deactivate DCTCP. If ECN is = successfully negotiated (but RTT> 10ms), will it still use ECN in the class= ic way, or will it stop sending ECT(0) packets? Windows Server 2012+ will always attempt to negotiate ECN for outbound conn= ections by default and accept ECN when requested for inbound connections. S= o yes for higher RTT connections, classic ECN will continue to work along w= ith an congestion algorithm like CTCP. However be mindful that using RTT an= d ECN negotiation to decide datacenter versus internet settings is simply t= he default out-of-box configuration. There are configuration knobs to force= any congestion algorithm and TCP settings globally, or on a per interface = basis (IP address range) or per TCP port range (say only HTTP traffic).=20 6.) The last sentence of section 6 states: "Much like standard TCP, DCTCP i= s biased against flows with longer RTTs. A method for improving the fairnes= s of DCTCP has been proposed in [ADCTCP], but requires additional experimen= tal evaluation". This reads as if DCTCP has an improved bias compared to st= andard TCP, but if I am correct the DCTCP bias is different than that of st= andard TCP, and the method in [ADCTCP] aligns it closer (or equal) to that = of standard TCP, right? Per [ADCTCP] DCTCP does have better RTT fairness when compared to TCP-Drop-= Tail but worse than TCP-RED. The method in [ADCTCP] makes it better than TC= P-RED. The results therein are based on an ns2 simulation. Regards, Koen. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Aug 25 16:47:03 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7D81AC3E4 for ; Tue, 25 Aug 2015 16:47:01 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 X3_aooA5m2I5 for ; Tue, 25 Aug 2015 16:47:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63BA1AC3F1 for ; Tue, 25 Aug 2015 16:46:59 -0700 (PDT) Received: from BN1PR03MB008.namprd03.prod.outlook.com (10.255.224.38) by BN1PR03MB008.namprd03.prod.outlook.com (10.255.224.38) with Microsoft SMTP Server (TLS) id 15.1.231.11; Tue, 25 Aug 2015 23:46:57 +0000 Received: from BN1PR03MB008.namprd03.prod.outlook.com ([169.254.7.65]) by BN1PR03MB008.namprd03.prod.outlook.com ([169.254.7.65]) with mapi id 15.01.0231.011; Tue, 25 Aug 2015 23:46:57 +0000 From: Praveen Balasubramanian To: "Scheffenegger, Richard" , "tcpm@ietf.org" , "Eggert, Lars" Thread-Topic: Review of draft-bensley-tcpm-dctcp Thread-Index: AQHQzgpxmWPEVFZ4mEG6Fs9KdKR56537gz4AgCH/zgA= Date: Tue, 25 Aug 2015 23:46:57 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <689c340eb92f410a81cdb2c7e6115956@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <689c340eb92f410a81cdb2c7e6115956@hioexcmbx05-prd.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:5::584] x-microsoft-exchange-diagnostics: 1; BN1PR03MB008; 5:z9BMw6iFIdznPS6cWoMUVFHXdP3nAoWZWZWgu+MNwhp4GNNDIlobT9Tj0A751wb2GVozQkv0fGx9IYFXg9itCOP69JQ0gq2atjNm53EPLCR6BsqjLKggMKKs7I9xNn5Pwdtqdj9nzSmZP6X5GTw+bg==; 24:NzLahvscBSJudMnJnuvHDnTOC5+N4NyCmETVt5/ZwZttSMUXwT802nLgnJNwC1uZ/LKXz3U002r8+Zv99kNqtI7xQtA3gVlQ7HhFFSf0ceI=; 20:oQSO8szp5QVlOHLkUN7QE7pugHZse9VlXDCgnZ+bK5bnZ1ktnvGq8bNBiSWoeIpo6YCEmGOS34J6M1QGhPmekA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB008; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BN1PR03MB008; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB008; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(199003)(377454003)(2501003)(101416001)(97736004)(54356999)(5001960100002)(106356001)(106116001)(122556002)(86612001)(76176999)(4001540100001)(46102003)(5001770100001)(19580395003)(5004730100002)(76576001)(33656002)(19580405001)(230783001)(5001860100001)(5001830100001)(50986999)(5005710100001)(74316001)(5003600100002)(92566002)(189998001)(5002640100001)(8990500004)(86362001)(2900100001)(87936001)(102836002)(10400500002)(99286002)(81156007)(10090500001)(64706001)(105586002)(77156002)(68736005)(5007970100001)(62966003)(2656002)(40100003)(2950100001)(10290500002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB008; H:BN1PR03MB008.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 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: 25 Aug 2015 23:46:57.5676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB008 Archived-At: Subject: Re: [tcpm] Review of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2015 23:47:01 -0000 Yes the Windows implementation does follow the order of processing CWR firs= t and then CE in essence allowing CE to override CWR. A DCTCP receiver does= not change this behavior. We will add text for CWR handling. Since this DC= TCP RFC draft doesn't update RFC 3168, maybe an errata is needed to describ= e handling of packet with CWR and CE set. -----Original Message----- From: Scheffenegger, Richard [mailto:rs@netapp.com]=20 Sent: Tuesday, August 4, 2015 1:29 AM To: tcpm@ietf.org; Praveen Balasubramanian ; Eggert, L= ars Cc: De Schepper, Koen (Koen) Subject: RE: Review of draft-bensley-tcpm-dctcp Hi, regarding to this comment by Koen, >=20 > 4.) The last sentence of section 3.3: "The setting of the Congestion=20 > Window Reduced (CWR) bit is also exactly as per [RFC3168]". Is there a=20 > reason to do this, and how does the receiver respond to this? (I=20 > assume a DCTCP receiver ignores it and an RFC3168 receiver needs it to=20 > stop echoing > CE) There is actually a gap in the description in RFC3168 for the case that a C= WR segment is also CE marked; at least one (significant) TCP stack got that= processing in the wrong order in the past, but not anymore.=20 The expected processing is to deal with CWR first (clear ECE - for a regula= r 3168 receiver), and the IP-header CE mark second (set ECE). Just wondering if this draft want's to describe the expected (proper) behav= ior for a regular 3168 receiver - or a DCTCP receiver in 3168 mode - somewh= ere, so that we have this as an RFC? (But with some luck, all receivers will deploy AccECN anyhow, very soon (TM= ) :) ). Best regards, Richard =20 From nobody Wed Aug 26 04:22:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF44C1A8825 for ; Wed, 26 Aug 2015 04:22:54 -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] autolearn=ham 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 MRMHitk2_Qu3 for ; Wed, 26 Aug 2015 04:22:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6C91A0171 for ; Wed, 26 Aug 2015 04:22:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150826112252.31534.58619.idtracker@ietfa.amsl.com> Date: Wed, 26 Aug 2015 04:22:52 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 11:22:55 -0000 Changed milestone "Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC", resolved as "Done". Changed milestone "Submit document on an analysis of more detailed ECN feedback in TCP to the IESG for publication as an Informational RFC", resolved as "Done", added draft-ietf-tcpm-accecn-reqs to milestone. URL: https://datatracker.ietf.org/wg/tcpm/charter/ From nobody Wed Aug 26 04:26:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D4F1B2A41 for ; Wed, 26 Aug 2015 04:26:56 -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] autolearn=ham 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 8eCC-fOndQqL for ; Wed, 26 Aug 2015 04:26:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F051B2B16 for ; Wed, 26 Aug 2015 04:26:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150826112654.27711.99311.idtracker@ietfa.amsl.com> Date: Wed, 26 Aug 2015 04:26:54 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 11:26:56 -0000 Changed milestone "Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC", added draft-ietf-tcpm-rtorestart to milestone. URL: https://datatracker.ietf.org/wg/tcpm/charter/ From nobody Wed Aug 26 04:28:11 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F34D1A87CC for ; Wed, 26 Aug 2015 04:28:10 -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] autolearn=ham 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 OEU8qUFVs0DU for ; Wed, 26 Aug 2015 04:28:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CA71A8F44 for ; Wed, 26 Aug 2015 04:28:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150826112808.10099.89780.idtracker@ietfa.amsl.com> Date: Wed, 26 Aug 2015 04:28:08 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 11:28:10 -0000 Changed milestone "Submit document on TCP support for rate-limited traffic for publication (status decided as earlier milestone)", resolved as "Done", added draft-ietf-tcpm-newcwv to milestone. URL: https://datatracker.ietf.org/wg/tcpm/charter/ From nobody Wed Aug 26 19:54:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322E11A1DBD; Wed, 26 Aug 2015 19:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 l3DOh5qhlsHb; Wed, 26 Aug 2015 19:54:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B91A1BDF; Wed, 26 Aug 2015 19:54:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2AF2F180452; Wed, 26 Aug 2015 19:53:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150827025358.2AF2F180452@rfc-editor.org> Date: Wed, 26 Aug 2015 19:53:58 -0700 (PDT) Archived-At: Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 7560 on Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Aug 2015 02:54:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7560 Title: Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback Author: M. Kuehlewind, Ed., R. Scheffenegger, B. Briscoe Status: Informational Stream: IETF Date: August 2015 Mailbox: mirja.kuehlewind@tik.ee.ethz.ch, rs@netapp.com, ietf@bobbriscoe.net Pages: 17 Characters: 40528 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-accecn-reqs-08.txt URL: https://www.rfc-editor.org/info/rfc7560 DOI: http://dx.doi.org/10.17487/RFC7560 Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Aug 27 03:26:04 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDD31B3536 for ; Thu, 27 Aug 2015 03:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 21tvC24hMJlm for ; Thu, 27 Aug 2015 03:26:01 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944E01B3195 for ; Thu, 27 Aug 2015 03:26:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,422,1437462000"; d="scan'208";a="63199663" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx143-out.netapp.com with ESMTP; 27 Aug 2015 03:25:23 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 27 Aug 2015 03:25:22 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::6d5f:5aa0:85e2:441%21]) with mapi id 15.00.1076.000; Thu, 27 Aug 2015 03:25:23 -0700 From: "Scheffenegger, Richard" To: Praveen Balasubramanian , "tcpm@ietf.org" , "Eggert, Lars" Thread-Topic: Review of draft-bensley-tcpm-dctcp Thread-Index: AQHQzgpxT32a1G1mK0OFkdDpIUY3B537gWcggCJ4hICAAc35IA== Date: Thu, 27 Aug 2015 10:25:22 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <689c340eb92f410a81cdb2c7e6115956@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Review of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Aug 2015 10:26:03 -0000 Hi Praveen, already done so a while ago. See https://www.rfc-editor.org/errata_search.p= hp?rfc=3D3168=20 I believe few actually look into the errata section - and AccECN (which Mir= ja, Bob and I are working on) are departing from the TCP signaling in 3168 = so much, that we can't accommodate that update in our document. >From my past experiments I knew that the (pre-DCTCP) Windows TCP stack was = behaving as expected (thank you), I just thought this might be a chance to = put the update into an RFC document earlier than waiting for an 3168bis (wh= ich probably won't come anymore). Best regards, Richard > -----Original Message----- > From: Praveen Balasubramanian [mailto:pravb@microsoft.com] > Sent: Mittwoch, 26. August 2015 01:47 > To: Scheffenegger, Richard; tcpm@ietf.org; Eggert, Lars > Cc: De Schepper, Koen (Koen) > Subject: RE: Review of draft-bensley-tcpm-dctcp >=20 > Yes the Windows implementation does follow the order of processing CWR > first and then CE in essence allowing CE to override CWR. A DCTCP receive= r > does not change this behavior. We will add text for CWR handling. Since > this DCTCP RFC draft doesn't update RFC 3168, maybe an errata is needed t= o > describe handling of packet with CWR and CE set. >=20 > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com] > Sent: Tuesday, August 4, 2015 1:29 AM > To: tcpm@ietf.org; Praveen Balasubramanian ; Eggert, > Lars > Cc: De Schepper, Koen (Koen) > Subject: RE: Review of draft-bensley-tcpm-dctcp >=20 >=20 > Hi, >=20 > regarding to this comment by Koen, >=20 > > > > 4.) The last sentence of section 3.3: "The setting of the Congestion > > Window Reduced (CWR) bit is also exactly as per [RFC3168]". Is there a > > reason to do this, and how does the receiver respond to this? (I > > assume a DCTCP receiver ignores it and an RFC3168 receiver needs it to > > stop echoing > > CE) >=20 >=20 > There is actually a gap in the description in RFC3168 for the case that a > CWR segment is also CE marked; at least one (significant) TCP stack got > that processing in the wrong order in the past, but not anymore. >=20 > The expected processing is to deal with CWR first (clear ECE - for a > regular 3168 receiver), and the IP-header CE mark second (set ECE). >=20 > Just wondering if this draft want's to describe the expected (proper) > behavior for a regular 3168 receiver - or a DCTCP receiver in 3168 mode - > somewhere, so that we have this as an RFC? >=20 > (But with some luck, all receivers will deploy AccECN anyhow, very soon > (TM) :) ). >=20 > Best regards, > Richard >=20