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

[Vasilenko Eduard <[e-mail]>]

Hi Neal,
Big thanks for your answer.

1.
For sure, smart people prefer cooperation to competition. CCAs are competing in reality, would like authors or not.
However I do not see a value for L4S after BBR finishes the migration (BBR should become the default for Windows, Linux, iOS, and Android to claim that the transition is finished, half of the real traffic is not enough to claim the transition finished).
Theoretically, L4S has a separate queue where latency is possible to guarantee. It should be better.
But practically, if the Classic queue would be occupied almost exclusively by BBR, then what would be the additional value of a separate queue?
I strongly suspect: miserable.
It is possible to prove only by tests or better pilot deployment.
If my suspect is true then there would be no motivation for additional hardware requirements of L4S.

L4S is good when compared to RENO which does not exist anymore.
L4S should be good compared to CUBIC, but for unknown reasons – it does not try to compare itself to CUBIC.

2.
Section 8 in general is “Security”. People typically do not read that section.
Requirements are in section 4 - It has nothing about burstiness.
The quote from section 8.2 has a little sense and may be interpreted very loosely.
Not many people would be capable of giving the interpretation that you did.

I did not read the Prague CCA yet because it has the status “personal opinion with zero deployments”.
It may be that it addresses the burstiness properly.
I am trying to understand and predict what will happen next, Prague does not look yet as the probable future.

Eduard
From: Neal Cardwell <ncardwell=[e-mail]>
Sent: Friday, April 19, 2024 17:24
To: Vasilenko Eduard <[e-mail]>
Cc: [e-mail]
Subject: Re: [tsvwg] "Pacing" requirement is lost in L4S

On Fri, Apr 19, 2024 at 4:39 AM Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:
Hi Experts,
I see L4S as the "Congestion Control Next Generation from IETF" (that is actually in competition with "Congestion Control Next Generation from Google").

IMHO BBR is not in competition with L4S.

BBR is, at its core, about maintaining an explicit model of the network path using whatever signals are available, and using that model to try to achieve low/bounded delay, low loss, and high throughput.

L4S, IMHO, is largely about creating a low-latency, low-loss, scalable throughput service model (metaphorically a "lane") in Internet bottlenecks, and using ECN to provide a signal to achieve that.

There is nothing fundamentally at odds about those two models. And once the details of the Prague congestion control algorithm are finalized, one goal (as our team has mentioned for a number of years) is to have a version of BBR that can use L4S signals and coexist with Prague congestion control in the L4S lane of Internet bottlenecks.

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.

IMHO it is not at all fair or accurate to say that L4S misses the pacing requirement. :-)
The pacing requirement is implicit in RFC 9330, at the very least in Section 8.2,  'Latency Friendliness':
   https://www.rfc-editor.org/rfc/rfc9330.html#section-8.2
That section says: "Like the Classic service, the L4S service relies on self-restraint to limit the rate in response to congestion. In addition, the L4S service requires self-restraint in terms of limiting latency (burstiness)." The only approach I'm aware of to limit the "rate" and "burstiness" of a flow, and the "latency" that it imposes, is to use pacing.

And this is explicit in Section 2.5.1, "Packet Pacing", of the Prague congestion control draft, which is part of the L4S suite of documents:
   https://www.ietf.org/archive/id/draft-briscoe-iccrg-prague-congestion-control-03.html#section-2.5.1
That section says: "A Prague CCA MUST pace the packets it sends to avoid the queuing delay and under-utilization that would otherwise be caused by bursts of packets..."

best regards,
neal


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

Best Regards
Eduard Vasilenko
Senior Architect
Network Algorithm Laboratory
Tel: [phone]<tel:+7%20985%20910-11-05>