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

[[e-mail]]

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?

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