Re: [tsvwg] path forward on L4S issue #16

"Black, David" <David.Black@dell.com> Wed, 17 June 2020 17:26 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 39ABC3A003B; Wed, 17 Jun 2020 10:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=JWSU0/QU; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=pqhQ+7oo
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 EiPtMY2UGe_T; Wed, 17 Jun 2020 10:26:03 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.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 26D2C3A0AB0; Wed, 17 Jun 2020 10:26:03 -0700 (PDT)
Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05HHLdJc027209; Wed, 17 Jun 2020 13:26:02 -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=MthnPQKORyI7f1IvFNgcdZhassBZPj+NQ783liIYor0=; b=JWSU0/QUE4YmU9kDZGIstp0easOMyu4o7/G1WbJfeORj8TNI6ME/tH7fRYZrjgEJmfjs fBr9bak40ukYa6JUcO+rktHWDqLwP8x//mFrqraxRrtzC8a1lpX9Mabhogj55GNErbdZ XHgdhErloZ4+ucB208IlSGjRJtVz32SOA2u2nS1TBV7Kj+syRoBVW06Q+kVe4Z8so6iU +sOElDmAZ/PLseGJabYmOfGRca+WWvqckyrXwkaKrKle3TVGCoDWE2hJXMk6aCjt2dmb Y2d9KNEEKhMhctwBFM8XFe3Hek6B6DDuJ0o/ISYiYvyIHxQti0jg9Yx1cRzCainGYIP8 Iw==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 31q67t3g7e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Jun 2020 13:26:02 -0400
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05HHIOw8142072; Wed, 17 Jun 2020 13:26:01 -0400
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2173.outbound.protection.outlook.com [104.47.59.173]) by mx0b-00154901.pphosted.com with ESMTP id 31q66d67f7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Jun 2020 13:26:01 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DSjsNRE7iPAnWQcYau8x/ub8wWLKmafl46xO23FdL/hNCC5m3O+miW2ecdVe6244qL4mmZjcDuzzKHlEYN4g3XmbR0VyQ417lT+cE2fBZ0DoWiOeQhMO904mXrdR+rbEY0p0yRzKlgEilxwb/B+BIbOdC3kJYKxvdzFtG0UghUsgv/MehTud8NxN83+knGtaVeVDrbZQRyzmVOnnVwCSJNP6ZS26gOB0MTgqqAAXFRU8355uXH7L3MYgAcRIHwapQnkv1qrUii9g+lj3fdJQFtjd8hgUiZXHZbOqNwDJWHQUQBZsOwnMff6nT4LKjOQaa8x5/3lf2+76B67SF5KWwg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MthnPQKORyI7f1IvFNgcdZhassBZPj+NQ783liIYor0=; b=ZR910UvWMoDNqMXTD1AD+ee098rR6K/QXyb3WG1csKs01UzkaqchJXkXCewC/WscPAGNz5EcfTI03DE/EdQvE0kPJhlH/Op+kMx0S1tGhzNlsGsSNChjpJLJ1AEqWnqo6Jj+gdwlqtFIzeA0AFv7ah+7DtohsLtvazXl44hA9gAYDIjTBHbAMzILTVI/wSBirvCr5AVGefq16gqxWNOOoJosX2iuRjBH+aXob5zO1kunQj8ip5J2GranYRTu3GKpNZ5RzMAHM21XUUafxvhdDN007hndmxAXMKeVfdg9IRYig3K9opQkkQOIkkgTn6KgW+JLaOPTRQf/DD2bckdD9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MthnPQKORyI7f1IvFNgcdZhassBZPj+NQ783liIYor0=; b=pqhQ+7oo8GGioEhLSWP7kvqIwsWIGwF9Nb5N09eZcw908CSiP8aR8udK/VnI20Lnscd2sFpmA1JB+YzowSqa0tQVP33fgAwLIu7wODRsEPlNd0lgbcIcqupqB6GB+2oTCxOLt1nOgY+pRZWtTF4OXTyWV2+sZNWZ5zneGTP4dks=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB4016.namprd19.prod.outlook.com (2603:10b6:208:1f0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 17 Jun 2020 17:25:59 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::3574:5511:eec9:567]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::3574:5511:eec9:567%9]) with mapi id 15.20.3088.028; Wed, 17 Jun 2020 17:25:59 +0000
From: "Black, David" <David.Black@dell.com>
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] path forward on L4S issue #16
Thread-Index: AQHWPmf3bVrZ0HY8O0yW2QMnN9/v4ajQVZ6AgAAGXoCAAATVAIAAF0yAgAAq6wCAAAwWgIAAuTIAgAAS/gCAAAv9gIAASXyAgAAREQCACCjrAIACzHSAgAAK5ACAAAWgAIAAI86AgAAKINA=
Date: Wed, 17 Jun 2020 17:25:59 +0000
Message-ID: <MN2PR19MB40450A06A919354C8D4CFC74839A0@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <2DC5C89B-C979-4354-98D7-BBDBC78A42B1@gmail.com> <202006171419.05HEJClG085550@gndrsh.dnsmgr.net> <HE1PR0701MB287641121218FC0AA72F56B0C29A0@HE1PR0701MB2876.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB287641121218FC0AA72F56B0C29A0@HE1PR0701MB2876.eurprd07.prod.outlook.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=2020-06-17T17:03:39.0635777Z; 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_ActionId=ab1388bd-0a25-4008-bf14-f22e98f5f0ee; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=dell.com;
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 037bd743-561f-4cef-a8d6-08d812e380a0
x-ms-traffictypediagnostic: MN2PR19MB4016:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB4016E3D434E7077835360224839A0@MN2PR19MB4016.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04371797A5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OE1dTu7236tJdXFLmlD/YQGYuofwBrIHSqifmM2MH77731sPsPdmKK4G82H4o3VSkJHlqu6xsWfdb0VreySvbkBQZHmGblRjQzz9flhCTEY63XDhhn6xDsxCicLHpsX4VP/oNjzzyTjFaWWTtUEHz5h8YIsjXhyvJZ32QM3aY9p9X/ZXuCJ8qatNTgOtXKwiz4Zb8MAxbkctFCEpnggp1Ox/AcJSHbibBcEvKwl4gJ45JHWRAeRM3hcaEDEWPJp9s1K98relVgK0uBETlE5ohYpsxt9zfwtX5dzg89NF7gxFYsJRqorh/edCAe/Ao+t+icM7JJF/8kr9m4mngNmtgQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(39860400002)(366004)(376002)(136003)(396003)(83380400001)(478600001)(9686003)(76116006)(7696005)(66946007)(5660300002)(6506007)(66556008)(64756008)(86362001)(316002)(786003)(53546011)(66476007)(52536014)(107886003)(66574015)(66446008)(186003)(55016002)(26005)(4326008)(8676002)(71200400001)(33656002)(2906002)(8936002)(54906003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: /jNKYQBDjsuB0/fOM4WOGdwU5o2sDCqEB/0gZm8zNu26YRlu+wcBk6x04sPpQ8qnDI3NfdpDReP5d4bNOKkivvoYSrxve7eOFyru6jhyWhv1/UC+5a2uikKjnOVRZp5vUZ7xUucfrRKcodjRaCFqupWmshFZ8s3FVfSVpDCREA2HkLCqFUmGjZVcXE4gMyEWm14mtMCotozVXp12S4SmNlOKk2uzNo/MMRQEYwV3+KuqBEiUPizXCO12NkAE7oeJ+zBWvVREPkQAH72AA+pTMlUDSPRmYbJ4tPSbpPTOKMcICfyZF/GyG2ZoThK32NI6kTDkret3ukk0huyv+Ri3SwlyWxWTnCtAKwRjzkT8iJyL6Vwzk02iST30oDB7JJ5wr/pVpcmlqEgC1j7zcg7cgBqUmTEswwMS7lUjpOzBwu2tfhqBfL/VwZQpnBhdre9A6QJWWzpMJdPDaThbp/eIhku4l3GODcfdQR5SgY08z9Q=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 037bd743-561f-4cef-a8d6-08d812e380a0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 17:25:59.6619 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Xz1Qrbwu1SYMKzIuWuHdkDYx+I8wRg6tZROPgIsG/s6zzW2lAiD9bVUBJ9g2hsM2tRpURH9IctZ7vmMABbi/9A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB4016
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-17_07:2020-06-17, 2020-06-17 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 malwarescore=0 bulkscore=0 spamscore=0 priorityscore=1501 cotscore=-2147483648 phishscore=0 mlxlogscore=999 suspectscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006170137
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 phishscore=0 spamscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006170138
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/4xSsHOmgFaZL3DE8XAKfTvCFRQ0>
Subject: Re: [tsvwg] path forward on L4S issue #16
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: Wed, 17 Jun 2020 17:26:05 -0000

Ingemar,
[posting as an individual]

> With that in mind, shouldn't it have been on the table to consider the
> possible future existence of L4S in the different realizations of fq-codel
> (and OpenWrt) development?
> 
> Issue #16 is pretty much a consequence of the above timeline, I see that
> there was ample time to react but that reaction did not come until 2019 (or
> late 2018?), was any assessment done as regards to how L4S could coexist
> with fq-codel before the debate started in TSVWG?.

The question seems relevant in the other direction - shouldn't L4S have taken coexistence RFC 3168 ECN more seriously in that timeframe?

To my recollection, the overall L4S approach to this topic in that timeframe is captured by this text that is still in the l4s-id draft (Appendix B):

      1.  It is quite unusual to experience queuing at more than one
          bottleneck on the same path (the available capacities have to
          be identical).

Thanks, --David

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Ingemar Johansson S
> Sent: Wednesday, June 17, 2020 12:27 PM
> To: Rodney W. Grimes; Jonathan Morton; Sebastian Moeller
> Cc: Ingemar Johansson S; tsvwg@ietf.org
> Subject: Re: [tsvwg] path forward on L4S issue #16
> 
> Hi
> 
> OK, I see that this discussion is only going in circles, nearly giving up on
> this.
> So far I see only one firm evidence that RFC3168 AQMs are deployed and
> enabled and these are related to the OpenWrt project, manifested in a few
> upgradeable devices (and some not upgradeable) that can be bought in retail
> stores. The rest is unconfirmed.
> 
> This leads me to a look at the time line for L4S and how it correlates with
> the fq-codel work and as a consequence the OpenWrt project.
> 
> 1) L4S was first brought up late 2013-early 2014 in TSVWG. The ECN
> experimentation draft (now RFC8311) was a draft -00 in sept 2016 and I know
> that this draft was preceeded by a discussion in TSVWG before that
> 
> 2) The FQ-codel work was finalized early 2016, not quite a perfect overlap
> with the 00 version of the ECN experimentation work but definitely an
> overlap with the preceeding L4S and dualQ discussions and references to the
> RITE project which happened around 2014-2015.
> 
> With that in mind, shouldn't it have been on the table to consider the
> possible future existence of L4S in the different realizations of fq-codel
> (and OpenWrt) development?
> 
> Issue #16 is pretty much a consequence of the above timeline, I see that
> there was ample time to react but that reaction did not come until 2019 (or
> late 2018?), was any assessment done as regards to how L4S could coexist
> with fq-codel before the debate started in TSVWG?.
> 
> /Ingemar
> 
> 
> 
> 
> > -----Original Message-----
> > From: Rodney W. Grimes <ietf@gndrsh.dnsmgr.net>
> > Sent: den 17 juni 2020 16:19
> > To: Jonathan Morton <chromatix99@gmail.com>
> > Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; Ingemar
> > Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>;
> > tsvwg@ietf.org
> > Subject: Re: [tsvwg] path forward on L4S issue #16
> >
> > > > On 17 Jun, 2020, at 4:20 pm, Ingemar Johansson S
> > <ingemar.s.johansson@ericsson.com> wrote:
> > > >
> > > > Given all the input sofar my impression is that It is difficult to say
> how
> > serious issue 16 really is.
> > > > Surely there is a possibility that L4S flows can get an potentially
> unfair
> > advantage over a congested node that is  RFC3168 capable (and ECN
> > enabled). The question is here when things are deemed as unfair and when
> > starvation is a fact, opinions differ.
> > > > Another question is to how large extent there will be legacy RFC3168
> ECN
> > capable (and ECN enabled ) bottlenecks that will "never" be updated or
> > replaced. This question is currently difficult to answer.
> > >
> > > When questions such as these are "difficult to answer", the correct
> design
> > choice is to assume pessimistically, unless and until the question can be
> > answered more definitively.  Therefore, the L4S design must account for
> the
> > possibility of RFC-3168 AQMs in the network, and actively avoid unfairness
> in
> > that case.
> > >
> > > > Yet another aspect is how successful it will be to implement RFC3168
> > bottleneck detection e.g. in TCP Prague, I am quite confident that these
> will
> > not always be successful.
> > >
> > > I think we can safely say that the detection mechanism currently in TCP
> > Prague is not successful.  David Black also pointed out that this would
> always
> > be a fragile mechanism, difficult to implement correctly, and thus likely
> to be
> > implemented wrongly by other transports even if a workable version was
> > somehow developed.
> > >
> > > With these facts established, I do not see how L4S can proceed without
> > changing the signalling mechanism it uses.  This is something we
> intuitively
> > realised more than a year ago, when the SCE project was started, but now
> > we have actual evidence to back up that intuition.
> >
> > And I would like to add to that, this is evidence the L4S team itself
> should of
> > identified, characterized and docuemented years ago.  I see no reason that
> it
> > took team SCE to disect the failure modes of L4S so that they could be
> > addressed.
> >
> > IMHO the fact that L4S is years into the process and only done positive
> test
> > results presentations leads one to believe it is simply being pushed
> through
> > the process with little to no care about the actual internet community.
> >
> > The proponents seem to genuily be a) unwilling to acknowledge that there a
> > problems they should be working on, and b) presenting that L4S is ready
> for
> > internet deployment inlight of the fact that data showing clear and
> present
> > problems exist.
> >
> > >  - Jonathan Morton
> > --
> > Rod Grimes
> rgrimes@freebsd.org