[tsvwg] Re: Thoughts on FQ-PIE

[Sebastian Moeller <[e-mail]>]

Hi Chris,

See below [SM].

On 4 November 2025 02:22:56 CET, Chris Box <[e-mail]> wrote:
>On Mon, 3 Nov 2025 at 15:35, Martin Duke <[e-mail]> wrote:
>
>> belatedly, this draft is adopted. Mohit, please submit an -ietf- version
>> of the draft as soon as possible.
>>
>
>Hi everyone. I wasn't following this list so missed the adoption call, but
>for the record I fully support adoption. We should definitely describe this
>form of modern AQM so the wider world is aware.
>
>I'd like to share my thoughts on how to evolve the document.
>
>Section 4
>I would prefer that RFC8033 (PIE) did not say the latency target "SHOULD be
>15ms",

[SM] Fully agree, especially since rfc8033 lacks any justification/rationale why, but I note the WG dropped the ball on that years ago and we are not talking rfc8033-bis here. I do note that these 15 ms seem to be aligned with what cable labs used for the PIE component for DOCSIS, but that still does not answer why.

> as the optimum queue size depends very much on the variability of
>the bottleneck bandwidth. Constant bandwidth can handle a shorter standing
>queue. 
>Wireless links often require a longer queue unless they are to
>sacrifice a lot of throughput. 

Well, for WiFi IMHP the state of the art is to put an fq scheduler and AQM into the wifi stack where more information about imjediate rate can be gleaned. But that is orthogonal to this ID's goal.

>So for this draft I'd prefer that we didn't
>reinforce the problem. Instead of "(recommended as 15ms in RFC8033)" we
>could say "(such as the 15ms default in RFC8033)".


[SM] Mmmh, if 8033 is faulty, we should fix this at the source as well, no. 


>
>Section 4.1 Enqueue
>This says "*It is important to note that the timestamping approach provides
>a "per-packet queue delay," while the drop probability is calculated
>periodically (every 15 ms, as specified in [RFC8033]). Therefore, the
>FQ-PIE algorithm MAY use the queue delay value from the most recently
>dequeued packet when calculating the drop probability.*"
>This feels like a big choice being offered to the implementer. Either we
>change the drop probability every packet, or we change it every 15ms. 


[SM] I have not looked into the imoolementation, but I read this as, at the time we re-evaluate the drop probability (so every 15ms) we might use the most recent sojourn time as input or the total queue size / egress rate.


>As
>all three current implementations take the per-packet approach, should we
>instead make this the default in the document? Are there some circumstances
>in which every 15ms is better? 


[SM] IIRC pie really needs the drop probability to stay constantish for some time to achieve some modicum of fairness, but that indeed might not matter for fq-pie.


>If yes, let's describe that. If not, get rid
>of it entirely.
>
>"*FQ-PIE does not adopt this approach for the reasons explained below.*"
>I think the document would be easier to read if we move the reasons
>paragraph to an appendix.


[SM] Rrespectfully disagree, the ID is not very long, so what is gained from moving this out of line?


>
>Section 4.3 ECN Support
>As L4S was published as RFC9330 nearly three years ago, any mention of ECN
>in this document shouldn't ignore its presence. These days ECT(1) does not
>generally imply classic 3168 marking.


[SM] Does it? Like in real world measurements? I note that to this day neither tcp prague nor the dualqueue AQM are in upstream Linux... and L4S is just another experiment, not a standard... (in fairness so are most AQM rfcs).


>
>RFC9330 section 4.2b actually mentions FQ-PIE!


[SM] Does it? Seems more of a theoretical shout out, given that fq-pie does not implement special treatment for ECT(1).



>"*Per-Flow Queues and AQMs: A scheduler with per-flow queues, such as
>FQ-CoDel or FQ-PIE, can be used for L4S. For instance, within each queue of
>an FQ-CoDel system, as well as a CoDel AQM, there is typically also the
>option 


[SM] Engineering by wishful thinking... unless somebody implements such a conditional treatment this option does not exist for the user.


>of ECN marking at an immediate (unsmoothed) shallow threshold to
>support use in data centres (see Section 5.2.7 of the FQ-CoDel spec
>[RFC8290]). In Linux, this has been modified so that the shallow threshold
>can be solely applied to ECT(1) packets [FQ_CoDel_Thresh]. 


[SM] Not false, but misleading, in current Linux that treatment can be applied to any (masked) value of the old TOS/TCLASS bitfield...


>Then, if there
>is a flow of Not-ECT or ECT(0) packets in the per-flow queue, the Classic
>AQM (e.g., CoDel) is applied; whereas, if there is a flow of ECT(1) packets
>in the queue, the shallower (typically sub-millisecond) threshold is


[SM] Unsure where that sub-millisecond claim is comming from... and whether that has been actually tested over the internet (this is a recurring figure in the L4S rfcs, that claims are made but not substantiated, quite puzzling given that these drafts are quite long).


>applied. In addition, ECT(0) and Not-ECT packets could potentially be
>classified into a separate flow queue from ECT(1) and CE packets to avoid
>them mixing if they share a common flow identifier (e.g., in a VPN).*"


[SM] Yeah, this lacks a discussion of the effects of the to be expected packet reordering on the VPN performance and seems, again, untested hypothesis.


>
>I think we should refer to the above, and add relevant commentary. I'm
>happy to write a PR to do this. 


[SM] Why? Unless these theories and ideas are substantiated first, I do not think we should treat them as more than vague proposals of what might be fresearched,


>We also have the interesting design choice
>about having separate FQs for ECT(1). The aforementioned VPNs are one
>reason to do this. The other (possibly more common) reason is for hash
>collisions.


[SM] The more flows you have the likelier are hash collisions, so potentially doubling all flows with mixed ECT is IMHO not guaranteed to be an advantage... heck I question whether the idea of mixed markings inside a single flow is not too cute for its own sake, until somebody presents actual empirical evidence that this solves real issues.
(A VPN should not leak internal state like whether a given packet uses ECT1 or 0 and arguably not even where the  real packet boundaries are).


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


[SM] Aling which performance axis? And how to test this given, that upstream Linux still has neither tcp prague nor dualqueue if I understand correctly, nor accurate ECN...


>* Assessment of performance differences of FQ-PIE vs FQ-Codel, using and
>extending the hackathon work.
>
>Interested to hear working group thoughts on the above ideas.

>
>Chris

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.