Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

"Black, David" <David.Black@dell.com> Fri, 19 July 2019 20:07 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B67120787 for <tsvwg@ietfa.amsl.com>; Fri, 19 Jul 2019 13:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=PmSdcju7; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=ZCl0ezy1
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 afsJGebvML0C for <tsvwg@ietfa.amsl.com>; Fri, 19 Jul 2019 13:07:34 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 B40951203DE for <tsvwg@ietf.org>; Fri, 19 Jul 2019 13:07:34 -0700 (PDT)
Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6JK4p5o006798; Fri, 19 Jul 2019 16:07:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=hV6xV7pbHtlFDTHIKKFOBDzUJaI5lwqpStIPy1QcvRI=; b=PmSdcju79AilZx9g9HEfM5rA+EqqWuy5aoM9+2RL4g+RpY6gRMfZLxZS8FyxlxoosUtl gYA4njez1s4mu+b5mMg2ARLqX/sfMvZzAnQ9qQ1eB2N072UtDDWaYq9n1eg8jts53ttq x+NcbwU13NfAKoyy4rHfVKwTNlNKAOrSzUnTogzKbV7TZryU57+qWwDlFRT7xDzY7nLl IlT4JQu1aLWBqhPsMdasHz9ZtSX1ncW7keQiG4udMjddIt1w14VoYRRmTbmjrZEU6vqb gY1WhmEeibjxUPD7HEzcb7RRC8YjkNF9pzBEX4q0voAKTCD499p2fq/vyT/PKHuNgKZp 3Q==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2tudhyt1nd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jul 2019 16:07:33 -0400
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6JK2aWD107343; Fri, 19 Jul 2019 16:07:33 -0400
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by mx0b-00154901.pphosted.com with ESMTP id 2tugs73a81-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Jul 2019 16:07:32 -0400
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6JK6TMv031909 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Jul 2019 16:07:31 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com x6JK6TMv031909
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1563566852; bh=Y/DkljbmiUeyo/sk9T5G/pLbxd0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ZCl0ezy1Gy+puCcup1pPkl7V2cvQ8CI9jZc5Yq6KV94Zg/d3RSu7KqpEdF4njM9on Myk5p3+TWcC059DGvNe61TlDIRpttWW3BIapwfb1LnEGE2pfELtkCYLrOj97mQN0Hq Va/bxhHx2w0DvV77eEEjIK1s3rwaGCsbn3nFIST0=
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 19 Jul 2019 16:06:04 -0400
Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6JK642e019039 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 19 Jul 2019 16:06:04 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0439.000; Fri, 19 Jul 2019 16:06:03 -0400
From: "Black, David" <David.Black@dell.com>
To: Wesley Eddy <wes@mti-systems.com>, Dave Taht <dave@taht.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
CC: "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] [Ecn-sane] Comments on L4S drafts
Thread-Index: AQHVPmCHbQOVja0uik6WYBMk3HvW4abSUwAA
Date: Fri, 19 Jul 2019 20:06:03 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363062879C@MX307CL04.corp.emc.com>
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <D13294C4-105C-4F58-A762-6911A21A18C6@akamai.com> <CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com> <ce4b1e2d-3bc8-265c-6bcd-5a26b4dd89e9@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <AM4PR07MB3459B1173917DAFBCEB25511B9FA0@AM4PR07MB3459.eurprd07.prod.outlook.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <AM4PR07MB345956F52D92759F24FFAA13B9F50@AM4PR07MB3459.eurprd07.prod.outlook.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <AM4PR07MB3459B471C4D7ADAE4CF713F3B9F60@AM4PR07MB3459.eurprd07.prod.outlook.com> <D231681B-1E57-44E1-992A-E8CC423926B6@akamai.com> <AM4PR07MB34592A10E2625C2C32B9893EB9F00@AM4PR07MB3459.eurprd07.prod.outlook.com> <A6F05DD3-D276-4893-9B15-F48E3018A129@gmx.de> <AM4PR07MB3459487C8A79B1152E132CE1B9CB0@AM4PR07MB3459.eurprd07.prod.outlook.com> <87ef2myqzv.fsf@taht.net> <a85d38ba-98ac-e43e-7610-658f4d03e0f4@mti-systems.com>
In-Reply-To: <a85d38ba-98ac-e43e-7610-658f4d03e0f4@mti-systems.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-07-19T20:05:36.0298834Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [10.238.21.131]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-19_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907190216
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907190216
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/4_JJOc2NtqNULGzh-jVKkKSnVaE>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2019 20:07:38 -0000

Two comments as an individual, not as a WG chair:

> Mostly, they're things that an end-host algorithm needs
> to do in order to behave nicely, that might be good things anyways
> without regard to L4S in the network (coexist w/ Reno, avoid RTT bias,
> work well w/ small RTT, be robust to reordering).  I am curious which
> ones you think are too rigid ... maybe they can be loosened?

[1] I have profoundly objected to L4S's RACK-like requirement (use time to detect loss, and in particular do not use 3DupACK) in public on multiple occasions, because in reliable transport space, that forces use of TCP Prague, a protocol with which we have little to no deployment or operational experience.  Moreover, that requirement raises the bar for other protocols in a fashion that impacts endpoint firmware, and possibly hardware in some important (IMHO) environments where investing in those changes delivers little to no benefit.  The environments that I have in mind include a lot of data centers.  Process wise, I'm ok with addressing this objection via some sort of "controlled environment" escape clause text that makes this RACK-like requirement inapplicable in a "controlled environment" that does not need that behavior (e.g., where 3DupACK does not cause problems and is not expected to cause problems).  

For clarity, I understand the multi-lane link design rationale behind the RACK-like requirement and would agree with that requirement in a perfect world ... BUT ... this world is not perfect ... e.g., 3DupACK will not vanish from "running code" anytime soon.

> > So to me, it goes back to slamming the door shut, or not, on L4S's usage
> > of ect(1) as a too easily gamed e2e identifier. As I don't think it and
> > all the dependent code and algorithms can possibly scale past a single
> > physical layer tech, I'd like to see it move to a DSCP codepoint, worst
> > case... and certainly remain "experimental" in scope until anyone
> > independent can attempt to evaluate it.
> 
> That seems good to discuss in regard to the L4S ID draft.  There is a
> section (5.2) there already discussing DSCP, and why it alone isn't
> feasible.  There's also more detailed description of the relation and
> interworking in
> https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-02

[2] We probably should pay more attention to that draft.  One of the things that I think is important in that draft is a requirement that operators can enable/disable L4S behavior of ECT(1) on a per-DSCP basis - the rationale for that functionality starts with incremental deployment.   This technique may also have the potential to provide a means for L4S and SCE to coexist via use of different DSCPs for L4S vs. SCE traffic (there are some subtleties here, e.g., interaction with operator bleaching of DSCPs to zero at network boundaries).

To be clear on what I have in mind:
	o Unacceptable: All traffic marked with ECT(1) goes into the L4S queue, independent of what DSCP it is marked with.
	o Acceptable:  There's an operator-configurable list of DSCPs that support an L4S service - traffic marked with ECT(1) goes into the L4S queue if and only if that traffic is also marked with a DSCP that is on the operator's DSCPs-for-L4S list.

Reminder: This entire message is posted as an individual, not as a WG chair.

Thanks, --David

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Wesley Eddy
> Sent: Friday, July 19, 2019 2:34 PM
> To: Dave Taht; De Schepper, Koen (Nokia - BE/Antwerp)
> Cc: ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org
> Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
> 
> 
> [EXTERNAL EMAIL]
> 
> On 7/19/2019 11:37 AM, Dave Taht wrote:
> > It's the common-q with AQM **+ ECN** that's the sticking point. I'm
> > perfectly satisfied with the behavior of every ietf approved single
> > queued AQM without ecn enabled. Let's deploy more of those!
> 
> Hi Dave, I'm just trying to make sure I'm reading into your message
> correctly ... if I'm understanding it, then you're not in favor of
> either SCE or L4S at all?  With small queues and without ECN, loss
> becomes the only congestion signal, which is not desirable, IMHO, or am
> I totally misunderstanding something?
> 
> 
> > If we could somehow create a neutral poll in the general networking
> > community outside the ietf (nanog, bsd, linux, dcs, bigcos, routercos,
> > ISPs small and large) , and do it much like your classic "vote for a
> > political measure" thing, with a single point/counterpoint section,
> > maybe we'd get somewhere.
> 
> While I agree that would be really useful, it's kind of an "I want a
> pony" statement.  As a TSVWG chair where we're doing this work, we've
> been getting inputs from people that have a foot in many of the
> communities you mention, but always looking for more.
> 
> 
> > In particular conflating "low latency" really confounds the subject
> > matter, and has for years. FQ gives "low latency" for the vast
> > majority of flows running below their fair share. L4S promises "low
> > latency" for a rigidly defined set of congestion controls in a
> > specialized queue, and otherwise tosses all flows into a higher latency
> > queue when one flow is greedy.
> 
> I don't think this is a correct statement.  Packets have to be from a
> "scalable congestion control" to get access to the L4S queue.  There are
> some draft requirements for using the L4S ID, but they seem pretty
> flexible to me.  Mostly, they're things that an end-host algorithm needs
> to do in order to behave nicely, that might be good things anyways
> without regard to L4S in the network (coexist w/ Reno, avoid RTT bias,
> work well w/ small RTT, be robust to reordering).  I am curious which
> ones you think are too rigid ... maybe they can be loosened?
> 
> Also, I don't think the "tosses all flows into a higher latency queue
> when one flow is greedy" characterization is correct.  The other queue
> is for classic/non-scalable traffic, and not necessarily higher latency
> for a given flow, nor is winding up there related to whether another
> flow is greedy.
> 
> 
> > So to me, it goes back to slamming the door shut, or not, on L4S's usage
> > of ect(1) as a too easily gamed e2e identifier. As I don't think it and
> > all the dependent code and algorithms can possibly scale past a single
> > physical layer tech, I'd like to see it move to a DSCP codepoint, worst
> > case... and certainly remain "experimental" in scope until anyone
> > independent can attempt to evaluate it.
> 
> That seems good to discuss in regard to the L4S ID draft.  There is a
> section (5.2) there already discussing DSCP, and why it alone isn't
> feasible.  There's also more detailed description of the relation and
> interworking in
> https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-02
> 
> 
> > I'd really all the tcp-go-fast-at-any-cost people to take a year off to
> > dogfood their designs, and go live somewhere with a congested network
> to
> > deal with daily, like a railway or airport, or on 3G network on a
> > sailboat or beach somewhere. It's not a bad life... REALLY.
> >
> Fortunately, at least in the IETF, I don't think there have been
> initiatives in the direction of going fast at any cost in recent
> history, and they would be unlikely to be well accepted if there were!
> That is at least one place that there seems to be strong consensus.
>