Re: [tsvwg] NQB PHB description and assumptions

[Bob Briscoe <[e-mail]>]

Ruediger,

Altho Greg's taken your suggestions on board, there's some need for me 
to explain those that weren't in the draft... inline...

On 06/09/2019 08:12, [e-mail] wrote:
>
> 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're assuming that NQB is classified into a queue designed the way EF 
has been specified in the RFC. In the solution for low latency DOCSIS, a 
queue is designed for sources that behave in an NQB way. And, altho the 
queue does not comply with the RFC defining EF, packets tagged EF are 
also classified into it, because their sources satisfy the NQB behaviour 
and they can take advantage of the low delay.

>   * You state that NQB is enabled largely by high bandwidth Internet
>     accesses. The NQB draft doesn’t.
>
I didn't intend hi b/w to be a requirement for NQB.

That was merely me saying that, if you have hi bandwidth, NQB could be 
designed like I proposed in my straw man. There might be other NQB 
designs for low b/w (obviously more difficult tho).

I.e. the more b/w you have, the less you're tied to 'old-school' QoS 
designs, where low delay depends on bandwidth priority.

>   * 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.
>
I've checked and I can't find where you think I said that. If I implied 
it, I didn't mean to. The closest was when I said this...

On 05/09/2019 19:23, Bob Briscoe wrote:
>> _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._
>> _

I only said sub-millisecond 'cos it's about an order or magnitude lower 
than typical propagation delays over the public Internet, and therefore 
tends towards an insignificant contribution to overall delay.

In the context of a data centre with 1ms RTT diameter, that sentence 
would translate to 'link rates ... fast enough that serialization delay 
.. can be sub-100us'.

>   * 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.
>
I gave a strawman example so I could argue with David & Sebastian in a 
concrete way. No implication that the draft should be as concrete, or 
even that it should use the example.

>   * 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.
>
Er no... Consider bursts of ten back-to-back 1500B packets sent on 
average every 30 ms from a 1Gb/s NIC into a 100Mb/s link. That's an 
average of only 4% utilization (4Mb/s), but at the end of each burst the 
queue is 9 packets.

Even if each NQB flow perfectly paces its own packets, the size of queue 
will depend on the number of uncoordinated flows. That's because the 
number of flows determines how many packets could arrive at about the 
same time and cause a queue. My calculation gave the worst case queue 
where a packet from all n flows happens to arrive at the same time. 
Statistically unlikely, but I explained I was calculating the tail of 
the delay distribution.




Bob

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/