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

[Toerless Eckert <[e-mail]>]

On Sat, Apr 14, 2018 at 06:50:43PM +1200, Brian E Carpenter wrote:
> > This however caused ~50ms of buffer bloat when there was competing BE 
> > traffic.
> 
> If buffer bloat is a problem for an "LE" application, it seems to me
> that the application is badly designed.

Right. I was asking the question mostly because of the need for
buffer space. With the results Mikael showed (thanks, great detail, Mikael),
i would say the recommendation to LE could be:

-> Afford as much buffer space to LE queue as you can based on HW
   capabilities of the device, up to the same buffer space used for
   BE. This might end you up using 2 times the amount of buffer space
   as you needed with only BE though.

   If you can afford these large amount of buffer space for the LE
   queue, you will create buffer-bloat for LE traffic when three is
   a lot of BE traffic competing - and LE therefore reduced to its
   weighted fair share of the link. Unlike BE traffic that often
   carries latency sensitive traffic such as real-time audio or
   even video, this buffer bloat should never be a problem for LE
   traffic. LE never promises any specific delay. Applying LE
   PHB to latency conscious traffic is wrong.

-> If you can not afford more buffer space on a device for LE, simply
   scale the LE queue respective to its weighted fair share of the
   link, for example only 5% of the BE queue if BE has 5% share.
   In this case, BE traffic will likely not able to fully utilize the
   link in the complete absence of BE traffic, but due to flow
   control issues max out at a lower rate. An example test showed
   the following results:
   effective LE buffer size before start of RED drop: 0.5 msec
   10 TCP flows (QUBIC), 1 Gbps link: 75..90% utilization max.
   Results would expected to be worse with slower links, better with
   faster links.

Now we'd just need to find a good place/draft to document these
type of BCP operational aspects of LE. Not sure if the PHB draft
is the right place. Would make life easier of course if it was.

Cheers
    Toerless

WARNING: only rants following, proceed at your own risk.

> Designing applications and transports to make good use of LE
> seems like a good PhD topic to me. I certainly wouldn't expect
> off-the-shelf FTP and TCP to do well, for example.

Have the PHD requirements dropped to the floor  since i left
university ?

I think even the hybrid BE/LE algorithm i suggested to document
for deadline based LE applications would at best qualify for a
bachelor thesis. If you do a lot of simulations to measure/simulate
queuing behavior LE vs. others using different applications, that
would qualify IMHO for a master thesis due to sheer amount of
work. 

For PhD the work itself would need to come up with something new.

While i do like novely in general, i also know the history of
young PhD joining the industry, pushing their novel scheduling
or aqm thesis into products, and then lots of poor operators
suffering with more and more incompatible nerd-knobs to manage
QoS in their network using multiple type of products. So...
i would be somewhat more careful here.

The root cause btw is the pressure of doing something novel raised
against PhD students often leads to just doing something unnecessarily
different because there just isn't that much "better" possible.
Finished PhD trying to apply their thesis at work because they have
made themselves believe it is better. Oh well, thats just missing
operational experience. And leaves a lot of really important
incremental improvement work unsolved because it's not novel enough
for research but still to difficult to productice due to dependencies
in the industry.