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

[Christian Huitema <[e-mail]>]

On 4/19/2024 7:24 AM, Neal Cardwell wrote:
> 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.

I have done simulations of what happens if QUIC and BBR are used 
end-to-end, and the bottleneck implements an L4S like ECN marking 
strategy. My implementation of BBRv3 was modified to monitor the ECN 
marking rate, and treat excess numbers as a congestion signal, in 
parallel with other signals such as RTT or delivery rate. Bottom line, 
it works exactly as expected.

Which is good news, because it means we can deploy L4S gradually, use it 
as a congestion signal if it is deployed on the path, use the other 
congestion signals if ECN is not deployed yet.

-- Christian Huitema