Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, Forwarding - Departure rate

[Greg White <[e-mail]>]

Hi Ruediger,
See my responses below [GW].
-Greg

On 4/5/23, 6:12 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:
Hi Greg,

Section "7.7.3.2 Inter-SF Scheduler" of CM-SP-MULPIv3.1-I24-221019 contains the following statement:

coupling .... the Classic Service Flow to the Low Latency Service Flow, it relies on the Inter-SF Scheduler to balance this. Weighted Round Robin (WRR) is a simple scheduler that achieves the desired results, and is recommended in [draft-ietf-tsvwg-aqm-dualq-coupled].

The above text covers L4S, not straight NQB.
- Please explain how this WRR scheduler is configured to support straight NQB/QB without L4S being configured. 
[GW] The WRR in DOCSIS has a configurable weight.  It can be set to whatever ratio the network operator chooses (e.g. 50/50) in the case that L4S support is disabled. 

- If there's no WRR scheduler, then please explain how an implementer ensures that NQB and QB fairly share the same resource, while each operate with separate queues. I'm especially interested in the part "no configurable service rate/weight etc." for the NQB queue. An example is sufficient, maybe one including a WRR scheduler, if applicable.
[GW] Aside from WRR mentioned above, perhaps a TS-FIFO could be used?  I have to admit that I've not thought about other scheduler options extensively.

- if WRR can't be used to realise separate NQB/QB queues for an implementation, please let me know, why this isn't possible.

Regards,
Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Freitag, 24. März 2023 21:24
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, Forwarding


Hi Ruediger,


FYI I've added an issue in the GitHub tracker to ensure this gets resolved.
https://github.com/gwhiteCL/NQBdraft/issues/32 <https://github.com/gwhiteCL/NQBdraft/issues/32>




I'll try to answer your question.


[RFC2598]: The EF PHB is defined as a forwarding treatment for a particular
diffserv aggregate where the departure rate of the aggregate's
packets from any diffserv node must equal or exceed a configurable
rate. The EF traffic SHOULD receive this rate independent of the
intensity of any other traffic attempting to transit the node. It
SHOULD average at least the configured rate when measured over any
time interval equal to or longer than the time it takes to send an
output link MTU sized packet at the configured rate. (Behavior at
time scales shorter than a packet time at the configured rate is
deliberately not specified.) The configured minimum rate MUST be
settable by a network administrator (using whatever mechanism the
node supports for non-volatile configuration).


[NQB]: ... the NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best-effort service. ... A node supporting the NQB PHB makes no guarantees on latency or data rate for NQB-marked flows, but instead aims to provide an upper-bound to queuing delay for as many such marked flows as it can and shed load when needed.


So, NQB PHB does not have a configurable departure rate, nor does it guarantee that NQB traffic will receive any particular departure rate, regardless of the presence of other traffic of any intensity.


<snip>