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

"Breno Jacinto" <breno@freeunix.com.br> Wed, 24 December 2008 15:10 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 678643A695A; Wed, 24 Dec 2008 07:10:15 -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 C85033A695A for <autoconf@core3.amsl.com>; Wed, 24 Dec 2008 07:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level:
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 nyD+LQFjPpEh for <autoconf@core3.amsl.com>; Wed, 24 Dec 2008 07:10:13 -0800 (PST)
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id ACEF03A682D for <autoconf@ietf.org>; Wed, 24 Dec 2008 07:10:12 -0800 (PST)
Received: by fk-out-0910.google.com with SMTP id 18so1703487fkq.5 for <autoconf@ietf.org>; Wed, 24 Dec 2008 07:10:01 -0800 (PST)
Received: by 10.181.153.12 with SMTP id f12mr3172280bko.132.1230131401500; Wed, 24 Dec 2008 07:10:01 -0800 (PST)
Received: by 10.180.245.2 with HTTP; Wed, 24 Dec 2008 07:10:01 -0800 (PST)
Message-ID: <2ced936d0812240710m6faacc5cwab9168363e933728@mail.gmail.com>
Date: Wed, 24 Dec 2008 13:10:01 -0200
From: Breno Jacinto <breno@freeunix.com.br>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
In-Reply-To: <49513057.2070603@earthlink.net>
MIME-Version: 1.0
Content-Disposition: inline
References: <be8c8d780812190119r200efceawef79c63766ea1a3f@mail.gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> <494F0B17.8070806@earthlink.net> <2ced936d0812230626q7182fec8p2d9d5cd901ec2a75@mail.gmail.com> <49513057.2070603@earthlink.net>
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-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: autoconf-bounces@ietf.org
Errors-To: autoconf-bounces@ietf.org

Hello Charles,

     Answers are below, they a bit long, I hope you' re not tired of
the discussion :). I'm really enjoying it.

2008/12/23 Charles E. Perkins <charles.perkins@earthlink.net>:
> Suppose we want to broadcast a packet to every node in the system.  We can
> create a reduced relay set to accomplish this, and it could be constructed
> using
> nodes across varying physical media.

      By system you mean an heterogeneous network? Which involves
multiple media? That's the only way I can imagine it.

      So, supposing that there are multiple media involved. But, it is
certain that for each media, a different network must be formed.
Practical example: nodes having Bluetooth, can only form a Bluetooth
network. Nodes with 802.11 b/g can only form networks with other nodes
with 802.11 b/g. And that applies to any technology.

      Now, if those nodes (which form different networks) wish to
talk, then there must be at least one node that is able to speak both
technologies, as in the example, 802.11 AND Bluetooth. Now, if we use
bridging or any other mechanism (such as Ana4 that I cited before), we
"glue" these networks at layer two, and they form a single broadcast
domain (this is in theory, in practice it currently doesn' t seem to
work). Then, to IP or any layer 3 protocol, this is just one network
where it's possible to broadcast and it's about the underlying
technology how is best to do it. I still dont see how IP can improve
anything below it in this case? An IP/ UDP broadcast will, ultimately,
become a layer 2 broadcast, right? If there is any kind of
optimization, then, it' s up to the underlay network. That' s how I
see it, if you have a different view about it, I'd really like to know
:).

      If you use IP on top of each of these separate networks, then, a
node may also be an IP gateway between those two networks, much like
we are used to and confident that works in the wired world. I could
successfuly make a Bluetooth network talk to a 802.11 b/g ad hoc
network just by using an IP gateway that had IPs for the Bluetooth and
802.11 ad hoc network. But, I was unable to do it at layer 2 (ie,
bridging). That's why I also think IP is a better glue in this case.

> If you want to distinguish between flooding and broadcast, by defining
> broadcast to be a transmission that cannot be forwarded, then there are still
> interesting issues about whether or not locally promiscuous reception is better than
> iterated unicast.  The better alternative could reasonably be selected by a good
> layer-2 design, but it might still benefit from getting neighborhood (or even
> two-hop neighborhood) information from topology management at a higher level.

     That' s interesting, I never thought about it. Do you know any
