Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is) - MUST fail gracefully

[[e-mail]]

Hi Sebastian,

my understanding is (I'm not an author and may have to be corrected), that the draft
- addresses applications which aren't using a flow-control mechanism
- at the same time allows for flow-controlled applications being marked as NQB
- suggests a 1% access bandwidth and 1 Mbps per flow bandwidth bound (neither of these is a requirement, it's guidance)
- is designed for access to AC_VI on WiFi
- and will, in the case of congestion at the access, re-mark and re-schedule offending flows.

If I was to mark app traffic at a sender, I likely evaluate the risk I take marking app traffic NQB as compared to the gain. By now, the only particular behaviour to protect the overall ecosystem access & WiFi was to reclassify and schedule offending traffic as LE (which then REQUIRES an LE queue). I'd suggest the NQB authors to provide a more through analysis of undesired usage of NQB, where I'd be happy, if the access scheduler (QB/NQB schedulers and load scenarios), all WiFi scheduling options and transport properties were covered. So far, they didn't expose any interest and text given mainly describes the "all behave well" scenario. 

The DiffServ link design validations I do are based on one/all senders misbehave. I have a clear, standards and standard-design based understanding what has to happen then and based on that I am and was in the past able to solve all issues with vendors if results weren't as expected. I don't look at NQB with standard text as it is by now to allow for resolving issues with vendors. I think I'd have to put many things into writing to define a test (like specifying flow, specifying objectives to verify and so on), likely need to communicate all that to my vendors, expect them to implement the DT taste of NQB, all in a compatible way - I stop here. I regard this as unlikely. I, and I'd think implementers too, expect a standard to define all or most of that.







-----Ursprüngliche Nachricht-----
Von: Sebastian Moeller <[e-mail]> 
Gesendet: Donnerstag, 16. März 2023 10:57
An: Geib, Rüdiger <[e-mail]>
Cc: Greg White <[e-mail]>; [e-mail]
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is) - MUST fail gracefully

Hi Ruediger

I have a related question to one of your enumerated conditions below. I hope it is OK to ask in this thread

> On Mar 16, 2023, at 10:01, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Greg,
> 
> that's a first step. The draft still doesn't specify, what that means in terms of traffic conditioning and scheduling. As "traffic protection fails gracefully" isn't defined any closer, I must do assumptions in the following. If you pursue different aims, please add text, but don't argue with me for my assumptions.
> 
> I assume traffic protection stops operating (i.e. doesn't do anything). As it operated prior to that, there's neither an NQB rate policer nor an NQB rate shaper. 
> 
> The following situations may occur:
> - QB/NQB traffic present, no congestion - cool, should just continue to operate
> - QB/NQB traffic present, congestion and NQB below NQB rate - NQB should just continue to operate
> - QB/NQB traffic present, congestion and NQB above NQB rate - ? The draft doesn't specify how an NQB conformant scheduler works under this operational condition. Traffic protection now doesn't reclassify traffic, does it? If it still does, how does it pick NQB packets to be reclassified, remarked and re-scheduled?

	[SM] So the guidance on what traffic rates are acceptable to label NQB are really weak, a prudent sender hence would try to watch for unambiguous signs of congestion and reduce the sending rate accordingly. E.g. the draft gives 1 Mbps as acceptable per NQB application sending rate* which for quite a number of links even in a developed country like Germany is well above the 1% limit as according to Ookla in February 2023 the _average_ rate for german speedtests was  Download
83.20 Mbps Upload 28.75 Mbps..., so one percent only give 0.8/0.3 Mbps (the assumed 100/100 Mbps symmetric access link seems optimistic).
	As an application developer when faced with such uncertainty, I would try to estimate somehow whether my current sending rate** is within the actual network path's capacity. To do so I would need unambiguous feed-back of the acceptable rate being exceeded. I now argue that EF's strict rate limiter is one predictable way to give such feedback, while the proposed NQB system does not. For the following reaons:
a) NQB traffic will get 100% of capacity if there is no QB traffic (so any capacity estimate during such a period would be wrong for the acceptable NQB share under load)
b) the proposed option to "re-sort offending packets/flows" to QB will make it essentially impossible to reliably and quickly figure out whether my flow exceeded its "welcome". (Having to monitor drops, per-packet delay and potential re-orderings to deduce "capacity share exceeded" conditions might be theoretically possible but that looks neither fast nor reliable).

