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

Hello again Breno,

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

>>> - 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
>>>  ....   We may then shift
>>> to the problem of connecting multiple ad hoc networks at the IP layer,
>>> doing inter-domain routing etc.
>>>       
>> ......   In fact, your very example of broadcast
>> 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?

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.

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

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.

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

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.

>     In the case of 802.11s and AWDS, see how things are simplified. To
> IP, it is just a switched ethernet network below it.

Yes, but what happens when a non-802.11s node arrives?   Is that poor
user just another error condition to be blithely cut off from the world?
Or, as above, what happens when a nonsymmetric link is encountered?
Do we just have to forget about it?  Or what if we could have designed
a better protocol that made better flooding, but used brute-force
broadcast instead because the interface didn't allow any distinction?

Regards,
Charlie P.

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf