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

"Holland, Jake" <jholland@akamai.com> Mon, 15 June 2020 18:35 UTC

Return-Path: <jholland@akamai.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 1B4763A0866 for <tsvwg@ietfa.amsl.com>; Mon, 15 Jun 2020 11:35:56 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 9zpOj-fAERjg for <tsvwg@ietfa.amsl.com>; Mon, 15 Jun 2020 11:35:54 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 847D13A0867 for <tsvwg@ietf.org>; Mon, 15 Jun 2020 11:35:54 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 05FILqJ8021054; Mon, 15 Jun 2020 19:35:50 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=vGDc5HZ9oh3c+PSpNsrSDwdOWF6aSbR+xGfss3+T6Z0=; b=PoiTwNEInpVV3WrnpXKKVTPLoFtPOElqHjEUPWfZWow5IHwQGz+k/pQlcMnBklzQ+t/Y uFv6Xe+4XO99OYC6QU/w32dizbNFjoWBE8wCVS3U7wSPV8qSfHGD6TvCPOj/j37bWIQj Y2kRc15wTVicOayGsscW6SM8GEm0gz1NByWSK/ivjxP9uBrQsVb9dbvEujYSAfk1VIGz s8PccqM4LFST57jqmH0uK/kzznFYUg2sc0R6w2J4e7x1oE+BKLQyD1MHDMZSHJpevIwJ yW2XVK//MCSG+cQ/YwuY/hE0AIJnzYfcgxIFjTHAl18UKXmo8aH0X2alJZLKf323RWYk eg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 31mkvngtky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Jun 2020 19:35:49 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05FIZKqP019285; Mon, 15 Jun 2020 14:35:49 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint1.akamai.com with ESMTP id 31n79kr3mb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 15 Jun 2020 14:35:48 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 14:35:48 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1497.006; Mon, 15 Jun 2020 14:35:48 -0400
From: "Holland, Jake" <jholland@akamai.com>
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" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] path forward on L4S issue #16
Thread-Index: AQHWPmflxF+ga8lui0+JiOujX3WmVqjQmKyAgAAGX4CAAATUAIAAF0yAgAAq6wCAAAwWgIAAuTMAgAAS/QCAAAv+gIAASXuAgAAREQCAB7ORgA==
Date: Mon, 15 Jun 2020 18:35:48 +0000
Message-ID: <26EA4BBF-6A6D-41FE-8C37-45568A475CA0@akamai.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>
In-Reply-To: <HE1PR0701MB2876726FC67BD2850B5D39FAC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.81.180]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7BC79C2AB507284EBB47310F5CBB0A72@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-15_08:2020-06-15, 2020-06-15 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 adultscore=0 suspectscore=0 mlxscore=0 bulkscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006150137
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-15_08:2020-06-15, 2020-06-15 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 spamscore=0 malwarescore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 cotscore=-2147483648 suspectscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006150137
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/k5vBwbZ5GhsqpxZgWu8Cw-JKV5I>
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: Mon, 15 Jun 2020 18:35:56 -0000

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>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