[Codel] fixing netem to be more useful

[Codel] fixing netem to be more useful

[Dave Taht]

On of my big issues with netem (a network emulator for linux that lets
you do delay, loss, etc) is that there is no way to setup multiple RTT
emulations without having a separate maximum number of packets limit
for each, which can really skew the results. I would like to see a
netem that had a multi-queue implementation with a shared limit, among
other things.

Is there anyone working on making netem better? is there someone
willing to work on it that someone could fund?

This comment arose from the code facebook for their shaper implementation here:

https://github.com/facebook/augmented-traffic-control/tree/master/atc/atcd#shaping-packets

and the comments on this bug:

https://github.com/facebook/augmented-traffic-control/issues/60

-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Codel] fixing netem to be more useful

[Jonathan Morton]

> On 25 Mar, 2015, at 19:32, Dave Taht <dave.taht@gmail.com> wrote:
> 
> On of my big issues with netem (a network emulator for linux that lets
> you do delay, loss, etc) is that there is no way to setup multiple RTT
> emulations without having a separate maximum number of packets limit
> for each, which can really skew the results. I would like to see a
> netem that had a multi-queue implementation with a shared limit, among
> other things.

Hold on - what does the packet limit control?  Is it the total number of packets in virtual transit and in the queue proper, or just those in virtual transit?  The former would certainly interact badly with superimposed qdiscs (which should have their own resource limits), but the latter would imply that the limit is just a safety factor (which should be set high, if it’s running on desktop hardware) rather than a performance knob.

It strikes me that there might be a fundamental design problem here - where is the line drawn between the queue before the emulated network and the emulated link itself?  If that were made explicit (eg. by making netem classful with a single class, and thus enforcing the existence of a subordinate qdisc), it might behave better in general.

Then, a related problem would be how to assign different delays and loss rates to different traffic (thus emulating a more complex network) while still funnelling all of it through the same subordinate qdisc.

> Is there anyone working on making netem better? is there someone
> willing to work on it that someone could fund?

I might be able to justify rolling that into my tinkering with cake.

 - Jonathan Morton