[olsr-dev] LQ code enhancements

[Bruno Randolf]

hello!

i think there is nothing wrong with calculating the LQ from bigger/combined 
packets - quite in contrary i think this is a good idea. in the end we are 
interrested in the packet loss of *all* packets, especially user traffic 
packets on the link, and not in the packet loss of artificially small HELLO 
packets. 

my assumption is, that user traffic packets will vary in size with a tendency 
to larger, MTU sized, packets, just like the combined OLSR messages in bigger 
networks. as sven-ola already said, the packet loss can be quite different 
for small and large packets, so small HELLOs or even smaller probe packets 
(like in the original ETX paper) might have no loss at all, while 
"normal" (MTU sized) user traffic can have a loss of 100%. in this case i 
would prefer the LQ beeing very low, and this is what we get when we 
calculate the LQ from the bigger combined OLSR messages.

bruno


On Tuesday 01 March 2005 18:43, onelektra wrote:
> Hi!
>
> >> You are shure that was a good idea?
> >
> > Hmmm. Well, my idea (The idea to look at UDP packets and not at the
> > individual messages inside the UDP packets. Not the idea to put more
> > than one message into a single UDP packet.) was inspired by the fact
> > that we thus potentially have more sequence numbers to look at and are
> > able to detect packet loss earlier, possibly before the next HELLO
> > message is due.
>
> I see.
>
> > As far as I can see we do not lose anything by doing so, do we? Even if
> > the LQ code went through the UDP packet and only looked at the HELLO
> > messages within, the HELLOs would still be transmitted together with
> > other OLSR messages in the same UDP packet. This behaviour has nothing
> > to do with the LQ code.
>
> No, you dont loose anything.
>
> > But I think that I can see your point. Big UDP packets get lost more
> > easily and, hence, HELLOs might be lost although they're pretty small
> > simply because they are packed with other OLSR messages into a single
> > big UDP packet. And, to make things worse, the UDP packets are
> > broadcasts, which are more prone to packet loss than unicasts, as there
> > aren't any acknowledgements for broadcasts. Right?
>
> Exactly. Well, broadcasting it is part of the LQ-idea - but letting the
> hello's be part of a UDP-transmission with other payload makes things
> unpredictable.
>
> > If this is a problem, then we should think about configuration options
> > along the lines of "LonelyHello", "LonelyTc", etc. that force HELLOs,
> > TCs, etc. to be sent in their own individual UDP packet separate from
> > any other messages. This shouldn't be much programming effort. Simply
> > flush the output buffer before adding a HELLO, a TC, etc., add the
> > HELLO, the TC, etc. to the buffer, flush the output buffer again.
>
> Yes, please. Having lonelyTC's as well is a maybe good idea - in a big
> mesh you have increasingly big TC-messages. If they need a lot of luck
> to be successfully transmitted cause you pack in more and more in every
> UDP-transmission things get pretty messy soon - route flapping etc.
>
> cu elektra
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20050301/a3ce768f/attachment.sig>