Re: [tsvwg] thoughts on operational queue settings (Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04)

[Mikael Abrahamsson <[e-mail]>]

On Fri, 13 Apr 2018, Toerless Eckert wrote:

> Q1: What would be the impact to BE traffic if one would scale BE 
> queue-size and AQM parameters to 1/20th of what they ideally should be ? 
> I guess some performance impact, but any useful estimate how big that 
> impact would be ? Worse than overall performance, would it create more 
> unfairness between short RTT and long RTT flows ? (i fear so).

In my testing with 10 TCP flows, 30ms RTT, hundreds of megabits/s of 
access speed configured, the 0.5ms LE buffer before drop probability went 
non-zero (5% LE 10ms configured, resulting as you say in 0.5ms actual when 
there is no competing BE) meant the LE traffic would not utilise the link 
speed but would sawtooth between 75%-95% of used capacity (1 second 
interval shown in iperf3).

> I would hope we can figure out a good recommendation for LE for the LE 
> B/20 queue config. If that setup will give reasonable performance with 
> existing TCP algorithms, e.g: in the absence of BE traffic LE with QUBIC 
> TCP could get to > 50% link, that would be a good start and keep LE 
> requirements reasonable (one more queue per link, 5% more bufferspace 
> need per link).

When I configured LE to insted have 50ms before RED curve (resulting in 
2.5ms when there is no other traffic) the above test fared a lot better. 
This however caused ~50ms of buffer bloat when there was competing BE 
traffic.

This is also heavily dependent on access speed, the red curves need to be 
different depending on if the access speed is 10 megabit/s, 100 or 1000. 
The lower the speed, the more ms you need in order for the flows to behave 
more smoothly.

> The less a problem it is, the easier we could skip the M/20 setup for LE 
> and would only need to worry about the bufferbloat questions for LE - 
> which should be much less of an issue. Just from the perspective of 
> evaluating the lowest feasible additionalr esource seetup for LE i would 
> still like to see if there are answers for the M/20 setup.

My results show decent performance even at very low queue depths for LE 
traffic, at least at higher access speeds.

My main interest in this anyway is to solve the problem with access speeds 
in the 10-1000 megabit/s range and come up with solutions that are 
deployable on most providers existing BNG (and equivalent) devices.

-- 
Mikael Abrahamsson    email: [e-mail]