Subject: RE: [manet] where does OLSR loss most occur in lightly loadednetworks?

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 03 Dec 2004 10:11:55 +0000

> > The 10-second buffer does not mean that the packet
> > dealy is very long.  In other words, this does not
> > necessary mean that VoIP will fail with such a
> > 10-second buffer.  The real bottleneck is the actual
> > end-to-end delay that occurs in your network.  In
> > fact, AODV does have small end-to-end delays
> > according to my simulations.  This is because AODV
> > fixes broken routes immediately after a transmission
> > fails.  The new shortest route is up fairly quick in
> > AODV if the network size is reasonable.
>
> Indeed.  With my results, I have noticed that the
> end-to-end delay is much greater in AODV than OLSR
> (four times greater), using the implementation of OLSR
> without Link Layer Notification to detect linkbreaks.
> (20 applications running (CBR 4 packets per sec)
> in the network of 50 nodes moving Random Way Point in
> 1500x300 with max speed of 20m per sec)
>
> I think this can also be explained by the effect of
> keeping a 10s buffer in AODV whereas OLSR would drop a
> datagram.  So OLSR has a much higher loss but but also
> a smaller end-to-end delay as it doesn't count those
> packets that were dropped.
>
> With the OLSR its an issue that a lot of packets are
> lost, but with AODV in my simulations then a lot of
> old packets stay in circulation which if they are part
> of a flow with a low delay or jitter requirement then
> they will just end up adding to congestion
> pointlessly, and overflowing the queues.

There's a serious issue of a lack of a level playing field
in comparing reactive and proactive protocols, not just
here. (I was conscious of this in the only results with
my name on in the open literature.) Reactive protocols queue
packets because they suffer from major packet loss if they
don't, especially in the sorts of scenarios that are
typically simulated (short data flows to reduce time etc.)
while they are waiting to establish routes. With queuing
this becomes delay rather than loss. Proactive protocols
don't queue packets because they can live without it.
But they could, and then they could improve their packet
loss results - at the expense of introducing delay. This
has been suggested by Mase & Clausen in a recent ID that
produced some disagreements in San Diego about whether
queuing packets whilst waiting for routing is acceptable.
There may be a difference in acceptability for queuing
before a route is first established, and queuing for packet
salvaging (some would accept the former but not the latter,
others both, others neither - at least that's the impression I
got). If you don't queue you might want to separate different
reasons for packet loss (waiting for a route, congestion,
lack of a route) but that's difficult of course (but maybe
not impossible).

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Tao Lin" <[email-masked]>
Date: Fri, 3 Dec 2004 19:25:30 -0500

Hi  Christopher ,

Yes, you are right about the fair comparison assumptions.

As I pointed out in my previous email, I summarized issues on fair
comparisons among leading MANET routing protocols in my PhD dissertation (I
am not trying to push my work, just want to share my experiences in MANET
simulations).  Without using the same set of assumptions, comparisons are
basis.

  Tao

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 06 Dec 2004 09:51:32 +0000

> In addition to the trade-off Chris brought up (delay vs. loss), Alex
> Zinin brought the concern of where and how to buffer as a function of
> the traffic parameters up: large-bitrate flows imply requirements for
> potentially large buffers (in source or intermediate nodes)
> -- and its own set of problems.

Also there is interaction with TCP. (Particularly mentioned at San
Diego, and I know Thomas and Mase know this, but I think it's worth
including it here.)