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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 19 December 2008 12:08 UTC

Return-Path: <autoconf-bounces@ietf.org>
X-Original-To: autoconf-archive@megatron.ietf.org
Delivered-To: ietfarch-autoconf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1053A6978; Fri, 19 Dec 2008 04:08:05 -0800 (PST)
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 252E93A6978 for <autoconf@core3.amsl.com>; Fri, 19 Dec 2008 04:08:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level:
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 oZIsY9TikfD1 for <autoconf@core3.amsl.com>; Fri, 19 Dec 2008 04:08:03 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id F24F73A68A2 for <autoconf@ietf.org>; Fri, 19 Dec 2008 04:08:02 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@gmail.com
X-Msg-Ref: server-10.tower-119.messagelabs.com!1229688446!34185858!1
X-StarScan-Version: 6.0.0; banners=.,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 32302 invoked from network); 19 Dec 2008 12:07:26 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 19 Dec 2008 12:07:26 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJC7Qq1017306; Fri, 19 Dec 2008 05:07:26 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mBJC7P2s027812; Fri, 19 Dec 2008 06:07:25 -0600 (CST)
Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mBJC7OmO027807; Fri, 19 Dec 2008 06:07:25 -0600 (CST)
Message-ID: <494B8E7C.7000505@gmail.com>
Date: Fri, 19 Dec 2008 13:07:24 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
References: <be8c8d780812190119r200efceawef79c63766ea1a3f@mail.gmail.com>
In-Reply-To: <be8c8d780812190119r200efceawef79c63766ea1a3f@mail.gmail.com>
X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message
X-Antivirus-Status: Clean
X-CFilter-Loop: Reflected
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] 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/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: autoconf-bounces@ietf.org
Errors-To: autoconf-bounces@ietf.org

Thanks for the description.  I think it's good to lay out our
understandings of terminology to clarify and eventually converge.

It's a short comprehensive draft covering a few essential points 
recently discussed on the list about particularities of wireless 
communications.

> In this document, we consider a multi-hop ad hoc wireless network to
>  be a collection of devices that all have radio transceivers using
> the same physical and medium access protocols.  All are configured to
>  provide store-and-forward functionality on top of these protocols,
> as needed to enable communications; consequently, they can be 
> classified as routers in the resulting wireless network.

It would be good to clarify that the "top" mentioned above is actually
the networking IP layer, decrementing TTL/HopLimit.  Otherwise one may
read the "routers" mentioned above as "MAC bridges".

Or you didn't mean that "top" to be the IP layer?

I continue assuming you meant the IP layer.

> First, there is no guarantee that a router C within S can, 
> symmetrically, send IP packets directly to router A. In other words, 
> even though C can "hear" packets from node A (since it is a member of
>  set S), there is no guarantee that A can "hear" packets from node C.
>  Thus, multi-hop ad hoc wireless communications may be "asymmetric". 
> Such asymmetry is often experienced on multi-hop ad hoc wireless 
> networks, due to well-known properties of wireless communication.

Sorry, could one mention why?  What's the example of this?  I haven't
ever experienced this problem with wifi.  I may have noticed a slight
difference in bandwidth upstream vs downstream but not a complete cut of
communication in one direction while the other direction was ok.

What are the well-known properties of wireless communication making this
asymmetric behaviour (communication works in one direction but not in
the other).

> Second, there is no guarantee that two given routers within S can 
> directly communicate with one another.  In other words, even though 
> two routers R1 and R2 can both "hear" packets from router A, there is
>  no guarantee that R1 can hear packets from R2, and there is likewise
>  no guarantee that R2 can hear packets from R1.  Thus, multi-hop ad 
> hoc wireless communications may be "non-transitive".

It is of paramount important for me to understand what is meant by
"hearing".  Is it MAC level or IP level.

It is very possible for R1 to not receive from R2 (although the
intermediary A receives from both) and this does not represent a problem
at all, even less a particular problem of wireless communications.  When
R1 doesn't hear from R2 it's because it's too "far" from it; the
solution could be A to bridge R1 to R2.  It is the same problem in wired
communication.

> Lastly, there is no guarantee that, as a set, S is at all stable. The
> membership of set S may in fact change at any rate, any time.

One would however differentiate this dynamic nature from a completely
disconnected on-off behaviour.  One would set the limits of
connectivity.  If we don't have limits for connectivity then we can't
even talk PHY (let alone MAC, Networking, Transport and Application).

If it's needed, I could help contribute text defining what movement may
mean in terms of fixed points, subnets, TTL/HoLimit and of IP address
change.  I could also contribute text about radio communication being
the same through the air as through copper or fiber, as seen from the
MAC layer.

Just some thoughts,

Alex



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf