Subject: Re: draft-spagnolo-manet-ospf-design-00.txt

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 26 Aug 2004 09:42:06 -0700

Mitchell,
Thanks for your comments-- responses inline below.

> -----Original Message-----
> From: Erblichs [mailto:[email-masked]]
> Sent: Monday, August 23, 2004 3:31 PM
> To: [email-masked]
> Subject: draft-spagnolo-manet-ospf-design-00.txt
> 
> 
> Design Considerations Wireless Interface   April 04
> 
> Group,
> 
>         I am sure that I am late to these wireless discussions..
>         I will try to keep my comments short.. My two cents..
> 
>         FYI: Their is always a number of hosts that
>         though they are "mobile" tend to be stationary for
>         periods of time. It is almost imperative to scale the
>         kbps requirements downwards during these times while
>         being able to verify that the LSDBs are synchronized.
> 
>         First, is this paper assuming the the LSF packet
>         type without acks? I am not.

Only Section 8 (Comparison with Unreliable Flooding) is considering
the LSF packet type.

> 
>         3.1 Neighbor Discovery
> 
>         Their are actually two bps values being generated here.
>         The first is a 1-way discovery within the avg 1/2 of
>         hello interval. The second is increased reliabliity
>         tradeoff in the event that multiple hellos are lost.
> 
>         The true required hello overhead are the extra hellos being
>         sent that are duplicates within the dead router interval.
> 
>         If we see no loss, then the minimum required hello pkt
>         overhead calcs should use dead router interval. The diff
>         between that value and your value should the resultant
>         overhead needed to assure a level of relaibility given
>         a certain loss of pkts.

I think that this is a terminology debate.  We considered all routing
protocol traffic as overhead.  I agree that there are different
components to this ("necessary" overhead vs. possibly "redundant" 
overhead).

> 
>         3.2 Adj Forming
> 
>         Their is a implied assumption that when a "partioned
>         network comes together" that their will be only one
>         router between the partition. If most of the new
>         full adjs are between the new partitions, and
>         they are formed first, then the "avg-LSAsOutSync" will
>         initially start at 100% * the number of number of
>         routers.

Yes, for simplicity, we assume the case that a partition is healed
by one router.  But some LSAs may still be in sync depending on
when the network partitioned in the past.

> 
>         EX: the area is partitioned between A and B. All of
>         the routers within A are sync with each other and the
>         same goes for B. Now we have 5 routers on the side of
>         A and 5 routers on the B side. A time "1" adjs will
>         form between A1/B1, A2/B2 ... A5/B5. All LSAs at this
>         time are different. It is only at a later time does
>         the avg-..OutSync drop to significantly lower values.
> 
>         Secondly, the lifetime of a LSA needs to be considered.
>         WRT, DNA (Do NOT AGE) LSAs the lifetime is infinite
>         and should not be part of the flooding overhead.

We did not consider DNA LSAs.

> 
>         Thirdly, if a nbr leaves and returns within the
>         LSA lifetime (and the router dead interval), then
>         the nbr movement cancels and should not effect the
>         equation (or be counted twice??).

Yes, from standpoint of needing to resynchronize out-of-sync
databases, this would be a non-event.

> 
>         3.3 LS Flooding
> 
>         A)
> 
>         "... Link State Flooding overhead to be the amount of
>         overhead generated without any packet loss."
> 
>         Shouldn't this be added..
> 
>         and that a ack is recieved within the timeframe as
>         to prevent a control packet rexmit.
> 
>         Reason, is that pkt processing delays also cause
>         rexmits...

that part was implied by the "without any packet loss" clause
(we did not consider packet processing delays).  So I would
agree in general to your clarification.

> 
>         B) neighborchangerate
> 
>         This is bounded by the router dead interval, it takes
>         us dead router interval to see that a router has gone
>         away.

In some implementations, there may also be layer-2 feedback
that a neighbor has gone away without waiting for dead interval.

> 
>         It is also bounded by 1/2 the value of the hello interval
>         to detect that a router has gone 2-way.
> 
>         To effect this value, one concievably could generate
>         a hello when,
>                 * an interface comes up,
>                 * first time we see a nbr listed in the hello,
> 
>         instead of jsut periodicly xmiting hellos..

Agree that there are some more intelligent Hello transmission
heuristics that are possible.

> 
>         3.4 Reliability
> 
>         I am not sure that you are seeking reliability as to
>         be seeking an implicit way to verify that two or more
>         LSDBs have converged.
> 
>         Within a wireless environment, the only method that I
>         can CONCIEVABLY come up with is with a new OSPF control
>         packets that contains a sum of the LSA checksums in a
>         LSDB. If the values matched, then I could assume that
>         the LSDBs probably match, given a LSA count, and THEN stop
>         rexmiting LSAs. To belablor the point, as a router
>         enters a new region of an area, he or she could xmit
>         this new control packet with 0. This could inform all
>         recvrs to xmit their LSAs.. Thus, the area goes into
>         a quiesent mode where just minimal summary information
>         is xmited when the mobile environment is temporalily in
>         stasis.
> 
>         This above concept assumes that the total number of
>         LSAs that need to be freq xmited is great, that
>         the overhead to process them is significant, and that
>         LSDB convergence is intended.

Please see the draft by INRIA on database exchange techniques
such as you described:
http://www.ietf.org/internet-drafts/draft-clausen-manet-ospf-dbx-00.txt

> 
>         --- I think this is enough to add at this time...
> 
>         Mitchell Erblich
>         Sr. Software Engineer
>         Currently consulting..
>