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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Thu, 11 June 2020 08:23 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 E6EA03A176C for <tsvwg@ietfa.amsl.com>; Thu, 11 Jun 2020 01:23:38 -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=ham 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 GV6O7AtzLiMH for <tsvwg@ietfa.amsl.com>; Thu, 11 Jun 2020 01:23:37 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2078.outbound.protection.outlook.com [40.107.21.78]) (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 A3C763A175A for <tsvwg@ietf.org>; Thu, 11 Jun 2020 01:23:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mTkUFJ3BvVD3GC4SrjWfM4iaRY4td1VXxk+EBhTreZ9d0YAcmql9epWE3hUFohOMoilkC8iDQ41inoMT66LPm28yb05VCMD89kOKb0xul0DBcKdn2uZ2tEILehseJI1+egXo1BE2kthXSGjXagARaZuQLI/GveDpxTYS29feCkLy+lOJA4ymE06DlhgGLAe8wK32NvMVz8t2qJTQTmbG2VrT82hrb80xGaernYXujw/UQtvEGBqJdH87gBiFDzo1QqiLeneH/h1CRH76eqCQZYWcjZV0itMmyTiTGTQaMUP+Ov8F6LtPGif1CAAc/NNbBKyPP2m5VYrQDEzTcQOOaw==
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=aOA3LKp9Tq++g5WmQgQo1114XlbxoqklcARG7HsXnEE=; b=iZ53C2263A1lcQkYpYLyFXzHzFwIbFaTfQINsO8RrN6UBs95GarEaNy/i7KuN5+WtZzlJUUtZkRAeTH52Fjtr30VVMhjInVn8cTbGXIYe8XwB8vrckf8PCfGWRQ6n2WsR1siFqEPvuKDAgrf3EfM5RXvD0H7DnryNTXrOoEc3++DbtGDwflh9i6TDVg70TlyTylXETwYJpb3JM8jjKk3KIOefARJEYv8oXO4ZjUM2BzFpUV0WdZ7M5I5vzBajkhzvUKq7AX475PIXNh+eZ1OFth/roLuoMr5pG2WZ03BnAyPKaQURZifATyyoEdDOIc4nIJyrKRb6bichDrknrbOIw==
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=aOA3LKp9Tq++g5WmQgQo1114XlbxoqklcARG7HsXnEE=; b=BIHUx4JITG5ihGaSRLhXprlzGVB+PaYuuRN+M2YGOuR0d2LtmGNHIhgZU3X5IPQQva+e7At1K77kEMA5yK9bicD67U3vCOKNAdcVQ9XoJbiiyMbjC4g/+SXOmq4qUgdzqEDwkV6JDitfwHkIE2ImsFzOfDzacP2E9R3ibOaCcQI=
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com (2603:10a6:3:56::8) by HE1PR0701MB2444.eurprd07.prod.outlook.com (2603:10a6:3:74::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.9; Thu, 11 Jun 2020 08:23:33 +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.010; Thu, 11 Jun 2020 08:23:33 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Sebastian Moeller <moeller0@gmx.de>
CC: Jonathan Morton <chromatix99@gmail.com>, "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/IIAABjQAgAAXTICAACKkgIAAFF2AgACvbJCAABzFAIAAByHAgABOV4CAAA2VUIAADWgAgAArITCAADEMgIAAwbKg
Date: Thu, 11 Jun 2020 08:23:32 +0000
Message-ID: <HE1PR0701MB2876B4A3087E2059BE1348E1C2800@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> <E17FCDCD-6D2D-4773-98AA-44EB54A79F62@gmx.de> <HE1PR0701MB287670627208FB1075F78F6DC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com> <E127BDE9-0249-47CD-ACBD-1C4296258B08@gmx.de>
In-Reply-To: <E127BDE9-0249-47CD-ACBD-1C4296258B08@gmx.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gmx.de; dkim=none (message not signed) header.d=none;gmx.de; 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: 4ec3edfd-30b5-47d9-184b-08d80de0bac9
x-ms-traffictypediagnostic: HE1PR0701MB2444:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB244412EE758B7565FD7E62EFC2800@HE1PR0701MB2444.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4714;
x-forefront-prvs: 0431F981D8
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: AYYFa3kLoZCRuynaVtE3WmyWPT5112hRiotwlAFg1CSqQmbFEpDVtdECEt5DYGITE+E+T3rNQhpD2fkFoIzO/Uc8RNp2+4yQgj9Zdc5T3MvRjM0Yf71GHAJSa58qYkdCW8eD9KmrzY1FEGBRIZ/cJOat6p71y7UYus9JhzrhnxR5pDYor7y8ChUwuKC9EgfgTlDR2t/bp4fYTzK01Z0fFZdoeqI/FGz9sUXbFjamkFfbMbAsFgEsacSJ8BPoJptVd0BmibfGQ3tYjOaL5tAyhLrwB4q2w7Wppgc0SxOZRLUqVcI4cC00npyME9RAwhqstG1pbrEYsWsz7/ICEDtnaWLXT3vWGFuSHsL5ABJIBpylW8ZOeTZYJDVkdN/T/Ov/p2/ok7WZtIZtp2zfx9EjSw==
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)(346002)(366004)(39860400002)(396003)(136003)(376002)(26005)(6916009)(316002)(5660300002)(4326008)(8936002)(86362001)(966005)(55016002)(478600001)(54906003)(7696005)(52536014)(107886003)(53546011)(99936003)(66616009)(83380400001)(71200400001)(66476007)(66946007)(66556008)(66574014)(9686003)(8676002)(76116006)(64756008)(33656002)(66446008)(6506007)(186003)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: UXNzmrDkjhL5mGTkcqLDhHHyYamR/1rRvTAkaXbVawTcyxiglnO/BE+z3VMtRyDc6NBHTi8GXpy1lgwPIppDSISWMAjPmVQdW7EdC3mObXTmcpXOYfOFYcFmJIfCw30ZjNFr5ExWEoyqFvXrFVU5P5zNYA/TYy3aoyqVn339zMeLVNaQPnkALidAUluHAqBXolgF2gZiLF0f8Lg4Jpt71eE+B11bbP/mjUidU3RGiyTFTg8bNyC027Rgbls5wAtZAMqrokSh9DbTAs5oQXNwp9vj+MgtlYL/hhzgB+9gmcyTdQiCU71kilUro2jqZ0nIkQ8E+n0Hf/2uKEHf1KGoNSW5TvH86mk07rvRRAQ59u/mQ3OaCbyUBAWaQk+gZ5PXrlduBSLMKHsvTAJk4jFfhV39jNn3i5CxDCUjn6w2oyvXHE+4wVLc+2ge1YKCCzU3hNiCpm+xzCInsJTurjzJjzQp2k/gIh4eOywnhoohEV4=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CD_01D63FDA.5AAC25A0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ec3edfd-30b5-47d9-184b-08d80de0bac9
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 08:23:32.8662 (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: E9F1siah1l5lOFLWlOMiX5ygieywQ4jObJPX4qqRInO+QpT2/1kZVJJbWlTbb0HqBTlQN5ZgpJxEtJo2a/oPzxKUhduEwfRA7fqnJDbDLP9nEXChG3p+dfEK+JPdYQ81
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2444
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vH409TotPPXl5NdzU-zxapZ0qsg>
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: Thu, 11 Jun 2020 08:23:39 -0000

Hi

Please see inline [IJ]
/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <moeller0@gmx.de>
> Sent: den 10 juni 2020 22:05
> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> Cc: Jonathan Morton <chromatix99@gmail.com>om>; tsvwg@ietf.org
> Subject: Re: [tsvwg] path forward on L4S issue #16
> 
> Hi Ingemar,
> 
> more below in-line.
> 
> > On Jun 10, 2020, at 19:15, Ingemar Johansson S
> <ingemar.s.johansson@ericsson.com> wrote:
> >
> > Hi
> >
> > As regards to dualQ (below), do you see any specific reason why it
> > would not be possible to upstream (complexity/memory whatever) it or
> > is your argument that it is just not done yet ?
> 
> 	[SM] Caveat: I am not involved in the Linux kernel and hence can not
> predict with any certainty dualQ's likelihood of getting included. BUT as
you
> know I am arguing for some time now, that there is a discrepancy between
> the dualQ claims and its actual performance. In other words it is not
done,
> and given the responses from the L4S team to this issue (like the 15ms
hack
> in TCP Prague's CC response) I am more and more of the opinion, that this
is
> not simply a case of dualQ just not being finished, but rather that the
current
> dualQ design simply can not meet its promises and someone would need to
> go back to the drawing board.

[IJ] Yes, and understand that there are widely differing views about the
severity of this possible problem, if it really is a problem.

> 
> >
> > Also, do you have any comments to my three other questions, please
> > refer to earlier email in the thread for the context.
> 
> 	[SM] I snipped these out of my reply since I had nothing meaningful
> to add to those.
> 
> 
> > 1) 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.
> 
> 	[SM] I do not know where Jonathan's numbers come from. But
> https://datatracker.ietf.org/meeting/98/materials/slides-98-maprg-tcp-ecn-
> experience-with-enabling-ecn-on-the-internet-padma-bhooma-00 has some
> numbers from Apple, I believe Bob cited these numbers multiple times in
the
> past.
> Given the fact that 3gpp contains quite a lot of large carriers maybe that
> would be a forum to ask for numbers?

[IJ] OK, that is the same reference that I have found, I was thinking that
there is perhaps something more up to date available? As regards to 3GPP
access then I can very safely say that we can stop worrying, there is AFAIK
no ECN marking (RFC3168 or anything else) in 3GPP base station nodes so
there are no interop concerns here. There is a remote possibility that ECN
marking can be enabled in e.g. industrial Cisco LTE routers I tried this a
while back but had problems with ECN bleaching which is a configuration
matter in 3GPP networks. 

> 
> 
> > 2) Which foras are the vendors that manufacture CPEs active in (if any)
?.
> 
> 	[SM] I believe that OpenWrt certainly supports rfc3168 behaviour,
> and there are CPE that run on modified OpenWrt, so the OpenWrt forum
> might be a decent starting point?

[IJ] OK, thanks, I was of the impression, that OpenWrt is on the table in
the implementation of fq-codel and the like, is this correct?, if that is
true then it perhaps fits bets with L4S issue #17 but perhaps it is relevant
for #16 and #17?. 
Has this extended beyond the early adopter do-it-your-self community?. I
recall from earlier in this long tread that you found off the shelf routers
in stores, were these shipped and ready with RFC3168 support or was an
update necessary to make it RFC3168 capable?.

> 
> > 3) 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 ?.
> 
> 	[SM] Well, it is these end-points that are going to suffer, when L4S
> gets it wrong (when, not if). So these numbers give you an estimate of the
> potential fall-out area.

