Subject: [tsvwg] New Version Notification for draft-white-tsvwg-nqb-01.txt

From: Greg White <[email-masked]>
Date: Mon, 11 Mar 2019 23:22:02 +0000

TSVWG,

I posted an update to the draft on Non-Queue-Building flows.  I have changed the intended status to Standards Track, and have updated the language accordingly (i.e. this is now a proposal for the definition of a PHB and DSCP).

I considered all of the comments on the mailing list, and made a number of updates.  I did not make all of the suggested changes.  In particular Dave Taht had suggested some modifications to this paragraph:

Flow queueing approaches (such as fq_codel RFC8290 [RFC 8290]), on the other hand, achieve latency improvements by associating packets into "flow" queues and then prioritizing "sparse flows", i.e. packets that arrive to an empty flow queue. Flow queueing does not attempt to differentiate between flows on the basis of value (importance or latency-sensitivity), it simply gives preference to sparse flows, and tries to guarantee that the non-sparse flows all get an equal share of the remaining channel capacity.  As a result, fq mechanisms could be considered more appropriate for unmanaged environments and general internet traffic.

1) He had suggested replacing “associating packets into "flow" queues” with “breaking flows back into individual packets”.  Frankly, I don’t understand what this means.  I didn't make this change, since I actually don’t think it helps the reader understand fq_codel.  Maybe with more context it makes sense, e.g. describing the behavior to someone who already understands fq_codel, or as some kind of outcome of the flow hashing and scheduling, but as *the* one sentence definition, it didn't seem to work.  

2) He'd suggested changing “i.e. packets that arrive to an empty flow queue.” to “i.e. packets that arrive to an empty flow queue that empties every round.”  The draft does contain that detail a couple of paragraphs later, after a little bit more context has been provided. “In fq_codel, a flow queue is considered sparse if it is drained completely by each packet transmission, and remains empty for at least one cycle of the round robin over the active flows (this is approximately equivalent to saying that it utilizes less than its fair share of capacity).”  So, I felt as if this one was already covered.

3) He’d suggested changing “gives preference to sparse flows” to “giving a slight preference to sparse flows.”  The fq_codel RFC is pretty clear that sparse (new) flows are given strict priority over non-sparse (old) flows.  So, saying “a slight preference” seems disingenuous.    I’m going to stand by my original wording there too.

4) He’d suggested changing “and tries to guarantee that the non-sparse flows all get an equal share of the remaining channel capacity” to “interleaves flows as best as possible”.  I didn't delete the fair scheduling part, but the interleaving part was a useful addition.  I changed it to: “and tries to guarantee that the non-sparse flows all get an equal share of the remaining channel capacity and are interleaved with one another”

-Greg

On 3/11/19, 4:59 PM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-white-tsvwg-nqb-01.txt
    has been successfully submitted by Greg White and posted to the
    IETF repository.
    
    Name:		draft-white-tsvwg-nqb
    Revision:	01
    Title:		Identifying and Handling Non Queue Building Flows in a Bottleneck Link
    Document date:	2019-03-11
    Group:		Individual Submission
    Pages:		9
    URL:            https://www.ietf.org/internet-drafts/draft-white-tsvwg-nqb-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-white-tsvwg-nqb/
    Htmlized:       https://tools.ietf.org/html/draft-white-tsvwg-nqb-01
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-white-tsvwg-nqb
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-white-tsvwg-nqb-01
    
    Abstract:
       This draft proposes the definition of a standardized DSCP to identify
       Non-Queue-Building flows, along with a Per-Hop-Behavior (PHB) that
       provides a separate queue for such flows.

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat