[tsvwg] Re: New Version Notification for draft-tahiliani-tsvwg-fq-pie-00.txt

["Mohit P. Tahiliani" <[e-mail]>]

Hi Sebastian,

Thanks for the email.

I have replied inline below:

On Tue, Mar 11, 2025 at 11:50 PM Sebastian Moeller <moeller0=
[e-mail]> wrote:

> Hi Mohit,
>
>
> thanks. I like this, short and sweet. I do have a question though
> (probably easy to answer) abgout the following section:
>

Thank you for the feedback and the question.


> Lastly, if an incoming packet arrives when the total number of enqueued
> packets has already saturated the queue capacity, FQ-PIE drops the packet
> without further processing. In contrast, FQ-CoDel identifies the queue with
> the largest current byte count (i.e., a "fat flow") when the queue capacity
> is saturated and drops half of the packets from this queue (up to a maximum
> of 64 packets, as specified in Section 4.1 of [RFC8290]). FQ-PIE does not
> adopt this approach for the reasons explained below.
>
> One thing that fq_codel but als DualQ seem to do on overload is take a big
> shovel instead of a scalpel. So while I have no idea which packets to drop,
> maybe doing a bit more than "close the queue for new comers" might be in
> order. Especially since together with ECN there is the potential for an
> unresponsive flow to fill the queue without feeling the "pain" for doing
> so? Yes, mischievous adversarial traffic might not be a target to optimize
> for, but I wonder how the drop only on enqueue can ever be safe with ECN?
>

I believe the enhancement outlined in Section 5.1 of RFC 8033 (
https://datatracker.ietf.org/doc/html/rfc8033#section-5.1) may address this
situation. It states that "if the calculated drop probability exceeds
mark_ecnth, PIE reverts to packet-dropping for ECN-capable packets. The
variable mark_ecnth SHOULD be set to 0.1 (10%)". Both the Linux and ns-3
implementations of PIE currently follow this approach.

Let me know your thoughts.

Thanks and Regards,
Mohit P. Tahiliani