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

[Christian Huitema <[e-mail]>]

On 11/1/2020 3:55 PM, Christian Huitema wrote:
>
>
> 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!
>
Sorry, bug in my spreadsheet. The marking rate is actually 0.1%, about 2
packets per RTT. Still not frequent enough for my taste, but much better
than 0.0008%. Nevertheless, the inverse relation between marking rate
and data rate is not great.

> 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
>
>
>
>
> _______________________________________________
> tcpPrague mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpprague