IETF Logo Mail Archive

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

Dave Taht <dave@taht.net> Wed, 06 November 2019 18:15 UTC

Return-Path: <dave@taht.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 D5EEF1200C4 for <tsvwg@ietfa.amsl.com>; Wed, 6 Nov 2019 10:15:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 0CTgefW89gal for <tsvwg@ietfa.amsl.com>; Wed, 6 Nov 2019 10:15:20 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795DD1200DF for <tsvwg@ietf.org>; Wed, 6 Nov 2019 10:15:20 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id ED6E82296E; Wed, 6 Nov 2019 18:15:14 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: Greg White <g.white@CableLabs.com>
Cc: Sebastian Moeller <moeller0@gmx.de>, "tsvwg@ietf.org" <tsvwg@ietf.org>
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>
Date: Wed, 06 Nov 2019 10:15:02 -0800
In-Reply-To: <D5D560CB-BC47-45BE-811E-E73E2D4909E3@cablelabs.com> (Greg White's message of "Wed, 6 Nov 2019 16:23:18 +0000")
Message-ID: <87d0e4hnx5.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cprO6wL-qezaBqUVAyf7GLPFtBA>
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: Wed, 06 Nov 2019 18:15:22 -0000

Greg White <g.white@CableLabs.com> writes:

> 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.

I'm very glad to see y'all finding bugs in the initial implementations.

>
>
> 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
>     > 
>     > 
>     > 
>     
>

v2.23.0 | Report a Bug | By Email