Subject: [manet] Re: Some follow-up OLSR/AODV results

From: [email-masked]
Date: Mon, 04 Mar 2002 16:11:09 -0800

Thomas,

> Richard,
> 
> Thanks for looking at our simulation code for OLSR in detail. You are
> correct in pointing out the bug in the simulation code, and your proposed
> solution seems to solve the problem.
> 
> Our belated reply is due to the fact that we wanted to investigate the
> impact of the bug before replying.
> 
> We have been running a set of tests, similar to those presented earlier by
> Joe (http://protean.itd.nrl.navy.mil/manet/olsrstatic.pdf) of the
> simulation code "with the bug" and "without the bug". 
> 
> Exactly the same scenarios being used, our observations basically amount
> to the following:
> 
> 	- the reported overhead (in bytes/sec) indeed is about 50% larger
> 	  with the "bugfix"

I guess you are talking about total control traffic, including RTS/CTS packets
that are used for data packets.  For just routing control traffic, I found
that the reported overhead is between 90% and 120% larger with the bug fix,
depending on the scenario.

> 
> 	- the number of control packets is roughly the same (the
> 	  differences being very small and due to the randomness
> 	  introduced by the jitter)
> 
> 	- more importantly: the delivery ratio is unaffected by the
> 	  change. I.e. the same amount of packets are being delivered.

This may not be the case in every scenario.  For example, when the 
data traffic starts to congest the network, the increased overhead
could affect delivery ratio significantly.  Also, the increased
overhead will have more impact in larger networks.

Richard

> So while we acknowledge that there indeed is a bug, the impacts seems to
be only related to the rapported overhead, not to the functioning of the
> routing protocol.
> 
> Thanks again for pointing out the bug in the code. 
> 
> --thomas
> 
> 
> 
> > I think I found a bug in that code regarding packet size. (I don't know
> > whether the same bug is in Joe's code or in the code used for
> > simulations that others have done.)
> > When running simulations with that code, I noticed in the trace file
> > that every OLSR packet has length 20 bytes, including the 20-byte IP
> > header (i.e., ns-2  considers each OLSR message to have zero length not
> > including the IP header).
> > 
> > So I looked in the file ns-olsragent.cc and noticed the line
> >
> >    ch->size() = IP_HDR_LEN;
> >
> > in the sendPacket() function, which explained the bug. I changed the
> > line to
> >   ch->size() = IP_HDR_LEN + p->datalen();
> >
> > which seemed to fix the bug.  Am I missing something?
> >
> > Richard
> 
> 
> -- 
> 
> -------------------------------------------
>   Thomas Heide Clausen
>   Civilingeniør i Datateknik (cand.polyt)
>   M.Sc in Computer Engineering
> 
>   E-Mail: [email-masked]
>   WWW:    http://www.cs.auc.dk/~voop
> -------------------------------------------
> 
> 

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

---

From: [email-masked]
Date: Mon, 04 Mar 2002 16:11:09 -0800

Thomas,

Richard

---

From: [email-masked]
Date: Tue, 5 Mar 2002 09:46:49 +0100 (CET)

Richard,

> depending on the scenario.

The control traffic, generated by OLSR, is broadcast. Hence, no RTS/CTS
packets are being exchanged (nor accounted).

Besides, the overhead we've accounted is overhead at the MAC layer (i.e.:
that, which is actually transmitted onto the medium), originating from
transmission of OLSR control packets. This is, indeed, consistently about
50% larger with the "bugfix" on the large selection of scenarios we've
been testing.

--

---

From: [email-masked]
Date: Tue, 5 Mar 2002 09:46:49 +0100 (CET)

Richard,

--