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

Sebastian Moeller <moeller0@gmx.de> Thu, 18 June 2020 08:15 UTC

Return-Path: <moeller0@gmx.de>
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 B44003A0F6A; Thu, 18 Jun 2020 01:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 UpsE0-yY6rfH; Thu, 18 Jun 2020 01:15:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 7076B3A0F6D; Thu, 18 Jun 2020 01:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1592468133; bh=kVdOkzBRw6FGuNZ8/xSNaXXIFZn/zJPiV6Rw1W/Kk8A=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=aZzi4IzgqbRAf6eDFSvbBXc2CZ7jMlUGCcMzKpVhbPWe5ug6/iBg3iYGBtWy+T4Zi UPueMRCkmNfcstvK97N+ndh+VJTyu2BI7qxifXbU9clHHtDIne4HJPz+Nysb4Nb29R 4dGXoJkH0SA5Csz/0C+tYVVb7xEEohlRGuwbrJ18=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.3] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MGQj7-1jg3Tc0PK1-00GtDm; Thu, 18 Jun 2020 10:15:33 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <57B28071-01F3-4C93-B309-1546F6E51C00@gmail.com>
Date: Thu, 18 Jun 2020 10:15:28 +0200
Cc: Paul Vixie <paul@redbarn.org>, TSVWG <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <745F7530-B3A4-40C6-AD5E-E39596B40C47@gmx.de>
References: <2DC5C89B-C979-4354-98D7-BBDBC78A42B1@gmail.com> <MN2PR19MB40450A06A919354C8D4CFC74839A0@MN2PR19MB4045.namprd19.prod.outlook.com> <9E403EBC-79D4-4C6E-B000-E53BE8B29228@gmx.de> <19188328.uKY2rrpm7d@linux-9daj> <CBCDBB42-81DF-4DD6-ACB6-2BB8F01F3564@gmx.de> <57B28071-01F3-4C93-B309-1546F6E51C00@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:OwVLPsscu0yoqAGJAwzTg37g12oES4/n3nlUj4Akn7Uec5+AmdB s+ls4LEm5riQB4UiaDRMbJTxrfu0Nbyk1jlA0LkuGIlmJSbBt03O9earizdY2oWCMgeON71 T52OLaVmVZOrcyF0h0qJ+pT38xIUycDJBfXsQR2/h5y2EzJJpEhjfIHw4Esd/n89FM2aHB4 G2f3HYWCNizags9ZKa4iw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:SSuqtqicrdQ=:PaLdhdyUsUgxQUn7hy7Gez VgMhWvqePiobFzrUw4HYZ/HZh0b3soCjcYCgMizBL8gfHP9J+5dsTQVwdoaTRpPuxM6HIIhpP E93RgQ1Fs1RVW3bfH7nLhxo/RNF1G2CLASjvBhQQ0t7XyooOsFKjZg+CT8FfWYH2d+Zfnq/s5 63LwuV774r32I8qR8W2KZkpIibLct4jyeAUCc4xWRj+ejI1E3sNT+mHkQw2epktFM4CeramkL u/ZtHRZDdI6vJrByCiMOSsr11KMYblmSJpc6XDqYKxiHErPRtXY9YugVyBw/4t9NrnZ++4Kvc OwIy1jR1RfwlkgMcxEdaR+I8jUIbJB2QL3E5HjqPz1QMD+A4BmHk5dWLlqF2y7FmdAo/Frn/a eIQp9w2xatN2V9z1/hpbZY85UWMRtZWOc7E/eSksoE/3RdAyPzRnkzfi0AiYqefYZLj3JoLpC MOrZXRniUXUYTRxMkE6H8RdXucvadBddqxX5+k7vbITTKfPnBu4YVualSJHQq947pNP7I7I6v kBQAWAyXprkq0TifWnbCLlv+OMu1WMvz3h78OoNF4ZSo/4SurycvkVz4EY7ykFLQJOWq22UJl hHH2RpAYtvw40uWA97xJlk9oXZOkmOXB6JsgJKgsstShzXfqk3OO5iTNp3Kxi8vC7MczG0vhO rRm2HJ7YITKMmU3AAKDjpjlX2lf0JYuA1wYh9WgpYoZdfIKiosL+WPaYTunDvWDmmQnppgk8W h/hl8L0UOeiR0OfAO5KsCEx4Oir3r/VlMhIslhGnIdtPnC1q9wmzFqohv0S2UATywVLlVIumS SCjnycnHB8PJf9/ZpIDz2peYBLe4VPWyP4Q5ZkKWwLdnHENXLo5/3crGEhZYLTvmDb5/4aY77 E1FQNemGMZGFsr3hz7hdyzmzXYQ7Vxj6DYCABZgHxHIvl4qhYV3GPGQhB672g3qgWnTHPu3lx YT79tSIQCSUV1T7ncFcMwPtJZEL190ketokeEfOB2tLq4H/nz1VE8KS/PtsBwlP0rwYbfCT5T Ss2miDIktvw4URCm/DJ2U8vO+5/iYRCw5XxeHpkAW4tBmAfuJeyqbXzf25isz/MUjWJq9EjeN K9YbEb+JjRES3qwcn5aZkC5S8Y1HjrecrQIK+r/5JDJpEPI0zFGo3JQZE9kp5uMNsDqf2QuDs 9ToHXaVB3xa3iKSw0cHpZkqGjbjWI7hB7i24xIpLn7kF+XvDdSlc/zpCrPm9fzgGhaTXA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/5RlZ6DKiC3WANfzI36ZLIPWYagI>
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, 18 Jun 2020 08:15:43 -0000

Hi Jonathan,

good point below, which basically adds one more really important test condition to the already long list of missing tests for L4S:

A) Saturated multi-hop paths (individually saturated for both down- and upload direction)
B) Bi-directionally saturated path
C) asymmetric paths (including A) and B) conditions)
D) tests over real internet paths, coast to coast in the US, as well as trans-european and trans-asia paths
E) paths with wifi links
F)...

But in all likelihood we will just see more tests for those conditions L4S is known to work reasonably well for, short RTT and/or low hop count, tests of the download direction with at best the download direction experiencing congestion...

Best Regards
	Sebastian




> On Jun 18, 2020, at 10:07, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 18 Jun, 2020, at 10:38 am, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> …the idea that a single hop is typically responsible for all delay variation seems like too strong a claim to me…
> 
> It's quite easy to construct a counterexample, too: any network path including two wifi hops.  Wifi is inherently a significant source of delay variation due to its shared-medium, half-duplex, CSMA/CA with ARQ architecture.  So even if the rest of that network path introduces no delay variation at all, there are still two hops independently introducing delay variations.
> 
> - Jonathan Morton
>