Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 4.2. Aggregation of the NQB DSCP with other Diffserv PHBs

[Greg White <[e-mail]>]

Thanks Ruediger,  responses below [GW].

On 2/3/23, 1:16 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Greg,


4.2. Aggregation of the NQB DSCP with other Diffserv PHBs


Last Para
Nodes that support the NQB PHB may choose to aggregate other service classes 
into the NQB queue....These could include Telephony (EF/VA), Signaling (CS5), 
Real-Time Interactive (CS4) and Broadcast Video (CS3). Or...[aggregates of] all 
traffic marked with DSCPs 40-47 (i.e., whose three MSBs are 0b101). 


https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification <https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification>
In addition, an operator could use other identifiers to classify certain additional 
packet types into the L queue that it deems will not risk harm to the L4S service, 
for instance, addresses of specific applications or hosts; specific Diffserv 
codepoints such as EF, Voice-Admit, or the Non-Queue-Building (NQB) per-hop 
behaviour; or certain protocols (e.g., ARP and DNS) (see Section 5.4.1 of [RFC9331].


a) the last paragraph of draft NQB section 4.2 describes which service classes may be forwarded by the NQB PHB, a content which a reader wouldn't expect with the headline "Aggregation of the NQB DSCP with other Diffserv PHBs". 

[GW] You are right. Most of that section covers carriage of the NQB DSCP in networks that don’t support the PHB, while the last paragraph covers aggregation of other DSCPs into the NQB PHB in a node that supports it.   These are opposite cases in a sense.  I'll add a subheading "4.3 Aggregation of other DSCPs in the NQB PHB" immediately before that last paragraph. That would make it easier for the reader to follow I think.

 

b) In this last paragraph, draft NQB adds the service classes Signaling (CS5), Real-Time Interactive (CS4) and Broadcast Video (CS3) as eligible to be forwarded by an NQB PHB, as compared to EF and Voice Admit only as specified by RFC9332. Please provide text explaining, why Signaling (CS5), Real-Time Interactive (CS4) and Broadcast Video (CS3) are not queue building in draft NQB (standards track), while they seem to be queue building in RFC9332 (experimental).

[GW] In both documents the lists are provided as examples, not as exhaustive lists, nor even directly as recommendations.  The RFC9332 sentence says "... an operator could ... classify ... into the L queue ... for instance ... Diffserv codepoints such as ...." So, if there are some differences in the chosen examples between the two documents I don't think it is a problem.  In NQB, I based the list of examples on the information provided in Figures 1, 2 & 3 of RFC 4594 in an attempt to be consistent with prior IETF guidance, though to be honest I personally think that document is rather dated at this point.  In the end, I think that a network operator would need to use their informed judgement in aggregating other DSCPs with either NQB or L4S traffic, rather than assuming that all traffic is DSCP marked according to the recommendations in RFC 4954.  To that end, I'm noticing that the paragraph in NQB starts off with "Nodes that support the NQB PHB may choose to ...". We probably shouldn't put that responsibility in the hands of the node itself.  It should be in the hands of the network operator to make this choice.  I will change that wording.   I could also add some more cautionary language that the operator would need to use their judgement as to which DSCPs are actually aggregated.  Would that address your concern?



I further note and take it for granted, that range based DSCP classification as a standards track DiffServ feature has been consented by the chairs.


Regards,


Ruediger






-----Ursprüngliche Nachricht-----
Von: tsvwg <[e-mail] <mailto:[e-mail]>> Im Auftrag von [e-mail] <mailto:[e-mail]>
Gesendet: Donnerstag, 12. Januar 2023 01:34
An: [e-mail] <mailto:[e-mail]>
Cc: [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/>


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>


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>




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