Re: [tsvwg] L4S issue #16/17 questions from reading the session slides

Sebastian Moeller <moeller0@gmx.de> Fri, 22 November 2019 08:53 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 23CCB1202A0 for <tsvwg@ietfa.amsl.com>; Fri, 22 Nov 2019 00:53:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 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_NONE=-0.0001, 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 kH1U2r7pzO0l for <tsvwg@ietfa.amsl.com>; Fri, 22 Nov 2019 00:53:22 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 4406912018B for <tsvwg@ietf.org>; Fri, 22 Nov 2019 00:53:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574412795; bh=LiKutMYS6zhCF4I2N7bp1qDrD7CFF/t7s3R6yf0svH8=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KYt67Co9bG3yi6B7CwegLzjc/STAY4glxGTgpQb04gtyODswGo9QOBk9lAlX9AyUG yy8GHjg/VSo/BQcw23xfyRANw1ej9Uf0cjsiOejwcBCqZGze1zYUYv8GUYGH138zVs c+ssSo/W+twIJPS1bCZg+CDIuUI7XnagE0OshZYg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MaJ7v-1iJYSt3ui5-00WBrh; Fri, 22 Nov 2019 09:53:15 +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: <F23E3290-4E6F-4982-B433-A7E4ECB65CB3@akamai.com>
Date: Fri, 22 Nov 2019 09:53:13 +0100
Cc: tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <173F03A3-F26B-42D5-98BC-6F490B2905D9@gmx.de>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <228d061d-f25e-b350-4a6e-2aea827a590c@kit.edu> <e5a7ed0e-90cb-10a9-c55f-0ba8d2144ecd@bobbriscoe.net> <2AFFF85C-E66F-4CF4-AA62-6F7249A16959@heistp.net> <357abfd2-2d93-b4cf-355a-71a2def32b15@gmx.at> <E175102C-CD01-40B3-9807-3DE0C2DB8277@heistp.net> <9d6c1ce4-d192-d016-8418-c26a09e25517@gmx.at> <716AA405-6C3D-4AF5-9C7A-FEEC8A988CF4@cablelabs.com> <6803E804-6F4F-4811-97CE-3DA058896AE0@gmx.de> <CAJq5cE1eAm=W+pNC4VySb8_1zLWv6Oe85NPLkASd5HEOKOT5Ag@mail.gmail.com> <8C7B3665-8A03-4E16-BE86-ED62D9005295@gmx.de> <F23E3290-4E6F-4982-B433-A7E4ECB65CB3@akamai.com>
To: "Holland, Jake" <jholland@akamai.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:rzxuXWe2tukdF5KMYAWZST2Ab2WY9F1up064M5rGQnKG5fvr7EL +020kahQeRqCdsbRSbABiS4BF1w71FnRtcNg/GsW1K3nQNkpJ+RitVyHJpcASyCgG49Kw9C GUqNkEX0MJvrTgYZRqKkpsHXIWXoOYW+GizoSwLRZAFpCRCaoOiB3kTBUkY3vce8Wsojcpv x6Cj2nRQLShLRYrcgHx3Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:CJF9SQVqOXg=:P05/tyoptzyD59zxhFPjeT xGjvNzlZemlYB/nuHNweZNObKwDT7IgZR398dVWjJH1TRurMQVsBxLXN7CgVGecXjEZyRXV67 v4tB0ITQy+QpoJTgYZEv/kw020AKUDU4/zZRZp1A6dzeMXr1wc+6Cp9QA91QcoXrjwhubQkyL wk08mvd9JX6837QEbfksv6cpEU0PWFYmSHOrylgpRh9ueX63btQqssrLLYDntgR49xo/hZkmR ulXn6Zu4G+HbEmA9d3yRK7VlNfxGseXHbnHMFv2U77jPqq8QvIdWOAU1HU4OhpGH8X3k2pfWk 10HqE4ME07yr3Yhkj8OBBaR/y5YL/5vqzv3h9Re5pYMs/kvhC0pU8+5GAYFFQpNzKoGPUf8JO l67QmMdrAeVixkLd0Kq9sb73XRnwoZ9PqkysREQ2gVHcRPZBcdfTHfhK/VuhyZAQS/5DTb26m m85TwYviPX4Ay0M2xyVtg6Hu6W1yB1uV/1xXaSHTIZhuWZ60kC/2BW3BaB+N6TgA74m8hrBsO 9jGpbeQ/eE0rPDonWjMb2vfGUvGf0nRd9e4fK99cidKS98aFnbV1HsUZJrbFj11RYC1i1Yovg 5NXzD/qjJf4O3WFe64JRcRFedJjHvPy4p82baCZeF8yQwq29QkR6YJOIXr4/Fd1OUsak+Jcgr Gmt7aKdMzvKkVDiR703o7ilSx71PZkFN81EPhs4855LbVLJkdsxQfcw1ax8wFDA/5uWPSW/Sl 7cinMl8aM5qeG3ORsPh5pfxLZ58AViAJoBKJvttAHXhXGPRZHuhoK8BjEO4vhLpfh7K0h4YVs mIorkjVBtUxgDfjQqBCbwYIqx3R6hV5ff7MrU5quE860lW+0PoWoowtEsNRmhW0qG0s7WgdOY AbWXKjW0/jT/yGXS1vCmnV7yZL7fUTvZB3/c/DTATf90reEi+NCqyK08GIQWVAYMxZlzuLcBl MdHw+ZsTLslQ2QSAlrDBE4tKOGO8hRRMPPyqZC9cjlVJhITIDGJNIFx9qKHqiOQmyGpaWz4w2 r4p2kvh1BXcZ73ik7NhiOyrP+qyw9qZkIlIWlv4VDJRjdGtTob7/pxYoG6Td+GGcYV0v6RFd0 gDAuws8mYaYNjhs7UeikIYe6HbA7jGul4rdWDisW5B1ocXdoKW3ue/Fo9bCoJj1G3UNEAteh8 HBekouEpPOOMcaZimPmS3TcUFaqsXS2vFYtsXSSRsoGCRYyRv17giO3f2MIEWcpGUDtBJykhk CRgC8B9LT9n3TQauWRHi0ohBr68jKkNb2CxTLUb3Jcw/jzj4JsYdL3vi+2yw=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/yRZKDHsW1P4I4JWdwBaIDySHzl4>
Subject: Re: [tsvwg] L4S issue #16/17 questions from reading the session slides
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: Fri, 22 Nov 2019 08:53:25 -0000

Hi Jake,

Thanks for your feed-back.

> On Nov 22, 2019, at 04:24, Holland, Jake <jholland@akamai.com> wrote:
> 
> On 2019-11-21, 19:20, "Sebastian Moeller" <moeller0@gmx.de> wrote:
>> D) "Issue #17: Conclusion
>> The main result of concern was due to a bug in initializing the value of TCP Prague alpha, which has been fixed and demonstrated to resolve the latency impact that was spanning multiple seconds"
> 
>> COMMENT: In the light of https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s6-2/batch-l4s-s6-2-prague-vs-cubic-50Mbit-80ms_fixed.png showing that L4S still mishandles CE markings in that condition (albeit with the fall-out restricted to itself) it seems that the alpha fix alone might not be sufficient (which basically makes TCP Pragues response to the first CE independent of the CE interpretation scheme)
> 
> I brought this up,

	Great, the video's are still not up, so it will take a while before I cought up with the status quo.

> but Greg and Pete each explained to me that this
> impacts only the L4S flow in the observed behavior during testing,
> and doesn't make a giant persistent queue in the upstream dumb fifo.

	Ah, yes, I should have made this clearer, in principle I have no objections against L4S if it did a) equitably share bandwidth with normal traffic and b) would default to only hurting itself (in case when the approximations fail). But unfortunately when L4S fails to meet its own requirements it mostly is at the expense of other traffic (not in this specific instance though), honi soit qui mal y pense...

> 
> While this is maybe still worth considering as a performance question
> for L4S, I don't think it's the safety issue that was originally
> opened (nor that it's especially severe and worth blocking on).

	Yes, I agree and should have made that clearer, thanks for pointing that out.

> 
> I think I agree this means the issue is closeable, AFAIK.

	Yes.

> 
> Just to clarify: my expectation is that finding a future test case
> with another similar problem for competing flows could still happen,
> and would justify re-opening the issue.

	I believe hope the chairs are open to that. I am going to try test this hypothesis soon, by trying to get dualq's isolation failure corner-cases onto the issue tracker asd the L4S team seems to ignore to properly address anything less than a tracked issue. I will try to frame the issue as an issue of "congestion collapse" for the normal queue (which I believe it to be) so I can cite RFC verses and rhymes to move this out of the realm of "oh, it is just Sebastian being a PITA, again".


> 
> I'll also suggest I'd be more comfortable if we had a suite of test
> situations that covered, in a more principled or structured way, a
> "range of environments" (a la 5033) that happened to include this
> case, among many others.

	Yes, it seems like a worthwhile goal for all CC/AQM work to have an enumerated list of known tricky issues a CC/AQM should/must solve.

> 
> I won't try to argue the lack of such a suite is a blocker, just that
> its lack remains a source of much of my skepticism.
> 
> Best,
> Jake
> 
>