Re: [bmwg] IGP Data Plane Convergence

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.

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.

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.

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

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.

thanks for starting discussions, more comments to follow,
Al

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