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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Wed, 17 June 2020 13:20 UTC

Return-Path: <ingemar.s.johansson@ericsson.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 9D1613A0063 for <tsvwg@ietfa.amsl.com>; Wed, 17 Jun 2020 06:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 ewo-R3-LEQ1v for <tsvwg@ietfa.amsl.com>; Wed, 17 Jun 2020 06:20:09 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2040.outbound.protection.outlook.com [40.107.22.40]) (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 7D3C73A0029 for <tsvwg@ietf.org>; Wed, 17 Jun 2020 06:20:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n55ClbVUVNR96XbPp8ZfriLAyEGNx6Ltl4ectEvU+HWJMZZ8IYr1iDkF1xfCI7xg69XELzOd4De2bDiqSSKNDRyFzcXJpI48UJztex5eGKZwVsVclqkhi3PERzLzTTi+EHf5sfn4LRLieCtu14kjL6YBdDLDWuwJ3CQIm3LeSQY9zk71Bi6mC+41gKhOtWidWOEHbgOD3berhj1yUbTQ1oHOTPNEiN7kKIFXyalm4mlZkGTpQZneYM/AzbOb2aCRWgEDV+IsxzF3SOBXWZXn96cDsjhVysk1p+X8vPspT5F3Sp+n9uRsnVko5SYYij2wukEOL9yw6W37jpY1KfLuWg==
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=URomVaLVXnYvLgwKx8a7nXgvkqlNiQGuC2YIdYhqUrY=; b=B/bhKKD+HtzURrEKjURgkfoqW66QuL65wOsilpp31zglqFUYD4I2HhogvsdcPmUCLX33MM/i0dLgfYWpL7k4aDzK9xnfAvZN5BKnN/cv5OTj159Ugku6ATzebth99vqbfNvGEfeJJxK8XVQWZTCSBklioC2i7uNX5Boo+E5FzzXuNDBGRyZ4Z+rmAkIoNIMJNZm7SepaSZE7ZgJLWGycSYjG0EZZPf5vNdR6PSf+8WVGVZftcPMSPuxPzesxC2nlqUvH2b4kSUhrLrfxt3j/fGhclj/7snLM/z7219H8B+Z7Euvp2hCOmr4BdAh/b1ghiyoZxrzrtv1+VKyudYvJ0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=URomVaLVXnYvLgwKx8a7nXgvkqlNiQGuC2YIdYhqUrY=; b=AcJ6z8HsJ3tEONSsZGkggDPt09NiW2l94AY0pIYLBtYWwfZGZqm1GDsph6X3vVDlJqG1hIZATfLz5W3cN86NLsaTWmzmTVfu3h3mzWpZdrPYxCB/BHFUlL2Z9w7ZJHOFG9HlonPsy74Uh/ma9RXboE82izP4c/LvC/X8mm0sv/g=
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com (2603:10a6:3:56::8) by HE1PR0701MB2330.eurprd07.prod.outlook.com (2603:10a6:3:6a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.15; Wed, 17 Jun 2020 13:20:05 +0000
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::f411:8f72:4035:41d1]) by HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::f411:8f72:4035:41d1%8]) with mapi id 15.20.3109.018; Wed, 17 Jun 2020 13:20:05 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "Holland, Jake" <jholland@akamai.com>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, Jonathan Morton <chromatix99@gmail.com>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] path forward on L4S issue #16
Thread-Index: AQHWPkYZyJNg6cgsQkOoRWoF9Fsxh6jQUFNQgAAFjoCAAAT/IIAABjQAgAAXTICAACKkgIAAFF2AgACvbJCAABzFAIAAByHAgABOV4CAAA2VUIAILGgAgALBbRA=
Date: Wed, 17 Jun 2020 13:20:05 +0000
Message-ID: <HE1PR0701MB287625771753F579227D90E7C29A0@HE1PR0701MB2876.eurprd07.prod.outlook.com>
References: <HE1PR0701MB2876AA3CBBA215B9FB895B0AC2820@HE1PR0701MB2876.eurprd07.prod.outlook.com> <3637517F-63A0-4862-9885-AB5EA7E6C273@gmail.com> <VI1PR0701MB2877E21B7F406C3DFCFF08BCC2820@VI1PR0701MB2877.eurprd07.prod.outlook.com> <92525827-39B6-4E88-B453-660F8FE22523@gmx.de> <VI1PR0701MB287768D465C37DC46A459C12C2820@VI1PR0701MB2877.eurprd07.prod.outlook.com> <57D7632A-594E-47BC-B6B0-5FBC22AAFE37@gmail.com> <DF67B660-DE2B-4EB8-AD77-5FECF27D1BAC@gmx.de> <HE1PR0701MB287679D1842F15FCDAC6223EC2820@HE1PR0701MB2876.eurprd07.prod.outlook.com> <7EEF7075-396F-4565-89C6-674CBB1E6CB8@gmx.de> <HE1PR0701MB28767A1E570A705EBC65EFC4C2830@HE1PR0701MB2876.eurprd07.prod.outlook.com> <5ADEBD56-1A2C-4C34-9132-E50A4A7A4A42@gmx.de> <HE1PR0701MB287695F2245A480A43DB5F9BC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com> <EEB9B5D1-5F06-4BA6-A078-BE9C26D0EAD6@gmail.com> <HE1PR0701MB2876726FC67BD2850B5D39FAC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com> <26EA4BBF-6A6D-41FE-8C37-45568A475CA0@akamai.com>
In-Reply-To: <26EA4BBF-6A6D-41FE-8C37-45568A475CA0@akamai.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b1f13895-3b28-467e-2733-08d812c12682
x-ms-traffictypediagnostic: HE1PR0701MB2330:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB23306C786AAF39AC25FA0EA4C29A0@HE1PR0701MB2330.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3513;
x-forefront-prvs: 04371797A5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Caa4CRY8NckNriKreD8EQaEnbg/jiHRbk5fBybBmMVyLr1y4HEI3paBSXys6gcqkv6V0GW2vFpgTP75PVpIUgXmJczknFapomOZI7C+fZYeej1X9Q33TXOLPx2M4EWGdei+BK4yy8pSz6rAUWgi8k2cdP+1pvODJVflXJEac3PpIIs2trJeFndhqo99JPKBU0hHJYS7yodKXy/o1hxJaA3iCSBtq3flPnw79HlElM8msvwRfERzm9l7pbS9oeHiFIVtiHc4ehKNRg5dD2z6hQKkK6yJfcnI8EPHPqjn+C1MBwlV0OqNVtgroCGrRotbOJjOxBuBC/IOsz++/MuOYqbR9yHOcOyIRIMFY7V5X85KBYw1FMsOJ7QVeq7g8QGGn1atBroLZgYYiNxd5BpycPg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2876.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(346002)(39860400002)(136003)(376002)(55016002)(4326008)(9686003)(8936002)(99936003)(7696005)(33656002)(54906003)(110136005)(86362001)(107886003)(6506007)(83380400001)(316002)(53546011)(66574015)(8676002)(64756008)(186003)(66616009)(966005)(478600001)(45080400002)(71200400001)(5660300002)(76116006)(2906002)(66476007)(66556008)(66446008)(66946007)(52536014)(26005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: o4/hd0HvlulcE1TD+edqyn3HNlFu135HPtm5tSVL8pyntpHxNTNjiHJ1QWixduQPMWqufMnuLh2GKO/gSHIool69yjyiHdZ4yXw9obtynwEjRcxb6AnhTQok6x4XxBj1BbJIk+sI6xEca8xIHIa2Gh9p+S+mecU8rMftYTpsfaQq99cl/TIZFt5YDQlEZM0wqqRTULmoUEyKnkokmGuatkjB5mVfRXklBdpMKpiuKwMqvvj4OdQJ9I/hcQzs8x9bCvtWDRa7BY3HcZ6UijVmB8tgM3ejltQVOy0J5uAu8T2s6ikXH3KP1gCdBaXYP9K+jtBe+T4ZLAl9jRYkWQW1IPuqQEzn0VqlcfmtfNnm4JBeGdG/ed+DgHgiAtbfeqjLRvt+stFyQ+jf9e1Tq6VN8MfbrzRIoo46vLtNnbnK0FbkXGeSTTUDatOpCeZuCmxZMJWYTOxRorSJaPg8+5l7SmVELbUYlgO36v4Q7wHLMpI=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_006B_01D644BA.C69CD0E0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b1f13895-3b28-467e-2733-08d812c12682
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 13:20:05.6117 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vRs71dTs8XWJ6PRUBqEZUtYY2Onm42nb0QJlD3JNZ3A1W4paOuZlRJq/t4/FwoQIG4Vv2Mz1mttae36UVNam+4syQMijyQfnbYp8Zbz4GIgaRhO3gV8lcbW0ocTIKA6W
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2330
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/HmXTGhGt-h4XJvYnUkXcBsDXEfg>
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 13:20:11 -0000

Hi Jake

And thanks for the input. 
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. 

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. But then, given the current deployment situation and possibility to update nodes in the networks (OpenWrt routers appear to support automatic updates) I am not convinced that these need to be 100% bulletproof either.

/Ingemar

> -----Original Message-----
> From: Holland, Jake <jholland@akamai.com>
> Sent: den 15 juni 2020 20:36
> To: Ingemar Johansson S
> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; Jonathan Morton
> <chromatix99@gmail.com>
> Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>;
> tsvwg@ietf.org
> Subject: Re: [tsvwg] path forward on L4S issue #16
> 
> Hi Ingemar,
> 
> I posted some summary numbers from some observations I made here:
> https://mailarchive.ietf.org/arch/msg/tsvwg/2tbRHphJ8K_CE6is9n7iQy-
> VAZM/
> 
> I didn't say anything about France or Norway, but the numbers I have seen
> were roughly in line with the numbers Jonathan gave.
> 
> The "growing" claim also looks tentatively well-supported, because I've seen
> 2 new ASNs since then with a high count of CE-marking paths.
> 
> HTH.
> 
> Best regards,
> Jake
> 
> On 6/10/20, 6:59 AM, "Ingemar Johansson S"
> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi
> 
> Do you have any public sources that confirm the numbers you quote below
> ?. I tried to look up data on this but it surely is not easy.
> Which foras are the vendors that manufacture CPEs active in (if any) ?.
> 
> As regards to endpoints implementing RFC3168, do you refer to servers and
> clients or something else?. My interpretation is servers and clients and I don't
> believe that they are central  to this discussion, or do I miss something ?. I
> understand that traffic shaping on outgoing interfaces can be applied in a
> Linux host but don't see why they become a problem especially as there are
> qdiscs that support dualQ.
> 
> /Ingemar
> 
> PS. I am not yet trying to convince anybody, I am just trying to find the
> answers.
> 
> 
> > -----Original Message-----
> > From: Jonathan Morton <chromatix99@gmail.com>
> > Sent: den 10 juni 2020 14:58
> > To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> > Cc: Sebastian Moeller <moeller0@gmx.de>; tsvwg@ietf.org
> > Subject: Re: [tsvwg] path forward on L4S issue #16
> >
> > > On 10 Jun, 2020, at 11:35 am, Ingemar Johansson S
> > <ingemar.s.johansson@ericsson.com> wrote:
> > >
> > > 1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled
> ?
> >
> > Enough for the effects to be visible on about 0.1-1.0% of current
> > Internet traffic - and rising steadily.  That's some combination of
> > endpoints
> negotiating
> > ECN support, and middleboxes implementing an AQM, but not necessarily
> > both on the same path.  Deployment of ECN-enabled AQM is very high
> > across a small number of forward-thinking ISPs, including a very large
> > one
> in
> > France and a major one in Norway.
> >
> > Basically every endpoint out there today implements RFC-3168 ECN, and
> > every Linux endpoint runs an ECN-enabled AQM by default on each
> > Ethernet interface.  If Linux and/or Microsoft had decided to switch
> > it on by
> default a
> > decade ago, rather than hiding it behind a non-default configuration
> > flag,
> we
> > would not be having this conversation, because the deployment numbers
> > would be too big and obvious to ignore.  It's been a long, slow
> chicken-and-
> > egg situation which the major consumer ISPs have essentially refused
> > to
> help
> > resolve.
> >
> > But now there are commercial, off-the-shelf CPE products which anyone
> > can buy and install, and which implement the sort of bufferbloat
> > mitigation measures that most ISPs have not.  I've found at least one
> > of those on the physical retail shelf, here in Finland.  I don't have
> > sales numbers, but
> they
> > must account for most of the deployment on ISPs that haven't deployed
> > it themselves.
> >
> > > 2) If they are deployed _and_ enabled, can/will they be updated ?
> >
> > Some can and will.  But some is baked in hardware so would be
> > difficult to update, and some is managed by people/vendors who do not
> > know or care about L4S, so would tend to keep using the old system
> > which is RFC- compliant today.  When was the last time your CPE
> > devices got a firmware update?  So L4S has to be able to cope with the
> > existence of such deployments in at least the medium term.
> >
> > Frankly, if you believe that tunnels are an intractable problem, then
> > this
> is
> > just as bad.  So please finally drop this argument; you're not
> > convincing anyone who matters.
> >
> >  - Jonathan Morton
>