Re: [bmwg] IGP Data Plane Convergence

[Scott Poretsky <[e-mail]>]

Al,

Thanks for the insightful comments.  See replies below.

Scott

At 05:55 PM 7/9/2003 -0400, Al Morton wrote:
>At 12:13 PM 07/09/2003 -0400, Scott Poretsky wrote:
>> > BMWG-ers,
>> >
>> > We have had a couple of issues raised for the IGP Data Plane Convergence
>> > benchmarking.
>> >...
>> > 1. Packet Sampling Interval -
>> > With some test equipment vendors you must use the Average Convergence
>> > Time and not the preferred Full (Peak-to-Peak) Convergence Time. This 
>> is because the
>> > minimum configurable packet sample interval is as high as 1 second.
>
>I think it's fair for the benchmarks we compose to encourage
>performance improvements in *both* DUTs and test equipment.

Absolutely!


>I agree you should add the new term on sampling rate, but the text on
>test considerations reveals other issues:
>
>1. The Methodology draft uses the undefined term "Peak-to-Peak
>Convergence Time," which you appear to be treating as equivalent to
>"Full Convergence Time" above.

Yes.  Good catch.  The Terminology draft will be updated to use the Term 
"Full Convergence Time" instead, as defined by the measured Peak-to-Peak 
time in the graph.


>2. If your proposal is to allow either "Full" or "Average"
>convergence time measurements in section 4,
>then make that option clear so we can discuss it further.

Got it.  Our proposal is to use Full Convergence Time, which provides the 
better result.  If however the test equipment Convergence Sampling Rate 
is >100msec, then the Average Convergence Time  may be used with indication 
that the result is the Average Convergence Time  .


>> >
>> > 2. Convergence Timers
>> > The Methodology draft "Test Considerations" section currently states 
>> to set
>> > Convergence Timers to minimum value. It has been requested that we include
>> > suggested values. We propose that the values appear as follow:
>> >
>> > SONET Failure Indication Delay (<10ms, almost immediate)
>> > IGP Hello Timer (1 sec)
>> > IGP Dead-Interval (3 sec)
>> > LSA Generation Delay (0, immediate)
>> > LSA Flood Packet Pacing (0, immediate)
>> > LSA Retransmission Packet Pacing (0, immediate)
>> > SPF Delay (0, immediate)
>> >
>> > Is there agreement, concern, or questions for these changes to be made for
>> > the 01 versions of the drafts? Are there additional issues that should be
>> > addressed?
>> >
>
>Yes.  I agree that the timer values should be reported with
>the results.  But, if we require very low specific values,
>we run the risk of precluding benchmarks for some products.
>(I have *not* surveyed the configuration ranges for all manufacturers.)

This is true and certainly a concern.

>If a configuration interface places limits on timers, the designers
>may have had a good reason to do so.  Do we require them to remove
>these safety limits in order to be benchmarked?

We should not.


>The proposal to report timer values raises another issue:
>The Methodology Draft has no Reporting Formats specified.
>Perhaps we can do something creative with the reports,
>where we normalize-out relevant timer values and simply report
>the additional convergence time? (thinking out loud here)
>Then we don't encourage designers to allow configurations
>that might be unstable just to perform well on the benchmarks.
>This is worth some investigation, IMO.

I agree.  This is a good idea.  The co-authors will propose a reporting 
format that facilitates the calculations in section 5.2.  The "recommended" 
values can still be provided for guidance.


>thanks for starting discussions, more comments to follow,
>Al
>
>
>
>_______________________________________________
>bmwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/bmwg



_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg