Mesh problems

[Kirill And]

Hi all!

There is a problem of mesh.cc example in current ns-3-dev repository: UDP data can not be delivered in 3x3 mesh topology.

The problem is caused by missing processing delays: ARP requests are collided during retranslations due to medium access procedure of WiFi-MAC.

This is the reason why random delay model solves this problem: delay variance must be higher than a propagation delay

The following bugs discuss this problem:

https://www.nsnam.org/bugzilla/show_bug.cgi?id=737

https://www.nsnam.org/bugzilla/show_bug.cgi?id=912

--
Regards, Kirill Andreev
Wireless Software R&D Group,
IITP RAS

[Mathieu Lacage]

Note that a simpler way to deal with this problem would be simply to
start the traffic generation applications at different times. i.e.,
add a variant of ApplicationContainer::Start that takes a
RandomVariable argument.

Mathieu

> --
> You received this message because you are subscribed to the Google Groups
> "ns-3-users" group.
> To post to this group, send email to ns-3-...@googlegroups.com.
> To unsubscribe from this group, send email to
> ns-3-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ns-3-users?hl=en.
>

--
Mathieu Lacage <mathieu...@gmail.com>

[roman....@googlemail.com]

Unfortunately changing application-container.cc to start source
applications at different times did not solve the problem, see my last
entry in this discussion.

http://groups.google.com/group/ns-3-users/browse_thread/thread/2ccd424121d91947/c628863674492e25?lnk=gst&q=ns3+mesh.cc#c628863674492e25

However it reduces the ARP rebroadcasting Problem slightly.

--Roman

On Oct 14, 8:59 am, Mathieu Lacage <mathieu.lac...@gmail.com> wrote:
> Note that a simpler way to deal with this problem would be simply to
> start the traffic generation applications at different times. i.e.,
> add a variant of ApplicationContainer::Start that takes a
> RandomVariable argument.
>
> Mathieu
>
>
>
>
>
>
>
>
>
> On Wed, Oct 12, 2011 at 09:55, Kirill And <and.kir...@gmail.com> wrote:
> > Hi all!
> > There is a problem of mesh.cc example in current ns-3-dev repository: UDP
> > data can not be delivered in 3x3 mesh topology.
> > The problem is caused by missing processing delays: ARP requests are
> > collided during retranslations due to medium access procedure of WiFi-MAC.

> > This is the reason whyrandomdelaymodel solves this problem:delay

> > variance must be higher than a propagationdelay
> > The following bugs discuss this problem:
> >https://www.nsnam.org/bugzilla/show_bug.cgi?id=737
> >https://www.nsnam.org/bugzilla/show_bug.cgi?id=912
>
> > --
> > Regards, Kirill Andreev
> > Wireless Software R&D Group,
> > IITP RAS
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "ns-3-users" group.
> > To post to this group, send email to ns-3-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > ns-3-users+...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/ns-3-users?hl=en.
>
> --

> Mathieu Lacage <mathieu.lac...@gmail.com>

[Mathieu Lacage]

It would be helpful to file a bug about this issue so that it does not
get forgotten.

(I read your email in this thread: I am not sure what the problem is
but my suspicion is that you are observing some ARP packets getting
lost which is causing a lot of problems down the road. Namely, losing
ARP apckets is something that most research papers do not account for.
They assume perfect ARP tables are always present which can be
simulated in ns-3 if you use a very large ARP cache delay and make
sure everyone sends at least one data packet before starting your data
stream. If this is the problem you are really faced with, I would
suggest looking carefully at what makes this a non-issue in the real
world.In the real world, things are never so perfectly synchronized
which is why pavel/kirill suggested using a processing delay to
randomize things. It has been a while since I did not look at this
kind of issue but I know from first-hand experience that it is not
easy to make sure that all stations do not start synchronized and do
not resynchronize later on data/ack transmissions)

Mathieu

--
Mathieu Lacage <mathieu...@gmail.com>