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

[David Young <[e-mail]>]

On Fri, May 13, 2011 at 04:23:19PM +0200, Georg Wittenburg 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.
> 
> 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)?

Suppose that there is a function that for a certain bit error rate (BER)
maps the packet size to the delivery ratio.  If we know the delivery
ratio at two or more packet sizes, it seems that we can fit a curve to
those ratios and derive the BER from the curve.  Then we can use the BER
to roughly predict the delivery ratio at each packet size.

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

You can probably derive a much better metric than ETX by tapping into
information that the rate adaptation collects.  More than one 802.11
rate adaptation in the literature has tried to optimize the so-called
goodput of a link by choosing a suitable bitrate for each packet based
on packet properties such as size.  Advantages of collecting information
from the rate adaptation are that you avoid duplicating any code or
computational effort, and you collect the information from a more
suitable (IMO) place in the network stack.  All the world's MANETs are
not built on 802.11, it is true, but the same general principles apply:
don't needlessly compute the same metric twice, and collect the link
metric at the most suitable place.

Dave

-- 
David Young             OJC Technologies
[e-mail]      Urbana, IL * [phone] x24