Re: [tsvwg] Reasons for WGLC/RFC asap

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Thu, 19 November 2020 14:24 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 86B463A10AA for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 06:24:31 -0800 (PST)
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 EITTxXZaxM4Y for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 06:24:29 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2065.outbound.protection.outlook.com [40.107.20.65]) (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 5C1883A109B for <tsvwg@ietf.org>; Thu, 19 Nov 2020 06:24:28 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d47jpKXMXlk42suLLizNXTuf1PcV5X1tE/2MhtdsEAUxgDlgHgLz+Cu8jl2iMTbZoec/k4BS76BTE2v/yW7gsStwaDn3PcDiasfDv3Uwgt7hb+U3KN+Me6pxzuTB6Tw8mddZYJNDU1fAN+QdjD6iP6p0r6HejXanmekO4/sXLw2bMmS//94GgUHVBHaUuJFmKpiFQX+1wqEl5HAXgQ6ywBTYpcDm54kj8fJQlUALNBTwb7mwZ1eWwPs6413zGbyDNyN16KOQBSU0dZhS6RS27PNhvGa8Jaz1S8Oua77ETRoOJ76bysNwBD+xzl/9mRBjDYruZnDWgCm/9rStzIxSlw==
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=B2+4fsoYGFS+2/YGRCJbrWVG5qPTVhrfMCs5cSCkUC4=; b=fD6NNBhPT8eIlsNlxNfHR5hghNb5bRf/zqRVt+v9Edp+HiKktHJe4a9ik2GDBzqdg96JVm3enQygc1El5hYOpi1HPrjEg8HJw9D60b88LjYWmGpxFZBSxzY+Zt4Zn5mIt7KpHMsKsXhtu0lj3iitnzjYuMgz1qpxQCadxyrH2XNQHdkrIdxYcwKqDG13jrJp8KYnfWevq/q+HFN9CmGcva0C7im6Br1Gm6t8LLRa/YFsSKJzccQNxpRZjnxV+7uMJOtkxkLgCQnmjRgi6arJJSmKO2/zdepBXcOkkOwe0je9QcyVox2IiWNIaSpfr0J5LQ6rrxjB91uQkQFLjh0Nkw==
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=B2+4fsoYGFS+2/YGRCJbrWVG5qPTVhrfMCs5cSCkUC4=; b=C5TamEZo/7CmfoXqJVyFUQiHIoDgo6n3C7fvUQhJ/dvWtyRew1O+xldIaKo+PC2XCa9s34gcu/b8pWXQhUBYh//Wj7ntiAGq1V5Q03MJmFLU3mPqZ801Kz0EYn4FSUFb8/rWPMKH/rDZOwLPKZ65KBZpIb5oSvH4EWTLgkUcFrs=
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com (2603:10a6:3:56::8) by HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.16; Thu, 19 Nov 2020 14:24:18 +0000
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::50c8:a7da:1a:48a3]) by HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::50c8:a7da:1a:48a3%11]) with mapi id 15.20.3589.016; Thu, 19 Nov 2020 14:24:18 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Lars Eggert <lars@eggert.org>
CC: Steven Blake <slblake@petri-meat.com>, tsvwg IETF list <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] Reasons for WGLC/RFC asap
Thread-Index: Ada9kaHRGNO57vIZSgq7zPn1SuIYhAAQZ1iAABevuwAACIsIYAACHYWAAAPTeVAAAlcCAAAB1G0A
Date: Thu, 19 Nov 2020 14:24:18 +0000
Message-ID: <HE1PR0701MB2876C5AE506AFCCCD99C1F54C2E00@HE1PR0701MB2876.eurprd07.prod.outlook.com>
References: <AM8PR07MB747626CB7622CB89209018A8B9E10@AM8PR07MB7476.eurprd07.prod.outlook.com> <5dff4f73463c2a7e7cc8dc8255ae9825e78f4c11.camel@petri-meat.com> <4FF8800F-B618-4818-AF5E-1E997EA9FBF3@eggert.org> <HE1PR0701MB2876C4FDA655284D4E563042C2E00@HE1PR0701MB2876.eurprd07.prod.outlook.com> <3EAC47AC-5937-4DB2-8B3C-D8C8A4459FBA@eggert.org> <HE1PR0701MB28761E448ACA1DAE0B2DCF56C2E00@HE1PR0701MB2876.eurprd07.prod.outlook.com> <F73E8DBB-0887-462C-ACC6-FA9212E50DF7@eggert.org>
In-Reply-To: <F73E8DBB-0887-462C-ACC6-FA9212E50DF7@eggert.org>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: eggert.org; dkim=none (message not signed) header.d=none;eggert.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3401a196-51b3-4f77-8dad-08d88c96cd30
x-ms-traffictypediagnostic: HE1PR0702MB3818:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0702MB3818C226C2674579221907E8C2E00@HE1PR0702MB3818.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 02uF9PC/fsH5acn1fMeqDry0gMUe3au7ORF3A+i7qO/l8dsOVfGNcx6YRRpaw1/z25NpurrwgFoz8vxAEoIsbI9DAxptTQuMaM4ocAJIOc+KkTywp98hMxGErqnP9d4l6xbK9Do9f4+qtmF9orbVHaxLLbL6o/9Oajb1BF22zoliXMLVd+xRr0Te4Xp0DWIlk4LFklKd0S5Zr7cgQ76W/IRTp7YmUIPxDSMUErU+2YBAEIwKoWliQzc5M1FE5MhQteqcFn6Zvzs5of/dWPyHpbs/6gludYG7PxKPYaX8JjemBp22qJMLMUmY/it5Ei14d3/JMFktisOqDhaIsqfp6jB5pmNB+28ELAEnutWguQFh2gEOTk36iyeFp7j2HV+2MVwoRDEZL20+gZPO2FFTEg==
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; SFS:(4636009)(136003)(346002)(366004)(39860400002)(396003)(376002)(76116006)(7696005)(83380400001)(71200400001)(2906002)(52536014)(5660300002)(4001150100001)(107886003)(8676002)(8936002)(66946007)(6916009)(478600001)(33656002)(54906003)(66616009)(4326008)(86362001)(26005)(99936003)(966005)(64756008)(66446008)(316002)(66556008)(55016002)(6506007)(53546011)(186003)(66476007)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: BChcOVUcSOIqYT8+40PtwkLzBypefHpT5U78pAP087MjW2cF9UdISDEQjqCHDr+sH7SC+Nos4wGocAAN7MxBFTvjWTjoJ3jMg8AvLH1wGyoE1zZ2LiB2soXnd9tlNL+eq3yuuXISF8fTC/oQgzpfsRfjBQTHBoyf2677u2vrCI81MM4RMcses9jVYizDv3rar0db+qwnpKyJOy1zNjR30ds5KE9WhZ03IkwSEyxRujAf2WPGe5SgLza33YR3Ge14+08BLxBWdnWgTWRv50LdpFPQBWkMItfDv7L/KTnNyYY0Uh6aRR9UN9i8KiowpeO72FzflOzLxLJ9qM35Hzzj2RLBwZjcE0tLdzJQyLxc8GPyuSFgn4g5MSfvDG3bVhgkUBfl5WTBlYU6x+11o0q3bCJ3ar+MjD4Z+2NxDMHy4KTOw9wEOwejqt6iI2uzLifExJ7vEiwUqBQoBtNa+ZFQEVjLxpeMTEW4nZlAGZxPsJBsGmsz4kVL1xw/5QvB3Flz2WzOb9qSoeb9XZPSFoaazUeVRHRJkV+YWbSoQcVyahjbL2hEI0LHlaaAcG7GdaPOJ6Fp3wIcTR4c8i45Y+lQc+8U8Pb9qX2khNlfTN73Ye92GWF2Ao3FOIac+H2DLZQFM3LaUmuajy7MonqiCwHKCQ==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00DD_01D6BE88.0B557D30"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2876.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3401a196-51b3-4f77-8dad-08d88c96cd30
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2020 14:24:18.7090 (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: RhLRNDNGQ+9KhRzxJO2BvhjCNkPuaDGDbqzB1NO2LR5XY2ssY7xbYPTg3U3DpRg9/xgheREmdZkJsXLdiItB1UfGwfpkqsuxeA+1eyqjbTX/a2Au9iyYAgxMvluUUICQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3818
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TcqPGVb5IMJn2tqBsQkW0sEFXEE>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
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, 19 Nov 2020 14:24:32 -0000

Hi

Please see inline [IJ]

/Ingemar

> -----Original Message-----
> From: Lars Eggert <lars@eggert.org>
> Sent: den 19 november 2020 14:10
> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> Cc: Steven Blake <slblake@petri-meat.com>om>; tsvwg IETF list
<tsvwg@ietf.org>
> Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
> 
> Hi,
> 
> On 2020-11-19, at 14:36, Ingemar Johansson S
> <ingemar.s.johansson@ericsson.com> wrote:
> > The only way is see is that the L4S
> > drafts are moved to WGLC, then people will hopefully read the drafts
> > and come with requests for clarifications where needed. Until then you
> > can only expect more of the same long incomprehensible discussion
> > threads until March, when we will repeat the same process again.
> 
> to clarify: I don't have opinions about the L4S drafts. I haven't read
them in a
> while, I agree that I should.
> 
> One point I am trying to make is that since the set of documents we are
> discussing seems incomplete, in that it doesn't seem to contain a TCP
variant
> that intends to delivers benefits over L4S paths w/o regressions.
> 
> My main point though is that there seem to be questions raised about the
> performance and behavior of L4S with various TCP variants. This is not an
> issue with the content of the L4S drafts. It's a remaining uncertainty
related to
> the experimental evaluation and analysis that the L4S mechanisms have seen
> so far. Going forward with a LC is not going to bring further clarity
here.
> 
> > [IJ] The only pain point I see now is the RTT bias in cases where long
> > RTT Prague flows compete with short RTT ditto. This is being addressed
> > by the developers and it is not only an L4S problem. Besides this,
> > Prague will be presented at ICCRG tomorrow as I understand it.
> 
> That is one point. I think interactions with tunnels was another.
[IJ] My take is that this is something for L4S ops that I see as a product
of the L4S experiment. It is not something that needs to be answered on its
own as it is mainly the RFC3168 AQM issue in another shape, we don't know
how widely spread this problem is or to how large extent this equipment can
be updated, earlier discussions on fq-codel implementations in home gateways
was not conclusive I guess but it appears that many of these have automatic
upgrade features, I guess the reason here is to be able to upgrade to combat
security threats but this is admittedly speculation.

> 
> I'm actually looking forward to the presentation on TCP Prague - is there
a
> draft?
[IJ] Not that I know of, code is found at https://github.com/L4STeam/  
> 
> > Besides this there is discussion around all sorts of cases with
> > RFC3168 style AQMs, additional discussion before a WGLC will
> > definitely not make us more wise.
> 
> Discussion won't, but experimentation would.
[IJ] Yes, but we need to get past the discussion on all possible things that
can happen. Recall from the discussion yesterday that Stuart Cheshire and
his team has not need evidence of ECN marking AQMs. So I fear that we spend
a lot of time discussing problems that are very rare.

> 
> > As regards to investment, already today there is investment in this,
> > examples that are disclosed in the open are Broadcom and Nokia. I can
> > imagine that there is some expectation that L4S will materialize in
> > RFCs
> 
> Sorry I was unclear. You are right that there is investment by vendors.
But I
> think the key question if there will be an investment by operators, since
they
> need to eventually buy L4S kit and deploy it. And that investment will
only pay
> off if end systems actually have deployed a CC scheme that takes advantage
of
> L4S. So the ready availability of such a scheme is IMO a key requirement.
[IJ] I would say that we already have CC algos that can be used. Surely they
do not meet all the requirements today but I don't see why it will not be
possible. It is definitely the case that we will be discussing what typical
RTTs are like forever but that is not something that should delay the L4S
drafts I think.  

> 
> > [IJ] If this would only be a IETF matter, then you are right. We
> > however try to address this also in 3GPP standards to make the whole
> > thing work in products, and that is of course hard to do if L4S is not
even an
> RFC.
> 
> Is L4S currently a requirement for a future 3GPP release?
[IJ] L4S is not currently pushed for in 3GPP, there is however work on the
support for extended reality that requires low latency. L4S will definitely
fit there. I would expect that L4S support can be proposed ~ mid next year.

> 
> Thanks,
> Lars