Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency: defaults ready for testing

Sebastian Moeller <moeller0@gmx.de> Wed, 18 November 2020 07: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 D42813A0CDA for <tsvwg@ietfa.amsl.com>; Tue, 17 Nov 2020 23:37:58 -0800 (PST)
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 IIexPf49ziMN for <tsvwg@ietfa.amsl.com>; Tue, 17 Nov 2020 23:37:57 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 065143A0CD9 for <tsvwg@ietf.org>; Tue, 17 Nov 2020 23:37:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605685073; bh=aHBpdCOn0vBMLwGj6gTiwOnimFCn5yGXw8neEF9IaOw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=WhiWgcesW8cHGte3L1fvNfOQAj7iheY0v7r4uY5QzZjsnRhIxbY0qEEOn3OzN6ITQ 4QzjUVizmisRZoqdd3O/662g3tKrmks4dHWsdlmzmsSEcNd03eHzcXnn66GJ2uBoqv eH72OEbA87WbRsnyMp+Dysy2AE7qdrQR0BXCpIWM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.102] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M2wGi-1kgNR73DjA-003M17; Wed, 18 Nov 2020 08:37:53 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <24FB0C00-74E2-474D-BCA5-E9B9D66D04FB@gmail.com>
Date: Wed, 18 Nov 2020 08:37:52 +0100
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B23A86F-558A-4043-88EB-3A41C3E40632@gmx.de>
References: <AM8PR07MB7476081896E0A1C4897FFBA3B9E20@AM8PR07MB7476.eurprd07.prod.outlook.com> <811A76DD-3D48-43D3-A962-3F15AE9E858B@gmail.com> <B0880150-AE61-46AF-8C3E-542DFE28BD51@gmx.de> <F28CA33B-37D1-4955-8025-11E01016B944@gmail.com> <HE1PR0701MB287640A91354C094E790D0CDC2E10@HE1PR0701MB2876.eurprd07.prod.outlook.com> <24FB0C00-74E2-474D-BCA5-E9B9D66D04FB@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:UrydU7hCwvT4k3NdXgeykVek2B3+i8WitJ4fU8ocbw/lDOMY/HN RiwAPB5rnZUh/LuWDPxNOxQm8rTQGNMzsNXmsMFXN04L+LmQHUD4fG2HSfq4PRdky/u5Am6 hStJXHkK9VqYulrHReJJ/z2NoyxcuhWDgqP00lxLh6+1btfwpOU+SlrpimhQ5OPb6xWj57c +D+WEdnwbjb57M3HV72jQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:yc5M1MsOX/Y=:GrfjASyE4oY6m9W9mpwHY+ eyDMLSnMVXxgaHd0ug7JtUiTfQUqf67vFl3Btoh/qwsB3W9vW6+qbt7UrHXNNC/rTPYPfJ7wc gKWb5TPmPgBKiuPKzrabpUFtXIb+gLtm4G+rch1H2l55LwUmVE62lM6jccfpfI2ul9SKhFQNU Oa4SbQ7vXLkxC9bhDfp2Gk2PcApIW1VdwguozpC5Rue7FrtIsIly43IsrhrgW7sUfwZcbCWJl bhn0qVsdyB5zIaPOJ6hoBx0a4mPTbl/H15WCxL2a8OpFjeW1dnTUyboDtRdjbUqeUOMMvoMFl OsmUMUz4LFkpxJIjZUZA1FUzvNOG8NsuG1bDzqdqxMrgLQKhwcm3n1wmePFeKBklnoq/gHy+V aX9bR5V8B1uUKplLoAStPxFL1DKG3RXYp38oUI3+ms0N6fsIUnzxrcuxceGGm1/enYWOehOH+ j7heFZoHFRbdFFYfIm2r6T42GqlIOw/0T6ueGRu4rLEMtYQJIIJ/Fa1hUjbtEf7lwSVfTn098 X3s8saiDywAInd+ZN46q0nJWqpNkOnfZIg6qddQTMUKwkYL3I8i+6cNh14dGc6aY6uPC4q9op E/lvHg8AtacrUTCCkV3NBWASxdhakDonVjoqY8tCklxcBrCcGx/Sm9YIfuMgcOp8TYfOWS5lL oPTIIQn+/9DHdWWKsJUUXPunW0SH7/hAexPh96afPIb1NA2wK2tXRqmgUmkNL+iR3BNK1Vu0e 6zpHNs9v/jU7AHiArrNUVvQnNzZMLMkgSVR9beKZAzUp13+v3lxqcUQ0py/WR8BYwT+AOO2Rc dHeOeslWFpxNcmHSjQTuCgQtil5NLeqwLFj5WeMOwGgmnk/i7Qh+DBeyt8sCxQpbyhZVrL+Si dlFeb+F4iJVwm++l/6Fw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/92ioXQW_nMMiSZquqg8iCcGTzuE>
Subject: Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency: defaults ready for testing
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: Wed, 18 Nov 2020 07:37:59 -0000

Hi Jonathan,


thanks a lot.

> On Nov 18, 2020, at 08:14, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 18 Nov, 2020, at 8:58 am, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
>> 
>> The difference does not look extreme to me.
> 
> It's a persistent and stable 2:1 throughput ratio for about 5-10 seconds after flow startup, followed by a reasonably sharp switch to near parity.  I didn't say it was extreme, only confirmed for Sebastian's benefit that it was clearly noticeable in the data.

	[SM] Thanks for confirming my intuition. 1:2 might not be terrible in itself, but since it seems to not be random, but systematic, I am not confident that this will not be trivially exploitable to persistently send data with a noticeable rate advantage. On the otherhand, the whole issue could be marketed as intended boost for short flows, but that fails to take into account that this only help short flows with short RTT.


Best Regards
	Sebastian



> 
>> Can’t guarantee it but I suspect that you’ll find similar anomalies with e.g. rate based congestion controls. We had all sorts of interflow fairness issues in the RMCAT work that ended up in RFCs for NADA and SCReAM and L4S was not on the table then. 
>> 
>> Besides this, I don’t want to kill this discussion, it is very useful. But… it delves into congestion control research and perhaps ICCRG is a better venue for this ?
> 
> I'm inclined to agree, except that the RTT independence requirement appears in TSVWG adopted drafts, and TCP Prague is presently the only CC available to test compliance.
> 
> What we're showing is that DualPI2 is not sufficient by itself to implement that particular requirement, and arguably makes matters worse than either the typical status quo (dumb FIFO) or the present state of the art (FQ-AQM or AF-AQM).  If all discussion of TCP Prague is to move to ICCRG, then what we will discuss in TSVWG is DualPI2's many shortcomings instead.
> 
> - Jonathan Morton