Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

[Christian Huitema <[e-mail]>]

On 11/1/2020 1:53 PM, De Schepper, Koen (Nokia - BE/Antwerp) wrote:
>
> >>By the way, I do think that L4S makes too many hypotheses about the
> CC. I wish the AQM was based on intrinsic properties, such as "this
> flow is using more than its fair share of bandwidth"
>
> This last quote is exactly what the L4S marking is intended to do: the
> smoothed marking probability over a longer time interval (about 10
> RTTs) indicates the fair target rate. Assuming we agree on 15ms being
> the reference RTT, then the average rate can be r=2/(p*0.015)=133/p
> packets per second. So you can evaluate yourself if you use more or
> less than the fair share. How you respond to this knowledge is up to
> your CC.
>
I think that part of the complexity in L4S AQM comes from trying to
achieve fair sharing of resource without actually implementing fair
queuing. You end up expecting that implementations apply a formula and
derive their packet sending rate from a smoothed average of the packet
marking rate. It may work well in controlled environments, but I am
afraid that very few implementations are ever going to do that in practice.

Congestion Control algorithms are much more likely to treat packet
losses, markings, or delay increases as signals that they are sending
too fast, while considering their absence or lower frequency as signal
that they might be able to send faster. Implementations also are likely
to take into account the recent history, for example monitoring the min
RTT (LEDBAT, BBR), or monitoring the recent available bandwidth (BBR).
They also typically filter signals, e.g., consider only one packet loss
or ECN mark per RTT (New Reno, Cubic, etc.). This is expected, because
we do see packet losses arriving in batches, and can reasonably expect
ECN marks to have the same behavior. But implementations are inherently
selfish, do not really trust the signals from the network, and are very
unlikely to end up applying the formula that you suggest.

In any case, you have a scaling issue. Let's consider a 1.5Gbps link,
with 15 ms delay and 1500 bytes packets. The nominal sending rate is
125,000 packets per second. The marking rate with your formula shall be
p = 2/(r*0.015), which is about 0.0008%. Over the last 10 RTT, the
connection will on average see 0.14 marks -- that is, no mark over the
last 10 RTT 86% of the time. This falls well short of the requirement to
provide frequent feedback!

If you give up the formula, you could end up with a significantly
simpler event based congestion control, in which applications slow down
if they see too many CE marks, accelerate if they only see a very low
marking rate, and stay put if they see an infrequent marking rate. I can
see applications doing that, resulting in a fairly stable network and
low delays. Of course, you will have to do some form of fair share
enforcement to catch violators, but I am sure you can come up with
something.

-- Christian Huitema