Re: [tsvwg] "Pacing" requirement is lost in L4S

["Bless, Roland (TM)" <[e-mail]>]

Hi Vasilenko,

[not answering w.r.t. the Scalable requirement, but like to discuss
a different point]

I strongly disagree with your conclusion that we should forget about
Window-based CC. Window-based CC has the big advantage
of being self-stabilizing and thus limiting the amount of queuing delay.
Rate-based CCs are harder to control in this respect: the amount of
queued data at the bottleneck buffer may grow over time in case you
overestimated the available bandwidth.

However, you are right that window-based CC may cause micro-bursts
due to various causes (application rate limits or distorted ACK
clocking). While I agree that the ACK clock isn't that reliable
anymore these days (see also 
https://dl.acm.org/doi/10.1145/3371934.3371956 "Deprecating the TCP 
macroscopic model"),
I disagree with abandoning window-based CCs due to that.
The counter-measure against micro-bursts and underutilization
that may be caused by distorted ACK clocks is *pacing*!
This avoids micro-bursts and lets the sender keep sending
for a limited time period even if ACKs are not on time.

So my conclusion is that you should actually combine both:
*window-based CC + pacing* or similar to BBR
rate-based sending+pacing + control of the inflight data amount (which
is similar to window-based CC).

Regards,
  Roland

On 19.04.24 at 10:39 Vasilenko Eduard wrote:
> I see L4S as the "Congestion Control Next Generation from IETF" (that is actually in competition with "Congestion Control Next Generation from Google").
> Then I see the important requirement that is missing in L4S.
> 
> The primary requirement for CC is that it "should not grow the buffer on the bottleneck link".
> It is very disputable: is "the Scalable" requirement about it or not? Let's pretend that it is about it.
> 
> Then the next critical requirement is "pacing" which is missed in L4S completely.
> Kudos to Google because I understood its importance after one local (but big) company tested and investigated BBRv1 (then implemented it).
> After tests, they concluded that pacing is even more important than low latency. (I doubt, probably latency is more important)
> Imagine that the server would increase the window sharply. The Server may have a 100GE interface. It could generate 10us of traffic as a burst (or even more).
> Intermediate links could be 100GE or even bigger (highly probable), and the burst would travel as it is (without any spreading).
> Then this burst could arrive at 10Mbps subscriber (good performance for shared public WiFi). 0.01ms burst would become 100ms burst.
> It would create many negative consequences for the bottleneck link:
> - tail drop if buffers are not enough
> - guaranteed huge latency
> Hence, we should completely forget about W (window) while discussing CC, we have to use T (time between packets).
> CC next generation "should avoid bursts regulating inter-packet time, not the information permitted in transit".