Re: [tcpPrague] [aqm] L4S status update

Bob Briscoe <> Fri, 25 November 2016 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BDAE12997C; Fri, 25 Nov 2016 06:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ME2Xv-rzNXSS; Fri, 25 Nov 2016 06:49:10 -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 3B1BF129ED3; Fri, 25 Nov 2016 06:23:28 -0800 (PST)
Received: from [] (port=34505 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <>) id 1cAHPS-00044q-M1; Fri, 25 Nov 2016 14:23:26 +0000
To: Jonathan Morton <>
References: <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 25 Nov 2016 14:23:26 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------CD4B2AF5D5C493A6434C123F"
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: <>
Cc: tsvwg IETF list <>, tcpm IETF list <>, TCP Prague List <>, "Bless, Roland (TM)" <>, AQM IETF list <>
Subject: Re: [tcpPrague] [aqm] L4S status update
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Nov 2016 14:49:15 -0000


On 22/11/16 20:37, Jonathan Morton wrote:
>> On 22 Nov, 2016, at 21:09, Bob Briscoe <> wrote:
>> {Note 1} I have never got a good answer to my questions on aqm@ietf as to why a sqrt that controls the shrinkage of the spacing between dropped packets has something to do with the steady state law of Reno, particularly because the law leads to linear growth in p over time.
> If you have intervals between events which follow a 1/sqrt(N) sequence, where N is the number of preceding events, you get an event frequency which increases linearly with time.
Yes, I pointed that out originally 
<>. And 
Toke confirmed in response that it did indeed happen in practice.
> This applies directly to Codel’s signalling strategy, which is to start at one mark per (assumed) RTT, and to increase the marking frequency if that was insufficient to control the queue.
> When you have multiple Reno flows sharing a single queue, there is a sqrt(N) factor in several of the characteristics, where N is the number of flows.  When such a shared link becomes saturated, all of the flows must be signalled to slow down, but for stochastic reasons it’ll probably take more than N signalling events to do so.  Increasing the signalling frequency while the queue remains insufficiently controlled has a good chance of quickly finding all the flows, while dropping relatively few packets (of non-ECN flows).
Just throwing a square root in "somewhere", doesn't mean it is the 
correct "somewhere".

A stated goal of the sqrt in the CoDel control law is to match the 
1/sqrt(p) in TCP Reno's window formula. Quite aside from whether that is 
a correct goal, it isn't even doing that:
* ACK-clocked load (number of flows, N) is proportional to 1/cwnd, ie. 
proportional to sqrt(p) [see 2nd para of section 4 of PI2 paper 
* because CoDel applies a sqrt to the interval between drops, it results 
in a linear increase in p with time (because the sqrt effectively gets 
squared - see the simple maths in my original posting about this 

So, the question is: "Why is a linear increase in p (starting from 0) 
good for controlling load from N flows, where N is proportional to sqrt(p)?"

> I’m reasonably convinced that Codel is a near-optimal solution to congestion signalling on TCP-friendly flows.
The word "optimal" has a precise meaning. I think you mean simply "I am 
predisposed to CoDel."

Whether the control law increases p linearly with time or by the sqrt, 
or by any function of time, is not the point anyway. Time is not the 
correct unit for this control law. The CoDel control law has no 
variables in it (other than the point at which it starts) that depend on 
any feature of the traffic. Once the CoDel control law starts, it just 
blindly increases until it reaches a high enough drop level to control 
the traffic. So the higher p needs to be, the longer it takes. And the 
lower p needs to be, the more it will overshoot within a round trip.

A constant increase in p with time, and no dependency on the traffic is 
just plain wrong.

No way will that result in anything that anyone could prove was 
"optimal" even if you put caveats around it like "near-optimal" or 
"reasonably convincingly near-optimal".

Perhaps this helps you to see why claims of near-optimality say more 
about the political or religious zeal of the person making the claim, 
than they do about CoDel itself.

> Regrettably, the latter are not the only type of traffic actually found on the Internet.
> Really, the central assumption of Codel is that each flow requires only one congestion signal event per RTT to cause it to back off.  Codel stops working well on traffic which doesn’t obey that assumption (a linear increase in drop frequency is inadequate to mitigate a flood - you need to work with drop probabilities for that), but it *does* work acceptably well with multiple flows sharing a queue, due to this operating-point search.
Similarly, isn't the phrase "acceptably well" another way of saying "We 
don't need to consider any other AQM that might be better at handling a 
wider range of load scenarios"? Even though there is already an 
alternative available that increases the drop level dependent on how 
fast the queue is growing.

This religious belief in a particular technology is not healthy. Please 
can we have some objectivity here.


>   - Jonathan Morton
> _______________________________________________
> tcpPrague mailing list

Bob Briscoe