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

["Teco Boot" <[e-mail]>]

Minor comment on "Aloha experiment being a lousy idea": let's not forget
that this idea is used quite often. Think of old days Ethernet, WLAN and
signaling channel in cellular networks, just to come up with a few examples.

More important: I think we should focus on the IP layer, and stay away from
media access technology and related problems. Not that is not interesting or
important, it is not the focus of IETF in general to work on layer-2 stuff.

Teco.



|-----Oorspronkelijk bericht-----
|Van: [e-mail] [mailto:[e-mail]] Namens
|Rex Buddenberg
|Verzonden: dinsdag 24 februari 2009 20:03
|Aan: Charles E. Perkins
|CC: [e-mail]; Emmanuel Baccelli
|Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
|communication
|
|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
|>
|
|--
|Rex Buddenberg
|Senior Lecturer
|Naval Postgraduate School
|Monterey, Ca 93943
|831/656-3576
|
|_______________________________________________
|Autoconf mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/autoconf