Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022

[Greg White <[e-mail]>]

Ruediger,

See [GW3].

-Greg

From: "[e-mail]" <[e-mail]>
Date: Tuesday, November 29, 2022 at 1:52 AM
To: Greg White <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "David.Black=[e-mail]" <David.Black=[e-mail]>
Subject: AW: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022

Hi Greg,

To, a standards track document should indeed be precise, especially if it is standardizing a forwarding path including an unlimited priority scheduler (AC_VI). This is a clear purpose of draft NQB.

[GW3] No. This statement is completely incorrect. NQB does not standardize the use of a priority scheduler (and furthermore, AC_VI is not an unlimited priority scheduler anyway). Since many of your [RG2] comments were based on this erroneous statement, it probably isn’t necessary to respond to them.  There were a couple of points that were unrelated that I will respond to.



[snip]


[GW2] I was not basing this on 50% NQB (or L4S) and 50% Default on the Access Network. See what I wrote below.  I could include some text that describes the derivation of the 5% number.

[RG2]: Yes please, engineering guidance which allows for deduction of parameters under other circumstances than those assumed by a draft is a requirement for a standards track doc to me. Further, I miss an NQB draft text section specifying the typical access bandwidth for which deployment of NQB is recommended. From your response I take the access bandwidth for which you recommend NQB deployment to as a minimum to be “typically on the order of 100 Mbps”.

[GW3] The intent is not to freeze the definition in 2022, but to allow it to evolve as network capacity grows. But, for “today’s network” we’ll add a milepost that “typical” access network rates are on the order of 100 Mbps.   Section 5.3 then provides a recommendation around what you are looking for, but it is written in terms of when *not* to implement the PHB.


[GW] In addition to this text, I think that the text around appropriate sender behavior should indicate that the 1 Mbps limit is given in the context of today’s networks “where access network data rates are typically on the order of 100 Mbps” i.e. the upper limit is approximately 1% of “typical” access network speeds.  Thus, the shaper/policer rates above work out to ~5 simultaneous maximum-rate NQB streams on access network segments that are less than the “typical” rate, and more such streams on higher rate access network segments.

[RG] this latter text addresses burstiness of NQB traffic. This discussion is within another thread. I so far failed to have understood your ideas on burstiness. As I think, this topic is very important, if an application  traffic flow must be designed to avoid queue build up, we need to take the time to agree on text helping implentors to understand what’s expected (and operators to understand how they are supposed to configure NQB).

[GW2] In terms of an individual application, the draft says the data rate should not exceed “a small fraction of the expected path capacity on an instantaneous (e.g., inter-packet, or a suitably short time interval) basis”.  I had previously argued that this guidance was reasonable, even if it was imprecise (https://mailarchive.ietf.org/arch/msg/tsvwg/46k1oWi7xt_7OslKt8PIlAYjn8w/). But, I understand that you are not comfortable with the imprecision.  While the term “inter-packet” is precise and well understood, it can be too strict. The terms “small fraction of the expected path capacity” and “suitably short time interval” are not precise. The L4S dual-queue-coupled-AQM implementations in DOCSIS gear set the minimum CE-marking threshold at 4000 bytes, whereas the pseudocode in the dualQ draft defaults this to 1 MTU instead.  Perhaps we could limit the burstiness of NQB senders to 1500 bytes.

[RG2] All of these latter statements are irrelevant for readers of draft NQB, as long as the draft text doesn’t contain specifications and requirements expressing these recommendation. How should operators or app implementers learn that? Please add suitable text to the draft. I thought we had agreed on the definition of “non-queue-building” as provided by EF / Van Jacobsen version: the rate of the NQB access network scheduler MUST be above the rate of the incoming NQB traffic at any timescale. Please confirm that or indicate disagreement (or discuss, if required).

[GW3] What I had meant is that we would add a statement in NQB to describe the amount of burstiness that is allowed (I’m suggesting 1500 bytes).   Also, I definitely didn’t agree that NQB is equivalent to EF or that we would add a MUST statement as you wrote above.  Remember, the NQB PHB is not a guaranteed service, it is simply a shallow buffered best effort queue at the same priority as Default. It “aims to provide statistically better loss, latency and jitter performance” for traffic that complies to the sender requirements, and it “solely provides isolation for traffic classified as behaving in conformance with the NQB DSCP (and optionally enforces that behavior).”

[snip]

[GW3] At this point, I’d like to take some time to fold in the changes that have been discussed in this thread and produce an updated draft.