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

["Charles E. Perkins" <[e-mail]>]

Hello Rex,

Thanks for the long email.  I think that I do have a good handle on the 
various
kinds of mobile communications scenarios as you have outlined below.

You have raised the particular point that many nodes in an ad hoc network
do not have to be routers.  I certainly agree with this, and agree that 
any work
in [autoconf] needs to be able to configure addresses for wireless nodes in
an ad hoc network that are not routers.  Perhaps Emmanuel and I could better
emphasize this point in our draft, but even non-router nodes can be 
subject to
the problems noted in that draft.  So we have to find better language to
identify the wireless nodes that would be affected other than just calling
them "routers".

However, I still maintain that this document under discussion is _not_ a
requirements document, and that Paul seems to be discussing various
requirements for ad hoc networks.  Don't you agree that requirements
should be located in a separate document?  The only "requirement" that
we have placed in our small document is a need to deal with reality.

I'd also like to point out one somewhat unrelated point.  It is agreed, of
course, that MAC-layer problems can pre-empt the usefulness of
routing protocols.  However, routing protocols can themselves cause
congestion, and any techniques that we can bring to bear that reduce
congestion are likely to increase the overall effectiveness of the MAC
layer protocols also.  Furthermore, I think it is likely that people who
do not have good understanding about the nature of the wireless
medium are more likely to make design decisions for routing protocols
that would increase congestion.

What do you think?

Regards,
Charlie P.


