Re: [iccrg] Will Fair Queuing change Congestion Control?

[Maximilian Bachl <[e-mail]>]

Hi Vidhi,

Thank you for your comments!

Few things to note, FQ expands to Flow Queue (not fair queueing) which
> means every flow (4 tuple) has a different queue. Priorities are
> implemented based on service classes, for example. Also, Apple devices are
> not the most common bottleneck on an end to end path.

I assumed "flow queuing" and "fair queueing" to be mostly synonymous, as
for example the fq_codel manual page in Linux calls it “fair queuing” (
https://man.archlinux.org/man/tc-fq_codel.8.en). To clarify, what I meant
is “flow queuing”.

Even if we assume there is enough deployment of flow queueing in the
> network, flows can hurt themselves by not responding to growing latency.
> This problem has been addressed in L4S drafts and I highly recommend
> reading them.

Endpoints could use delay-minimizing congestion control if they could be
certain that fair queuing is deployed at the bottleneck of a path. Thus, I
think they wouldn’t necessarily hurt themselves.

ECN combined with an immediate AQM combined with Prague congestion control
> is basically the idea of L4S.

I think that L4S can improve how congestion control is done. However, from
what I understand, it doesn't necessarily isolate flows. Thus a bad faith
actor could get an unfairly large share of bandwidth, which couldn't happen
when FQ were deployed. With FQ being deployed on a path, each flow could
also choose its own congestion control and whether it wants to prioritize
low delay or maximum throughput. That's why I think that exciting
possibilities open up when more vendors deploy FQ like Apple did.

Regards,
Max

On Tue 3. Jan 2023 at 20:45, Vidhi Goel <[e-mail]> wrote:

> Hello Max,
>
>
> Few things to note, FQ expands to Flow Queue (not fair queueing) which
> means every flow (4 tuple) has a different queue. Priorities are
> implemented based on service classes, for example. Also, Apple devices are
> not the most common bottleneck on an end to end path.
>
> Even if we assume there is enough deployment of flow queueing in the
> network, flows can hurt themselves by not responding to growing latency.
> This problem has been addressed in L4S drafts and I highly recommend
> reading them. ECN combined with an immediate AQM combined with Prague
> congestion control is basically the idea of L4S.
>
> Vidhi
>
> On Jan 3, 2023, at 9:20 AM, Maximilian Bachl <[e-mail]>
> wrote:
>
> Apple introduced fair queuing (FQ) on more than a *billion of devices* in
> the last years (https://blog.cerowrt.org/post/state_of_fq_codel/). I
> wonder if this could have an impact on congestion control. When there’s
> fair queuing at the bottleneck link of a path, the endpoints can use *delay-minimizing
> congestion control* and don’t have to worry about more aggressive
> senders.
>
> However, currently, there’s *no established mechanism* for endpoints to
> know of the *existence of fair queuing* on a path. There are some
> possibilities, though, how endpoints can be made aware of the existence of
> fair queuing:
>
>    - A *dedicated bit* in some packet header. For example, some ECN or
>    DSCP bits could be repurposed to indicate the existence of fair queuing at
>    the bottleneck. Drawback: It’s hard to convince people to
>    repurpose/introduce new bits and switches/routers have to support it.
>    - An *end-host-based mechanism* to detect fair queuing without the
>    involvement of switches/routers. I created a proof-of-concept
>    implementation of such a mechanism, which can detect the presence/absence
>    of fair queuing with an accuracy of > 95% (
>    https://arxiv.org/abs/2206.10561).
>    - *Closed ecosystems* in which all components are aware that there is
>    fair queuing: As a hypothetical example, let’s assume a user plays a game
>    on nvidia’s cloud-gaming platform on an iPhone. The phone is connected to
>    T-Mobile’s 5G network. Both the client on the iPhone as well as the server
>    in nvidia’s network know that there’s fair queuing on the path between the
>    client and the server, since they have an agreement with T-Mobile, which
>    controls the entire path. No extra bits in packet headers are needed, just
>    mutual agreement between the user’s device, the cellular network provider
>    as well as the server on the internet.
>
>
> If you have some opinions on whether fair queuing is going to change how
> we do congestion control, I’d be curious.
>
> Regards,
> Max
>
> _______________________________________________
> iccrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/iccrg
>
>
>