fixing netem to be more useful

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: 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

Re: fixing netem to be more useful

[Emmanuel Lochin]

Another issue, I think, is the way burst of lost packets are computed. The scheme implemented is not a two state Markov chain that would allow to set an average burst size and I failed to find an explanation concerning this point.
If somebody has information ...

Emmanuel

--
Emmanuel Lochin 
Professeur ISAE - OSSI 
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) 
Issu du rapprochement SUPAERO et ENSICA 
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 
Web : http://personnel.isae.fr/emmanuel-lochin/ 
--- 
"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" Le 25 mars 2015 18:32, Dave Taht <dave.taht@gmail.com> a écrit :
>
> 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
> _______________________________________________
> Bloat-devel mailing list
> Bloat-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat-devel