Re: [tsvwg] Comments on draft-white-tsvwg-nqb-02

[Kyle Rose <[e-mail]>]

On Fri, Sep 13, 2019 at 11:49 AM Bless, Roland (TM) <[e-mail]>
wrote:

>
>    - I find the whole term "non-queue building flows" a bit confusing.
>    What the draft actually means are application-limited, mostly low data
>    rate
>    flows (sparse flows in RFC8290). According to the draft, capacity
>    seeking
>    flows seem to *always* be queue building.
>
> I have had the same concern about the terminology. I'm wondering if "NQB"
is a term of art that isn't intended to be interpreted literally. As you
point out below, a tiny additional flow to a saturated link can cause a
queue to start building, which makes me question whether "queue building"
is really the right description at all. It seems the draft is trying to
classify flows merely according to sender behavior when it's not clear how
useful that will be as a tool in preventing queue buildup in bottlenecks of
varying size and with varying traffic profiles.

Comparing BBR with Reno, the latter will tend toward full queues while the
former will oscillate around a small queue, and yet both are
capacity-seeking. The draft classifies BBR flows as QB. Should they be? If
so, what actually constitutes queue-building? BBR builds a small queue to
probe for capacity but backs off quickly in response to increased latency.
Does minuscule transient queue-building like this (with the intent to keep
queues small) really qualify as QB? Why should they be stuck in the same
queue with Reno flows, when from a latency and queue-building standpoint
they are more like the flows described in the draft as NQB (and in some
cases better, since they'll actually be able to back off, unlike
fixed-bandwidth flows).


>    - It's not clear to me how the service rates between the NQB and QB
>    queue
>    are distributed by the scheduler. From the description in the draft, I
>    have
>    no clue what kind of scheduler would be a good fit for the desired
>    behavior.
>
> ...

>
>    1. "NQB traffic is not rate limited or rate policed." what happens if
>    the load in the
>    NQB queue increases (e.g., not by queue building flows)? Will QB flows
>    be starved?
>    I think that some scheduler will determine the rate share between
>    NQB/QB queues...
>
> ...

>
>    1. "it places unnecessary restrictions on the scheduling between the
>    two queues"
>    so what is the requirement for your own approach then?
>
> Good questions related to some of my main concerns related to the L4S,
SCE, and FQ debate.

When a link is close to saturated, FQ policy allocates an equal share of
available capacity to all non-sparse flows/buckets, preventing a subset of
flows from starving the rest via aggressive capacity-seeking behavior. This
clearly isn't ideal in every circumstance, but what's an
application-oblivious alternative that is? I want someone to explain how a
bottleneck is supposed to divide capacity on a saturated link between (say)
file downloads and videoconferencing without knowing what either of those
flows contain. An oracle might give priority to video and treat the file
download as best-effort, but that's a policy choice as much as one in which
the user is willing to sacrifice video quality by forcing the application
to downgrade encoding bitrate so their download completes more quickly.

Whether we like it or not, there is no knob-free QoS even with huge pipes.
This draft must attempt to identify and address relevant policy
considerations at bottlenecks.

Kyle