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

"Charles E. Perkins" <charles.perkins@earthlink.net> Thu, 26 February 2009 18:01 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824133A6BD2 for <autoconf@core3.amsl.com>; Thu, 26 Feb 2009 10:01:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjaDK5Y5lr1A for <autoconf@core3.amsl.com>; Thu, 26 Feb 2009 10:01:43 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 6EEA03A6BC4 for <autoconf@ietf.org>; Thu, 26 Feb 2009 10:01:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TFBGno68B2xz7iFGO7pIJ5r24bjghLVEtoT2aEYOZSF2lcAMwcL/NbJV3SqeYzpv; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.129.145] (helo=[10.166.254.136]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1LckYc-0002sM-1S; Thu, 26 Feb 2009 13:02:02 -0500
Message-ID: <49A6D918.7060505@earthlink.net>
Date: Thu, 26 Feb 2009 10:02:00 -0800
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.nl>
References: <be8c8d780902230203k5f0ffb38m97d817aff9d95554@mail.gmail.com> <49A31B60.9050604@gmail.com> <49A31CD5.4090204@earthlink.net> <532BA0E9-FBFD-4022-88AF-BB0D5108FF4D@thomasclausen.org> <002c01c99722$3a526390$aef72ab0$@nl>
In-Reply-To: <002c01c99722$3a526390$aef72ab0$@nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526761694a95b540d832c725f255593c95350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.129.145
Cc: autoconf@ietf.org, 'Emmanuel Baccelli' <Emmanuel.Baccelli@inria.fr>
Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 18:01:44 -0000

Hello Teco,

I don't think anyone answered all of your questions yet...

Here are my answers for some of them.

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

The picture as drawn is a correct representation of the exposed node 
problem.
RtrC cannot receive packets from RtrD because it's getting interference from
the transmissions sent by RtrA.  So, the point about transmission from C 
is not
relevant.


> 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.
>
> I suggest swapping the two problems, mentioning the important one first.
>   

I think that would be a good idea.

>
> 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 ? :-)
>   

O.K.  We can mention that.  But the point of the draft is not to
be negative -- only to explicitly point out some of the well-known
realities of radio transmissions.
>
> 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 remember the previous discussion, but the fact that there is
this disagreement illustrates the real need to identify some unambiguous
and agreeable terminology for us to use during our discussions.

So, if  B hears A either
(i) A is a neighbor of B (your interpretation), or
(ii) B is a neighbor of A (what was in our draft).
I'm happy to settle on either interpretation, but it would
be nice if there were some consensus about it on the
mailing list.  I am assuming one of the two possible
resolutions to the typo in your text.  Maybe it is a moot
point anyway because, if the link is sufficiently
asymmetric, either:
(a) A is a neighbor of B, but A doesn't know it -- or,
(ii) B is a neighbor of A, but A doesn't know it.
So for asymmetric links, the concept of "neighbor" is
really confusing and maybe we should disqualify the
use of that term unless the links are symmetric.
Or, perhaps best, we should include some of these
points directly in the text of the draft instead of just
noting whatever emerges as consensus on the list.

Regards,
Charlie P.