Re: [iccrg] [tsvwg] L4S related activity in 3GPP

Sebastian Moeller <moeller0@gmx.de> Wed, 13 November 2019 08:04 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11FD120145; Wed, 13 Nov 2019 00:04:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (1024-bit key) header.d=gmx.net
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 e45lpoddCnsz; Wed, 13 Nov 2019 00:04:11 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 660571200FE; Wed, 13 Nov 2019 00:04:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573632232; bh=W/TykBhGkbcN8Fs1d3I+m/QGO6EA3tlVUlSXi09TtqY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=AHUSKtyEUN0bHY7r9FkxU32l3aTZYazvTxnahj2Ianowu5xMOe2VSyN6HulzSj41f V4+mlcX8DIeDoJxSU/n4XLZKOjY4//CC9/MGiycog/ojr3R5PH/kQA0GAVJSviyV4U WPNFbxgZUXiNsKtw0bkElKh1Z4+74gSDBj+rUNhk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MaJ81-1iRFN70Ig1-00WAov; Wed, 13 Nov 2019 09:03:52 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <95DD7C4B-0C48-4726-AD7A-D977D1D9C5CC@akamai.com>
Date: Wed, 13 Nov 2019 09:03:43 +0100
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "iccrg@irtf.org" <iccrg@irtf.org>, "koen.de_schepper@nokia.com" <koen.de_schepper@nokia.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ED8E685-E284-4470-B808-114316E81D98@gmx.de>
References: <HE1PR07MB4425A148B5BB1E6FD8E5A3FBC27A0@HE1PR07MB4425.eurprd07.prod.outlook.com> <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de> <HE1PR07MB4425DD6FE15DB130B24BCEA1C27A0@HE1PR07MB4425.eurprd07.prod.outlook.com> <764B1E43-7B86-4BAE-9FA2-CA5B56A73047@akamai.com> <HE1PR07MB4425AC20F458B38EB3AF12C9C2750@HE1PR07MB4425.eurprd07.prod.outlook.com> <577095C3-EE27-40D6-9A8C-662DACEA1A5C@gmx.de> <95DD7C4B-0C48-4726-AD7A-D977D1D9C5CC@akamai.com>
To: "Holland, Jake" <jholland@akamai.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:wm41HQ3nKNM7fPMK9LbHvs8L7e6BdqtXYZnNXSQoHPZLAz2cjid h5GzDZ3kytqM0KkxYFQ59RNAzXWZHY7KFbh9Ifd4oH69Ats9MvazmlaD8+MYqVJlxrRABPU m+IKJsbLF5MPrxZ0JG93AP0dfSpi2VJmZIHP7DSoWJgDYlsxeyTTXpI9T9fVwQhj9/0dXKj 24KzOxT4/O1nLgJdNRlOg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:P0iPPI0fGmw=:n4gi6MYyDY7YzEy+FWyzJS Dhw+UHUQS4VAZSm4erX/J2ZfjmpkrUDp7y5wZX+/6cKyPwSZn5emy4ZhOTJcWF1c4fo6u9v9C h37yBjIEEwUJKDMm5po43YGliZKdMiJEPaD4ek4dyMzLJPF3Z6lCLT+IAdW33MwznmHvIlI68 bXwTwsRwDRlm5GDZuA3iW2ID5BWe/Jx23vBOSyGfozV0CG6CKJi29g3PiZltKJh61LcwBPcUT EhGNUcw8+f12zrcB+tBdDOfktAa/WSMHwaV9wxhMlJXvy/It5NZ+1upGcfyrClSlDgF7yC/CI 8+z70gCRZWsePUEUhQvg3OALVf61A8O5sNxCwh+LV/gMWIjldCPJaxlKpF5RUp4a/gqMdIUGE ZlVEvqi1aV39u1BH+KozOJOZBf1fge13Za2WRe0aKjZju0FBWmS0K/PWW50XzMH4ngQlS28Ve OcuoraMWojvx0ysPg1RcyTU4t4BPyWNpv+GojGf29M0dTlaYVsJhNVSLMQ2eJU5R2Vt7d4LAK +aEgkS/+uwv2zSFyyDaEraE95JpDKJ4JOZPc8gXByt15RVcOurDvBccX092d8qfxXkGKHwx28 Qg+Zk7lKlT4HWapFz3xVSd+5dRZ6am5zvoLmn31rG0CTdZGT1B6G/oQXwuBClt/E4IjfQEj8e ygpX0olW7tXreZn0T1tKZ721mwZjejT+z1dkJisZ6jJScwUgPyiiX4ZToKk3BJjlPPMd3gXZC p8sszbAjQUWrW0JnFQtfyMRs9pRQiZhhUnItjwBSkbjA00+ikXK/UJl/H3Nxi3CHTST97zqrS 1iklvMGE/AIxpCeGSq06ifXLL32CyLXkbErZkXdSWisP5nJNIQEdbuRHJGLaFiG3IsUBajnaG DXOv7gWOGXqbm3O0OccDhO7iroCIXWcFqxD+ia3w5rhNfBa7rWYpACkuMJfa6ZTLTscT903Hu SEhMMMAN4AjA8TlUUrGX3Z1iAH7rucmxzk3TQHxO88PboiYJHlFauK41UOZtql0Lk2AUiypxr iWAY1LpuuuzBkBWRKScfxNZ7sv5A9E+BJdIIuFMZhdar6jj7oG4vfpaDZKlEKulEu5pVsXIeF nYhGTxkuWeWB3342kHfzwF3Wxjecpu5tXOOWfSDduU7TQDteQ4YRmjv3pXWhjwXYUNPj5M6qv Ga7nxItwqw4SBpfi7+TVJt+E0At7LPMG1wcRrPeoHsQyFjjPVfW7T4A48FMmCqUsL3tNdxbvK EAa915cfqVXGxoKFIe7c+3Tl82TDR3cM/JrKeXeo6WHoDBtlYGYTfWUOCHo0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/TYJ9UhqZBaEoLlvHGH5Sr91Sf9Y>
Subject: Re: [iccrg] [tsvwg] L4S related activity in 3GPP
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2019 08:04:13 -0000

