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

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 19 Dec 2008 10:19:12 +0100

Hi all,
here's a draft that aims at describing important aspects of multi-hop
wireless communication, as observed over the past decade of experience with
such networks.

The goal of this document is to identify a consensus about this topic, and
then use this to move on quicker with the working group documents.

Please review it, and provide feedback as soon as possible.

http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-00

cheers
Emmanuel
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 13:07:24 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 19 Dec 2008 13:08:48 +0100

Hi Emmanual and Charles,

Thanks for the efforts. 
I like the compactness of the draft.

Maybe mention alternate terminology “uni-directional” for "asymmetric" ?
As discussed before, asymmetry is also used for different link qualities
for A to B and B to A, where A and B have a symmetric relation.

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

In this case, the neighbor table of router B would list router A.
So I say router A is neighbor of router B, and there is no guarantee
that router B is a neighbor of router A.
Or I say the relation between neighbors is symmetric, but some neighbors 
may not be aware of this.

Regards, Teco

===
Van: [email-masked] [mailto:[email-masked]] Namens
Emmanuel Baccelli
Verzonden: vrijdag 19 december 2008 10:19
Aan: [email-masked]
Onderwerp: [Autoconf] aspects of multi-hop wireless communication

Hi all,

http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-0
0

cheers
Emmanuel

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Dec 2008 12:11:54 -0000

> Sorry, could one mention why?  What's the example of this?

The simplest example (but by no means the only) is different power
levels transmitted by A and C.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 13:14:45 +0100

> levels transmitted by A and C.

And isn't it the same for wired communications ?  (and would a potential 
solution to this to have the same power levels transmitted by A and C?)

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Dec 2008 12:17:38 -0000

> (and would a potential solution to this to have the same power levels
> transmitted by A and C?)

This may not be possible.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 19 Dec 2008 13:19:30 +0100

|>>> 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.
|>
|>> Sorry, could one mention why?  What's the example of this?
|>
|> The simplest example (but by no means the only) is different power
|> levels transmitted by A and C.
|
|And isn't it the same for wired communications ?  (and would a potential
|solution to this to have the same power levels transmitted by A and C?)

One other reason is noise levels.

Alex, if you can provide a noise suppression device, please send me one.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 13:20:03 +0100

> This may not be possible.

Thinking about which type of existing IP solutions may accommodate 
this... maybe SMTP? (store and forward).

Not sure what you mean.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 13:20:54 +0100

> Alex, if you can provide a noise suppression device, please send me one.

There's noise in the wires as well and gets supressed by PHY and MAC.

Not sure whatkind of solutions you think are designable.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Dec 2008 12:32:04 -0000

> There's noise in the wires as well and gets supressed by PHY and MAC.

PHY layers, especially in radio, are not magic noise suppressors.

I'm going to spell this one out once, then give up and suggest
any elementary text on radio.

If I put a loud noise source right next to C, it will mess up
C's reception. But A, who is much more distant from the noise,
won't care.

And before you suggest avoiding noise sources, let's just say
they range from things in the environment (inclusing man made
things) that are difficult to avoid, to people doing this
deliberately.

And note that different power levels, and different noise
environments are still not the only reasons for asymmetry. But
either one is sufficient to make it happen.

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 19 Dec 2008 14:04:46 +0100

Thanks for your feedback Alex,

On Fri, Dec 19, 2008 at 1:07 PM, Alexandru Petrescu <
[email-masked]> wrote:

> It's a short comprehensive draft covering a few essential points recently
> discussed on the list about particularities of wireless communications.
>
>> as needed to enable communications; consequently, they can be classified
>> as routers in the resulting wireless network.
>>
>

I guess that in the context of the IETF, yes. We should spell this out in
-01.

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

I have nothing to add to what Chris replied to that ;)

>  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 R2 can hear packets from R1.  Thus, multi-hop ad hoc
>> wireless communications may be "non-transitive".
>>
>

 Actually this is out of the question because, as stated in the previous
paragraph in the draft, there is no guarantee that A can hear either R1, or
R2... (all we know is that R1 and R2 can hear A).

> the same through the air as through copper or fiber, as seen from the

Thanks. But I think this is not in scope for this document. The goal of this
document is simply to describe what was experienced over the years on
multi-hop wireless networks in terms of communication characteristics. Such
"conclusions", based on the characteristics described in this draft, should
go in a separate document, in my mind.

Emmanuel

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 19 Dec 2008 14:06:46 +0100

Yeah, me too! We'd keep it a secret and we'd get rich ;)Emmanuel

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 19 Dec 2008 14:11:14 +0100

Hi Teco, thanks for your feedback,

On Fri, Dec 19, 2008 at 1:08 PM, Teco Boot <[email-masked]> wrote:

> Maybe mention alternate terminology "uni-directional" for "asymmetric" ?

I agree. I think it would be nice to have unidirectional mentionned in the
alternative terminology. Should have this in -01.

> may not be aware of this.

OK, I think I see what you mean: you are saying that since B hears A, the
text should rather be:
"A is neighbor of router B, and there is no guarantee that router B is a
neighbor of router A"
Am I correct?

 Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 19 Dec 2008 14:33:55 +0100

Am I correct?

Yes, but others could prefer the original text. 

If so, I am interested in the protocol that implement such.

If there is no such implementation, please update the text.

Teco.

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 19 Dec 2008 14:49:04 +0100

OK ;) As far as I'm concerned, I think we should update the text; Should be
in -01.Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 15:44:14 +0100

> either one is sufficient to make it happen.

Christopher,

I'a afraid I won't converge in this direction.

Noise and interference are also solved by government regulation (the 
famous "political" layer).

I'm really doubtful I could converge this way...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 16:01:50 +0100

Emmanuel Baccelli wrote:

>>> 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".
>> 
>> 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.
> 
> Actually this is out of the question because, as stated in the
> previous paragraph in the draft, there is no guarantee that A can
> hear either R1, or R2... (all we know is that R1 and R2 can hear A).

So this second issue is tightly bound to the first, it seems.

I agree a radio-through-air system may behave that way.

I think some solutions exist at PHY and MAC layers in the case of 802.11.

I doubt a solution is necessary at IP layer.

Maybe there's a need to discuss this radio-through-air problem more in 
terms of what IP could do for it.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Dec 2008 15:06:57 -0000

> I think some solutions exist at PHY and MAC layers in the case of
802.11.

As has been said many times before, MANET is not just
about 802.11.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 16:20:43 +0100

> As has been said many times before, MANET is not just

I may have missed something.  What other than 802.11 is it about?

Alex

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 19 Dec 2008 16:21:35 +0100

> As has been said many times before, MANET is not just

I think Chris makes an important point here.
We are discussing things experienced at the IP layer.
The draft is not saying "there is a need for a solution".
The draft is saying "this is what is often observed".
That's it. I think we can agree on this ;)

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 16:53:04 +0100

Emmanuel Baccelli wrote:
> 
> 
> On Fri, Dec 19, 2008 at 4:06 PM, Dearlove, Christopher (UK) 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> As has been said many times before, MANET is not just about 802.11.
> 
> 
> I think Chris makes an important point here. We are discussing things
>  experienced at the IP layer.

Observation should report the name of the link layer, otherwise a peer
may think the author logically extends what s/he sees on one link layer
to another (instead of experiencing same phenomena on each link layer
individually).

The scientist orders the frog to jump, who so does.  Then cuts its legs,
orders it again to jump; the frog obviously can't jump.  Scientist
deduces the frog can no longer hear.  However, if the order were issued
to the legs (instead of ears) in the first place then maybe the false
conclusion could have been avoided.

> The draft is not saying "there is a need for a solution". The draft 
> is saying "this is what is often observed". That's it. I think we can
>  agree on this ;)

I agree one may have observed this behaviour.  I don't agree it is an
often observed behaviour - I didn't.  I often observed wifi works ok in
the types of deployments described in the draft (R1,R2,A).

Alex

> 
> Emmanuel
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 19 Dec 2008 17:10:55 +0100

On Fri, Dec 19, 2008 at 4:53 PM, Alexandru Petrescu <
[email-masked]> wrote:

>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>
>>  I think some solutions exist at PHY and MAC layers in the case of
>>>
>> 802.11.
>>

I knew this joke with a spider instead of a frog. Funny.

>
>  The draft is not saying "there is a need for a solution". The draft is
>> saying "this is what is often observed". That's it. I think we can
>>  agree on this ;)
>>
>

Well Alex, you are the only one I know that has had such unbelievable luck
with radio links (wifi or any other type of radio) during the last decade. I
guess this is says a lot about reality ;)
Emmanuel

> For more information please visit http://www.messagelabs.com/email______________________________________________________________________
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 17:17:43 +0100

Emmanuel Baccelli wrote:

>>> The draft is not saying "there is a need for a solution". The 
>>> draft is saying "this is what is often observed". That's it. I 
>>> think we can agree on this ;)
>> 
>> I agree one may have observed this behaviour.  I don't agree it is 
>> an often observed behaviour - I didn't.  I often observed wifi 
>> works ok in the types of deployments described in the draft 
>> (R1,R2,A).
> 
> Well Alex, you are the only one I know that has had such unbelievable
>  luck with radio links (wifi or any other type of radio) during the 
> last decade. I guess this is says a lot about reality ;) Emmanuel

I think that's a good point that could be clarified.

All I could do, and I already offered to do, is to describe the A-B-C
wifi deployment which works ok with MAC bridging.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Dec 2008 08:26:50 -0800

Hello Alex,

I have to object!!

> to another (instead of experiencing same phenomena on each link layer

Not really.  We've observed that various link technologies exhibit
some or all of the communication problems under consideration.  I do
not want to write a document specific to a particular link technology.
> conclusion could have been avoided.

Interesting story, but not characteristic of the abilities of the people
involved here.  I think we're a bit beyond such knee-jerk reactions
or frog-jumping contests.

> the types of deployments described in the draft (R1,R2,A).

First, you have to be kidding about nontransitivity.  That's obvious.
It even has a famous name -- "hidden terminal" problem.  You can
read about that in a google of places.

Second, take a look at the MIT Roofnet project papers.  That project
was a very strong re-verification of the well-known properties discussed
in the draft, along with numerous implications drawn out for IP routing
protocol behaviors.

I'd be very curious if you could find anyone who has seriously studied
the matter (e.g., refereed publications) to support your position.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Dec 2008 08:33:16 -0800

Hello again Alex,

> wifi deployment which works ok with MAC bridging.

Do you mean to say that we should stop engineering solutions to
ad hoc network problems, and instead all deployments must
install MAC bridging hardware?  What if I want to join a
working ad hoc network of devices using solutions that have
already been developed without bridging?  Why is this bad?

What if there is a hurricane and some of the relief workers
forgot to put their wireless bridging devices in their backpacks?

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 17:46:39 +0100

Charles, hi, thanks for the reply,

Charles E. Perkins wrote:
>> All I could do, and I already offered to do, is to describe the 
>> A-B-C wifi deployment which works ok with MAC bridging.
> 
> Do you mean to say that we should stop engineering solutions to ad 
> hoc network problems, and instead all deployments must install MAC 
> bridging hardware?

Errr... somehow yes, if I'm permitted.  I simply suggest a link-layer
solution to a link-layer problem.

> What if I want to join a working ad hoc network of devices using 
> solutions that have already been developed without bridging?  Why is
>  this bad?

It's not bad.

One would first deploy bridges in networks that are partitioned and in
need of bridges.  Then any new terminal needing to join could do so,
without needing to be itself a bridge.

The question is why does one refuse the use of bridges when the network
is partitioned at link-layer?

> What if there is a hurricane and some of the relief workers forgot to
>  put their wireless bridging devices in their backpacks?

No no... they won't, because they're trained to never forget these
things at home.  And if they do, then there exist other super-reliefs
aids sending them trucks full of these devices.

Alex

> Regards, Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Dec 2008 09:05:30 -0800

Hello Alex,

I think we're approaching the point of having
to agree to disagree.

> solution to a link-layer problem.

IP is a solution that puts together different links.

If you would like to suggest limiting the applicability of IP to
_only_ be allowed to work for links with specific characteristics,
then I think you should be explicit about it.  Perhaps you would
get some support, but I'm guessing it would not arise from the
community of engineers and developers within autoconf or
manet.

>> solutions that have already been developed without bridging?  Why is

Whew!

> is partitioned at link-layer?

That's not a question I have raised, nor do I think that the
answer would be illuminating.  But my answer is that no one
is making any such refusal.

The question is, why can't we use IP as a good tool to solve
problems of connecting together wireless links into a network,
even when bridging solutions are not available?

> aids sending them trucks full of these devices.

Well, here is where we have stark disagreement.  I am surprised if
you truly suggest that IP should not be engineered to work because
it is an "error condition" to not have truckloads of equipment.

Regards,
Charlie P.

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 19 Dec 2008 09:46:27 -0800

Cleanest example is in satellite communications where several pipes are
out-and-out one-way.

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 19 Dec 2008 09:53:28 -0800

You haven't been watching ... both US Army and US Marine Corps are
filling up the space between brigade and company with IEEE 802.16 gear.
And routing it all together.

For military, WiFi is a bauble.  Army worked through a proposal to
implement it in command centers (think tents in the desert) and finally
scrapped the proposal.  Because you could indeed clip the ethernet wire
but not the power cord, so not much payback.  And in order to get that
niggardly payback they were going to pay a lot for a layer 2 encryption
solution.  Spent the money on .16 gear instead ...

This is wide of the MANET issues.  But MANET (and autoconf) is
applicable to a lot of wireless LAN and radio-WAN problems well beyond
WiFi.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 18:58:23 +0100

> And routing it all together.

IETF has specs for IPv6 over 802.16 gear.  It works, it's been 
experimented.  The A-B-C terminal problem wasn't mentioned.

> applicable to a lot of wireless LAN and radio-WAN problems well beyond

AS above, IPv6 over 802.16 works has been implemented, from emulators to 
the real link layer.

What other link layer?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 18:58:48 +0100

Charles E. Perkins wrote:
> Hello Alex,
> 
> I think we're approaching the point of having to agree to disagree.
 >
>> Errr... somehow yes, if I'm permitted.  I simply suggest a
>> link-layer solution to a link-layer problem.
> 

Yes, provided IP knows what are those links, each one in particular detail.

> then I think you should be explicit about it.

YEs, I'm explicit: it's wifi.

> Perhaps you would get some support, but I'm guessing it would not
> arise from the community of engineers and developers within autoconf
> or manet.
> 
> 
>> 
>>>  solutions that have already been developed without bridging?
>>> Why is this bad?
>> 
>> It's not bad.
> 
> Whew!
> 
>> 
>> One would first deploy bridges in networks that are partitioned and
>> in need of bridges.  Then any new terminal needing to join could do
>> so, without needing to be itself a bridge.
>> 
>> The question is why does one refuse the use of bridges when the
>> network is partitioned at link-layer?
> 
> That's not a question I have raised, nor do I think that the answer
> would be illuminating.  But my answer is that no one is making any
> such refusal.
> 
> The question is, why can't we use IP as a good tool to solve problems
> of connecting together wireless links into a network, even when
> bridging solutions are not available?

WE need to be able to know over what is IP supposed to run.  If we don't 
have a good under-IP then it can't run.  Actually we could think as much 
it will run as we think it won't run.  Sorry, I can't be clearer than that.

Alex

>> things at home.  And if they do, then there exist other
>> super-reliefs aids sending them trucks full of these devices.
> 
> you truly suggest that IP should not be engineered to work because it
> is an "error condition" to not have truckloads of equipment.
> 
> 
> Regards, Charlie P.
> 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 19:01:38 +0100

Rex Buddenberg wrote:
> Cleanest example is in satellite communications where several pipes
> are out-and-out one-way.

Hi Rex, sorry, I don't know the terms.  But I could legitimately ask
about the name of the link layer for out-and-out one-way.

I think I know about some specs for IP over uni-directional links (UDLR)
and some implementations for it.

Alex

>> |>>> 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. |> |>> Sorry, could one mention why?
>> What's the example of this? |> |> The simplest example (but by no
>> means the only) is different power |> levels transmitted by A and
>> C. | |And isn't it the same for wired communications ?  (and would
>> a potential |solution to this to have the same power levels
>> transmitted by A and C?)
>> 
>> _______________________________________________ Autoconf mailing
>> list [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Dec 2008 10:19:17 -0800

Hello Alex,

> Yes, provided IP knows what are those links, each one in particular 

Actually, all that is needed is for IP to have a useful interface to the
device driver.

> YEs, I'm explicit: it's wifi.

That restriction is not in the charter.  Do you want to campaign
for a charter revision?

> WE need to be able to know over what is IP supposed to run.  If we 
> don't have a good under-IP then it can't run.  Actually we could think 
> as much it will run as we think it won't run.  Sorry, I can't be 
> clearer than that.

But is does run.  I guess that's also pretty clear.

I'd like for it to run using standard protocols.

And not just for WiFi.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 19 Dec 2008 19:36:10 +0100

|YEs, I'm explicit: it's wifi.

Please explain to me how I can connect couples of hosts to wifi bridges
configured in ad hoc mode.
Hint: A bridge shall not connect to an IEEE 802.11 Independent BSS
(802.1D-2004)

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 19:39:17 +0100

> Actually, all that is needed is for IP to have a useful interface to the

I agree.  Device driver interfaces are known for several wireless link 
layers.  I think there isn't one special for the A-B-C hidden terminal 
problem.  I may be wrong, but I think.

> That restriction is not in the charter.  Do you want to campaign

Right... No, no, I don't want to restrict to wifi.  I think the A-B-C 
hidden terminal problem was mentioned in the wifi context.  I haven't 
seen it elsewhere.

I agree for a solution IP to run over several link layers, for example 
wifi and 802.16.

When a router needs to route between a wifi and a 802.16 link it never 
has the hidden terminal problem.

> I'd like for it to run using standard protocols.

Yes, I'd like to help with a protocol for wireless links, like wifi and 
802.16.  But routing between these two doesn't expose the hidden 
terminal problem.  I'm pretty sure about it, I can say that because I 
have experience with IP over wifi and over 802.16 (emulated) links.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 19:40:49 +0100

> Hint: A bridge shall not connect to an IEEE 802.11 Independent BSS

The picture I can draw has a bridge with two wifi interfaces and runs 
brctl software (which is pure link-layer, no IP).  Would this be ok if I do?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Dec 2008 10:54:08 -0800

Hello again Alex,

> problem.  I may be wrong, but I think.

That's because IP doesn't need to know whether the link
has problems with hidden terminals.

> has the hidden terminal problem.

The main thing a router needs, is to know the next hop.

>
>
>
> Yes, I'd like to help with a protocol for wireless links, like wifi 
> and 802.16.  But routing between these two doesn't expose the hidden 

Again, routing doesn't need to know about that.  And, in fact,
I believe that IP doesn't have to know about asymmetry, nontransitivity,
or the time of day.  It just has to know about the next hop.

But the routing protocols have to be engineered to provide that
information.  And, as this overly long and time-consuming discussion
has shown, there is a bit of confusion about how to engineer
routing protocols that work over the links under discussion.

You seem to claim that we shouldn't worry about them because
the link layer has to solve problems like asymmetry and hidden
terminal problems.  I'm of the opinion that routing protocols have
to be engineered in some circumstances to avoid making
unwarranted inferences about symmetry and transitivity.

I think it would be nice to identify exactly what your concern is.
Once it was WiFi only, now it's not.  Do you think that routing
protocol work should only be chartered for links that conform to
certain regularity assumptions like symmetry and transitivity?

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 19 Dec 2008 20:42:11 +0100

Try it, and you will see it will fail.
OK, you can modify the code if you have a C compiler nearby, and some
sources to modify.
But that is no longer wifi.

You could enable routing, and you are done!
Play a little with it, and check your (false) assumptions.

Teco.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 19 december 2008 19:41
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication
|
|Teco Boot wrote:
|> |YEs, I'm explicit: it's wifi.
|>
|> Please explain to me how I can connect couples of hosts to wifi
|bridges
|> configured in ad hoc mode.
|> Hint: A bridge shall not connect to an IEEE 802.11 Independent BSS
|> (802.1D-2004)
|
|The picture I can draw has a bridge with two wifi interfaces and runs
|brctl software (which is pure link-layer, no IP).  Would this be ok if I
|do?
|
|Alex
|
|
|______________________________________________________________________
|This email has been scanned by the MessageLabs Email Security System.
|For more information please visit http://www.messagelabs.com/email
|______________________________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 21:04:27 +0100

> OK, you can modify the code if you have a C compiler nearby, and some

I'm not meaning to modify any code.  It's existing software doing 
bridging between two interfaces as it always did.

> But that is no longer wifi.

Well, it's two 802.11a/b interfaces, running as before.  I could put 
both interfaces in ad-hoc mode with iwconfig.  There's probably a 
misunderstanding between what the IEEE standard documents mean by 
"ad-hoc" and what iwconfig and related implementations mean by "ad-hoc" 
but I'm sure it works, by experience.

Or I could set up both to act as access points, it's the same.  (the 
only visible difference  between AP mode and ad-hoc modes in 
implementation is the MAC address of the essid... in AP mode it's the 
real MAC address of the interface doing AP, in ad-hoc mode it's some 
random 48bit).  The resolution between this 48bit number and essid ascii 
name is done by 802.11 link-layer exchanges (probe req/reply IIRC).

> You could enable routing, and you are done!

Why doing routing when I could do bridging, simpler, widely available 
software.

> Play a little with it, and check your (false) assumptions.

I'm not sure which assumption you think I made false?  The fact that I 
could build a bridge with brctl and two wifi interfaces?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 21:12:19 +0100

Charles please let me bring forward a clarifying point, which is your
last point, and sorry for too long emails.

> Do you think that routing protocol work should only be chartered for
>  links that conform to certain regularity assumptions like symmetry 
> and transitivity?

Is this a MANET WG question?

I think in AUTOCONF WG we don't do work that applies _only_ to DYMO, nor
to OLSR, nor to DSR.

In this case, an AUTOCONF address and prefix configuration mechanism
would be used too by something else than DYMO, other than OLSR, other
than DSR.  It could be used by two Mobile Routers not running DYMO, nor
OLSR, nor DSR.

It's very straightforward to clarify this particular point, people could
and have expressed opinions.

If the AUTOCONF mechanism is to be only for DYMO/OLSR/DSR exclusively
then I just say ok for the draft titled 'aspects of multi-hop...'.

The points I mainly agree with you follow below...

Charles E. Perkins wrote:
>>> Actually, all that is needed is for IP to have a useful interface
>>>  to the device driver.
>> 
>> I agree.  Device driver interfaces are known for several wireless 
>> link layers.  I think there isn't one special for the A-B-C hidden 
>> terminal problem.  I may be wrong, but I think.
> 
> That's because IP doesn't need to know whether the link has problems 
> with hidden terminals.

I fully agree.

>>  and 802.16.  But routing between these two doesn't expose the 
>> hidden terminal problem.  I'm pretty sure about it, I can say that 
>> because I have experience with IP over wifi and over 802.16 
>> (emulated) links.
> 
> Again, routing doesn't need to know about that.  And, in fact, I 
> believe that IP doesn't have to know about asymmetry,
> nontransitivity, or the time of day.  It just has to know about the
> next hop.

I partially agree (may need link quality params, maybe expressed as TOS
in OSPF, for better decisions) but in this discussion context I fully agree.

> You seem to claim that we shouldn't worry about them because the link
>  layer has to solve problems like asymmetry and hidden terminal 
> problems.  I'm of the opinion that routing protocols have to be 
> engineered in some circumstances to avoid making unwarranted 
> inferences about symmetry and transitivity.

Maybe yes, but maybe in MANET WG?

> Once it was WiFi only, now it's not.

Sorry, to make myself clear: in this discussion wifi and 802.16 were
mentioned.  I agree both should be dealt with.  I don't agree to deal
with a link-layer whose name I don't know.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Dec 2008 12:52:22 -0800

Hello again Alex,

> Is this a MANET WG question?

It is a question that you could use to explain your view of how
to engineer solutions for wireless networks.

> I think in AUTOCONF WG we don't do work that applies _only_ to DYMO, nor

Actually, I'd say the same thing about [manet] wg.  And, the authors of
TBRPF and many others would bristle that you didn't mention them.

> then I just say ok for the draft titled 'aspects of multi-hop...'.

The existing [autoconf] solutions (not yet working group documents)
that motivated the creation of the group _did_ have to face the same
issues as we have been discussing in the context of engineering routing
protocols.

> Maybe yes, but maybe in MANET WG?

I'm also of the opinion that there is going to be some
overlap between the mechanisms for address assignment,
and the routing protocols.  For instance, it is very reasonable
to use a multi-hop gateway beacon to advertise information
relevant to address assignment.  I do not say that it is
absolutely required to be this way, but on the other hand
solutions that take care to avoid the pitfalls under discussion
are, in my opinion, more likely to succeed than other more
brute force solutions.

> with a link-layer whose name I don't know.

But, on the other hand, if a solution that works for 802.{11*,16,...} is
created in a way that is cognizant of the wireless characteristics as we
have described in our Internet Draft, then it is _more likely_ to work for
the other unspecified but presumably similar media.

Which is why we wrote it.

Do you disagree with this motivation?

Regards,
Charlie P.

---

From: Paul Lambert <[email-masked]>
Date: Fri, 19 Dec 2008 13:34:45 -0800

Hi,

It's great having a clear set of definitions to better describe our problem space.

It is good to be able to have a common understanding of asymmetric, non-transitive, and time-varying issues - however I feel strongly that all of these attributes should not be used to characterize all ad hoc networks.   Specifically - asymmetric networks are interesting, but they are an anomaly that is not present in most commercial link layer protocols.  At the link layer, radio networks are clearly asymmetric - but the data transfer services used to carry IP packets are acknowledged reliable link transmissions (aka bi-directional - not asymetric).

In this context it would be useful to be able to distinguish symmetric ad hoc networks versus non-symmetric ad hoc networks.  Can these be broken out as separate use cases in the definitions?

In this context I'd propose that you change in section 3 (and similar locations):

                We may say that router A has a link to router B. In this

      terminology, there is no guarantee that router B has a link to

      router A.
to

        We may say that router A has a link to router B. In this

      terminology, there is no guarantee in an asymmetric network that router B has a link to

      router A.

Other topics that I do not see fully defined are the:
- differences in link setup requirements and
- in the nature of a ad hoc networks support for multicast.

On link setup - it's often assumed that wireless communications once configured will allow communications between all peers without any explicit association or connection.  This has historically been a model of ad hoc communications (at least for 802.11).  Going forward (assuming IBSS is not displaced from Wi-Fi usage), this model must change to support link layer security.  Security is essentially connection oriented.  Every pairwise communication currently requires an explicit connection establishment (aka WPA 4-way handshake).  This connection is required for both unicast and any multicast communications (due to per device multicast key).  These means that for two devices on network to "hear" each other they had to first establish a explicit WPA  link layer 'connection'.

So Multicast then becomes a issue - not all ad hoc networks will have an ability  to support multicast.   This has considerable implications for the design of mechanisms for IP address assignment.

Regards,

Paul

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Baccelli
Sent: Friday, December 19, 2008 1:19 AM
To: [email-masked]
Subject: [Autoconf] aspects of multi-hop wireless communication

Hi all,

here's a draft that aims at describing important aspects of multi-hop wireless communication, as observed over the past decade of experience with such networks.

The goal of this document is to identify a consensus about this topic, and then use this to move on quicker with the working group documents.

cheers
Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Dec 2008 23:20:31 +0100

Hello Charles,

[..]
>> I think in AUTOCONF WG we don't do work that applies _only_ to 
>> DYMO, nor to OLSR, nor to DSR.
> 
> Actually, I'd say the same thing about [manet] wg.  And, the authors
>  of TBRPF and many others would bristle that you didn't mention them.
> 
Sorry, it wasn't intentional.  TBRPF too for MANET.

[...]
> I'm also of the opinion that there is going to be some overlap 
> between the mechanisms for address assignment, and the routing 
> protocols.  For instance, it is very reasonable to use a multi-hop 
> gateway beacon to advertise information relevant to address 
> assignment.  I do not say that it is absolutely required to be this 
> way, but on the other hand solutions that take care to avoid the 
> pitfalls under discussion are, in my opinion, more likely to succeed
>  than other more brute force solutions.

Well I'm not looking at brute force solutions, but solutions to simpler
problems.  The advertising you mention - could work without taking into
considerations the asymmetricity/nontransitivity, if we think it's about 
Router Advertisements.

> But, on the other hand, if a solution that works for 802.{11*,16,...}
>  is created in a way that is cognizant of the wireless 
> characteristics as we have described in our Internet Draft, then it 
> is _more likely_ to work for the other unspecified but presumably 
> similar media.
> 

No, I don't disagree with that motivation - supposedly if it works for 
non-transitive links it will work for transitive links too.  I just look 
at it as something which may be too much for simpler needs.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Dec 2008 14:20:55 -0800

Hello Paul,

Follow-up inline below...

Paul Lambert wrote:
>
> It is good to be able to have a common understanding of asymmetric, 
> non-transitive, and time-varying issues – however I feel strongly that 
> all of these attributes should not be used to characterize all ad hoc 
> networks.
>

Agreed -- but we are not proposing to do that. I suggest instead that,
when designing protocols for ad hoc networks, we keep these potential
characteristics in mind so that our results will be applicable to such
networks. If it turns out that a simpler protocol would be helpful for
a symmetric, transitive, stable network, then that would be a useful
additional goal.

> Specifically – asymmetric networks are interesting, but they are an 
> anomaly that is not present in most commercial link layer protocols. 
> At the link layer, radio networks are clearly asymmetric – but the 
> data transfer services used to carry IP packets are acknowledged 
> reliable link transmissions (aka bi-directional – not asymetric).
>

This is not really true. Again, look at Roofnet for some examples.

I do not remember seeing any requirement that IP should run
only over acknowledged media. In fact, we have UDP for
such cases.

> In this context it would be useful to be able to distinguish symmetric 
> ad hoc networks versus non-symmetric ad hoc networks. Can these be 
> broken out as separate use cases in the definitions?
>

Which definitions? To reiterate, it is not the purpose of the document
to define ad hoc networks as just those networks that exhibit all of the
abovementioned characteristics.

> In this context I’d propose that you change in section 3 (and similar 
> locations):
>
>       terminology, there is no guarantee _in an asymmetric network_ that router B has a link to
>       router A.

This is reasonable... a matter of wordsmithing to maintain
readability while still avoiding overly tedious correctness.
How about, instead, if we just preface these examples with
a paragraph that makes it clear what kind of networks we
are describing?

> On link setup – it’s often assumed that wireless communications once 
> configured will allow communications between all peers without any 
> explicit association or connection. This has historically been a model 
> of ad hoc communications (at least for 802.11). Going forward 
> (assuming IBSS is not displaced from Wi-Fi usage), this model must 
> change to support link layer security. Security is essentially 
> connection oriented. Every pairwise communication currently requires 
> an explicit connection establishment (aka WPA 4-way handshake). This 
> connection is required for both unicast and any multicast 
> communications (due to per device multicast key). These means that for 
> two devices on network to “hear” each other they had to first 
> establish a explicit WPA link layer ‘connection’.
>

Really, I would hope to avoid these issues in our very simple draft.
In fact, I would insist.

It is not to say that they are not important. But it is just too far afield
from the very simple ideas we are trying to put forth.

> So Multicast then becomes a issue – not all ad hoc networks will have 
> an ability to support multicast. This has considerable implications 
> for the design of mechanisms for IP address assignment.
>

I'd be happy to discuss this with you, and it is appropriate for 
[autoconf] wg,
but again I'd insist on keeping multicastability out of scope for our very
simple draft.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Dec 2008 15:06:34 -0800

Hello Alex,

Alexandru Petrescu wrote:
> considerations the asymmetricity/nontransitivity, if we think it's 
> about Router Advertisements.

This is the crux of the discussion, and what I claim you have
to decide about.  Either you want to restrict the effort to
only links which are unaffected by asymmetry/nontransitivity,
or not.  If you want to make the restriction, and yet the
group is chartered to create solutions for networks that
do not adhere to the restrictions, then I think it means that
you need to charter another group or build support for
rechartering [autoconf].
> non-transitive links it will work for transitive links too.  I just 
> look at it as something which may be too much for simpler needs.

This is the same point, reformulated.  You would like to deal
only with simpler networks, and seem to claim that is sufficient.
Perhaps at the cost of truckloads of repeaters for disaster
situations?

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Dec 2008 00:55:04 +0100

Charles E. Perkins wrote:
>> Well I'm not looking at brute force solutions, but solutions to 
>> simpler problems.  The advertising you mention - could work without
>>  taking into considerations the asymmetricity/nontransitivity, if
>> we think it's about Router Advertisements.
> 
> This is the crux of the discussion, and what I claim you have to 
> decide about.  Either you want to restrict the effort to only links 
> which are unaffected by asymmetry/nontransitivity, or not.  If you 
> want to make the restriction, and yet the group is chartered to 
> create solutions for networks that do not adhere to the restrictions,
>  then I think it means that you need to charter another group or
> build support for rechartering [autoconf].

Eh, I was looking at it as inserting a little effort into an already
large effort.

Chartering another group or build support for rechartering already
happened while MANEMO and it didn't work.  Nothing worked since anyways, so.

>>> But, on the other hand, if a solution that works for 
>>> 802.{11*,16,...} is created in a way that is cognizant of the 
>>> wireless characteristics as we have described in our Internet 
>>> Draft, then it is _more likely_ to work for the other unspecified
>>>  but presumably similar media.
>>> 
>> No, I don't disagree with that motivation - supposedly if it works 
>> for non-transitive links it will work for transitive links too.  I 
>> just look at it as something which may be too much for simpler 
>> needs.
> 
> This is the same point, reformulated.  You would like to deal only 
> with simpler networks, and seem to claim that is sufficient. Perhaps 
> at the cost of truckloads of repeaters for disaster situations?

:-)

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 20 Dec 2008 10:31:08 +0100

|> Try it, and you will see it will fail.
|> OK, you can modify the code if you have a C compiler nearby, and some
|> sources to modify.
|
|I'm not meaning to modify any code.  It's existing software doing
|bridging between two interfaces as it always did.

No, you are prohibited to add a 802.11 IBSS interface to a bridge.

OK, you can do it without warnings, but the 802.11 mechanisms will not
operate as they should. There are problems with address fields, the NIC
cannot send CTS or ACK to the sender, because the transmitter MAC address is
missing in the RTS or DATA MAC header.
You could disable RTS-CTS and send unicast frames until retry limit, but is
this the behavior that you suggest?

|> But that is no longer wifi.
|
|Well, it's two 802.11a/b interfaces, running as before.  I could put
|both interfaces in ad-hoc mode with iwconfig.  There's probably a
|misunderstanding between what the IEEE standard documents mean by
|"ad-hoc" and what iwconfig and related implementations mean by "ad-hoc"
|but I'm sure it works, by experience.

I am not aware with problems with iwconfig. It should configure the NIC in
IBSS mode. 

|Or I could set up both to act as access points, it's the same.  (the
|only visible difference  between AP mode and ad-hoc modes in
|implementation is the MAC address of the essid... in AP mode it's the
|real MAC address of the interface doing AP, in ad-hoc mode it's some
|random 48bit).  The resolution between this 48bit number and essid ascii
|name is done by 802.11 link-layer exchanges (probe req/reply IIRC).

There are lots of other differences between IBSS and BSS.

On (R1, R2, A):
What if A is STA and R1 and R2 are APs? Assume APs cannot communicate with
each other (no DS). Assume some kind of disaster.

One could deploy dense APs and a (to be standardized) form of mesh MANET
protocol. This could be disaster^2! 
(think of beacon-rain and probe-response-storms, and melt downs due to
collisions)

|> You could enable routing, and you are done!
|
|Why doing routing when I could do bridging, simpler, widely available
|software.

Try and you will see lots of shortcomings with bridging and 802.11 IBSS.
I am not saying it cannot be solved at a shim layer, but please accept this
is not supported by current wifi standards.

And provide evidence if I am wrong. I will ask errata on the IEEE 802
standards if you come up with it.

|> Play a little with it, and check your (false) assumptions.
|
|I'm not sure which assumption you think I made false?  The fact that I
|could build a bridge with brctl and two wifi interfaces?

I explained above your assumption is false. I analyzed your suggestions
before and my conclusion 802.1D bridging is indeed not allowed with 802.11
IBSS.

By the way, there is code around that improves 802.11 IBSS mode, so bridging
is allowed. Ask Ronald In't Velt for details. This could be very useful if
you want to connect a 802.11 IBSS bridge to a router (split devices) or just
connect a couple of hosts to an ad hoc bridge.

Teco.

---

From: "Seung Yi" <[email-masked]>
Date: Sat, 20 Dec 2008 16:48:34 -0800

Just one simple comment unrelated to the ongoing interesting discussion threads.

Isn't the definition of transitivity "If A->B and B->C, then A->C"?
This document seems to use the term to mean "if A->B and A->C, then
B->C" in Section 2, second point.

- Seung

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 20 Dec 2008 17:10:00 -0800

Hello Seung,

Yes, of course you are right (embarrassment).

What is a good name for the property under discussion?

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Sun, 21 Dec 2008 12:59:41 +0100

What about a small adjustment:

   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 have symmetric communication with 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".  Such non-
   transitivity is often observed on multi-hop ad hoc wireless networks,
   due to well-known properties of wireless communication.

Now it says: "If R1->A and A->R2, there is no guarantee for R1->R2".
And the second behavior is not mixed up with the first one.

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Charles E. Perkins
|Verzonden: zondag 21 december 2008 2:10
|Aan: Seung Yi
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication
|
|
|Hello Seung,
|
|Yes, of course you are right (embarrassment).
|
|What is a good name for the property under discussion?
|
|Regards,
|Charlie P.
|
|
|Seung Yi wrote:
|> Just one simple comment unrelated to the ongoing interesting
|discussion threads.
|>
|> Isn't the definition of transitivity "If A->B and B->C, then A->C"?
|> This document seems to use the term to mean "if A->B and A->C, then
|> B->C" in Section 2, second point.
|>
|> - Seung
|>
|> 2008/12/19 Emmanuel Baccelli <[email-masked]>:
|>
|>> Hi all,
|>> here's a draft that aims at describing important aspects of multi-hop
|>> wireless communication, as observed over the past decade of
|experience with
|>> such networks.
|>> The goal of this document is to identify a consensus about this
|topic, and
|>> then use this to move on quicker with the working group documents.
|>>
|>> Please review it, and provide feedback as soon as possible.
|>> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-
|communication-00
|>>
|>> cheers
|>> Emmanuel
|>> _______________________________________________
|>> Autoconf mailing list
|>> [email-masked]
|>> https://www.ietf.org/mailman/listinfo/autoconf
|>>
|>>
|>>
|> _______________________________________________
|> Autoconf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/autoconf
|>
|>
|>
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Seung Yi" <[email-masked]>
Date: Sun, 21 Dec 2008 15:00:17 -0800

I'm sorry but it sounds even more confusing to me.

I'm not sure what to call it but it seems to describe the hidden
terminal problem to me. Or, it's simply saying that the link (or
whatever you want to call the "S") is of non-broadcast flavor because
R1 and R2 can expect to hear each other only when the medium itself
provides broadcast capability as in the Ethernet.

- Seung

---

From: "Breno Jacinto" <[email-masked]>
Date: Sun, 21 Dec 2008 21:53:47 -0300

Hello,

     That's a very interesting discussion, indeed. I didnt see anyone
mentioning related work about underlay networking (meaning: routing
below IP), and there has been some interesting work in academia, as
well as some practical efforts to prove the concept. Since this is my
line of research currently, let me cite some of the related work:

- 802.1D bridging: as Alexandru cited, that is an already available
implementation, stable and functional and can do bridging and create
an illusion for IP that there is a simple Ethernet network below it.
Now, as Teco mentioned, I also could NOT make it work with 802.11 in
*AD-HOC* mode (Alexandru, I'd be glad to know how you managed to do it
without any special patch or tweak on the drivers, using just the
standard). Other people tried with AP mode and it works (and this is
expected, as the popular APs such as WRT54G do it for Ethernet and
802.11 networks).

- 802.11s (http://en.wikipedia.org/wiki/IEEE_802.11s): nobody cited
it, but this standard is supposed to implement multi-hopping at layer
2, instead of layer 3 as all Ad Hoc protocols do (OLSR, AODV etc...).
As everyone knows, 802.11 b/g standard does not support multi-hop for
real.

- AWDS (http://awds.berlios.de/) - Ad Hoc Wireless Distribution
System. This project is quite stable and functional implementation a
layer 2 protocol for doing multi-hop communication over ordinary
802.11 b/g cards. Now, to me this is pretty much what 802.11s is
attempting to do, but does it now. It works, and it is being tested in
test-beds today. It is a very active project, but it seems it hasnt
got very popular up to now.

- Ana4 Framework (http://ana4.citi.insa-lyon.fr/): An academic
initiative with the intention of transparent connecting heterogeneous
networks at the underlay, i.e., at a virtual 2.5 layer. It is supposed
to work with any link-layer, including Bluetooth, but actually they
just implemented for Ethernet and 802.11 ad hoc networks. I tested it,
and it works. It's like bridging, but it actually does real routing in
a virtual network (and I could interconnect an Ethernet and 802.11 ad
hoc network).

- MIT RoofNet (http://pdos.csail.mit.edu/roofnet/) and B.A.T.M.A.N
(http://en.wikipedia.org/wiki/B.A.T.M.A.N.),  are, as far as I can
tell, implemented as a layer 2.5 protocol. Unfortunately I could not
study them deeply enough to confirm this, maybe someone on the list
can.

     Now, going back to this draft, which I believe to be of utmost
importance, I think some questions must be answered as well:

- Should Mult-hop communications happen at the IP layer, really? I
think that this decision was taken just because 802.11 b/g standard
become popular and could not do multi-hop at layer 2. So, everyone
thought, let's do it at layer 3, because it is possible to emulate
multi-hop then.

- If multi-hopping is done at layer 2, isn't that a good thing? I
mean, you can deal with problems specific to the link layer (including
the aforementioned hidden node problem, or whatever
next-popular-link-layer for multi-hop become available in the future)
and make IP more neutral. I think that would conserve the initial aim
of IP, which is simply to glue heterogeneous networks, not fixing a
particular link-layer problem as it is being done with 802.11 b/g.

- Now, if we could assume that multi-hop is done at layer 2; to layer
3 (such as IP), a broadcast should reach (be flooded to) everyone in
the network. Now, IP sees the network as a single broadcast domain and
issues in the "real" network should be dealt there. We may then shift
to the problem of connecting multiple ad hoc networks at the IP layer,
doing inter-domain routing etc..

    I'm sorry for so many observations: I hope to contribute for the
discussion and show some of the research that's been done in the last
years in ad hoc networking (and not everyone is aware of, I think).

regards,
-- 
-- 
:: 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.  ::

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 21 Dec 2008 19:35:51 -0800

Hello Breno,

> thought, let's do it at layer 3, because it is possible to emulate

I think this is not an accurate reflection of the evolution of thought
on the subject.  At least for me, it was clear that one could easily
make a routing solution by revising RIP to get rid of poison reverse
and other hacks, so that we could have just the next-hop routing
as needed.  This was a very long time before 802.11.

Your word "should" is loaded.  IP is, I think, great at stitching together
links into a network.  They don't even have to be the same physical
media.  That's a major plus compared to layer 2 solutions.  Plus,
the same layer 3 solution works for a lot of different wireless physical
media.  That's better than blasting away with different solutions for
each different medium.

I just don't see what's wrong with it.

> particular link-layer problem as it is being done with 802.11 b/g.

There is no free lunch.  You are going to solve those problems at layer 3,
or you are going to solve them at layer 2.  And, even if the latter, you may
still have to worry about it at layer 3 unless you impose some very strong
regularity conditions (I'm still puzzling over truckloads of repeaters).

> doing inter-domain routing etc.

There's that "should" again.  In fact, your very example of broadcast
disproves your point: what if the best broadcast used multiple media?

Regards,
Charlie P.

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Mon, 22 Dec 2008 09:47:39 +0100

> regularity conditions (I'm still puzzling over truckloads of repeaters).

First, this is not just about 802.11 b/g. The same behavior was observed
with other radio MAC, such as simple proprietary sensor "MAC" layers for
example, and there are many other examples. One can also anticipate some
future L2 standards that will have the same properties.

We are dealing with a specific _category_ of networks here. And thus, this
would not be the first time that something special is done at L3 to cope
with a specific category of L2 networks. Lets recall different OSPF
interface types, for instance.

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 22 Dec 2008 09:48:01 +0100

I tried to get rid of B->A and C->A and [NOT B->A].

Somewhat adjusted proposal, and using C and D and not the newly 
introduced R1 and R2:

 Second, there is no guarantee that two given routers within S can
 directly communicate with one another.  In other words, even though
 two routers C and D have symmetric communication with router A, there is
 no guarantee that C can hear packets from D, and there is likewise
 no guarantee that D can hear packets from C.  Thus, multi-hop ad
 hoc wireless communications may be "non-transitive".  Such non-
 transitivity is often observed on multi-hop ad hoc wireless networks,
 due to well-known properties of wireless communication.

Now C->A and A->D, but [NOT C->D] and also D->A and A->D, but [NOT D->C].
This characteristic is "non-transitive" and it is orthogonal with
"asymmetry".

Your terms "hidden terminal problem" and "non-broadcast" could be used 
as alternative terminology, but could have different meanings in 
different context.
  o  "hidden terminal problem" could have to do with collisions.
  o  "non-broadcast" does not apply here, because set S contains at 
     least 3 routers (B, C, D).
     Term "Semi-Broadcast" (I-D.ietf-autoconf-manetarch) was introduced,
     where S is subset of N. (N is all nodes in network N). I suggested
     not introducing new terms if they not needed.

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens Seung Yi
|Verzonden: maandag 22 december 2008 0:00
|Aan: Teco Boot
|CC: Charles E. Perkins; [email-masked]
|Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication
|
|I'm sorry but it sounds even more confusing to me.
|
|I'm not sure what to call it but it seems to describe the hidden
|terminal problem to me. Or, it's simply saying that the link (or
|whatever you want to call the "S") is of non-broadcast flavor because
|R1 and R2 can expect to hear each other only when the medium itself
|provides broadcast capability as in the Ethernet.
|
|- Seung
|
|On Sun, Dec 21, 2008 at 3:59 AM, Teco Boot <[email-masked]> wrote:
|> What about a small adjustment:
|>
|>   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 have symmetric communication with 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".  Such non-
|>   transitivity is often observed on multi-hop ad hoc wireless
|networks,
|>   due to well-known properties of wireless communication.
|>
|>
|> Now it says: "If R1->A and A->R2, there is no guarantee for R1->R2".
|> And the second behavior is not mixed up with the first one.
|>
|> Teco.
|>
|> |-----Oorspronkelijk bericht-----
|> |Van: [email-masked] [mailto:[email-masked]]
|Namens
|> |Charles E. Perkins
|> |Verzonden: zondag 21 december 2008 2:10
|> |Aan: Seung Yi
|> |CC: [email-masked]
|> |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication
|> |
|> |
|> |Hello Seung,
|> |
|> |Yes, of course you are right (embarrassment).
|> |
|> |What is a good name for the property under discussion?
|> |
|> |Regards,
|> |Charlie P.
|> |
|> |
|> |Seung Yi wrote:
|> |> Just one simple comment unrelated to the ongoing interesting
|> |discussion threads.
|> |>
|> |> Isn't the definition of transitivity "If A->B and B->C, then A->C"?
|> |> This document seems to use the term to mean "if A->B and A->C, then
|> |> B->C" in Section 2, second point.
|> |>
|> |> - Seung
|> |>
|> |> 2008/12/19 Emmanuel Baccelli <[email-masked]>:
|> |>
|> |>> Hi all,
|> |>> here's a draft that aims at describing important aspects of multi-
|hop
|> |>> wireless communication, as observed over the past decade of
|> |experience with
|> |>> such networks.
|> |>> The goal of this document is to identify a consensus about this
|> |topic, and
|> |>> then use this to move on quicker with the working group documents.
|> |>>
|> |>> Please review it, and provide feedback as soon as possible.
|> |>> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-
|> |communication-00
|> |>>
|> |>> cheers
|> |>> Emmanuel
|> |>> _______________________________________________
|> |>> Autoconf mailing list
|> |>> [email-masked]
|> |>> https://www.ietf.org/mailman/listinfo/autoconf
|> |>>
|> |>>
|> |>>
|> |> _______________________________________________
|> |> Autoconf mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/autoconf
|> |>
|> |>
|> |>
|> |
|> |_______________________________________________
|> |Autoconf mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/autoconf
|>
|>

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Mon, 22 Dec 2008 10:17:24 +0100

Hi Teco,yes I agree, the term "non-transitive" was not very
straightforwardly used. Saying as you propose would be better, more
precisely (correct me if I'm mistaken about what you meant), that if:
C and A can hear each other through A's interface, and,
A and D can hear each other through A's interface, then
it does not mean that C can hear D or that D can hear C

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 22 Dec 2008 10:59:16 +0100

Oeps, I forgot to include a minor adjustment on "First":

c/C/B/
 First, there is no guarantee that a router B within S can,
 symmetrically, send IP packets directly to router A. In other words,
 even though B 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 B.
 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.

Above "First", routers A and B are introduced. Here, A "sends" 
and B "hears". OK for me. 
In "First", the same topology is used: A "sends" and B "hears".

For "Second", I introduced routers C and D for non-transitive, 
as B was used for asymmetry. 
B, C and D are in set S.

===========

> yes I agree, the term "non-transitive" was not very straightforwardly 
> used. Saying as you propose would be better, more precisely (correct 
> me if I'm mistaken about what you meant), that if:

Yes, this is correct.
You introduced "interface". More complete text:
 C and A can hear each other through A's and C's interface to 
 network N, and
 A and D can hear each other through A's and D's interface to 
 network N, then
 it does not mean that C can hear D or that D can hear C through 
 C's and D's interface to network N.

Maybe check I-D text on "node".
Example: "router A is reachable from node B"
c/node/router/  ?? 
Except first quote: "node equals router", section 2, 1st paragraph.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Dec 2008 11:43:32 +0100

> No, you are prohibited to add a 802.11 IBSS interface to a bridge.

TEco, I can report more details about this particular experiment early 
next year about the experiment, if you wish.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 22 Dec 2008 12:37:08 +0100

|Teco Boot wrote:
|> |> Try it, and you will see it will fail.
|> |> OK, you can modify the code if you have a C compiler nearby, and
|some
|> |> sources to modify.
|> |
|> |I'm not meaning to modify any code.  It's existing software doing
|> |bridging between two interfaces as it always did.
|>
|> No, you are prohibited to add a 802.11 IBSS interface to a bridge.
|
|TEco, I can report more details about this particular experiment early
|next year about the experiment, if you wish.

Yes, I am interested.
I'll compare your results with the nonstandard implementation from Ronald
(http://madwifi-project.org/ticket/1131). It would be discouraging for him
if his work is needless.

Teco.

|Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Dec 2008 14:09:40 +0100

Teco Boot wrote:
> |Teco Boot wrote: |> |> Try it, and you will see it will fail. |> |> 
> OK, you can modify the code if you have a C compiler nearby, and 
> |some |> |> sources to modify. |> | |> |I'm not meaning to modify any
>  code.  It's existing software doing |> |bridging between two 
> interfaces as it always did. |> |> No, you are prohibited to add a 
> 802.11 IBSS interface to a bridge. | |TEco, I can report more details
>  about this particular experiment early |next year about the 
> experiment, if you wish.
> 
> Yes, I am interested. I'll compare your results with the nonstandard 
> implementation from Ronald (http://madwifi-project.org/ticket/1131). 
> It would be discouraging for him if his work is needless.

Hi Teco, and thanks to Ronald for the madwifi patch.

I wanted to say I didn't consider the madwifi driver, I think
bridging+adhoc would work without madwifi but with offtheshelf drivers.
  It is something I should confirm later.

About the madwifi bridging adhoc patch: this means that with that patch
the bridging could be done with a PC having two wifi interfaces in adhoc
mode, right?  If that patch goes mainstream then it's all good, right?
I understand you also seem to say this patch would break an IEEE
specification (802.1D?), right?  If so then maybe that spec would be
fixed according to implementation?

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 22 Dec 2008 15:30:32 +0100

|> Yes, I am interested. I'll compare your results with the nonstandard
|> implementation from Ronald (http://madwifi-project.org/ticket/1131).
|> It would be discouraging for him if his work is needless.
|
|Hi Teco, and thanks to Ronald for the madwifi patch.
|
|I wanted to say I didn't consider the madwifi driver, I think
|bridging+adhoc would work without madwifi but with offtheshelf drivers.
|  It is something I should confirm later.
|
|About the madwifi bridging adhoc patch: this means that with that patch
|the bridging could be done with a PC having two wifi interfaces in adhoc
|mode, right?  If that patch goes mainstream then it's all good, right?

No, there are more problems.
Reported problems (bugs...) are split networks due to failing BSSID (clock
synchronization problems), and problems with beacon suppression. Personally
I think the probe reply storm with high collision probability is a more
difficult one to solve.

More important, there is a need for multi-hop forwarding. 802.1D does not
support that. Some came up with some kind of STP implementation, but this is
IMHO not well behaving in a mobile environment. Better approaches use some
kind of MANET protocols, often copies from the IETF ones.

Anyhow, there are other reasons using IP MANET protocols. Using multiple
types of media is often mentioned and in fact you also came up with this
one. Scalability and finding the best paths in a dynamic topology is our
challenge.

|I understand you also seem to say this patch would break an IEEE
|specification (802.1D?), right?  If so then maybe that spec would be
|fixed according to implementation?

It is partly solved. 802.1D does not provide multi-hop communication in an
ad hoc network.
The patch provides support for an Ethernet connection between a MANET router
and a WLAN radio in a mode similar to .11 IBSS.

802.11s would provide something that is similar to a MANET. Again, it is .11
only. Not sure on performance / scalability. Not even mentioning split /
merges with multi-homing.

Teco.

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 19 Dec 2008 11:01:20 -0800

A layer 2-specific solution is a clear no-no.  

There are more specific links in the military that have been roped into
the internet that we want do catalog here.  CAPs around legacy MILSTAR,
CAPs around INMARSAT B.  Global Broadcast System 'does IP' but isn't
integrated (for reasons that I cannot fathom).

And the list of specific radio links that _should_ be in the internet is
far more immense than you have the patience to listen to.  
	JTRS Wideband Network Waveform
	JTRS Soldier Network Wavefrom
	Three flavors of Mil-Std-188-220
	God knows how many flavors of data link under Common Data Link
program ...
	... the list goes on apparently eternally.

For most of these, the 'data links' are not routable networks so the
subject of routers in general, much less router mobility, is rather
moot.  But that's really beside the point --we need a general solution
view to a general solution problem, not something link-specific (we have
enough of those already).

I'll recite a point I made to Emmanuel off-line.  There's a topology
shift that is happening first in the military, but is a general
harbinger. 
	Today when one thinks of wireless (in an internet context) most think
of WiFi and at the fringe of the network.  In other words a LAN solution
-- reach from last router to end systems.
	But that's not the military problem.  The most extreme existence proof
today is a navy ship with a LAN inside (wired ethernet).  End systems
all attach to that.  Router in radio central to reach out to the
radio-WANs.  Whether or not there's a satellite between, it's a
router-router WAN problem (no end systems in sight -- they're on other
side of the router).  
	The question to toy with is 'how long before that's what you see in
your automobile?'  If you use the term 'fire engine', it may not be long
at all.  WiFi is a wholly inappropriate technology for the radio-WAN
problem for several reasons; the contention MAC being at the top of the
list.

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 22 Dec 2008 09:31:32 -0800

Charlie's right.  But IMHO, not quite complete.

The issue is not one of standards but provisioning.  In almost every
instance I can think of where we'd want MANET and multi-hop features,
high availability is a concern -- indeed usually a trumping one.  There
are three principles of high availability engineering: the second one is
'reliable crossover'.  
	The protocol design of IP (connectionless, stateless) solves this
second principle by protocol design.  Routers use altroutes, if they are
provisioned, all day every day.  
	Bridges, at least in the classical sense do not.  An off-shelf bridge
runs spanning tree protocol which curtails loops by killing off the
altroutes (turns a graph back into a tree).  This flat defeats the
second principle of high availability engineering.  

brctl .... I don't know what that is.  But the litmus test I'd apply is
whether it still preserves the second principle.  

This is not really a standards and protocols issue but a configuration,
provisioning and implementation one.

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 22 Dec 2008 11:36:35 -0800

Emmanuel,  You've managed to generate a lot of discussion.  But a lot of
it is 'micro' and tends to blast past some of the macro -- just why are
we doing all this?  So let me try this: a use case from which we can
derive some requirements that places some context around.  Sense?
	This by no means invalidates your draft.

Objective: extend the internet to mobile platforms.

First, a sorting model.  In 15 years of teaching plowshares-into-swords
internet (and 20 years as a practitioner prior), I've found that all the
requirements differences fall into four categories:
	- high availability (Ao in the lingo)
	- security
	- Quality of Service control
	- reach to mobile platforms.
These categories aren't orthogonal but I've never found diffs that fall
outside them so makes a good mental checklist.  You can use it to get a
feel for priorities too -- I've had to browbeat a lot of folks who start
a discussion with QoS and immediately leap to the need for RSVP or
something similar that reintroduces state at layer 3 ... Ao is always a
trumping requirement.  

Now to a use case.  A fire engine -- it's a good example to illustrate
the interplay:
        - we want a good robust wired internet as far as it can go.  The
problems are always easier there than when radios get in the act.
(We'll assume that the fire engine's dispatching and supervisory command
are on the net).  
        - a reach to emergency services vehicles.  This is not
necessarily a 'mesh' job but one that IEEE 802.16 is well suited for.
While some automated config features are useful; they're not essential
to getting something that works.  Possible to construct mesh use cases
where one fire truck becomes a relay between a fixed POP and a second
fire truck (and yes, all the transitivity discussion can get in here).
But the mesh issues are not necessary to get real value.  
        - a WiFi splotch around the fire engine, to support several end
systems, is useful.  Again, no meshing here -- just plant an AP on the
truck.  But the thread should start to show you why you want a router on
the fire truck, not a bridge.  
        - now to the firemen working in a burning building.  Here's
where the mesh issues start to be useful.  What we want to do is
continue to extend the internet, this time from the fire truck to the
firemen in the building.  
        It is entirely practical that this network be homogeneous (e.g.
all WiFi).  And we can argue about whether the meshing should be solved
at layer 2 or 3 ... the central point in the argument is whether I can
meet 2nd principle of High Ao engineering (support multiple altroutes,
if the meshing arrangement can only be cognizant of one at a time, take
it out behind the paint locker). 
	- but we're not finished.  We've passed the stage where the fireman has
only one end system on his person (e.g. a VOIP rig).  In this particular
use case, he needs a location sensor too -- knowing where firefighters
are in a smoke-filled, blacked out building is a critical safety issue.
And he may need a PDA to see where his buddies are.  And he may have a
heat sensor to detect hot spots (which also should be exporting its
data).  So we have a LAN problem on the firefighter's person, which then
routes into the mesh that reaches to him.  

Now, gander at the sorting model and see what we can derive:
	- anyone disagree that this is a high Ao situation?  So we need
altroutes (principle 1) and we can't use protocols that ace out their
use (e.g. spanning tree)(principle 2), and we need a monitoring system
(SNMP does this) to detect failures as they occur (principle 3).  
	- security divides into two issues: 1) security of the content, a layer
7 issue which is outside of our scope here (e.g. signed e-mail).  2)
infrastructure protection security -- we don't want the neighborhood
script kiddies to get into the network while we're trying to fight a
fire (but we may want to open the door to another fire department --
don't raise this bar indiscriminately).
	- QoS is, of course, important.  Especially in radio-WANs which are
four orders of magnitude less capacious than the wired internet they're
extending from.  Diff-serve is fine; it doesn't interfere with the Ao
issues above.  Emergency services data has a much higher multicast
content than 'civilian' and once you factor in the high Ao ...
everything becomes multicast.  
	And now you have a requirements context to tackle the reach to mobile
platforms subject.  

Any help?

On Fri, 2008-12-19 at 10:19 +0100, Emmanuel Baccelli wrote:
> wireless communication, as observed over the past decade of experience
> with such networks.
> 
> 
> The goal of this document is to identify a consensus about this topic,
> and then use this to move on quicker with the working group documents.
> 
> 
>

---

From: "Breno Jacinto" <[email-masked]>
Date: Tue, 23 Dec 2008 11:26:04 -0300

Hello Charles,

> I just don't see what's wrong with it.

    Neither do I :). IP is fine, and great.  Let me make my point
clearer: you claim that a layer 3 solution may work for a lot of
different wireless media. I just don't know any protocol today that
does that (for ad hoc networking, not the Internet or wired
technologies). I work with Bluetooth, 802.11 and Ethernet networks,
and, in practice, they are different enough. For example, Bluetooth
barely supports broadcasting, and forces a master-slave topology which
is built on-demand (pairing). Multi-hop is, in thesis, possible, but
then you need to make scatternets which also force some kind of
inter-master communication etc.. 802.11 b/g can do only single-hop
communications by default, multi-hopping is done only by IP.

    So, my view is that IP should really just glue the different iinks
together. Underneath, each link should solve their peculiarities and
provide a clean interface to IP (or any layer 3 protocol). That splits
the problems: we keep on doing inter-networking with IP, but
intra-networking is about the layer 2 protocol.

    In the case of 802.11s and AWDS, see how things are simplified. To
IP, it is just a switched ethernet network below it. I wonder if other
link-layers provided the same thing: again, I can only see problems
getting spitted and solved separately.  I don't see what is evil about
this, but I still do not have enough evidence in practice.

> regularity conditions (I'm still puzzling over truckloads of repeaters).

    Yes, that's what I mentioned above. Of course, you may say that I
use too much the word "should", and that reality does not offer such
regularity conditions at layer 2. Then I can only see a layer 3
protocol that is able to cope with each peculiar link it supports,
that would also be different and worth of research. Something like
OLSR with Bluetooth support would be interesting for a start.

> disproves your point: what if the best broadcast used multiple media?

    I dont quite get it. Broadcasting is specific to each media
(meaning, link-layer) and is supposed to reach everyone in the link
only. So, to keep that definition, it's necessary to flood the packet
in a multi-hop context. Yet, if multiple media are involved,
broadcasts are different to each media. That's why I dont follow your
best broadcast over different media idea. Could you elaborate a bit
more?

    I think the discussion generated here may seem off-topic, but in
my opinion they are not. I think it is really important to try to make
the concepts and terminology of ad hoc networking independent of the
practical experiences we had, which is restricted (at least to me) to
802.11 and Bluetooth networks. Other people mentioned a lot of
proprietary technologies that do ad hoc, as well. So, how can we keep
concepts general enough if there are several technologies that work
differently from each other?

regards,

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 23 Dec 2008 10:39:19 -0800

Hello again Breno,

Comments inline...  I have modified the order of your
original text.

>>> the network. Now, IP sees the network as a single broadcast domain
>>>  ....   We may then shift
>> ......   In fact, your very example of broadcast

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.

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.

It's easier at layer 3, I think.

> differently from each other?

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.

> intra-networking is about the layer 2 protocol.

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.

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

Regards,
Charlie P.

---

From: "Breno Jacinto" <[email-masked]>
Date: Wed, 24 Dec 2008 13:10:01 -0200

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 <[email-masked]>:
> create a reduced relay set to accomplish this, and it could be constructed
> using

      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.

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

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

> to varying interpretations, though.  For instance, if IP required symmetric
> links,

     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.

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

> Charlie P.

best regards, and merry christimas!

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 24 Dec 2008 10:41:00 -0800

Hello Breno,

I have to make this short, but anyway provide some responses to
your comments.

> multiple media? That's the only way I can imagine it.

Yes, I meant potentially heterogeneous network.

> certain that for each media, a different network must be formed.

Well, depending on what you mean by "network", I don't take that as an
article of faith.  However, I reckon we can agree that nodes using different
physical media won't be able to properly manage access to the disparate
media.

> with 802.11 b/g. And that applies to any technology.

What if you s/networks/links/?

> work).

Well, it does work.

> Then, to IP or any layer 3 protocol, this is just one network
> anything below it in this case?

Here, I am definitely not seeing your point.

>  An IP/ UDP broadcast will, ultimately,
> become a layer 2 broadcast, right?

Not necessarily, especially if one wants to do iterated unicast.

>  If there is any kind of

One example I mentioned before, was that IP could decide
which nodes handle relay.

> with some layer 3 "talk".

What if your layer-2 signaling eats 30% of the bandwidth and
layer-3 signaling would have only used 5%?  Again, there's no
free lunch.  Furthermore, proactive protocols in any sufficiently
big domain will eventually use 100% of the bandwidth.  I do
understand that many proponents don't believe in huge ad hoc
networks, so from that perspective it's a moot point.

> hoc networking?

Well, I am not a religious person, and especially not religious
about technology choices.  So I don't think there is necessarily
any one "way" to do it.  For me, the bottom line is performance,
including scalability.

> this not as simple as it sounds. I'm aware that there are challenges

It is my belief that the challenges are exacerbated by trying to do multihop
forwarding at layer 2.  But lots of engineers enjoy a good challenge, and if
they can sell the results, even better, except insofar as new challenges are
introduced relating to backwards compatibility to poorer technology choices.

> multi-hop communication transparently to IP.

Here I disagree.  Complicating one level and reducing proper visibility
at another level is not automatically equal to "simpler".

>  No need of highly

That's an awfully long stretch.

> for layer 3 to know about them, them a little bit of cross-layering

So, do you want IP to run over asymmetric links, or not?  If layer 2 cannot
create the fiction of symmetry, do we lose the link or not?

Felicitous Festivities!

Regards,
Charlie P.