Subject: RE: [Ospf-wireless-design] some comparative results

From: "Spagnolo, Phillip A" <[email-masked]>
Date: Mon, 23 May 2005 08:21:10 -0700

Richard,

I am now going to try you most recent changes to verify your note below.
Thanks for sending the code.

Sincerely,
Phil

> -----Original Message-----
> From: Richard Ogier [mailto:[email-masked]] 
> Sent: Monday, May 23, 2005 7:46 AM
> To: Spagnolo, Phillip A
> Cc: Henderson, Thomas R; [email-masked]
> Subject: Re: [Ospf-wireless-design] some comparative results
> 
> 
> Phil,
> 
> I discovered that if the rxmt time is reset (for LSAs waiting to
> be retransmitted) when a BMDR floods an LSA, in addition to using
> BackupWaitInterval = 2000, then there is less overhead due to
> fewer retransmissions and fewer BMDR floods. In your simulations,
> the decrease in BMDR floods might have been offset by more
> retransmissions. (Note that since the maximum jitter equals
> BackupWaitInterval, this makes the maximum wait time 4000 msec, so the
> wait time plus the ack interval of 1800 could be larger than 
> RxmtInterval.)
> But having (B)MDRs send a multicast ACK immediately when receiving
> a duplicate, unicast LSA seems to help the most in reducing overhead,
> at least for larger networks.
> 
> Richard
> 
> 
> Spagnolo, Phillip A wrote:
> 
> >Richard,
> >
> >In response to the following comments:
> >
> >>Actually, I'm not even sure setting BackupWaitInterval to be larger
> >>than AckInterval will help much in the full adjacency case.
> >>It might help more if the BMDR floods the LSA after (the larger)
> >>BackupWaitInterval whenever some adjacent neighbor has not ACKed.
> >>This would increase the number of backup relay floods (and hopefully
> >>decrease the number of retransmissions), whereas just increasing
> >>BackupWaitInterval would decrease the number of backup relay floods
> >>(which is already small).
> >>
> >>For partial adjacencies, as you say, I am trying to achieve faster
> >>LSA dissemination. I want the flooding procedure to be independent
> >>of the retransmission procedure (as much as possible), so 
> waiting for
> >>a possible ACK is not an important objective - covering all 
> neighbors
> >>is the main objective.  This independence is also important for the
> >>non-ackable LSA option, i.e., for unreliable flooding without ACKs.
> >>I still plan to experiment with the non-ackable option,
> >>to see how it reduces overhead in large, highly mobile networks.
> >>
> >>But practically, BackupWaitInterval should be set to whatever gives
> >>the best performance, and I did not see any improvement 
> with a larger
> >>value of this parameter. It may reduce overhead a little, but may
> >>also increase the number of out-of-sync LSAs.
> >>
> >
> >
> >I reran the MDR case with full adjacencies and full LSAs using a
> >BackupWaitInterval of 2000 msec (instead of 1000 msec, 
> AckInterval still
> >set to 1800 msec).  As was expected, the change did not make much
> >difference. If anything, the 1000 msec BackupWaitInterval preformed
> >better.  The amount of overhead due to retransmissions 
> stayed about the
> >same.  
> >
> >Note that these results do not include any of your most 
> recent changes.
> >
> >Here are the results (previous results in parenthesis):
> >Nodes    Overhead (kbps)    Delivery Ratio
> >10       11.59   (12.23)    .978 (.977)
> >20       88.97   (88.17)    .960 (.964)
> >30       278.68  (280.80)   .959 (.963)
> >40       682.85  (660.36)   .951 (.946)
> >50       1802.24 (1731.17)  .957 (.955)
> >
> >Sincerely,
> >Phil
> >
> >
> 
> 
> 

_______________________________________________
Ospf-wireless-design mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design