[tsvwg] Re: Thoughts on FQ-PIE

[Christian Huitema <[e-mail]>]

On 11/3/2025 5:22 PM, Chris Box wrote:

... a lot of relevant feedback on the design of FQ-PIE, and then this:

> Section 5 Experiments
>
> If we're going to list suggestions for experimentation, we could add:
> * Assessment of performance differences of handling mixed L4S/Classic
> traffic through FQ-PIE vs DualPI2.
> * Assessment of performance differences of FQ-PIE vs FQ-Codel, using and
> extending the hackathon work.


I will be very interested in seeing how FQ-PIE compares to the PI2 
version of DualQ. If we follow the design guidelines in RFC9330 section 
4.2b, FQ-PIE will isolate a set of queues, with separate queues for 
buckets of ECN/ECT(1) connections, and for buckets of what L4S call 
"classic" connection. It will do that without having to resort to the 
"coupling" function in L4S. We can compare the results for the same 
load, with one or the other approach.

I am very interested by the comparison, because I am very skeptical of 
the "1/X^2" equation used in dualQ. Yes, this matches the asymptotic 
behavior of TCP Reno as modelled by M. Mathis et al. in 
https://dl.acm.org/doi/10.1145/263932.264023... in 1997. But that model 
only applies to TCP Reno. Cubic is significantly different, and BBR is 
more different still. For example, the recent versions of BBR monitor a 
"packet loss rate", and only backs off when that loss rate is above a 
threshold, set to 2% by default. The FQ approach avoids that kind of 
equation, and the experiments. Hence my interest in observing the 
results of the comparison!

-- Christian Huitema