Subject: [manet] Comments on "Problem Statement for OSPF Extensions ..." draft

From: "Charles E.Perkins" <[email-masked]>
Date: Thu, 25 Mar 2004 13:27:51 -0800

Hello folks,

During the recent meeting, the abovementioned draft
was discussed.   The draft has been submitted for a
long time, but after finally reading the draft, and
motivated by the recent WG discussion, I have a few
comments.

- In section 2.1, it is stated that mobility makes
  the use of directional antennas into a pointless
  exercise.  There are numerous studies that conclude
  otherwise.  It seems likely that, given sufficient
  justification, a workable system can be built.
  Whether or not the additional cost is justified
  compared to other expenses is debatable.  Overall,
  however, I would say that "pointless" is far too
  strong an adjective in this sentence.

- In section 2.3, the acronym "VC" is left undefined.

- In section 2.5, the misconception is promulgated
  that receiving takes less power than transmitting.
  While it is typically true per message, the fact is
  that receiving is often more power-consuming
  when the receiver has to be always powered up.
  In contrast, typically the transmitter can be
  powered down during most of the timm.

- In section 2.7, if a node's ability to support new
  neighbors is exhausted, then one can truly say that
  the number of neighbors is numerically limited,
  so that the nodal degree is limited.  Said another
  way, geographic proximity may not result in network
  adjacency.

- In section 2.8, replace "should not thrash" by
  "should avoid thrashing"

- In section 2.9, last paragraph: the suggested
  strategy requires too much binding between a node's
  IPv4 addressability and its IPv6 addressability.
  This issue may not need solution in this document
  anyway.  In fact, I question the need for binding
  even separate network interfaces to the same nodal
  identifier, but again that is a separate issue.

- Section 2.10 gets to the heart of a crucial
  problem.  I would suggest that it be taken as
  a requirement to outfit the OSPF implementations
  so that unreliable flooding is acceptable,
  otherwise I just don't believe the solution
  will be scalable.

I have other minor editorial improvements to
suggest which don't really need to be brought
out here; if the authors are interested, I will
be happy to send them.

Regards,
Charlie P.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 30 Mar 2004 20:09:17 -0800

Charlie,
thanks for your comments (responses inline)

> -----Original Message-----
> From: Charles E.Perkins [mailto:[email-masked]]
> Sent: Thursday, March 25, 2004 1:28 PM
> To: Mobile Ad Hoc IETF working group
> Subject: [manet] Comments on "Problem Statement for OSPF 
> Extensions ..."
> draft
> 
> 
> 
> Hello folks,
> 

agreed-- maybe "difficult" instead

> - In section 2.3, the acronym "VC" is left undefined.

virtual circuit

>   powered down during most of the timm.

agreed, although the point that power management is a 
concern is still applicable (but this should be reworded)

>   way, geographic proximity may not result in network

agreed (I don't think you are arguing the text?).
Fred Baker's "outsider's view of MANET" draft explored
the possibility of limiting the nodal degree.

>   identifier, but again that is a separate issue.

This section alludes to a draft in the OSPF WG suggesting
that multiple addressing families could be supported by
a single protocol (OSPFv3).  The point is that, if we
are doing ad hoc routing at layer 3, we should concern
ourselves with handling both v4 and v6 efficiently.

>   otherwise I just don't believe the solution

I agree with you that this is a crucial problem, and the
way that this is solved is going to affect the 
scalability.  

Our studies have indicated that flooding is by far the 
dominant contributor to overhead.  We have looked at
a number of the proposals for reliable but optimized
flooding, and found that they can improve the situation,
but a reduction in overhead by half seems to be a rough
bound on the achievable improvement.  However, in some
highly mobile environments, unreliable flooding does
significantly better (order of magnitude) than reliable
flooding.  

We'll put out a draft on this topic shortly, but suffice
it to say that reliable flooding doesn't seem capable of
approaching the overhead reduction offered by unreliable
flooding, as mobility increases.  

But whether or not a reliable flooding protocol can be 
scalable or not scalable is debatable.  "Doesn't scale"
is frequently a dismissive term that is not qualified
enough.  The working group may decide that, in the case
of OSPF, it is willing to trade some scalability to 
retain reliable (but optimized) flooding.  The design 
decision that I believe is the true non-starter is to 
decide a priori that OSPF flooding should not be optimized,
period.  

Tom