Re: [tsvwg] L4S and the detection of RFC3168 AQMs

Bob Briscoe <> Mon, 15 February 2021 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D99F3A0DFE for <>; Mon, 15 Feb 2021 09:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.774
X-Spam-Status: No, score=0.774 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id juyJCFlxdRSW for <>; Mon, 15 Feb 2021 09:17:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86C783A0DE5 for <>; Mon, 15 Feb 2021 09:17:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=9TpddLO8ux/3TzD+h5KwhbFIy5noBD8j3l388ZYQ2Ls=; b=AG0i8u0uvlq2O+fFWo61iLj0n R2zucLeRnzyxu44wcGZUphIZVD6gAOq3eZiw284oECUZ4X/dEHgr/8xjPd7+kruyiE9kTaoI6DAs6 U0jUmbWrYb4zUETuM6sTboAsYt/AZt3cOFiek5Yl//6WmWhXRrekJMniMbScWFPKjK3Sb3s0SgGtN 2C1c60NbWyBgRFAalMscValyH08yqA1dQ7Z0jnjfUZqpSL9QU+20zElLaHXKxDB+oXmeTQOgdTByr LFJjYJ3OeQnBVL6MS+1E8IBJDTxwfHK9jY3CbarVcTBhhIoaRH3u4+oAo17iEmsMNTAriunuj0iO5 SrDxI4YQg==;
Received: from ([]:57252 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1lBhUy-0008Ue-Df; Mon, 15 Feb 2021 17:17:24 +0000
To: "" <>
Cc: Martin Duke <>, "" <>
References: <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Mon, 15 Feb 2021 17:17:23 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------F07EF2BF3CDD9EE6ECAC6D4F"
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] L4S and the detection of RFC3168 AQMs
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: Mon, 15 Feb 2021 17:17:27 -0000


On 15/02/2021 11:23, wrote:
>>    If that is the case (and the WG accepts it) then there are no false positives at startup. The only reason then  to worry about the amount of time to wait without seeing ECT(0)->CE is if there is an RFC3168 AQM, which you previously detected, and now might no longer be the bottleneck. under those conditions it would seem reasonable to be conservative about switching back.
> [BB] How and when did you "previously detect" an RFC3168 ECN AQM? I've read this para (and the whole thread) over and over, but I still can't work it out.
> [AB2] Most likely you are looking for something more clever than I intended to write. 'Previous detection' here just meant that in-band detection previously observed a packet it expected to be ECT(0) marked as CE, and thus assumes it has detected an RFC3168 ECN AQM - but sufficiently long ago that it is worth considering if that AQM is no-longer the bottleneck.

Understood. I (wrongly) took it to possibly imply that some other test 
had been running before your test.

Thanks for the other responses (snipped).


Bob Briscoe