[tsvwg] Re: WGLC for A NQB PHB for Differentiated Services (draft-ietf-tsvwg-nqb) to end 27th May 2024.

[Greg White <[e-mail]>]

Sebastian,
See below [GW].

On 5/21/24, 10:01 AM, "Sebastian Moeller" <moeller0=[e-mail] <mailto:[e-mail]>> wrote:
Hi Jason,
> On 21. May 2024, at 15:57, Livingood, Jason <jason_livingood=[e-mail] <mailto:[e-mail]>> wrote:
> 
> On 5/21/24, 02:34, "Sebastian Moeller" wrote:
> 
>> [SM] Could you be a bit more explicit, what exactly did you test, what was posiztive and did yu also look for side effects?
> 
> While you directed this question to Michael, we have tested this as well in our field trials. We have for example, tested single queue with AQM and looked at p99 latency under load and jitter as well as median & max bitrate for different application flows - then turned on NQB LL and observed the same for the classic and LL queues. What we have found generally is that the bitrates, working latency, and jitter for classic traffic with single queue AQM and dual queue LL is the same; classic queue applications do not experience degradation.


[SM] Puzzled, how can the bitrate in the C-queue not change when there is also quantitative traffic in the L-queue?

[GW] This shouldn't be puzzling. See below.  


> At the same time, the NQB flow experiences working latency that approaches idle latency, with consistently low latency.

[SM] Well, we know that priority scheduling does work and will give a sufficiently sparse traffic in the priority class shorter delays (and more potential throughput)... so that is not all that surprising.
Surprising is that according to your argument that improvement in service did not come at a cost for other traffic. And I question that, priority scheduling does not magically create more capacity or transmit opportunities, for every packet you treat to less delay, some other packet(s) will be treated to more delay. We can argue that the amount of this additional delay is insignificant, but that is a different claim than 'it does not exist' as you seem to be making above.

[GW] That isn't true. A simple thought experiment case is a 100 kbps gaming flow (200B @ 60Hz) sharing a 200 Mbps bottleneck with a Cubic TCP flow. Whether these two flows share a single FIFO or are separately queued in an NQB instance, the gaming flow consumes 100 kbps and the Cubic flow can consume the rest (199.9 Mbps). There is no difference in capacity available to the Cubic flow.  In the single FIFO case, with DOCSIS-PIE AQM, the Cubic flow might induce a packet loss every (say) 1.4 million packets, which will cause a single packet drop in the game flow once every 48 hours, so I suppose the single FIFO does reduce the gaming flow rate by 800 bpd (bits per day), and the Cubic flow could take advantage of that. The delay of the Cubic flow is controlled by the AQM, which has a target of 10ms in both cases, so there is no difference in Cubic delay caused by using NQB.    

[GW] Even if the NQB marked flow was non-compliant and was running at 180 Mbps, the Cubic TCP flow would have essentially 20 Mbps either way.  In this case the NQB flow would see 0.007% packet loss in the single FIFO option so that does give the Cubic flow an additional 13 kbps, so I guess it is 20.013 Mbps vs 20 Mbps. So, yes the bitrate is slightly different.  As above, the delay of the Cubic flow is controlled by AQM so remains the same whether single queue or dual queue.  

[GW] If the NQB marked flow was even more non-compliant, and was running at greater than 180 Mbps, the NQB implementation could potentially provide some protection to the Cubic flow, depending on whether and what kind of Traffic Protection function is provided.  


Regards
Sebastian


> 
> JL
> 
>