IETF Logo Mail Archive

Re: [tsvwg] plan for L4S issue #29

Sebastian Moeller <moeller0@gmx.de> Thu, 01 October 2020 13:37 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 56D053A1030; Thu, 1 Oct 2020 06:37:09 -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 U6R0xLegswvB; Thu, 1 Oct 2020 06:37:06 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 669AD3A1056; Thu, 1 Oct 2020 06:37:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1601559422; bh=WHc7AB8ifHODQNS/LDyM2QduiF2X8eS/FFKkAFzE3GU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=TZmfHi2eSjg2inrgMOoA4fBAAkKXXqqXU/13JSHA/EMkuXTXhRIQbEgSswbKG9pD8 goa/8Y7Cl6bBaOw1+R+nq/en4clljUiXJ7ZHYmRZn5srf6b1ccgN3A0iePeXnaDOUF 5x2MvmzxkDIc/XkOefOEaEWmqQgtkAphza5I5xGM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.102] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJE27-1k8m3x0ce3-00KheX; Thu, 01 Oct 2020 15:37:02 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <1E049DCD-51CB-4779-BD86-43C67CD01C05@gmail.com>
Date: Thu, 01 Oct 2020 15:37:01 +0200
Cc: Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <455E2FD2-913A-488F-8211-BBC4744DA3D9@gmx.de>
References: <202009291549.08TFnvFV068509@gndrsh.dnsmgr.net> <c7080365-233c-5f1e-ef5c-1f42c969042a@erg.abdn.ac.uk> <73562E45-3EE7-43D4-B26B-76478AE19AF8@cablelabs.com> <ae5eb008118ab1b88d65e7712a5e3c54b4207e52.camel@heistp.net> <28cd9795-5b04-4ecb-6e8c-2e12e476f034@erg.abdn.ac.uk> <alpine.DEB.2.20.2010011436510.15604@uplift.swm.pp.se> <D19117FC-24F5-477C-8431-0CFCBCA6FE04@gmail.com> <B64A9A8E-9664-4EC6-8D5E-26C8AA464BB1@gmx.de> <1E049DCD-51CB-4779-BD86-43C67CD01C05@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:iUxjpsAUHwDjBNQvvEGAIEZXNyp0rA0UH1h8xL+KIkwj8CN3PcC PQNlki+bEzpEyCcKh6sCziKTDsJ3xGJje3MEdvPnUGOtqDYxHHK3pf7GbNJF4cPeolPHmSV 7p3+cEG8F6EzC8MsbfFWL5aPobW26lY97m61RWx640d9Wdhyb5THS8EZ3AOqJC3EeCn1xPp 8ABpAt/RbNodaqtGuuvIw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Gpvx1S44P6Y=:CnM6y85AZltjX37DuYkpqU YOEbJztlfkpsXUzoDqII8G+G73Qdr+mNtquKUX1sND0gY1Xg6KGhSKAXJEM98oQrUXh0xo6Nk utaH4w7hHnEaEIpaWysQKeMu08V/apytKYz6PhfAqKcbQaDLRmPy+o2imhvGouO62ON0dzYZZ ZvoGev6HKt3dEzghIeC1fAHF3BuLFJnaw8T6LirxpUypQtJITear4ChfrF4+HAudH9ES16tOS aUrLqbnoV1HKVLZzaOm6MM85vBJHBtJZe7j3g4OvhPk4JpzddQpSwa2th4u+HrpshfMx892DO CusIp+XgWyywMxgucfJBGp+aBZaQcBcj8gJp8bLF+AElP7eZ+d8EP1pYmmD1ToWh6BZDV8FNw vDdL1Gi2nhisVphXN1CTe2EBK9JQlDmq2lyojwk1e0DpTF4a0HFNkVD6RYGLtY1zVFc0HMGIz cuC+YJu0Gombv1sYO2FOrMB4rLvQuUVDpEzF9xWfMoHbPO22UetYmbCXyHNv071NeiP7bMshq wGN5aruZy6thFRMIGnIDwNmrRYLgzmeA9qhKLBagu375H+qajWBgQOuVz1AzbVhO+uzpy8far 0e4m3vxIiraqGVDFS3WcTT124kUbtBmZgtVG4vz5NFGivXLBozn/2EtPZ7KRVCwQNP4lcIPt+ 38IJGXyusQF0puwAm7mvRWLwUFEOu0Y5gGaQuJUiQfGon6EYi0terw8iweKa5wT9cG4EpqRUL 7CUGjmvEoPajfeZr/lMCWEyPbm079lLDp7W70SfzZtPAPF0xhY2CcSTP/fvn4sm4NmnSEyNgH P4puIR+AGxelcoEx0nVv4L4COmzYzCPHPvDOVIolnVZejCaQ1LaPA2MXi5NcFE+oc2qHrXuQ1 wvBG8vTKyuSI5LgcaJx8QYDbmxP4LNhNiv9nFzvEmyWUJEbOSeIOS0TwmPxEzpzGDgft0/z9i 6HVj2mjC/KVY1nUb+8vPskrrRxe0tOxiK2fNLeqy8Syz4uNkD3/wWv6hy+Y1v14dVJebJsJCl XPV+aKoIzxajpQLke4PBzV5q3Nly5WCVFmfMwBhsnbZ/LamYOGnGO/rV4jdX2A111wIeN51o5 Go27FgH61zM1XknKD2RxqcSWM8CqMpZvtfAOH3lrxviJbMn3O2hRfwlbGGsvZftUidIRtnbLN OBiJr7WVLKq75FcB3QGT+a3avsPN2G8qJvn2G4/mdv17lQICIV8wWjOSG33yvLfhu6OVLL604 dCRXsOjufMto9SBh7
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/MU3d5xmyx6lGS_9bGKO77j5bgRA>
Subject: Re: [tsvwg] plan for L4S issue #29
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, 01 Oct 2020 13:37:09 -0000


> On Oct 1, 2020, at 15:24, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 1 Oct, 2020, at 4:16 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> This seems driven by the fact that according to the RFC the dual queue coupled AQ actually is set up with a 1:16 or 1:15 worst case split between the L4S and the non-L4S queue. The idea seems to be to have that as a backstop to avoid "starvation", but only for very peculiar definition of starvation. IMHO differences >= 1:8 over the expected equitable share are clear cut cases of starvation and need to be avoided. 
> 
> I suppose we also have to distinguish between the behaviour when the bottleneck is L4S enabled, and when it is not L4S enabled but is ECN enabled, and also when neither L4S nor ECN are enabled.  A robust solution would be one that behaves well in all three cases.
> 
> Presently, the 1:16 ratio approximately applies in both the first two cases (but for different reasons) when the baseline path length is short, and is only avoided in the last one where both conventional and L4S flows exhibit an AIMD response to losses.

[SM] Good point, the last case however seems genuinely irrelevant to assess L4S' safety, unless we want to go through all of this only to keep the novel low latency mode disabled forever. IMHO especially failure mode 1 is a showstopper, this is L4S failing to keep its promises for the one use-case it was designed for short RTT CDN-to-end-user paths.

Best Regards
	Sebastian



> 
> - Jonathan Morton

v2.23.0 | Report a Bug | By Email