Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

Bob Briscoe <> Sun, 21 July 2019 11:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 549F5120118 for <>; Sun, 21 Jul 2019 04:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XtR-IFXwBKy9 for <>; Sun, 21 Jul 2019 04:53:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA5BB120059 for <>; Sun, 21 Jul 2019 04:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qpClK1w/IVwc/SVw+pK23642qfw53lfM0IOr21MVopw=; b=J3Dvl9U6ZBDvtbMH0Xygr2Bfy1 2JAIgzzL0zY5rm5nzktxNqSH4VDNa3DxP9lqaU+JOsLMSK1GccEGziY/DNVLN+bvBiKXU3nu/Y1US tCjcm/yJ2yehQbSPSTGgciR3MGuWzQ2/c6QOxsN6Kv62Rlq1xpzxaKhqnOA7gFAlPUmzOJitGMBR+ lTDsJmwEKYvRTHwMhLMuQ/gtzDZVm6/ILWAo96x0r9DD/iTyfWm4KyWqcW+0jLTNs3483jfDvLB9d YZ/CkvQ7s3GJvQauOhgwOpZwroXAb8/6cdoH1t5y47PxW8QgW5k3qZolAPdT8J4tiTPc4ZzLEuXn1 cjeLXA9w==;
Received: from ([]:60266 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1hpAPa-0000fP-LE; Sun, 21 Jul 2019 12:53:54 +0100
To: Sebastian Moeller <>, Jonathan Morton <>
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <>, "Black, David" <>, "" <>, "" <>, Dave Taht <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Sun, 21 Jul 2019 12:53:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Jul 2019 11:54:00 -0000


On 19/07/2019 23:03, Sebastian Moeller wrote:
> Hi Jonathan,
>> On Jul 19, 2019, at 22:44, Jonathan Morton <> wrote:
>> So I'm pleased to hear that the L4S team will be at the hackathon with a demo setup.  Hopefully we will be able to obtain comparative test results, using the same test scripts as we use on SCE, and also insert an RFC-3168 single queue AQM into their network to demonstrate what actually happens in that case.  I think that the results will be illuminating for all concerned.
> 	What I really would like to see, how L4S endpoints will deal with post-bottleneck ingress shaping by an RFC3168 -compliant FQ-AQM. I know the experts here deems this not even a theoretical concern, but I really really want to see data, that L4S flows will not crowd out the more reactive RFC3168 flows in that situation. This is the set-up quite a number of latency sensitive end-users actually use to "debloat" the internet and it would be nice to have real data showing that this is not a concern.
Both teams brought their testbeds, and as of yesterday evening, Koen and 
Pete Heist had put the two together and started the tests Jonathan 
proposed. Usual problems: latest Linux kernel being used has introduced 
a bug, so need to wind back. But progressing.

Nonetheless, altho it's included in the tests, I don't see the 
particular concern with this 'Cake' scenario. How can "L4S flows crowd 
out more reactive RFC3168 flows" in "an RFC3168-compliant FQ-AQM". 
Whenever it would be happening, FQ would prevent it.

To ensure we're not continually being blown into the weeds, I thought 
the /only/ concern was about RFC3168-compliant /single-queue/ AQMs.


> Best Regards
> 	Sebastian
>> - Jonathan Morton
>> _______________________________________________
>> Ecn-sane mailing list
> _______________________________________________
> Ecn-sane mailing list

Bob Briscoe