From nobody Fri Apr 7 17:35:37 2017 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554BA127978; Fri, 7 Apr 2017 17:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.496 X-Spam-Level: X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=0JYDn0Ch; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=oH3G/0PO 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 cHyKN2A30gZR; Fri, 7 Apr 2017 17:35:21 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B48128BE1; Fri, 7 Apr 2017 17:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1491611450; x=1523147450; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OfXPGk+4TNoe9dRoEoODY7k9gsLmpWbwc7LvroNjhXs=; b=0JYDn0ChLir8nEGeTmsu918m68pMoH0aOm5WPmz+mW7Nd/7NqxSZfebX mXhv2bwg+gq7hTfsIHubuBVjIW5tAz0pPakQ3z2Eg99Vx2/3GFGZHFL7v 1y1k9YaeKIXfMxXStyV70hw5wWFkWS7Vvt9fwXAVsHIrbUCFqzkCP56GM k=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 19:30:48 -0500 From: "Black, David" Cc: TCP Prague List , tsvwg IETF list , "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2017 06:28:11 +0600 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v380ZApO026744 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 20:35:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v380ZApO026744 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1491611710; bh=Tm2zLpDx6g96+xQi+W8WcVSen3k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oH3G/0POCTPwwFeIwuNp9oGdpqoqBZ124NOP/tBlxhgUoGwjndOw60dUaDRWmBilP cDAjVpJctPKbflDvgUYdiPIfvw4zpbSlD+ABvOyZELOL1u2NHkphDY8KNIL6PuCd/C hg2+U9UIKms93U3wOvX5O0fyp36lX+4qPzrphoyw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v380ZApO026744 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 7 Apr 2017 20:34:31 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v380YsQu018079 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 7 Apr 2017 20:34:54 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0266.001; Fri, 7 Apr 2017 20:34:54 -0400 To: Bob Briscoe Thread-Topic: [tcpPrague] Treatment of ECT(1) pre L4S Thread-Index: AdHkCFgirgx3HT3iRm+SY64tLECkYTEduXEAAd+VebA= Date: Sat, 8 Apr 2017 00:34:53 +0000 Message-ID: References: <20160722110102.5697618.36413.99476@sandvine.com> <449c5fea-32ba-bf3f-bb7b-8f7b48b22f4f@bobbriscoe.net> In-Reply-To: <449c5fea-32ba-bf3f-bb7b-8f7b48b22f4f@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 00:35:28 -0000 This message is written as the author of the ECN Experimentation draft, not= as a WG chair. This topic was discussed in Chicago with a request to me as author of the E= CN experimentation draft to check that both options below are permitted. T= hese options are for network nodes that do not implement L4S dual queues bu= t for which there is a desire to do something reasonable with ECT(1) in lig= ht of L4S usage. The crucial ECN experimentation draft text is in Section = 4.2 (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimenta= tion#section-4.2): ----------------------------------- 4.2. ECT Differences Section 5 of RFC 3168 specifies that: Routers treat the ECT(0) and ECT(1) codepoints as equivalent. In support of ECT Differences experimentation, this memo updates RFC 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints differently, provided that the changes from RFC 3168 are documented in an Experimental RFC. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC" at the end of the above sentence. ----------------------------------- The ecn-l4s-id is intended to become an Experimental RFC, and hence would b= enefit from the added "unless otherwise specified by an Experimental RFC" t= ext. That added text imposes no limits on the scope of "otherwise specifie= d" - we are relying on the combined good sense of the draft authors, WG mem= bers, the IETF community and the IESG to ensure that nothing horrendous in = this area makes it into an Experimental RFC ;-). I see no problem with an Experimental RFC for L4S specifying not only exper= imental changes to network nodes that fully participate in the experiment (= dual queues) but also specifying experimental changes for network nodes tha= t only partially participate - the options below are for network nodes that= only partially participate. Thanks, --David > -----Original Message----- > From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Bob > Briscoe > Sent: Wednesday, March 29, 2017 3:26 AM > To: Dave Dolson > Cc: TCP Prague List ; tsvwg IETF list > Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S >=20 > Dave, >=20 > I've cc'd this to tsvwg. > We will put text in the ecn-l4s-id draft unless there is not consensus > from others about this yet. >=20 > I agree with Koen now. >=20 > To be clear, I believe that a classic AQM supporting only RFC3168 > (Classic) ECN: > * should never alter the ECT(1) field > * should be configurable between the following two behaviours: > - [default] treat ECT(1) as if it does not support ECN, so drop where > it would have marked CE > - treat ECT(1) as if it is ECT(0) >=20 > I am less keen than Koen on adding the latter option - I prefer clear > simple advice to avoid confusion. > So IMO, if you don't want another config knob, it would be OK to just > support the default. >=20 > Ideally, once the DualQ specs are approved, the AQM should also be > upgraded to support Dual Qs and the squared relationship between them. >=20 > Sorry it's taken so long to confirm this. >=20 > Cheers >=20 >=20 >=20 > Bob >=20 > On 22/07/16 12:01, Dave Dolson wrote: > > If an operator were to deploy ECN today, pre L4S, what should be the > treatment of ECT(1)? > > > > I believe, from a discussion with Koen, that the safest approach is for= a pre- > L4S implementation to signal congestion to ECT(1) by dropping. If ECT(1) > were treated the same as ECT(0) then new experimental TCP-Prague flows > would out-compete any ECT(0) traffic. > > > > Is this agreed? If so, should it be recommended somewhere? > > > > Note that I got mixed answers on this from other IETF folks, so I think= it is > worth sorting out. > > > > > > -Dave > > > > > > > > _______________________________________________ > > tcpPrague mailing list > > tcpPrague@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpprague >=20 > -- > __________________________________________________________ > ______ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague From nobody Sat Apr 8 02:05:57 2017 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963F41205D3; Sat, 8 Apr 2017 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpdIQHbS_5jD; Sat, 8 Apr 2017 02:05:52 -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 850B61293EB; Sat, 8 Apr 2017 02:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q+PzN+hJydlZjAUcnVEdzLwappJmJC28KwGpjZcn0zM=; b=U7yvb249YOgfrNxMRwQY1mIBXQ CEUV97kX+48FMHjRtNt/+fcFo3iNoDqBYUjtEIwgiv7ure9YQfESB1nmjK/mvuLXa3jEXzWd4izGA BaGfMB98gQ0WG73TrEglADRQWX74esC3GISbvRiT+AgRnbE4tgGVnSBVISv+ARz0SFH8VkuAtXzj4 SWySVh+zyyx9mVLvu8XLw43pFxwjbXcT+3pn5/OENYTqkICnlM8ckrBVR74OMFQHQ23nG+WVAFjk+ x1fXWcE4QiGjis3yHiD9d8Xi62yTvGMpGMt68YOk3RMnUZgPN6Q422ND04chJ46zHrYvnB6DGFsp6 NZndrPEg==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:52786 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cwmJX-0004NA-K2; Sat, 08 Apr 2017 10:05:47 +0100 To: "Black, David" References: <20160722110102.5697618.36413.99476@sandvine.com> <449c5fea-32ba-bf3f-bb7b-8f7b48b22f4f@bobbriscoe.net> Cc: TCP Prague List , tsvwg IETF list From: Bob Briscoe Message-ID: <0c9f29ef-993d-606a-c0c6-05a411903993@bobbriscoe.net> Date: Sat, 8 Apr 2017 10:05:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 09:05:55 -0000 David, Thx for confirming we are OK to go ahead with this. What's the status of the ecn-l4s-id adoption call? If it's about to be formally adopted, I could add in this text at the same time as changing the filename to draft-ietf... Bob On 08/04/17 01:34, Black, David wrote: > This message is written as the author of the ECN Experimentation draft, not as a WG chair. > > This topic was discussed in Chicago with a request to me as author of the ECN experimentation draft to check that both options below are permitted. These options are for network nodes that do not implement L4S dual queues but for which there is a desire to do something reasonable with ECT(1) in light of L4S usage. The crucial ECN experimentation draft text is in Section 4.2 (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation#section-4.2): > > ----------------------------------- > 4.2. ECT Differences > > Section 5 of RFC 3168 specifies that: > > Routers treat the ECT(0) and ECT(1) codepoints as equivalent. > > In support of ECT Differences experimentation, this memo updates RFC > 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints > differently, provided that the changes from RFC 3168 are documented > in an Experimental RFC. The specific change to RFC 3168 is to insert > the words "unless otherwise specified by an Experimental RFC" at the > end of the above sentence. > ----------------------------------- > > The ecn-l4s-id is intended to become an Experimental RFC, and hence would benefit from the added "unless otherwise specified by an Experimental RFC" text. That added text imposes no limits on the scope of "otherwise specified" - we are relying on the combined good sense of the draft authors, WG members, the IETF community and the IESG to ensure that nothing horrendous in this area makes it into an Experimental RFC ;-). > > I see no problem with an Experimental RFC for L4S specifying not only experimental changes to network nodes that fully participate in the experiment (dual queues) but also specifying experimental changes for network nodes that only partially participate - the options below are for network nodes that only partially participate. > > Thanks, --David > >> -----Original Message----- >> From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Bob >> Briscoe >> Sent: Wednesday, March 29, 2017 3:26 AM >> To: Dave Dolson >> Cc: TCP Prague List ; tsvwg IETF list >> Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S >> >> Dave, >> >> I've cc'd this to tsvwg. >> We will put text in the ecn-l4s-id draft unless there is not consensus >> from others about this yet. >> >> I agree with Koen now. >> >> To be clear, I believe that a classic AQM supporting only RFC3168 >> (Classic) ECN: >> * should never alter the ECT(1) field >> * should be configurable between the following two behaviours: >> - [default] treat ECT(1) as if it does not support ECN, so drop where >> it would have marked CE >> - treat ECT(1) as if it is ECT(0) >> >> I am less keen than Koen on adding the latter option - I prefer clear >> simple advice to avoid confusion. >> So IMO, if you don't want another config knob, it would be OK to just >> support the default. >> >> Ideally, once the DualQ specs are approved, the AQM should also be >> upgraded to support Dual Qs and the squared relationship between them. >> >> Sorry it's taken so long to confirm this. >> >> Cheers >> >> >> >> Bob >> >> On 22/07/16 12:01, Dave Dolson wrote: >>> If an operator were to deploy ECN today, pre L4S, what should be the >> treatment of ECT(1)? >>> I believe, from a discussion with Koen, that the safest approach is for a pre- >> L4S implementation to signal congestion to ECT(1) by dropping. If ECT(1) >> were treated the same as ECT(0) then new experimental TCP-Prague flows >> would out-compete any ECT(0) traffic. >>> Is this agreed? If so, should it be recommended somewhere? >>> >>> Note that I got mixed answers on this from other IETF folks, so I think it is >> worth sorting out. >>> >>> -Dave >>> >>> >>> >>> _______________________________________________ >>> tcpPrague mailing list >>> tcpPrague@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpprague >> -- >> __________________________________________________________ >> ______ >> Bob Briscoe http://bobbriscoe.net/ >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/