Re: [tsvwg] Reasons for WGLC/RFC asap

Lars Eggert <lars@eggert.org> Thu, 19 November 2020 13:10 UTC

Return-Path: <lars@eggert.org>
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 78D063A0E3E for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 05:10:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=eggert.org
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 C2dphjT_qK60 for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 05:10:18 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40AA3A0E3A for <tsvwg@ietf.org>; Thu, 19 Nov 2020 05:10:17 -0800 (PST)
Received: from [IPv6:2a00:ac00:4000:400:a1c1:451:99bd:2fed] (unknown [IPv6:2a00:ac00:4000:400:a1c1:451:99bd:2fed]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 35562610415; Thu, 19 Nov 2020 15:10:06 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1605791406; bh=La0Kw1FDwHYd+FLBjRqeVYiAQXjd8UCfGdlHsh0qILo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=m4xv/PY3G4ddWOBD7I1EYZ0O65/b4piMwZuJnMZK7hX3QRg0o7b0BLF2D6jlfMxK9 zlcqAO8r9ZZeFpte2YCyMi9EumLsRWvPNHGy/lz/1X+Z15kmyaY4Jb8hj/NtXwdPmY hyDePFkQTS6PRkP2CYqotMo1EBUeJ+l6uDQNJ8iA=
From: Lars Eggert <lars@eggert.org>
Message-Id: <F73E8DBB-0887-462C-ACC6-FA9212E50DF7@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_2B61E029-828D-4160-830C-772AA3C09BA2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 19 Nov 2020 15:10:02 +0200
In-Reply-To: <HE1PR0701MB28761E448ACA1DAE0B2DCF56C2E00@HE1PR0701MB2876.eurprd07.prod.outlook.com>
Cc: Steven Blake <slblake@petri-meat.com>, tsvwg IETF list <tsvwg@ietf.org>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.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>
X-MailScanner-ID: 35562610415.AEAC8
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/p5hF5tZp9qLobWSYm2n4UDyu3OE>
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 13:10:20 -0000

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.

I'm actually looking forward to the presentation on TCP Prague - is there a draft?

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

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

Thanks,
Lars