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

[Emmanuel Baccelli <[e-mail]>]

Hi Georg,

On Fri, May 13, 2011 at 4:24 PM, Georg Wittenburg <[e-mail]
> wrote:

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


So far, this draft documents how the guys from the wireless community
networks (FREIFUNK, FUNKFEUER etc.) have been using ETX in OLSR in their
networks, and translating that in OLSRv2 formats.

While I agree we should let some flexibility in, and try to not preclude
things like you describe, in my opinion the first priority should be to
specify actual operational experience with OLSR and ETX.

Emmanuel





>
> 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/
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>