So from a perspective of responsible NQB senders that actually want to do he right thing during run-time, the proposed soft-limited NQB/QB sharing behavior seems sub-optimal. A strict capacity limit as in EF is considerably easier to reason about for an application as it gives much tighter feed-back (the acceptable capacity share still depends on dynamic variables like how much other NQB packets hit the queue, but at least there now is a theoretical upper limit that is useful and a feed-back path if even the dynamic capacity share is exceeded).

So how are NQB using applications supposed to figure out which rate is acceptable? The current guidance in the draft is quite general and seems aimed at figuring out whether an application is at all eligible to use NQB (e.g. a 600Kbps CBR rate video stream might, a 25Mbps 4K HD VBR video stream probably does not), but says little on what to do at run-time.

Regards
	Sebastian


*) This is a rate that already allows for non-HD video conferencing according to the listed rate requirements for e.g. zoom or skype. Given that the draft should add explicit guidance whether such streams are considered NQB eligible or not.
**) Even a fixed rate sending application has the option, a) informing the user that it exceeds capacity and hence needs to stop, or b) stop marking itself as NQB and accept the highe potential jitter for QB c) switch back to a lower data rate even if that reduces the application fidelity/utility***. These might not be attractive option, but options they are.
***) E.g. it might still be better for a temperature measurement device t give updates every X ideal sampling periods than "never".


> 
> Regards,
> 
> Ruediger
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Greg White <[e-mail]> 
> Gesendet: Donnerstag, 16. März 2023 00:20
> An: Geib, Rüdiger <[e-mail]>
> Cc: [e-mail]
> Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is) - MUST fail gracefully
> 
> Hi Ruediger,
> 
> I notice that RFC2475 has a statement: 
> 
>   Robustness concerns dictate that the
>   arrival of packets with unacceptable DS codepoints must not cause the
>   failure (e.g., crash) of network nodes.
> 
> Would you agree with changing the requirement in NQB to say:
> 
> "The traffic protection function MUST be designed such that the node implementing the NQB PHB does not fail (e.g. crash) in the case that the flow state is exhausted."
> 
> 
> -Greg
> 
> 
> 
> 
> On 3/15/23, 4:02 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> [RG] I suggest that you as the editor of draft NQB provide text specifying how an NQB traffic protection fails gracefully, if flow state exhausts, so that I as a reader interested in implementation can put verifiable requirements on this part of NQB functionality when I ask a vendor for implementation.
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Greg White <[e-mail] <mailto:[e-mail]>> 
> Gesendet: Sonntag, 12. März 2023 01:05
> An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is)
> 
> 
> See [GW].
> 
> 
> On 2/3/23, 1:17 AM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> 
> 
> <snip>
> 
> 
> - draft: The traffic protection function MUST be designed to fail gracefully in the case that the flow state is exhausted.
> 
> 
> 
> 
> I’m surprised to find a MUST here, while the major part of the queue protection mechanism isn’t specified. But to me, this requirement is vague too, as the draft doesn’t specify what is meant by “failing gracefully, if flow state is exhausted”.
> 
> 
> [GW] What would you suggest?
> 
> 
> 
> 
> Regards,
> 
> 
> 
> 
> Ruediger
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: tsvwg <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> Im Auftrag von [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> Gesendet: Donnerstag, 12. Januar 2023 01:34
> An: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-15.txt
> 
> 
> 
> 
> 
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
> 
> 
> 
> 
> Title : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services Authors : Greg White Thomas Fossati Filename : draft-ietf-tsvwg-nqb-15.txt Pages : 25 Date : 2023-01-11
> 
> 
> 
> 
> Abstract:
> This document specifies properties and characteristics of a Non- Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB PHB is to provide a separate queue that enables smooth, low-data- rate, application-limited traffic flows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building flows.
> 
> 
> 
> 
> 
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;>
> 
> 
> 
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html&gt;>
> 
> 
> 
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15&gt;>
> 
> 
> 
> 
> 
> 
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>