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

[Georg Wittenburg <[e-mail]>]

Dear Henning, all,

On Thursday 12 May 2011 08:07:31 Henning Rogge wrote:
> On Wed May 11 2011 16:10:58 Georg Wittenburg wrote:
> [...]
> > - 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.

OK. But the point below still remains, doesn't it?


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

I agree. However, it still remains true that link loss estimation that relies 
excessively on small packets will lead to suboptimal results. I'm aware that 
the original ETX paper doesn't cover this, but it doesn't mean that it 
shouldn't be addressed in this draft.

How about, for example, only incrementing the respective counters for packets 
whose size is above a certain threshold, say MTU / 2 (or even MTU / 4)?


> [...]
> > 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.

Neither am I. :) In this case, I just suggest that the wording in this draft 
is chosen in such a way, that amendments regarding highly volatile or moving 
networks can be made easily later on through a second complementary draft.


> > - 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).

But since the link cost value depends on the metric used, it would be up to 
this draft to suggest values for this, wouldn't it?


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

Yes, link speed, just as packet size, is not covered by the original ETX 
proposal. I'm aware that properly considering link speed greatly increases the 
complexity of the problem. The best workaround that I see is to be relatively 
conservative in what is considered a useful link (see above).


Best,

	Georg

-- 
Dr. Georg Wittenburg
Postdoctoral Researcher
INRIA / École Polytechnique, HIPERCOM Team
Laboratoire d'Informatique de l'École Polytechnique (LIX)
Route de Saclay, 91128 Palaiseau (CEDEX)
Phone: [phone], Fax: [phone]
http://www.lix.polytechnique.fr/~wittenburg/