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

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

Hi Charlie,

On Wed, Apr 07, 2004 at 10:08:01AM -0700, Charles E.Perkins wrote:
> 
> Hello Madhavi,
> 
> Long time, no see!

I know!  I trust all is well.

> >>> == me,
> >>  == Tom
> >   == Madhavi
> 
> "Madhavi W. Chandra" wrote:
> 
> > I agree with most of Tom's responses...see one comment at the end.
> 
> Sounds like we are all three in basic agreement here...

Yes, for the most part I think so.

> > Charlie, can you please forward the editorial comments that you had.
> 
> I'll type them in separately, but if I forget to send them please
> remind me because this is one of those weeks.

OK...thanks!

> In my comments below, I also discuss some of Tom's points
> a bit more.
> 
> >>> - In section 2.1, it is stated that mobility makes
> >>>   the use of directional antennas into a pointless
> >>>   exercise.           ...........
> >>>            I would say that "pointless" is far too
> >>>   strong an adjective in this sentence.
> >> 
> >> agreed-- maybe "difficult" instead
> 
> Judging from later discussion, I would suggest that
> "more expensive" is about the most pejorative term
> one might truthfully use here.
> 
> >>> - 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)
> 
> Certainly, power management is crucial, and for
> the most part overlooked in [manet] development
> up until now.  However, there are many interesting
> results we could try to incorporate.  Moreover, this
> has a strong interaction with flooding strategies.
> 
> >>> - 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.
> 
> Agreed -- but it does not necessarily imply a close binding
> of those addresses _as part of the routing protocol_
> 
> >    ...                                             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...
> 
> Check.
> 
> >                                                               and
> > probably the opposite in a relatively low mobility environment where
> > periodic signaling seems excessive.
> 
> You seem to mean that (a) reliable flooding can outperform
> unreliable flooding in a low- (or zero-!) mobility
> environment, which is within the realm of imagination.  Then
> the next clause would mean that in low-mobility environments
> periodic advertisements are excessive, which also sounds
> reasonable if you mean that they aren't needed since likely
> nothing has changed.  But, in context it means that OSPF is
> both more likely to succeed and yet burdened with excessive
> signaling in a low mobility environment.  In fact, I could
> even agree, after more investigation, with both parts, but
> I was not sure it was what you meant.

Sorry.  What I mean is that in low mobility environments, reliable 
event driven signaling seems more productive than periodic signaling
since likely nothing has changed.  The point is that the performance
of reliable vs. unreliable will depend on the dynamic nature of the
network.  And, for unreliable flooding...the flooding period.  

> Furthermore, while it is within the realm of imagination
> that reliable flooding can outperform unreliable flooding
> in low-mobility scenarios, it is by no means certain, and
> probably depends a lot on other features of the algorithms
> doing the flooding.
> 
> I thought that the _only_ reason for even considering
> reliable flooding was because that was what OSPF already
> did.

I wouldn't say that.  Reliable event-driven flooding has its merits in
performance as well.  

In high mobility, frequent period flooding would be needed to avoid
packet loss and low throughput...so the overhead may be justified.  But,
the same frequency will unnecessarily consume bandwidth in low
mobility scenarios.  Even with a dynamic flooding period, it is not
instantaneous, so I'm not clear on what happens while in flux.  I can
imagine that in low mobility, you have a 'large' flooding
period to reduce the unnecessary overhead.  If the network becomes
highly dynamic before the flooding period catches up, what happens to
network throughput?  I imagine that many packets will get dropped.

So, it comes down to 'performance' and network requirements.

> >                                        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.
> 
> Do you think it's acceptable to equip OSPF with extensions
> that presume reliable flooding even when that strategy is
> likely to place stringent limits on the how fast the nodes
> are "allowed" to move?

Do you mean that reliable flooding will impose an 'upper' limit on the
dynamic nature of the network?  Clearly we cannot place such limits.
As I see it, this is work in progress and the solution may end up
being a hybrid approach, or some other optimizations that further
reduce the impact of ACKing.

I guess I'm just saying that we should not dismiss reliable flooding.
The solution phase is still in an early stage.

Regards,
Madhavi

> 
> >> 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.
> 
> That's true, but I make a very intentional effort to
> avoid such dismissive uses.  Even scalability isn't
> important unless one's protocol is intended to be
> applicable to large-scale deployments, according to
> whatever parameter you want to make large (often
> the number of nodes, but could also be the amount
> of traffic or number of flows).
> 
> >>    The working group may decide that, in the case
> >> of OSPF, it is willing to trade some scalability to
> >> retain reliable (but optimized) flooding.
> 
> "Reliable" does not equal "optimized", except unless
> all the signaling overhead is counted and it is indeed
> optimal.  Furthermore, "optimized" is subject to the
> same abuse as "scalable", and both really need to be
> put in good context in order to be truly understood.
> 
> >>                                        The design
> >> decision that I believe is the true non-starter is to
> >> decide a priori that OSPF flooding should not be optimized,
> >> period.
> 
> I am sure I agree with this statement, but I also admit
> I was wondering what motivated it.
> 
> Regards,
> Charlie P.

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