[Battlemesh] Result documentation RFC
nemesis at ninux.org
Fri Aug 21 20:56:38 CEST 2015
On Fri, 21 Aug 2015 20:24:01 +0200, Benjamin Henrion <zoobab at gmail.com>
> On Fri, Aug 21, 2015 at 7:47 PM, Nemesis <nemesis at ninux.org> wrote:
>> Hi everybody,
>> this is a request for feedback: comments, suggestions and pull
>> See here:
>> Before starting to work on it I exchanged a few ideas via chat with
>> and Henning.
>> Here's a quick recap:
>> having all the results on one page would have made it quite hard to
>> so the tests have been split in 3 pages
>> mesh of adversity: one single stream from client (connected to A) to
>> (connected to K)
>> ping + iperf
>> crossed streams jeopardy: two streams, client A to server K and node
>> D to
>> node H
>> 10 mbit iperf streams
>> 100 mbit iperf streams
>> blowing up the network: tests performed with Flent by Toke
>> Realtime Response Under Load (RRUL)
>> Realtime Response Under Load Best Effort (RRUL_BE)
>> 8-stream download test
>> TCP upload
>> TCP download
>> As you can see, there are quite a few things that can be improved!
>> some graphs are missing (some purposely and some I was not able to
>> english needs to be checked
>> it would be good to provide some additional explanation to the
>> shall we add a conclusion section to each page? if yes, anybody
>> willing to
>> propose a conclusion?
>> shall we add a last "lessons learned" page with all the things that
>> wrong and the proposed solutions for the next edition?
>>From what I have heard in the videos, none of the routing protocols
> resists network saturation.
> Maybe adding a QOS rule for packets belonging to routing protocols
> would help?
I believe this was asked at the event and the bufferbloat crew provided
some interesting insights.
Short answer is "we should ensure the protocols work gracefully with
default settings" .. for the long and detailed answer I'll pass the ball
More information about the Battlemesh