Re: [tcpPrague] Treatment of ECT(1) pre L4S

"Black, David" <David.Black@dell.com> Sat, 08 April 2017 00:35 UTC

Return-Path: <David.Black@dell.com>
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" <David.Black@dell.com>
Cc: TCP Prague List <tcpPrague@ietf.org>, tsvwg IETF list <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
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 <ietf@bobbriscoe.net>
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: <CE03DB3D7B45C245BCA0D243277949362F9B3D37@MX307CL04.corp.emc.com>
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: <https://mailarchive.ietf.org/arch/msg/tcpprague/HAMa7lYw4ev9vLH7gLODUi1lX0A>
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." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=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 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 <ddolson@sandvine.com>
> Cc: TCP Prague List <tcpPrague@ietf.org>; tsvwg IETF list <tsvwg@ietf.org>
> 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