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

[Neal Cardwell <[e-mail]>]

On Fri, Apr 19, 2024 at 4:39 AM Vasilenko Eduard <vasilenko.eduard=
[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] <+7%20985%20910-11-05>
>
>