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

Emmanuel Baccelli <> Wed, 25 February 2009 15:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EF4C3A69E6 for <>; Wed, 25 Feb 2009 07:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.873
X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FhdTsWvy0rtE for <>; Wed, 25 Feb 2009 07:44:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 602EE3A690E for <>; Wed, 25 Feb 2009 07:44:31 -0800 (PST)
Received: by fxm24 with SMTP id 24so40163fxm.37 for <>; Wed, 25 Feb 2009 07:44:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=UKUW42IOBLzwV68/4BoT11SENkCbM4sB3mgUkx8Ug1E=; b=aGonr3OaL6u3IPnsJ2dxh2v3XZiA83reEgG8ACk66QqKzsNJwdG+PgC/Vp1uzAC1+/ cylbSTKocGJlkQZqFkCNq6fvaAtuBg4JUfMvTjbCvxY26IZH05ZvhAAPhZRU59AikrLd AN4RzoPje9lX9C+Kd1rG5F/TG9uHuUOVZPDN4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=A4nDFhg9RmFr9uqbU+Hl5XRTqgQo1/A00N1w3Vnd9CKYJ25tt5EpECL56gV/F2iiVr 9shayxDY5ZuuS6n1b9ZDoIdlCvYbHEIfcYE7he1nf9KVVO/q9g/opAZP6M7LpIAG7wFv DSbtyHZaeIVdAA+10yXgi+c2jllmf2MbvcuLg=
MIME-Version: 1.0
Received: by with SMTP id a20mr124634muq.63.1235576689944; Wed, 25 Feb 2009 07:44:49 -0800 (PST)
In-Reply-To: <002e01c99729$bc956350$35c029f0$@nl>
References: <> <002d01c99722$dcf7f650$96e7e2f0$@nl> <002e01c99729$bc956350$35c029f0$@nl>
Date: Wed, 25 Feb 2009 16:44:49 +0100
X-Google-Sender-Auth: ee24d64b09d8da44
Message-ID: <>
From: Emmanuel Baccelli <>
Content-Type: multipart/alternative; boundary=0016369fa20db26a9a0463c01d67
Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Feb 2009 15:44:33 -0000

Hi Teco, inline

On Wed, Feb 25, 2009 at 10:16 AM, Teco Boot <> 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?

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?