Rex Buddenberg wrote:
> Charlie,
>
> Paul has a reality check point and its worthwhile understanding this 
> because missing the point has made both MANET and autoconf harder than 
> they need to be ... IMHO.  It's also made them less relevant to what I 
> think I see in the future.
> My background is analyzing information systems in DoD and emergency 
> services ... why are they not interoperable (or, in the rare inverse 
> instance, why are they interoperable)?
>
> In dealing with some DoD bureaucracy, I'm finding that they don't 
> understand the implications of the differences between LANs and 
> WANs.   And by MANET stating that every end system is also a router, 
> we equally obfuscate the point.
>
> Reality today.  Our ships have wired LANs (mostly fast etherrnet and 
> gigabit ethernet) within the hull.  End systems (Paul's printers) 
> attach to that LAN.  And those end systems don't need more than one 
> entry in the routing table and it's not likely to change.  (The analog 
> to your LAN at home is good).
> The problem that DoD has is not in the LAN; it's in the radio-WAN.  
> Which is the link between the router in Radio Central and that in 
> another ship and/or the commsta ashore.  While there's lots of noise 
> in the system, this is properly a pure radio-WAN problem -- entirely a 
> router-router interconnect one.  No end systems.  This presents MAC 
> and QoS control problems.  What's important is that they are isolated 
> from the end systems -- other side of the router.
>
> Reality ... not very far in the future.  We have all the technology 
> today to extend the internet to a fire truck.  But do we want the WAN 
> to reach to all the end systems on the fire truck?  Perhaps in the 
> near term, but this is not a long term good idea.  What makes better 
> sense is to plant a router on the fire truck and divide the problem 
> into a radio-WAN (sometimes slangily known as 'reachback') and the LAN 
> problem -- which might be solved by a WiFi splotch around the truck.  
> Once you start thinking about reaching to firefighters inside a 
> burning building, this makes more and more sense.    And reality ... 
> not much further in the future.  Should such a pattern not fit into 
> your automobile?  Instead of the cellphone reach to your end system, 
> it reaches to your car-resident router.  And you have several end 
> systems within the car that ... attach to a LAN.
>    And reality, again not too far in the future.  A Marine infantryman 
> has several end systems, or at least potential end systems, as part of 
> his combat outfit.  Radionav receiver, PDA/laptop, rifle scope, night 
> vision goggles (think webcam), laser rangefinder, VOIP rig.  As soon 
> as the list becomes plural, the idea of each end system being its own 
> router (which implies it's own radio) ceases to make sense.
>
> The difficulty I repeatedly find in DoD programs (we're talking $B 
> here) is that they try to use wireless-LAN technology in a radio-WAN 
> situation.  For example, we see satcom and air-ground specifications 
> that persist in using contention access methods, when the Aloha 
> experiment 40 years ago showed that was a lousy idea.  The MAC problem 
> is orthogonal to the routing problems, but somewhat of a prerequisite: 
> if the net has crashed due congestion, then your routing tables are 
> likely to be fiction.
>
> For Paul: is this anything related to your comments?
>
>
>
>
> Charles E. Perkins wrote:
>>
>> Hello Paul,
>>
>> Paul Lambert wrote:
>>
>>>> I am almost certain they
>>>> should be considered out of scope for the document
>>>> under discussion.
>>>>     
>>>
>>> In looking at the reference in the charter for "ad hoc" (RFC 2501) 
>>> the defined MANET is a Chimera - a mythical beast made of the parts 
>>> of many other animals. It is a shame that smaller monsters are out 
>>> of scope (like 802.11 ad hoc) ...
>>>   
>>
>> I am thoroughly mystified by your reply.  Just because certain
>> topics are out of scope for the small document by Emmanuel
>> and me, does not mean they are out of scope for [autoconf].
>> Isn't it possible to have more than one document?  Shouldn't we
>> collect requirements in a requirements document instead of every
>> other document that might be written?
>>
>> To be explicit, I am wholly in favor of making sure that
>> the results of [autoconf] are applicable to 802.11 ad hoc.
>> Did I say anything to imply otherwise?
>>
>> Regards,
>> Charlie P.
>>
>>> Paul
>>>
>>>
>>>
>>>  
>>>> -----Original Message-----
>>>> From: Charles E. Perkins [mailto:[e-mail]]
>>>> Sent: Monday, February 23, 2009 10:21 AM
>>>> To: Paul Lambert
>>>> Cc: Emmanuel Baccelli; [e-mail]
>>>> Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless
>>>> communication
>>>>
>>>>
>>>> Hello Paul,
>>>>
>>>> The document isn't intended to suggest a list of work
>>>> items for consideration by [autoconf].  Instead, it is just
>>>> a description of common properties of radio and other
>>>> wireless links.  These properties are not quite universal,
>>>> but they are widespread.  Some of them can be alleviated
>>>> a bit by mechanisms below the network protocol level.
>>>>
>>>> So we are not suggesting requirements or work items.
>>>> Instead, we simply wanted to make as clear as possible
>>>> some of the characteristics of the transmission media
>>>> whose widespread availability is motivating the work
>>>> of [autoconf].
>>>>
>>>> Your list of issues would, I think, all fit best in a
>>>> requirements document.  I am almost certain they
>>>> should be considered out of scope for the document
>>>> under discussion.
>>>>
>>>> Regards,
>>>> Charlie P.
>>>>
>>>>
>>>> Paul Lambert wrote:
>>>>   
>>>>> Hi,
>>>>>
>>>>> The draft-baccelli-multi-hop-wireless-communication-01 provides an
>>>>>       
>>>> interesting list of issues that might be addressed by this working 
>>>> group.
>>>>   
>>>>> >From a quick review it does not appear to address:
>>>>>  - ad hoc network coalescing.  Coalescing has clear implications for
>>>>>    IP address assignment
>>>>>  - there is no mention of multicast versus unicast issues.  Perhaps
>>>>>    since the document makes all links potentially asymmetric and
>>>>>    unreliable there is no distinction.  At least for 802.11 ad hoc
>>>>>    I find significant implications.
>>>>>  - it does not address link security establishment
>>>>>    The process of setting up the link security is out of scope, 
>>>>> but as
>>>>>    I've mentioned in earlier emails this has a clear impact on 
>>>>> available
>>>>>    networking mechanisms.
>>>>>    It is also a very important architectural consideration to ensure
>>>>>       
>>>> that
>>>>   
>>>>>    IP address assignment has some level of security.
>>>>>
>>>>> Asymmetric links in all "ad hoc" networks.  Is it possible to 
>>>>> partition
>>>>>       
>>>> our problem statements so that this is just one of several optional
>>>> attributes that must be addressed?
>>>>   
>>>>> Most modern wireless MAC layers have reliable unicast.  I can see 
>>>>> some
>>>>>       
>>>> broadcast only links - like satellite broadcast, but outside military
>>>> applications I am not familiar with broadly deployed commercial 
>>>> wireless
>>>> networking technologies that are based on asymmetric unicast 
>>>> transmissions.
>>>> Perhaps someone on this list could point me to the technologies 
>>>> that they
>>>> are considering for this requirement.
>>>>   
>>>>> Regards,
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>>       
>>>
>>>
>>>
>>>   
>>
>> _______________________________________________
>> Autoconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/autoconf
>>
>