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

Rex Buddenberg <budden@nps.navy.mil> Tue, 24 February 2009 19:01 UTC

Return-Path: <budden@nps.edu>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF693A6B3C for <autoconf@core3.amsl.com>; Tue, 24 Feb 2009 11:01:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN3nHz6pqIiP for <autoconf@core3.amsl.com>; Tue, 24 Feb 2009 11:01:55 -0800 (PST)
Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id CCD9F3A6A1C for <autoconf@ietf.org>; Tue, 24 Feb 2009 11:01:55 -0800 (PST)
Received: from localhost.localdomain ([172.20.57.107]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 11:02:15 -0800
Message-ID: <49A44459.9020400@nps.navy.mil>
Date: Tue, 24 Feb 2009 11:02:49 -0800
From: Rex Buddenberg <budden@nps.navy.mil>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
References: <be8c8d780902230203k5f0ffb38m97d817aff9d95554@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net>
In-Reply-To: <49A431E9.3010401@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Feb 2009 19:02:15.0176 (UTC) FILETIME=[681BB080:01C996B2]
Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 19:01:57 -0000

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:charles.perkins@earthlink.net]
>>> Sent: Monday, February 23, 2009 10:21 AM
>>> To: Paul Lambert
>>> Cc: Emmanuel Baccelli; autoconf@ietf.org
>>> 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
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>

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