[Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available

[Erik Tromp]

I think that there are two principle ways of measuring the "quality" of a
link:

1.) Passively, by monitoring the "quality" of the incoming packets.

2.) Actively, by sending specially formed probe packets and monitoring the
"quality" of the probe packets.

Advantages of 1.):
+ No extra air time

Disadvantages of 2.):
- links that carry hardly any traffic are difficult to measure (as Daniel
points out "you may never discover a better alternative route due to lack of
measurements on it")
- Tapping all traffic into user space for analysis by a user-space process
causes a high CPU load
- Alternatively, if tapping is not used, there is a dependcy on non-standard
interfaces to retrieve metrics such as Layer-1 or -2 metrics (radio signal
strength, number of retransmissions at the MAC layer, etc.) Besides, it is
difficult to determine the "quality" based on only these metrics.

Advantages of 2.):
+ Permanent monitoring of quality is possible, even in low-traffic
circumstances.
+ Low CPU load because only the probe packets are processed (socket selects
in kernel space)
+ No dependency on non-standard interfaces

Disadvantages of 2.):
- Requires extra air time


Additional issue: what is "quality"? There are various possibilities here:
- 'specified' link speed (bit/sec) e.g. 1, 2, 5.5, 11, 54, 300 Mbit/sec
- effective throughput (bit/sec) (my personal favourite :-)
- latency, jitter, air time (sec)
Or maybe even things like:
- used energy (joule)
- power (watt)
- battery drain (percentage)
- humanly percieved quality :P
- etc.

Just my 2 cents...

Erik



> -----Oorspronkelijk bericht-----
> Van: (spam-protected) 
> [mailto:(spam-protected)] Namens Daniel Nitzpon
> Verzonden: donderdag 13 november 2008 13:49
> Aan: (spam-protected)
> Onderwerp: Re: [Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available
> 
> hmmm..  i don't have an easy solution here...
> 
> but i wonder how you intend to deal with the underlying 
> issues in other
> algorithms:
> 
> * the "collision avoidance" issue also has a "reality factor" 
> built-in: 
> if you only consider the speed of a link during times on 
> which airtime for this link is available, you will end up 
> extremely over-rating links on which generally little airtime 
> is available.
> 
> * if you circumvent the "unicast traffic" issue, by only 
> measuring existing unicast traffic you may never discover a 
> better alternative route due to lack of measurements on it. 
> as lots of real-world scenarios have little 
> peer-to-peer-traffic (almost all unicast goes to the next 
> internet-gateway and back), it may be a real problem, not 
> just an academic one.
> 
> in how far do you consider these issues "issues"? any 
> solutions in sight?
> 
> greetz,
> daniel
> 
> Henning Rogge schrieb:
> > Am Thursday 13 November 2008 09:59:55 schrieb Daniel Nitzpon:
> > 
> >  > what about the mechanism with measuring timing of deliberate 
> > small/large
> > 
> >  > IP-packets? why did you drop this version?
> > 
> > There are two problems with packet-pairs...
> > 
> > first, WLAN is a "collision avoidance" medium, so WLAN drivers may 
> > wait for a longer time until they start to send the package (longer 
> > than the whole transmission will take). This waiting time is 
> > independant for each package.
> > 
> > second, the time delay in the operation system between kernel and 
> > userspace is sometimes larger than the WLAN transmission time too.
> > 
> > Maybe you could make packet-pair work by using radiotap header for 
> > sender AND receiver (so you know the exact times), but if you have 
> > enough CPU power for radiotap you don't need packet-pairs.
> > 
> > But the most important problem with bandwith measurements 
> is that you 
> > can only measure bandwith if there is traffic on the link. 
> So you have 
> > to spam unicast packages to each of your neighbors and 
> waste lots of 
> > airtime.
> > 
> > Henning
> > 
> > *************************************************
> > 
> > Diplom Informatiker Henning Rogge
> > 
> > Forschungsgesellschaft für
> > 
> > Angewandte Naturwissenschaften e. V. (FGAN)
> > 
> > Neuenahrer Str. 20, 53343 Wachtberg, Germany
> > 
> > Tel.: 0049 (0)228 9435-961
> > 
> > Fax: 0049 (0)228 9435-685
> > 
> > E-Mail: (spam-protected)
> > 
> > Web: www.fgan.de
> > 
> > ************************************************
> > 
> > Sitz der Gesellschaft: Bonn
> > 
> > Registergericht: Amtsgericht Bonn VR 2530
> > 
> > Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. 
> Joachim Ender
> > (Stellv.)
> > 
> 
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev
>