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

[[e-mail]]

Hi Greg,

sorry, I had to deal with other issues.

[GW] In many systems (including DOCSIS, WiFi, 3GPP & (to my knowledge) PON), Default traffic is not given a guaranteed departure rate, so 50% of a non-guaranteed value is also a non-guaranteed value. In these systems, a stds compliant NQB PHB will differ considerably from a stds compliant EF PHB.

RG: Which PHB behaviour is experienced by NQB traffic if specialized PHBs for these other service classes are not configured by an operator in the above cases?

Regards,

Ruediger


Von: Greg White <[e-mail]>
Gesendet: Mittwoch, 12. April 2023 01:50
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, Forwarding - Departure rate

Hi Ruediger,

As I wrote below, I had misunderstood your earlier question. So, my 6 April response probably wasn’t helpful.  I thought I had explained it better in the 7 April response below. Why not quote that response?  The draft provides 50/50 DRR as a compliant example of a scheduler between Default and NQB.

In many systems (including DOCSIS, WiFi, 3GPP & (to my knowledge) PON), Default traffic is not given a guaranteed departure rate, so 50% of a non-guaranteed value is also a non-guaranteed value. In these systems, a stds compliant NQB PHB will differ considerably from a stds compliant EF PHB.

It sounds to me like the one change that we agree on is to add a clearer statement that the two queues (NQB and Default) share the same overall resources.  I will add this to the issues tracker.

-Greg


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 11, 2023 at 4:16 AM
To: Greg White <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: AW: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, Forwarding - Departure rate

Hi Greg,

also I perceive this exchange to be a bit difficult. I’ve asked for a comparison of NQB with EF/2598:


[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.



Getting me



[GW] 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.



And after I ask you, to please explain how [a] WRR scheduler is configured to support straight NQB/QB without L4S being configured, then



[GW] It [RG: the WRR scheduler weight] can be set to whatever ratio the network operator chooses (e.g. 50/50) in the case that L4S support is disabled.



Good. Do you want to say, under no expectable operational circumstances, this NQB WRR weight will ever translate to “a configurable departure rate”? The conventional wisdom that I am aware of is

-          Rate-limit Priority queues (which will leave capacity for other queues)

-          Assign a minimum bandwidth to the default queue (to avoid, e.g., starvation of DNS)

I however can imagine an access scheduler just or mainly to offer default forwarding. Would you classify the latter as “fiction”?



Could kindly explain what you mean by “NQB PHB does not have a configurable departure rate” ? I’d like to understand how NQB is configured and operated and your (unfortunately undocumented) assumptions seem to deviate significantly from mine. I’d expect a Standards Track doc to be relevant for the Internet as a whole, not for a particular environment (unless it is clearly specified for such a particular environment).



My understanding is, that the NQB PHB at least very likely has access to dedicated resources. If this is an unlikely or unsuitable operational environment for an NQB deployment, please add text.



Regards,



Ruediger


Von: Greg White <[e-mail]<mailto:[e-mail]>>
Gesendet: Freitag, 7. April 2023 20:12
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 - Departure rate

Hi Ruediger,

Apologies, sometimes it is difficult for me to understand whether you are asking me to explain to you (and the WG) a particular item, or whether you are asking me to introduce new/changed text in the draft to explain that item.

So, the draft currently says:  “The NQB queue SHOULD be given equivalent forwarding preference compared to Default. The node SHOULD provide a scheduler that allows NQB and Default traffic to share the link in a fair manner, e.g., a deficit round-robin scheduler with equal weights.”

I think this covers most of what you are asking for.  Note that up until draft-06 we did use the phrase “equal priority” but changed it to “equivalent forwarding preference” based on input from one of the DiffServ experts in the WG.

We’ve left these statements a bit flexible in part because “fairness” is in the eye of the beholder.  While 50/50 DRR (WRR) is considered fair in one sense (bandwidth share between the two classes), NQB flows are intended to be sparse, low-data-rate, non-capacity-seeking flows (each less than 1% of the link capacity), so I think it is a little less clear what fairness means between that class of application and the (e.g.) capacity-seeking applications in the Default queue. That said, I am comfortable with 50/50 DRR as being the referenced algorithm.  But, Sebastian has recently reminded us that WRR isn’t per-flow fair unless the ratio of flow counts just happens to be equal to the ratio of weights. I don’t like the idea of forbidding an implementer to implement something like AFQ if they prefer something closer to per-flow fairness.  The guidance “share the link in a fair manner” (along with the example of 50/50 DRR) seems to me to be an ok way to say this.

Also, in the end there could be a wide range of scheduler implementations that produce nearly identical results when things are operating as planned (e.g. the NQB-marked flows are all compliant to the sender requirements, and there isn’t an overwhelming number of them), so the situations where it does matter (overload of some kind, non-compliant NQB-marked flows, etc.) are also the situations where the traffic protection mechanism is involved in determining the outcome.   I’ve argued (and I think you’ve agreed) that mandating a specific traffic protection algorithm isn’t what we want to do here, so I think we similarly need to leave implementation flexibility around the scheduler choice so that an implementer can choose a scheduler that works well with their traffic protection algorithm.

I sense that you and I have different views on how proscriptive an IETF RFC needs to be.  I think it is a benefit to allow implementers to make some decisions about the details as long as they comply with a necessary set of requirements. I think this is aligned with many of the DiffServ RFCs which describe the expected behavioral requirements in fairly high level terms, and leave the details open for some variation between implementations.

In my response about “whatever” ratio, I was again responding to your question, not proposing that the draft include text along those lines.  Even so, in re-reading what I wrote, I probably should have said it differently.  The scheduling weight in DOCSIS can be set to whatever ratio the network operator chooses, i.e. the equipment does not enforce any limitations*.  The default is 90/10 (and L4S is enabled). In the case that L4S support is disabled, it could be set to 50/50 (this would align with the recommendation in the draft).
*The scheduling weight could also be used to configure non-L4S-related or non-NQB-related bandwidth sharing between two queues.

From your list of items below, maybe what we are missing in the draft is a clearer statement that the two queues share the same overall resources.  This is what the statement “A node supporting the NQB PHB SHOULD NOT rate limit or rate police the aggregate of NQB traffic separately from Default traffic.”  was intended to mean, but it doesn’t say that very clearly.

Greg




From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, April 6, 2023 at 12:24 AM
To: Greg White <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: AW: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, Forwarding - Departure rate


Hi Greg,



draft NQB is on standards track. Please specify the weights to be set for NQB and QB scheduler by requirements:

- some generic text, not based on any implementation (which I think is roughly there). I'd appreciate text stating that QB/NQB share the same overall resources, are configured by the same priority, weight (or minimum departure rate) and also are equipped by the same priority and weight to access spare capacity. There's some text in the draft, but it is not very precise.


- to that a clarification related to your response: you write
[GW] It can be set to whatever ratio the network operator chooses (e.g. 50/50) in the case that L4S support is disabled.
Please clarify "whatever" in the sense of standard track NQB: which range of NQB/QB WRR weight configurations is compliant with this draft standard? My perception was exactly 50/50, but "whatever" seems to allow for arbitrary configurations.



- I'd strongly suggest that you provide an example traceable for a fair share of readers, which from my perception is good practice of other RFC authors. You reference the DOCSIS L4S implementation, a WRR scheduler with 50/50 weights (and the same for access to spare capacity) seem good to me.



Regards,



Ruediger





-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]<mailto:[e-mail]>>
Gesendet: Donnerstag, 6. April 2023 01:57
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 - Departure rate



Hi Ruediger,

See my responses below [GW].

-Greg



On 4/5/23, 6:12 AM, "[e-mail] <mailto:[e-mail]><mailto:[e-mail]%20%3cmailto:[e-mail]%3e>" <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[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]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

Gesendet: Freitag, 24. März 2023 21:24

An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

Cc: [e-mail]<mailto:[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>