Hi Jake,

I guess my tone was more negative than it should have been, PC is a clever idea, and it would be great if it succeeds in the real world. More below in-line.


> On Nov 13, 2019, at 07:57, Holland, Jake <jholland@akamai.com> wrote:
> 
> On 2019-11-10, 02:46, "Sebastian Moeller" <moeller0@gmx.de> wrote:
>> [SM] has any one actually tested paced chirping (PC) over real-life
>> bonded links? As far as I can see PC pretty much relies on a) little
>> to no re-ordering of packets (weird given that L4S also wants to allow
>> larger re-ordering tolerance by recommending/mandating the use of RACK)
>> and b) that the packet delivery time of each packet reflects a common
>> path characteristic (which is less true for a bonded link).
> 
> I'd certainly love to see paced chirping fleshed out.

	[SM] No objection. The promise of it is certainly interesting. What I would like to see first, before getting too excited is rigorous testing to demonstrate its robustness and functionality even under adverse conditions. Of the top of my head, here is a list of things that I would like to see tested:

1) robustness against bi-directional path saturation
2) robustness against asymmetric paths
3) robustness against bonded links (possibility of re-ordering and inter packet delay does not reflect a single patch characteristic) I believe paired-packet probes have similar issues.
4) effect of high prevalence of paced chirpers in the network (these are active probes, at what point do the probes of different flow start to interfere with each other and ist that problematic)
5) conceptually, if I understand correctly it actually measured return latency, while ideally it should measure one-way delays, what are the consequences of that mismatch.

Again, would great if this works reliably and robustly, but as far as I can see so far all we know is that it works under some conditions.


>  If there's a robust
> version,

	[SM] +1

> it seems a promising way to avoid overshooting on slow start for
> just about everyone (so maybe we could all get rid of that latency spike
> on scenario 5),

	[SM] In the new scenario 5? I guess there not re-defining CE would be the cleanest solution...

> and I'd think it could have applications even outside of
> slow start anywhere you have a way to back off before pushing to overflow
> (e.g. BBR, or something using SCE, as well as L4S).

	[SM] Yes, that is why getting it tested under adverse conditions seems like an important next step!

> 
> Of course as the paper said, it's not ready yet, but it does also seem
> potentially helpful for the use case of highly variable link throughput.

	[SM] Excuse my ignorance, but in its proposed role as slow start replacement, it would only trigger rarely (on flow start-up and on certain time-out conditions, no)?

> To me it seems worth keeping in mind and examining further, whether
> or not you think L4S with ECT(1) will end up being viable.

	[SM] I apologize for lumping to many things together in the referenced email, it is just that the whole L4S set of concepts and drafts, IHO all could do with more thorough testing...

Best Regards
	Sebastian

> 
> Best,
> Jake
> 
>