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

["Madhavi W. Chandra" <mchandra at cisco.com>]

Tom and Charlie,

I agree with most of Tom's responses...see one comment at the end. 
Charlie, can you please forward the editorial comments that you had.

Thanks,
Madhavi

On Tue, Mar 30, 2004 at 08:09:17PM -0800, Henderson, Thomas R wrote:
> Charlie,
> thanks for your comments (responses inline)
> 
> > -----Original Message-----
> > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com]
> > 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,
> > 
> > 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.
> 
> agreed-- maybe "difficult" instead
> 
> > 
> > - In section 2.3, the acronym "VC" is left undefined.
> 
> virtual circuit
> 
> > 
> > - 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.
> 
> agreed, although the point that power management is a 
> concern is still applicable (but this should be reworded)
> 
> > 
> > - 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.
> 
> 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.
> 
> > 
> > - 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.
> 
> 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.
> 
> > 
> > - 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 agree with you that this is a crucial problem, and the
> way that this is solved is going to affect the 
> scalability.  

Agreed.  And, as Tom pointed out on another email thread, the debate
over reliable vs. unreliable flooding will really depend on the
mobility scenario.  It seems intuitive that unreliable flooding will
'outperform' reliable flooding in a highly mobile environment...and
probably the opposite in a relatively low mobility environment where
periodic signaling seems excessive.  In any case, as we know
performance is not just the overhead.  It is a tradeoff that will be
governed by the network scenario.  We can change the wording to
indicate as such.

-Madhavi
 
> 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
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet