Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

Pete Heist <pete@heistp.net> Mon, 11 November 2019 19:57 UTC

Return-Path: <pete@heistp.net>
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 1D1C3120A5D for <tsvwg@ietfa.amsl.com>; Mon, 11 Nov 2019 11:57:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heistp.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 ZhYbXz41jD9K for <tsvwg@ietfa.amsl.com>; Mon, 11 Nov 2019 11:57:29 -0800 (PST)
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 2A57F120A47 for <tsvwg@ietf.org>; Mon, 11 Nov 2019 11:57:27 -0800 (PST)
Received: by mail-wm1-x341.google.com with SMTP id l17so637177wmh.0 for <tsvwg@ietf.org>; Mon, 11 Nov 2019 11:57:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QRMhYIR78QwbQr0jsD3p5TKEXRqYmG+Z+l70019e/Qk=; b=RAPcTBAgGFjFxYwJde+fb2tCg17y8H76w/dZzfyXRojT823jmduvVSTIUFP69mSM9D h9lW5YObyQbA7X3PInD3lWyjznTZuoeAP6PXYeaCrhe+YYWzgT8HGQQa8dYl5p7wZ3FZ daAN2LkNCWDAHQi6vTpgujnGym55tvBoWl5ClAmdtCV9l24uRPXsJYRbOxSmn7yQvmGA kzCDLoVsrX/YTYMm1/K5+FHD5g5lfMwZ9FqICCkBT2d3EVZoQDQp6m38CxKEqhkdy2XS /YEjHXKNHvSNohFLcYfu06KRfeBOhSIqxxtJURpES9nEJyL8IabbyML2ZtTCWrzx+cKj ZXjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QRMhYIR78QwbQr0jsD3p5TKEXRqYmG+Z+l70019e/Qk=; b=jAOLeMp8fMuneNR1Lz4A/JuRTm+pxUyWGhnePTQBlQogcONeLGxfFxCdBp4ZXtoSqE +0bKkZ6R81b6cvO6KWc+RDrEWKYkV2irgUBnptjzLDhOzXwtoi5YwvdHEuBwn9y5fBRo a8kKY5TrYzoVmpqHsTsPWAOeENkALgof6Oo+WJEHgqV9dB7c8/F1Rk8QiKm6ob+hWSXj lyrK6W9o5sOkOe9F1IylhA2Hz0maREi048Nh1fhOF06xu8sHQLIji8zjQnfnFCPFY8EZ 4VaOsDQFXk5VTt5vpXInOuam7thKeFkiIc+o0vb3FecE4oAhiu/YI0tnhlG8H+pAIDQU uM3g==
X-Gm-Message-State: APjAAAV4uNIS91ZavB7VyWDgCaTTrWFZ9g53+l06Ms/SKb7xSn4ts943 /i04Zk8iarw634FReNVfCwCRrA==
X-Google-Smtp-Source: APXvYqzInwoELrmGJQfuB8sJU/GQAEKRbri9H9iBWCICjGOsm11dW3WtiEzhNk9nnyA2yKbMsuY1GA==
X-Received: by 2002:a05:600c:218e:: with SMTP id e14mr603576wme.22.1573502245581; Mon, 11 Nov 2019 11:57:25 -0800 (PST)
Received: from yoda.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id y17sm18726545wrs.58.2019.11.11.11.57.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Nov 2019 11:57:24 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist <pete@heistp.net>
In-Reply-To: <D5D560CB-BC47-45BE-811E-E73E2D4909E3@cablelabs.com>
Date: Mon, 11 Nov 2019 20:57:23 +0100
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, Sebastian Moeller <moeller0@gmx.de>, Wesley Eddy <wes@mti-systems.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <40B5DA8A-8290-41DC-8A2B-B9DE9661D605@heistp.net>
References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <B58A5572-510E-42C7-8181-42A0BE298393@gmail.com> <D2E12331-F504-4D5F-B8E7-A1A5E98DDF7E@cablelabs.com> <2275E6A5-C8F8-477F-A24A-3E6168917DDF@gmail.com> <55F724CD-6E74-40D9-8416-D1918C2008DD@cablelabs.com> <BBE7C7A9-0222-4D84-BF27-8D5CAE2F995E@gmail.com> <6f189711-ffa0-90f4-fd16-3464ba4df3ce@mti-systems.com> <4A706B11-3239-4DAC-BE85-0B4BFF2D8FF8@heistp.net> <8B28ECE4-FF4B-4BB2-ACBE-80B30708F97E@cablelabs.com> <AAEA9AC2-B8A1-4837-A7C9-8EEA21A7C523@gmx.de> <D5D560CB-BC47-45BE-811E-E73E2D4909E3@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/c08wW5WZbC2yjACg-K4NaOp-Zho>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
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: Mon, 11 Nov 2019 19:57:31 -0000

