Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1. Primary Requirements

[[e-mail]]

Hi Greg,

thanks, ok.

Regards,

Ruediger

Von: Greg White <[e-mail]>
Gesendet: Donnerstag, 31. August 2023 19:55
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1. Primary Requirements

Hi Ruediger,

These suggestions are constructive and will make those sentences clearer. That said, the current text was not providing guidance on default buffer sizing, but was simply making an observation about common practice. I think the observation is still helpful here, but I will reword it so that it isn’t confused as being guidance.  I will wordsmith your other suggestions a bit before including them as well.  How about we provide the context first, and then the requirements?

Support for the NQB PHB is advantageous at bottleneck nodes. Many bottleneck nodes have a relatively deep buffer for Default traffic (e.g., roughly equal to the base RTT of the expected connections, which could be tens or hundreds of ms).  Providing a similarly deep buffer for the NQB queue would be at cross purposes to providing very low queueing delay and would erode the incentives for QB traffic to be marked correctly at such a bottleneck node.  The NQB queue SHOULD have a buffer size that is significantly smaller than the buffer provided for Default traffic. It is RECOMMENDED to configure an NQB buffer size less than or equal to 10 ms at the shared NQB/Default egress rate.

What do you think?

-Greg




From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, August 1, 2023 at 4:29 AM
To: Greg White <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: AW: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - 5.1. Primary Requirements

Hi Greg,

it proved to be best to read the latest version and then comment issue by issue. Let’s start this round by 5.1.  Primary Requirements.

Regards,

Ruediger

#########


5.1.  Primary Requirements

OLD
It is expected that most Default traffic is engineered to work well when the network provides a relatively deep buffer (e.g., on the order of tens or hundreds of ms) in nodes where support for the NQB PHB is advantageous (i.e., bottleneck nodes).

An NQB buffer size less than or equal to 10 ms is RECOMMENDED.

CHANGE
The NQB queue SHOULD have a buffer size that is significantly smaller than the buffer provided for Default traffic. It is expected that most Default traffic is engineered to work well when the network provides a relatively deep buffer (e.g., roughly equal to the base RTT of the connection, which could be tens or hundreds of ms) in nodes where support for the NQB PHB is advantageous (i.e., bottleneck nodes). Providing a similarly deep buffer for the NQB queue would be at cross purposes to providing very low queueing delay and would erode the incentives for QB traffic to be marked correctly. An NQB buffer size less than or equal to 10 ms is RECOMMENDED.

NEW
The NQB queue SHOULD have a buffer size that is significantly smaller than the buffer provided for Default traffic. Support for the NQB PHB is advantageous at bottleneck nodes. Providing a similarly deep buffer for the NQB and Default queue would be at cross purposes to providing very low queueing delay and would erode the incentives for QB traffic to be marked correctly at such a bottleneck node. It is RECOMMENDED to configure an NQB buffer size less than or equal to 10 ms assuming operation at the same dequeue-bandwidth applied to dimension the Default traffic buffer at such a bottleneck node.

Discussion
...in nodes where support for the NQB PHB is nodes is advantageous (i.e., bottleneck nodes). – That sounds winding to me, if it should express that “Support for the NQB PHB is advantageous at bottleneck nodes.”

Buffer-dimensioning in units of time is pointless without a reference bit rate. Text as is

-          Discusses dimensioning of Default buffers – as this is a standards track doc, I’d prefer it to stay away from a Default buffer dimensioning guidance. Text should focus on NQB.

-          AFAIK, the presence or absence of some AQM impacts the required QB/Default buffer depth, which isn’t discussed by the text as is (to me an additional reason not to discuss Default buffer depth config within draft NQB).

-          Mentions both, Default and NQB buffer depths in [ms] without informing the reader about a dequeue-bandwidth assumption, which is to be applied to derive the buffer depth (which is [Byte] on hardware). I expect a standards track doc to be clear about the assumptions upon which it’s dimensioning rules are based.