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

[Rex Buddenberg <[e-mail]>]

Charlie,

Thanks for note back ... this might be progress.  I was afraid that you 
might mash the 'irrelevant' button.

"However, I still maintain that this document under discussion is _not_ a
requirements document..."

I'm genuinely confused regarding just what the order of business needs 
to be and what the document artifacts that result from that should be. 

I've also been a much more intimate witness on how NOT to do such things 
within DoD than I ever wanted to be.  Are there, perhaps, some parallels?

How to get it backwards:
    1.  Shout  'the acquisition system is broken'.  This bloviating is 
good every four years.  So we apply some bandaids to the bureaucracy.
    2.  Muse that we need an architecture.  But we lack a useful 
definition of the term, so any answer is 'right' and the ones enshrined 
in the system have nothing to do with interoperability, modularity or 
interchangeable parts.
    3.  At this point, the exercise usually peters out, but if it 
doesn't, we have a requirements flailex.  Which tends to look a lot like 
a Dilbert cartoon.
    4.  And nobody seems to get to an observed taxonomy of 
interoperability.  Which is what the scenarios of the previous e-mail 
were hinting at.  (taxonomy, reference model, sorting model, Linnaeus)

Aside from the steps (e.g. #4) that are missing altogether, this is 
exactly the reverse order of business!  We can, and should, build the 
reference model without reference to requirements.  Is that were we are 
agreeing or disagreeing?  Or even on the same page?






Charles E. Perkins wrote:
>
> 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
>>>
>>
>
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/autoconf
>

-- 
Rex Buddenberg
Senior Lecturer
Naval Postgraduate School
Monterey, Ca 93943
831/656-3576