Hi, thanks for working on the issues we posted in our “bakeoff” tests on Sep. 12. We have updated our repo with a re-run of the tests using the L4S code as of the tag 'testing/5-11-2019', and those results are at the same location:

https://github.com/heistp/sce-l4s-bakeoff/

We’ve put together a list of changes we saw in the results:

https://github.com/heistp/sce-l4s-bakeoff#changes

The changes are:

- The previously reported intermittent TCP Prague utilization issues appear to be fixed.

- TCP Prague vs Cubic now does converge to fairness, but appears to have fairly long convergence times at 80ms RTT (example: https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s3-2/batch-l4s-s3-2-prague-vs-prague-50Mbit-80ms_fixed.png). Convergence times in other scenarios are similarly long.

- In scenarios 2, 5 and 6, the previously reported L4S interaction with CoDel seems to be partially, but not completely fixed. By reversing the flow start order (prague vs cubic instead of cubic vs prague, second flow delayed by 10 seconds), we can see that while the TCP RTT spikes no longer occur at flow start, they are still present when a second flow is introduced after slow-start exit (example: https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s2-2/batch-l4s-s2-2-prague-vs-cubic-50Mbit-80ms_fixed.png).

- In scenario 3 (single queue AQM at 10ms RTT), the previously reported unfairness between TCP Prague and Cubic grew larger, from ~4.1x (40.55/9.81Mbit) to ~7.7x (44.25/5.78Mbit). This trend appears to be consistent at other RTT delays in the same scenario (0ms and 80ms).

I will update the issues in trac with these results, and if there are any questions let us know…

Pete

> On Nov 6, 2019, at 5:23 PM, Greg White <g.white@CableLabs.com> wrote:
> 
> Good timing __
> 
> We've just wrapped up our findings on Issue 17, and have posted them here (along with some comments on Issue 16 as well):
> 
> https://l4s.cablelabs.com 
> 
> (Note, the ns3 repo is not public yet, but will be shortly.   We'll update that page with links within a day or two.)
> 
> In summary, we reached the following conclusions:
> 
> - 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
> 
> - the remaining short duration latency spike in the FIFO queue is seen in *all* congestion control variants tested, including BBRv1, NewReno, and Cubic, and is not specific to Prague
> 
> - if the CoDel queue is upgraded to perform Immediate AQM on L4S flows, the latency spike can be largely avoided.
> 
> We invite a thorough review of the work, but believe that this closes issue #17.
> 
> 
> Best Regards,
> 
> Greg White, Tom Henderson, Olivier Tilmans
> 
> 
> 
> 
> 
> 
> On 11/6/19, 12:59 AM, "Sebastian Moeller" <moeller0@gmx.de> wrote:
> 
>    Hi Greg,
> 
> 
>> On Sep 11, 2019, at 19:16, Greg White <g.white@cablelabs.com> wrote:
>> 
>> I'm planning on doing testing as well, but it will be more than a day or two to get it done.  Rough timeframe would be 2-3 weeks from now.
> 
>    	Since I can not hide my impatience any loger, did anything come out of this yet?
> 
>    Best Regards
>    	Sebastian
> 
>> 
>> -Greg
>> 
>> On 9/11/19, 1:52 AM, "Pete Heist" <pete@heistp.net> wrote:
>> 
>> 
>>> On Sep 9, 2019, at 9:01 PM, Wesley Eddy <wes@mti-systems.com> wrote:
>>> 
>>> Since this thread seems to have dwindled, I just wanted to summarize that it looks to me like we have agreement that testing as described is needed.
>>> 
>>> I updated the issue tracker with a comment saying as much and pointing back to this thread in the archive for reference.
>>> 
>>> Is anyone planning to perform this testing in a rough timeframe they might want to share?
>> 
>>   Hi Wesley, I’ll share results from relevant testing in the next day or two...
>> 
>>   Regards,
>>   Pete
>> 
>> 
>> 
> 
> 
>