Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 7. Example Use Cases

[Greg White <[e-mail]>]

Ok, since neither you nor I can be certain that the existing Security Considerations adequately cover 3GPP networks (or other SDOs), I can add a sentence to that effect. 

-Greg
 

On 10/10/23, 6:03 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Greg,


thanks for closing the "use case" headline issue.


Regarding security related to 3GPP, I'm not an expert either. Maybe adding a sentence that the security section doesn't discuss 3GPP related issues and favours a discussion there, if the suggested scheduling is adapted? Such a comment may apply as well for standards of all other SDOs, if preferred. Such a statement would cleanly delineate IETF responsibility from that of other SDOs. 


I note that draft NQB recommends implementation for several other SDOs by requirements language, but so far wasn't liaised with these SDOs. I'd prefer clarity on the topic "security of NQB operation if supported by standards of other SDOs", as the document extensively discusses support by other SDOs and does so by using requirements language. In particular, the security section should be explicit
- whether the IETF NQB security discussion covers the deployment of NQB within another SDO
- if not, please add an explicit statement that the security of deployment and operation of NQB is expected by an SDO set to specify support of NQB.


Regards,


Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Donnerstag, 31. August 2023 20:21
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 7. Example Use Cases


Hi Ruediger,


Per your suggestion, I will relabel section 7 as "Mapping NQB to standards of other SDOs".


Regarding cases where NQB is not supported, we already have the overall requirement (section 4.2) that NQB be aggregated with Default traffic, and in the Wi-Fi sub-section there is specific text around legacy W-Fi gear. In DOCSIS there is no inspection of the DSCP unless it is explicitly configured, so the default behavior aligns with section 4.2 already. I believe the same is true in 3GPP networks (but would welcome validation of that from someone more expert than I am).


Regarding the security discussion, that can be found in section 11, where it covers general concerns and also some specific ones that relate to Wi-Fi. I believe that the security considerations for DOCSIS are covered sufficiently by the general statements. Are you aware of specific security considerations for 3GPP? If so, please provide text to address the concerns that you have in mind.


-Greg








On 8/1/23, 4:49 AM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:




Hi Greg, hi chairs,




Section 7. Example Use Cases




This section doesn't contain example use cases. The section contains NQB mappings to standards of other SDOs and does so by requirement language. I'd like to offer two proposals to make progress:
- either keep the section title "Example Use Cases" and change content to example use cases.
- or keep the content and change the section title to reflect the content offered. Example: "Mapping NQB to standards of other SDO's" (inspired by "Mapping Diffserv to IEEE 802.11")




- I note that Section 7 only standardizes how to support NQB by standards of other SDOs. The draft so far does not specify how these SDO's should forward NQB marked traffic, if the NQB PHB is not supported.
- There's no or little security discussion of possible threats imposed if NQB mappings to standards of other SDO's are applied as specified by this draft. Please add these.




I address the chairs too, as I failed to find other RFCs applying extensive requirements language in a section named "Example Use Cases" when making a small sample of other RFCs. This may be usual practice, but I'm unfortunately not aware of it. I welcome guidance.




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: Mittwoch, 26. Juli 2023 19:08
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-19.txt








A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Transport Area Working Group (TSVWG) 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-19.txt Pages : 29 Date : 2023-07-26




Abstract:
This document specifies properties and characteristics of a Non- Queue-Building Per-Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best-effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, 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 microflows.




[NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.]




The IETF datatracker status page for this Internet-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-19.html <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html&gt;>




A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19&gt;>




Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts