Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01

[Henning Rogge <[e-mail]>]

On Wed May 11 2011 16:10:58 Georg Wittenburg wrote:
> Dear authors, all,
> 
> after carefully reading draft-funkfeuer-manet-olsrv2-etx-01, here are some
> comments that I would like to share with the community.
At first, thank you for the feedback on the draft...

> Regarding the current text:
> 
> - Naming conventions: In Sec. 4, ETX is defined as (R_etx * D_etx) where
> R_etx and D_etx are the loss rates over the link. I feel that R_etx and
> D_etx are badly labeled since these names do not adequately reflect the
> meaning of these variables. Furthermore, in the original ETX paper "A
> High-Throughput Path Metric for Multi-Hop Wireless Routing" by De Couto et
> al. in MobiCom '03, ETX is defined as (1 / (d_f * d_r)) where d_f and d_r
> are the forward and reverse delivery ratios respectively. Given the long
> time that this paper has been around, it may well make sense to stick to
> the established formalism and naming scheme.
I see no problem renaming both variables to stay consistent with another 
naming scheme.
 
> - Size of HELLO messages: Sec. 8.1 states that HELLO messages should be
> generated as specified in draft-ietf-manet-olsrv2 which in turn refers to
> RFC 6130. In the absence of other traffic, the delivery ratios of these
> HELLO messages will be the only input to the ETX metric.
That is not right... there will be more TC messages in the network (especially 
in larger networks) than Hellos, so they will contribute to the size of the 
packets too.

> The problem is
> that packet delivery ratios differ depending on the size of the
> transmitted packet. If small packets are used to estimate link quality,
> this estimate will be flawed if the link is used for large packets later
> on, i.e, packets that make full use of the MTU. A workaround would be to
> require that if HELLO packets are to be used for link quality estimation
> then they must be padded to correspond in size to the average data packet,
> or MTU.
The funkfeuer metric drafts suggests to use all RFC 5444 packets for link loss 
estimation, not only a certain message type. Your suggestion would make it 
necessary to pad all RFC5444 packets to the maximum MTU, which might be a 
considerable overhead.
 
> - Order of processing: Secs. 8.2 and 8.3 independently state that link
> metric processing is carried out *after* OLSR-related processing. In my
> (unrelated) experiments I found it beneficial to *first* update the link
> metrics and then continue with layer 3 packet processing. The rationale is
> simply that routing decisions should be based on the most up-to-date
> information.
Routing decissions are done for unicast traffic, which is independent from the 
OLSR/NHDP processing. Even if the metric processing is done after the packet 
processing, it could still be done before a potential dijkstra calculation, 
which would update the routing table.

> Hence, I suggest to rephrase Secs. 8.2 and 8.3 to first
> update the data structures related to link metric processing, and only
> afterwards hand off packets to be processed by OLSR.
Incoming packets don't trigger direct metric updates, so the order of both 
operations don't matter that much for the FUnkfeuer ETX metric.

> Similarly, periodic
> metric computation has the drawbacks of a) inducing delays before the
> updated metrics are available to other components, and b) the
> computational load of having to recalculate all links at the same time.
> Wouldn't it be beneficial to trigger per-link recomputations based on
> link- related events (number of transmitted packets, sudden changes in the
> loss ratios) and merely use periodic timers as fallbacks?
We use the timer approach to implement a sliding window, which always contains 
the total reception/loss for the last few seconds (ETX_MEMORY_LENGTH).
I am not sure this can be done easily without the timer approach.

> Regarding possible additions:
> 
> - Convergence time: Has it been considered to add weights to the list of
> measured loss ratios in order to optimize the convergence time after major
> changes to a link?
Yes, but this metric has been mostly used in non-moving mesh networks where 
weights would only add computational overhead.

It might be a tuning parameter for moving networks, but I am not able to guess 
a good value for the weight distribution.
 
> - Useless links: Has it been considered to have an upper bound on the ETX
> value above which links are considered as being too bad to be useful?
We do this in the Freifunk/Funkfeuer meshs, but in NHDP/OLSRv2 this would be 
the job of the link hysteresis (which easily could be implemented based on the 
link cost value).

> - Modulation issues: How does this metric deal with packets that are send
> at different transmission rates using different encodings? For instance,
> if a link is measured using broadcast packets, then the metric may well be
> flawed for high-speed streams of unicast packets.
ETX metrics do not consider link speed, so our metric would not encode this 
difference into the link cost.

> I hope these comments are helpful.
Yes, they are. :)

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon [phone],   Fax [phone]
mailto:[e-mail] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0