Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <f16c9830-f97a-64e0-76e6-66f146576616@bobbriscoe.net>
Date: Tue, 22 Nov 2016 22:37:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <053CE5B0-1879-4A2B-B4E9-8BCDDE5BA482@gmail.com>
References: <be67928d-e1f7-2495-147d-1d42d6783cc8@bobbriscoe.net>
 <f6b89407-14d8-b532-b793-7490cb5a2117@kit.edu>
 <f16c9830-f97a-64e0-76e6-66f146576616@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/JARS-jPJj43z-tikoBfi5KdN-EI>
Cc: TCP Prague List <tcpPrague@ietf.org>, tcpm IETF list <tcpm@ietf.org>,
 "Bless, Roland \(TM\)" <roland.bless@kit.edu>, AQM IETF list <aqm@ietf.org>,
 tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: [tcpPrague] [aqm] L4S status update
Precedence: list


> On 22 Nov, 2016, at 21:09, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>=20
> {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.  This applies directly to Codel=92s =
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=92ll =
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).

I=92m reasonably convinced that Codel is a near-optimal solution to =
congestion signalling on TCP-friendly flows.  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=92t 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.

 - Jonathan Morton