Re: [tsvwg] NQB PHB description and assumptions

[<[e-mail]>]

Hi Bob,

a PHB usually isn’t defined to the detail of implementation. AF and EF allow for a coarse understanding how to implement and configure the required functions. For me, NQB isn’t at that level yet.

I remove some of the prior text and reply [RG], marking your statements [BB]

#######################


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

     [BB] 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).

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

[RG] I’d appreciate, if the draft clarifies this point. Is NQB recommended for high bandwidth links? If yes, what’s meant by “high speed”? When is “old-school” QoS recommended and how will NQB work there? Some rough guidance should be given.

#################################

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.

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

    [BB] 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'.

[RG] I’d appreciate text telling a reader, what NQB is about and how it works. In that sense, picking up and mixing your statements, is it something like that:

The bitrate configured for NQB traffic should ensure that a queue of a few MTU sized packets introduces a delay causing only an insignificant contribution to the overall end-to-end delay.

######################################

  *   Further, your example suggests a 3ms@accessbandwidth buffer depth for the NQB Queue. ..[snip]

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

[RG] Your explanation is correct. Unfortunately, it doesn’t help me. Do you want to say, the example flow is NQB compliant? Then this shouldn’t be an issue (it adds of 2,4 ms delay in the worst case)? Or this is an issue? But what happens then and what’s the impact on the NQB traffic? None? I’m lost. Your example proposed a configuration and I take the available NQB text giving some examples for NQB traffic by the letter. What’s wrong here?

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

[RG] Yes. That’s why I’d expect the draft to be more specific on the traffic properties expected by NQB compliant traffic. Current text is

        There are many applications that send traffic at relatively low data
        rates and/or in a fairly smooth and consistent manner such that they
        are highly unlikely to exceed the available capacity of the network
        path between source and sink.
        These Non-queue-building (NQB) flows ..typically ….
        send traffic at a lower data rate and don't seek the capacity of the
         link (examples: online games, voice chat, DNS lookups).  Here the
        data rate is essentially limited by the Application itself.

[RG] What’s a “lower data rate”? What are the multiplexing conditions to avoid a queue build up at a link operating NQB (to quote you:… because the number of flows determines how many packets could arrive at about the same time and cause a queue)? How does an application developer and a service provider decide, which traffic is NQB? Which congestion indication is required by NQB and is an AQM expected? If yes, what is the AQM supposed to do an where’s that specified?

[RG] If the sole signaling of congestion is to forward flows identified as causing congestion by a QB PHB, the draft should state it that way. If the bottleneck is congested and the NQB flows consume more than (say) 80% of the bandwidth set aside for the NQB PHB, all flows could be perfectly well behaving and still a queue starts to build up. How does NQB work then and how to avoid these situations or return to desired NQB operational conditions for all NQB marked flows (please note, I don’t assume misuse and per definition admission control is absent)?

Regards,

Ruediger