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

Kyle Rose <> Mon, 16 September 2019 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1E6212003E for <>; Mon, 16 Sep 2019 11:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QAYFjtTAH-jc for <>; Mon, 16 Sep 2019 11:06:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E272212000F for <>; Mon, 16 Sep 2019 11:06:12 -0700 (PDT)
Received: by with SMTP id z2so365973ybp.9 for <>; Mon, 16 Sep 2019 11:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s3X7AkQfFD7dCD+YiyBRT0edhQQ68CXXTIetuOhFio8=; b=Mtf73fbjvmwGqTgDxtCfIKUdtkOvwjzZ1UlK0S8Md3D75/GNMmaCF06xQk4I4rlJFA TQAMmumtu5HCqMmhBLo1+TDrHsQFCohxOEsLX4i7Ozz7p28fCTlQVK0PCpMSR3U+sskR t5cSOEOJE8HLTQlJSEJ0oIMiWBZqxxdZVagTo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s3X7AkQfFD7dCD+YiyBRT0edhQQ68CXXTIetuOhFio8=; b=qbP1mhaL/CKfYnZofO8R6cqstreIN+E1CNyzqWxKoIZnczj7jUt2j+/l1xVMHyLVWD Ay2Xj8360/5zuhGFD0UDOkHEUda1dCa45HEoec7ZZiiRMHXGyMuV+mds3F5L193LlcK/ o7Vvw5Q9wlYDIhIH9YP/blVChjJzEykKjcyEF01h9AlPY9AXtm/y1sNe0trYC8LAv1hc tDxanMXRiLswZNGhml/5ZnXdw+dHvVnmT8wkf6umUgo3aGd/t5FgpP6KfQH82JfGUjXL j5J3tC7TNN2s8nhleBrIdv8pDmPOWMXjxhmL9Qg0PJauV1xWz8a+8UwJyQv3L2xC+Koa pjrw==
X-Gm-Message-State: APjAAAWw5lxJzVgafVIB4+Mi5SemG+XZQuF0nNhH734K65roJGBNeRCo 169ZB3cciLoTjNGaE1DT+agVkW0hUWlqx8ABo3PrHA==
X-Google-Smtp-Source: APXvYqzKcIHXnoR0ukd+UgDQ+j7/VDCDzHG4+vDZ0KrHT4nmh6zcxvOWxcwRLvfeLfbgWRa7cqMowqPGTa0XNlADVAE=
X-Received: by 2002:a25:b5c2:: with SMTP id d2mr467554ybg.82.1568657171059; Mon, 16 Sep 2019 11:06:11 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Mon, 16 Sep 2019 14:06:00 -0400
Message-ID: <>
To: "Bless, Roland (TM)" <>
Cc: "" <>, Greg White <>
Content-Type: multipart/alternative; boundary="00000000000074aad40592af753b"
Archived-At: <>
Subject: Re: [tsvwg] Comments on draft-white-tsvwg-nqb-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Sep 2019 18:06:16 -0000

On Fri, Sep 13, 2019 at 11:49 AM Bless, Roland (TM) <>

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