Re: [Autoconf] updated draft on aspects of multi-hop wireless communication

[Emmanuel Baccelli <[e-mail]>]

Hi Teco, inline

On Wed, Feb 25, 2009 at 10:16 AM, Teco Boot <[e-mail]> wrote:

> Thanks for the updated draft.
> Here some feedback:
>
> On exposed node: I do not understand what is mentioned here. I think the
> exposed node problem is communication from A to B (correct) and C to D
> (reverse direction of arrow). With CSMA, transmit from C is delayed because
> C noticed carrier busy caused by transmit from A (or CSMA/CA virtual
> carrier
> sense by CTS from B) . The delay was not needed, as C transmission does not
> affect B reception of frame transmitted by A.
> I think exposed node is more a research problem and less an operational
> problem.



I agree, but it may become more operational as multi-hop ad hoc networks are
more widely deployed. What do you think about this description of the
exposed node issues on wikipedia?
http://en.wikipedia.org/wiki/Exposed_terminal_problem

As for the use of CSMA/CA to cope with this, see my comment below.



>
> On Hidden Terminal: I think this __is__ an operational problem, but handled
> in some or many cases by a media access mechanism, like CSMA/CA or TDMA.
> Some / many cases implies "not all" cases, e.g. CSMA/CA does not work for
> multicast. And multicast may be of large importance in MANETs, e.g. MANET
> routing protocol flooding.



Yes you are right, most of the time, L2 will cope with these issues.
However, as you mention, not all the time, even with L2 technology that is
aware. For example because of multicast/broadcast, or because of
non-synchronization (common in multi-hop ad hoc networks).

In any case, maybe we should make clearer that this radio range limitation
aspect in multi-hop ad hoc networks causes some problems that force L2 to
use specific mechanisms (you cite CSMA/CA). Similarly it is causing some of
the problems described in Section 3 (and to some extent Section 4) at L3,
which have to be taken into account when designing L3 protocols that can
support such networks.





>
>
> I suggest swapping the two problems, mentioning the important one first.



I don't have a problem with reordering this ;)



>
>
> The draft emphasizes problems introduced by limited radio range. Note that
> it has also a welcome characteristic, that is spatial reuse. Be positive on
> wireless communication one time ? :-)
>
>
> Once again, I think:
>  - We may say that router B is a neighbor of router A. In this
>  terminology, there is no guarantee that router A is a neighbor of
>  router B, even if router B a neighbor of router A.
> is incorrect. B hears A and I would say A is a neighbor of A and A is
> listed
> in B's neighbor table.
> Is there a reason not to update the text, as we agreed on before?



I don't follow you here, maybe I misunderstood. If B is a neighbor of A, it
means that A hears B, and B is thus in A's routing table. It does not
necessarily mean that B hears A too, or that A is in B's routing table,
hence it does not mean that A is a neighbor of B too?

Emmanuel