Re: [tsvwg] NQB PHB description and assumptions

[Greg White <[e-mail]>]

Hi Ruediger,

These are good suggestions for improvement of the draft.

Thanks,
Greg



From: tsvwg <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Friday, September 6, 2019 at 1:13 AM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [tsvwg] NQB PHB description and assumptions

Hi Bob,

the following excerpt of your reply to David and Sebastian contains text for which I couldn’t identify a clear reference in the NQB draft. You ask the authors of that draft to add a description of the scheduling. I agree with you and like to expand that to a description of the PHB so that a reader has an idea about how to implement or configure a NQB PHB beside the default PHB.

What the NQB draft doesn’t mention, but you do:

-          You state NQB doesn’t require priority queuing (the NQB draft suggests to operate EF and NQB via the same queue with DSCPs 101110 for EF and 101010 for NQB, which to me means, it’s traffic destined to a priority queue).

-          You state that NQB is enabled largely by high bandwidth Internet accesses. The NQB draft doesn’t.

-          You are quite specific with one possible requirement, which in general would be that a maximum length PDU should be serialized by a link suitable for NQB within less than 1 ms. The NQB draft doesn’t say so.

-          Further, your example suggests a 3ms@accessbandwidth buffer depth for the NQB Queue. The draft is not specific here, and it likely doesn’t have to be that detailed. In my eyes, the draft NQB PHB description is vague. I’m clueless how to implement or configure an NQB queue, if I read the draft.

I’d like to add another point: if, in the example below, the NQB traffic stays below 50% link utilization also in the case of access link congestion, it shouldn’t see a queue.

Regards,

Ruediger
===Misunderstanding?==
[snip]

Please confirm that you (both) understand that, with NQB, the low latency is not provided by scheduling in the network. It is primarily a property of NQB traffic sources, and the only necessary property of the network's per-hop behaviour for NQB is to isolate NQB from QB traffic (i.e. in a separate queue for the NQB class). There is no priority scheduling requirement.

[A comment I would make to the authors about the draft: it needs to give some example approaches to scheduling between NQB and QB, or at least talk about this scheduling.]
==Incentive Alignment?==
Background: NQB has become possible largely because Internet access link rates have typically become fast enough that the serialization delay of a packet can be sub-millisecond, and therefore a queue of a few packets introduces delay that is small relative to other non-optional sources of delay like propagation. In these cases we no longer need priority scheduling for low delay.

Config:
·         Scheduler:
o    WRR with weight 0.5 for NQB on a 120Mb/s link. That gives at least 60Mb/s for NQB flows.
o    Scheduler quantum: 1500B.
·         Buffering:
o    The NQB buffer is fairly shallow (30 packets or 3ms at 120Mb/s).
o    The QB buffer is deeper (say 200ms) with an AQM target delay of say 10ms.