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

Bob Briscoe <> Tue, 09 February 2021 23:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2D6E3A0EE6 for <>; Tue, 9 Feb 2021 15:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 Y505hH611PGm for <>; Tue, 9 Feb 2021 15:09:24 -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 24D433A0EE1 for <>; Tue, 9 Feb 2021 15:09:23 -0800 (PST)
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=7U6nVTGpiU4EPG4+qQ9Zp7li6yaF8ESg3SUYRgMxdD0=; b=13N3YDBEus3+JFgscddFdEhEcJ OJDgKtcwt6Vc7LRxLsY+YZqBO4eZ1E9K21iVJGsPFyYmIXUptefdO68PdjdhQAq6eDTZ5UCWQ3A1B JaAQjR5BfuIbJ0Ao7n0jbgK4kJQ2/UhfwW8ZwNpw6h7ERmS1lMUnd8gLGTgg3eWdSbliXCky+ynia 3oSYZ2sf9dQgdTyJRGOSCFrBNvoksTAihh2X57uugFoUGZZYZju5mhYLljTT3cadPa/SGsuY/S0Ei eR444/9XXKyzY1l79s0joJJG8XqCtQco41kK3mLJUWlm3gBsItPV9AMfBBikIYTTQIZbmXC9FtLrk z6jNoiXQ==;
Received: from ([]:49240 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1l9c8G-0000wi-7l; Tue, 09 Feb 2021 23:09:20 +0000
To: "Scheffenegger, Richard" <>
Cc: Martin Duke <>, "Black, David" <>, TSVWG <>, "" <>
References: <> <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Tue, 09 Feb 2021 23:09:20 +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: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Tue, 09 Feb 2021 23:09:26 -0000


First, thank you for reviving this thread, because it brought Alex's 
last posting (in Dec) to my attention. I'll respond to that separately 
(probably mañana, as it's getting late).

Pls see inline tagged [BB]...

On 09/02/2021 11:05, Scheffenegger, Richard wrote:
> Martin, group,
> AccECN is not tied to RFC3168 (and quite the opposite, it tries to be as
> impartial to the specifics of when/why packets were marked in whichever
> way).

[BB] Also, in case people aren't aware: an L4S sender using TCP MUST 
negotiate the use of Accurate ECN TCP feedback with its peer. So I think 
there's no case where a transport would not provide feedback for Alex's 

> Therefore the Packet-CE counter (you refer to it as PCE, while the draft
> refers to the (full) counter as cep [from CE_packet] is incremented
> regardless of which packet arrives with the CE mark (control, data,
> retransmission, ...).
> Similar for the Byte-CE counter (BCE, in the AccECN draft ceb from
> CE_bytes). As only TCP payload bytes arriving with the CE mark would be
> accounted, the behavior as expected in the discussion below is already
> implicitly available when using AccECN.

[BB] ...only if the data receiver supports sending the AccECN TCP Option 
(optional) and the new TCP Option traverses the path successfully and 
the data sender supports reading the TCP Option (optional).

Nonetheless, if any of these three is not the case, it might still be 
possible to work out whether a CE marking was on a probe packet...

The ACK that carries the CE packet counter also carries an ACKno (and 
possibly SACK options). When a zero-sized probe is sent, it won't elicit 
an ACK on its own (TCP doesn't ACK pure ACKs). But if the probe is CE 
marked, when the data receiver ACKs subsequent data packet(s), the CE 
packet counter will include any CE marking on the probe. It seems that 
doesn't help, because the data sender cannot tell whether the CE mark 
was on the data packets or the probe. But if the counter ever increases 
by more than the number of data packets covered by the ACK, the probe 
must have been marked as well.

That sounds like having to wait quite a time for the possibility of all 
packets together being marked. But there might be a more deterministic 
way by use the same trick that keep alive probes use...

That is, send a zero-sized probe with SEG.SEQ = SND.NXT-1. Being out of 
window, each of these probes would immediately elicit a pure ACK from 
the receiver. This might cause problems alongside the other regular 
ACKs, because I think these might look like Dup ACKs (when the trick was 
invented for keepalives, this wasn't a problem 'cos there were no other 
data packets being ACK'd). However, it's possible the sender can work 
out that they are not Dup ACKs, given it knows it sent a probe.

(I'm not totally certain of my facts here - we'd need a TCP expert to 
confirm - Richard?)


> There may be some ambiguity, as AccECN doesn't strictly require an
> immediate ACK on a CE (only that the next packet after a received CE
> mark has to convey the changed CE-related counters), but in the general
> case, AccECN would allow and support such a detection scheme.


> Best regards,
>    Richard
> Am 12.12.2020 um 00:22 schrieb Martin Duke:
>> Excellent, thank you for the reminder. So the L4S sender could
>> interleave some ECT(0) marked pure ACKs (or retransmissions of the last
>> acknowledged byte) and hope that the PCE counter increases without
>> corresponding increases in BCE.
>> The AccECN spec might need to be updated to specify that these should be
>> reported in PCE even though they are not 3168 compliant.
>> Scheduling these probes might not exactly be trivial, but if they are
>> temporally correlated with ECT(1)->CE marks, this would be highly
>> suggestive, yes?
>> On Fri, Dec 11, 2020 at 3:03 PM Black, David <
>> <>> wrote:
>>     In which case, RFC 8311 Section 4.3 allows experimental usage of ECN
>>     with such packets (
>> <>).____
>>     __ __
>>     Thanks, --David____
>>     __ __
>>     [EXTERNAL EMAIL] ____
>>     My understanding of 3168 is that only in-window data packets are
>>     marked ECT(0). A zero-length segment is a equivalent to a pure ACK,
>>     which is not marked.____
>>     __ __
>>     On Fri, Dec 11, 2020 at 12:09 PM C. M. Heard <
>>     <>> wrote:____
>>         On Fri, Dec 11, 2020 at 11:51 AM Martin Duke
>>         < <>>
>>         wrote:____
>>             This falls under the "much easier to do in other transports"
>>             category, where I could just send a PING or HEARTBEAT marked
>>             ECT(0) to test the queue in mid-connection, without
>>             affecting the latency of anything that matters. But in the
>>             TCP case, I'm not sure how to resolve Bob's second objection
>>             (running ECT(0) for a long time would be unacceptable).____
>>         __ __
>>         Could zero-length TCP segments be used instead of PING or
>>         HEARTBEAT? ____
>>         ____
>>         Mike Heard ____

Bob Briscoe