text with a comparative  study between these different techniques,
such as iterated unicast versus promiscuous reception?

     About the broadcast forwarding: yes, it seems to be a norm that
routers do not forward any broadcast packet. Up to now I'm just
accepting it, wondering that it can get messy if every router starts
to rebroadcast whatever broadcasts it receives. But maybe in some
cases this can be interesting.

     About the topology information: I was recently talking to the
guys from AWDS, and they did something interesting. For example, their
layer 2 protocol is a proactive, link-state one, very much like OLSR.
So, any information about the network is generated there, at layer 2.
Now, if, at layer 3, I wish to know any information (such as the
topology), then, just ask layer 2. They send it to you. That's some
kind of cross-layering that could be interesting in designing better
layer 3 protocols in this context.

> It's easier at layer 3, I think.

    With the example from AWDS, I still think its better at layer 2
with some layer 3 "talk".

> I thought that we could do this by identifying the appropriate
> sort of characterizations for the media and putting them into a draft.
> For instance, I am pretty sure that AODV works well enough over the
> various media.  If, for instance, Bluetooth has not established a proper
> scatternet for good connectivity, it simply would not report as many
> links to neighbors.  Since making scatternets seems to be so hard,
> maybe anyway it would have been better to let IP interact with the
> master/slave coordination.  Resolving this issue, however, is not at
> all easy and, I think, doesn't help us with the matter at hand.

    What kind of media did you test AODV? Up to know I only could
check it working over 802.11.

    And that's another point. How can we know the "way" of doing ad
hoc networking? Is it just about offering a mesh
(multipoint-to-multipoint) topology? Or, maybe the interconnection of
multiple star-like topologies, like scatternets? I think that these
assumptions may define the reasoning and concepts we'll be dealing
with. That's why I think there's a trend to think in terms of 802.11
ad hoc nets: that's what seems to work up to now and most people can
try it, verify and even modify.

> As written, I completely agree with this.  I guess the words are susceptible
> to varying interpretations, though.  For instance, if IP required symmetric
> links,
> some useful communication paths may simply cease to exist since layer 2
> could not provide them.

     OK, but I think that a little bit of talking between layer 2 and
3 (as the AWDS example mentioned) could solve this. But, of course,
this not as simple as it sounds. I'm aware that there are challenges
involved.

>>    In the case of 802.11s and AWDS, see how things are simplified. To
>> IP, it is just a switched ethernet network below it.
>
> Yes, but what happens when a non-802.11s node arrives?   Is that poor
> user just another error condition to be blithely cut off from the world?
> Or, as above, what happens when a nonsymmetric link is encountered?
> Do we just have to forget about it?  Or what if we could have designed
> a better protocol that made better flooding, but used brute-force
> broadcast instead because the interface didn't allow any distinction?

    No, never.  The non-802.11s (such as 802.11g or whatever) will be
able to form their own networks. Now, as I said in the beginning,
someone who is able to talk two (or three or many) must make them
participate in the world. It's an internetworking world, after all.
It's just that 802.11s or AWDS approches make it simpler by handling
multi-hop communication transparently to IP. No need of highly
specialized protocols such as OLSR at layer 3, something similar is
already at layer 2.

     The rest is up to IP protocols and internetworking. Symmetric /
assymetric links can be handled at layer 2 as well... after all, this
is a layer 2 problem, right? If it is still important in some cases
for layer 3 to know about them, them a little bit of cross-layering
sounds good to me.

      But I do get your point here. I just think that doing something
as AWDS did for 802.11 b/g, we could do it for other link-layers, such
as Bluetooth. And that would be a bliss from the IP standpoint, in my
opinion.

> Regards,
> Charlie P.

best regards, and merry christimas!
-- 
-- 
:: Breno Jacinto ::
:: breno - at - gprt.ufpe.br ::
:: FingerPrint ::
   2F15 8A61 F566 E442 8581
   E3C0 EFF4 E202 74B7 7484
:: Persistir no difícil é a única maneira de torná-lo fácil algum dia.  ::
_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf