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

[Vasilenko Eduard <[e-mail]>]

Hi Roland,
Thanks for your reply.

1.
CC may measure RTT, understand buffer growth, and increase the interval between packets.
Reaction by W and T looks the same effective against loaded buffer.
Actially W is easy to re-calculate to T. I do not see a problem.

2.
It looks like I use the wrong terminology because "pacing" for me is exactly the situation when information is sent on some timer (that may change slowly).
But you use "pacing" in combination with "BBR rate-based sending" which looks to me like "pacing for pacing".
It looks like "pacing" is something different for you.
Probably it is my fault. But I have not understood.

Eduard
-----Original Message-----
From: Bless, Roland (TM) <[e-mail]> 
Sent: Friday, April 19, 2024 12:17
To: Vasilenko Eduard <[e-mail]>; [e-mail]
Subject: Re: [tsvwg] "Pacing" requirement is lost in L4S

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".