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 14:23 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 D117D3A0992 for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 06:23:41 -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, HTML_MESSAGE=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 e59GsL1QCY6F for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 06:23:39 -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 7C9D63A09C0 for <tsvwg@ietf.org>; Wed, 18 Nov 2020 06:23:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605709387; bh=mXg+xB/Z/oILlD0DKXHq6kFfvJwmZG4C1BZM3LBZ+fs=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=LubysQBDhdAyRAWndRE8u9SyRguie4KO2lNuUGyDanWjLWvyDAGe9V43zbmKB8ALs F7iU2HJ6t7laFf+48wV76cXbCrdS41jebWvv8nG9X9emhIjhXZnFQ9jRXv2gC04U/y Sj7IjOmA8JV7Z6GdiMSHS6kWx2f24+qKezl3R0KE=
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 1MI5QF-1kRLTx3plX-00FAkB; Wed, 18 Nov 2020 15:23:07 +0100
From: Sebastian Moeller <moeller0@gmx.de>
Message-Id: <C3E564C5-4146-4E2E-B261-16E10FBD2B60@gmx.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F2C079B8-19B2-454B-9077-6688E201D456"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Wed, 18 Nov 2020 15:23:00 +0100
In-Reply-To: <811A76DD-3D48-43D3-A962-3F15AE9E858B@gmail.com>
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, tsvwg IETF list <tsvwg@ietf.org>
To: Jonathan Morton <chromatix99@gmail.com>
References: <AM8PR07MB7476081896E0A1C4897FFBA3B9E20@AM8PR07MB7476.eurprd07.prod.outlook.com> <811A76DD-3D48-43D3-A962-3F15AE9E858B@gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:m7xtYWhbUT8PMgdHq09CaYUdUiMkhUmXWxUVoyXiTEGszuM7f17 7tTSyxMbt8jz5hbzvpPpRqRlF9nXTRtF5Ahgxj/VulHVTHJLXleBUptLRXX1ZftSUuNQEfN VVfW/3fxWHeaVYR5JxqCUOrrJdV4Ty8VQJM2LGkyBwJk60bh2zkt5XEwo5WldXlG//nJhkA BgQUjigHRrHSLd/3XObsQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Lj5CovqwOCk=:RqlPFM2s4bXcPWnzRDjBm/ XS21U3EqtOquGVXdZt0iRngV+WvQjKvqayc2vJshG31pxQ+xMsSUqO8G0AEquBuLc65FpFm6H aIecJ0UMCTBE2dC2BYEW4BOGxtjNRL35p87IkH/pW2T0nP/2bUo/v3KvQY29mfLsS2A6WJTCj /mbl601g7NqMUpDeFq82EfS4eJgeDThY1wzxkedKxWHqihfDuswwob035L7sd1UrZYLd6bNpH wreSa1AR6AD1yMEA+e0D3vmSp+ygRKd90hpgONuDbArJzfdv4Ru50Ut+nGa812Gu6Em3/aXip TIZAg4xpKEz1K+DH7X2KN33EVWdUMgkZ/YfTbWsqF0nZ/c6za4J/dJMPJYPhPE4Mi26zAj+B9 ygwBZTHZBIzfFqp/OFKaxFwxemeXjjclmmfDqi2gl40GRi29HP7DMSy5gcdVzAvmRMrg1XWVN 42EISNenxjnEwb4KjL/Gyv7IqFcFXSFzHGUhjnUby3sCaUo27UCOfvkibAX2WnxZs5Cd0dnHk 336mFRxOEWZqjbs29zHbfquREkPdRRpsJtdGHV8YMJtef5IP5Mx4IXuD1959F5rrqE++VY+HT ejw7k0ZUiIAIJaroW7XcgE0y6xXbZ1wKhxO1Wrvetsfo92atZQCoXf7WcHpHLZhTdE9HsG91z onJ6lYnWl3jjfPvIfsJfFueF5a7slzjjXn9AaMibWtp+pLeEiPHI9kIYaagGfupU6SMRGKETt Y13qW9Mc6Om6mwWivJRtA/ZCyYDs/Am3BqJ8ndi2w2knkZ5mAYjJQID9GTh1aM3YXB7tB9jkv 7M3xsuQQm0aE988JMCLpvhFwgKVlkinSybkQQoHhMtqD7OFbpsXAqN/5s32ry/65r+sItZowT VgC/L/JF15K0+dUD/bVw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2I2KOhQ4JD0-8RZYoaadGTRxd9s>
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 14:23:42 -0000
Hi Jonathan, to come back to this. > On Nov 18, 2020, at 01:28, Jonathan Morton <chromatix99@gmail.com> wrote: > >> On 17 Nov, 2020, at 3:32 pm, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> wrote: >> >> The RTT-independence was implemented, available and demonstrated several meetings ago already and as presented working very well according to our tests. The following parameters are now set as default, so can be tested out of the box: >> >> All Prague flows with an RTT below 25ms will now converge to the same rate, independent of their real base RTT. This means that flows with a bigger RTT than 25 ms will never have to compete against smaller than 25ms RTT flows. >> >> Now the defaults are set, I'm looking forward to independent evaluations. > > Since our tests are quite well automated, we were able to run a subset of them (all at 50Mbps) against the new defaults this evening. > > I'll give you credit: there is some improvement in some of the tests. However, we could still draw most of the same conclusions from the new data as we did from last week's data; the big-picture problems are still present and in some cases have actually deteriorated. > > I'll focus on two major concerns in particular: > > 1: Prague outcompetes CUBIC in DualPI2, at a common baseline RTT. This only stops being true when the BDP is large enough for Prague to have difficulty growing to steady state in a reasonable amount of time. > > With the new code, the Jain's index improves from .823 to .987 at 10ms (the advantage in both cases being to Prague), but actually worsens from .880 to .838 at 20ms, and from .936 to .890 at 80ms. All of these are sampled after allowing two minutes for the flows to converge to steady-state. > > 2: Prague vs Prague competition on differing RTTs. > > Here is Figure 3 from the test report we recently posted, followed by an equivalent chart generated from the new data this evening. Let's play spot the difference: > > > > > I can say that the throughput ratio for Prague vs Prague via DualPI2 is, in fact, slightly improved in the new data, but it is still significantly worse even than the 16:1 ratio expected from the baseline RTTs at identical average cwnd. In a similar test with 80ms versus 20ms RTTs, the two Prague flows also have more than the expected 4:1 throughput ratio. I don't have an immediate explanation for that. > > Notice that with both the old and new code, CodelAF gets very close to parity in throughput with the same traffic load, and that even through DualPI2, a pair of CUBIC flows is closer to parity than a pair of Prague flows. That is not, overall, an improvement in RTT independence from switching to TCP Prague and/or DualPI2. > > However, we did find an improvement in fairness, compared to the older code, when comparing 20ms vs 10ms Prague flows. That's what you were going for, wasn't it? A shame that, in achieving that singular success, so many other things are left unresolved. [SM] Would be interesting to see 20/10, as well as 26/13 with the newly changed code... My hunch is that 26/13 should look more different from 20/10 than the additional 6ms (30%) RTT offset would lead on to believe. Best Regards Sebastian > > I'm sure we will have the opportunity to run more tests on your future efforts. For the moment, with limited time on our hands, this will have to do. > > - Jonathan Morton
- Re: [tsvwg] new tests of L4S RTT fairness and int… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] new tests of L4S RTT fairness and int… Sebastian Moeller
- Re: [tsvwg] new tests of L4S RTT fairness and int… Jonathan Morton
- Re: [tsvwg] new tests of L4S RTT fairness and int… Sebastian Moeller
- Re: [tsvwg] new tests of L4S RTT fairness and int… Jonathan Morton
- Re: [tsvwg] new tests of L4S RTT fairness and int… Ingemar Johansson S
- Re: [tsvwg] new tests of L4S RTT fairness and int… Ingemar Johansson S
- Re: [tsvwg] new tests of L4S RTT fairness and int… Jonathan Morton
- Re: [tsvwg] new tests of L4S RTT fairness and int… Sebastian Moeller
- Re: [tsvwg] new tests of L4S RTT fairness and int… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] new tests of L4S RTT fairness and int… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] new tests of L4S RTT fairness and int… Sebastian Moeller
- Re: [tsvwg] new tests of L4S RTT fairness and int… Sebastian Moeller
- Re: [tsvwg] new tests of L4S RTT fairness and int… Sebastian Moeller