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

["Teco Boot" <[e-mail]>]

Hi Emmanuel,  inline

 

Van: [e-mail] [mailto:[e-mail]] Namens
Emmanuel Baccelli
Verzonden: donderdag 26 februari 2009 9:47
Aan: Teco Boot
Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
communication

 

Hi Teco, thanks for your feedback, please see inline.

 

 

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

Inline.

Van:  <mailto:[e-mail]> [e-mail] [mailto:
<mailto:[e-mail]> [e-mail]] Namens
Emmanuel Baccelli
Verzonden: woensdag 25 februari 2009 16:45
Aan:  <mailto:[e-mail]> [e-mail]
Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
communication

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 

OK, this ref depicts the arrow in the right direction.

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).

Maybe one would say some L2 technology solves this completely, e.g. fixed
slot TDMA. Maybe not really ad hoc and limited scalability, but no hidden
terminal probem here J

OK. Note however that for TDMA you need synchronization. It's not so common
in the decentralized, multi-hop environments we are addressing in the draft.
But I agree, we could say something like "some popular L2 technologies have
these aspects/issues, so we need to take that into account at L3".

 

Teco:

Let's specify the L2 technology, to circumvent confusion.

CSMA/CA (e.g WLAN with RTS-CTS enabled) unicast traffic and TDMA does not
have a hidden terminal problem. 

Plain CSMA, also being used by broadcast and multicast in a CSMA/CA network
has the hidden terminal problem.

Different people may have different opinions on "popular L2 technology".

 

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.

For the hidden terminal problem: I agree that this L2 problem affects L3.

For exposed node, I don't see this effect. 

 

 

Can you explain a little more, why? As far as I can see, we potentially get
the same result: radio signal collision/retransmission. As explained in
http://en.wikipedia.org/wiki/Exposed_terminal_problem 

 

 

Teco:

Maybe I have another wiki page as you have.

Can you provide text from wiki with the terms "collision" or
"retransmission"?

 

My page mentions only "prevented from sending", i.e. delay.

 

if the nodes are not synchronised the problem may occur that the sender will
not hear the CTS or the ACK during the transmission of data of the second
sender. 

 

Teco:

This text is on the wiki page I see. It is a special case, where the exposed
terminal problem is not solved. It is not a collision or whatsoever. By the
way, I wonder if 802.11 really circumvents the Exposed Node problem. 

See http://wifi.cs.st-andrews.ac.uk/wifiexposednode.html for a more detailed
explanation. 

 

 

Anyways, I agree that it is not the main issue for L3, but again, it is
noteworthy, as an illustration of issues that come from the fact that radio
ranges are limited, and overlapping, a fact that must be taken into account
at L3 in the context of networks such as described in this draft.

 

Teco:

After having consensus on what the Exposed Node problem is, we can decide on
removing it from the text. 

I would say: remove, as the Exposed Node problem does not affect L3.

 

 

[skipped some text]



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?

 

B is member of set S and can hear A.

B will store the received info in the neighbor table.

So from the viewpoint of B, A is a neighbor.

 

 

This is still confusing for me, but I guess this is just a matter of
wording. The essential message here is:

B=>A does not imply A=>B, whatever words you want to express the arrow with.

 

Teco:

The scenario in the draft is: B hears A. Let us use this scenario. OK?

 

In the draft, which is coherent as far as I can see, we know a priori that B
is a neighbor of A. 

 

Teco:

Who is "we"? God only knows.

 

We imply from this that B is in S(A), so that A hears B. And we can't imply
from this that B hears A.

 

Teco:

Now you are confusing me. What scenario do you have in mind? B is in set S
and can hear A (your draft) or otherwise (above text)?  

 

If you want translate the arrows in the reverse with the same vocabulary
there is no problem, but I don't see the point really, because it is correct
as is.

 

Teco:

As replied to Charlie, I prefer the option that corresponds with what
routers tell you and not what God only knows.

 

 

 

[skipped text]

 

 

Regards, Teco