[IJ] OK, then I understand. I was a bit mislead as I assumed that we
discussed network nodes that do RFC3168 ECN marking, not end hosts that
negotiate ECN. I would like to see these as separate parts of the problem. 

> 
> Best Regards
> 	Sebastian
> 
> 
> >
> > /Ingemar
> >
> >
> >> -----Original Message-----
> >> From: Sebastian Moeller <moeller0@gmx.de>
> >> Sent: den 10 juni 2020 16:35
> >> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> >> Cc: Jonathan Morton <chromatix99@gmail.com>om>; tsvwg@ietf.org
> >> Subject: Re: [tsvwg] path forward on L4S issue #16
> >>
> >> Hi Ingemar,
> >>
> >> to gently push back on some details.
> >>
> >>> On Jun 10, 2020, at 15:59, Ingemar Johansson S
> >> <ingemar.s.johansson@ericsson.com> wrote:
> >>>
> >>> [...]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.
> >>> [...]
> >>
> >> 	There seems to be a single out-of-the-mainline-Linux-tree repository
> >> (https://protect2.fireeye.com/v1/url?k=e33cc533-bd9c7f5d-e33c85a8-
> >> 869a14f4b08c-0ec6a27e7722e722&q=1&e=29721776-06f8-43e4-a1e6-
> >> 67f0d2c15283&u=https%3A%2F%2Fgithub.com%2FL4STeam%2Flinux) for
> both
> >> the dual queue coupled AQM and TCP Prague.
> >> 	I would not call that prrof of sufficient existence of "qdiscs that
> >> support dualQ" to allow Linux system admins to switch over to
> >> dualqand I
> > do
> >> not see how even inclusion into the mainline kernel* would this
> >> solves the issue for currently deployed Linux machines, which often
> >> use vendor
> > kernels
> >> which do not necessarily track mainline closely, especially for
> >> server distributions.
> >> 	I would respectfully argue that for safety considerations one should
> >> look at the current state of the internet and not potential less
> > problematic
> >> states one would like to find the internet in...
> >>
> >> Best Regards
> >> 	Sebastian
> >>
> >>
> >> *) As far as I can tell there have been no attempts at upstreaming
> >> the
> > dual
> >> queue coupled AQM yet, so it is not clear what/if survives the
> >> contact
> > with
> >> the linux kernel maintainers.