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

["Charles E.Perkins" <charliep at iprg.nokia.com>]

Hello Madhavi,

Long time, no see!

>>> == 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...

> 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.

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.

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.

>                                        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?


>> 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