[Battlemesh] tests for downloads ? and tests follow-ups

[Axel Neumann]

On Samstag 26 März 2011, Juliusz Chroboczek wrote:
> Interesting.  Thanks to all of you for compiling this data.
> 
> Axel, could we have a histogram of the distribution of protocol packet
> sizes?

So somebody must generate it ;-)  
I would also be interested,  But I wont find time for this now.
Find the raw tcpdump logs for each measurement 
at: http://dabax.net/wbm/axel/raw-data/ *.rawdump  . They are truncated to 80 
bytes but should be enought for what you are looking for.

As far as I know Pau is currently also postprocessing completely independent 
measurements. And I we once already discussed to present specific  
distributions. But he'll tell you more soon...

> 
> A few comments, after staring at it for just a few minutes:
> 
> (1) I'm impressed by the good results of BMX6.  Axel, is there
> a detailed description of the protocol?

Yes! some very detailed comments in .c and help files in .h format :-)


If you are addressing the metric algorithm I can give some more info:

I implemented and tested variations of TQ, ETX, ETT (ETT only estimating link 
bandwidth). You can easily lookup the supported algorithms straight in the .c
comments (eg ETX-alike path_metric_ExpectedQuality() function:
http://doxygen.bmx6.net/bmx6/html/db/d2a/metrics_8c-source.html#l00358 )

The main difference in bmx6 is that a greater metric value represents a better 
metric. And some confusion caused by range scaling for better calculation 
precision ( [0..1] input range transfomed to [0...UMAX] and back ). 

The bmx6 default metric_algorithm (also used during the battle) is a bit the 
result of my experience and feeling.

If you think of 
ETT_next = ETT_incoming_path + ETT_incoming_link  where 
ETT_incoming_path represents the expected transmit time over the so-far-
traversed path (without the last hop) and 
ETT_incoming_link represents the assumed ETT via just the last hop.

then 
the bmx6 default path_metricalgo_VectorBandwidth() would do something like:
ETT_bmx6 = sqrt( ETT_incoming_path^2 + ETT_incoming_link^2)
The idea is to apply less penalty for additional hops that original ETT would.

To better reflect asymmetric links also ETT_incoming_link is a bit tuned: 
ETT_incoming_link is calculated from the detected link-packet loss and an 
assumed ETT_LINK_MIN (1/1Gbps for wired and 1/56Mbps for wireless links) as:
ETT_incoming_link = ETT_LINK_MIN / ( TQ * sqrt(RQ) )

Might not be the RFC you were looking for but this is all I can offer right 
now.

/axel

> 
> (2) No loops in Babel and BMX6, as expected.  Some loops in BATMAN,
> which I don't understand.  Moderate number of loops in OLSR, as
> expected.  No data for BATMAN-adv.
> 
> (3) The issue with Babel having high protocol overhead in marginal
> networks is still present, as expected.  This is due to Babel sending
> a bunch of explicit requests whenever it loses a route (Section 3.8.2.1
> of RFC 6126); I'm considering a fix that would consist in rate-limiting
> the requests, but I need to get the details right.
> 
> (4) Surprisingly low protocol overhead for OLSR.  Counter-intuitively
> enough, OLSR's strategy which consist in having no adaptative intervals
> at all appears to pay off in this particular case.
> 
> (5) Although Babel was being run with a higher hello interval, its
> performance in the mobility scenarios was as good or better than that of
> the other protocols.
> 
> --Juliusz
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh