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

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

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?

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

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.
_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf