Re: [bmwg] IGP Data Plane Convergence

Scott Poretsky <> Wed, 09 July 2003 22:13 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id SAA25794 for <>; Wed, 9 Jul 2003 18:13:27 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 19aNBM-0002tc-9j; Wed, 09 Jul 2003 18:13:00 -0400
Received: from ([] by with esmtp (Exim 4.20) id 19aNAn-0002t1-Bt for; Wed, 09 Jul 2003 18:12:25 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA25659 for <>; Wed, 9 Jul 2003 18:12:20 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19aNAk-0004JT-00 for; Wed, 09 Jul 2003 18:12:22 -0400
Received: from [] ( by ietf-mx with esmtp (Exim 4.12) id 19aNAj-0004JI-00 for; Wed, 09 Jul 2003 18:12:21 -0400
Received: from ([]) by (8.11.0/8.11.0) with ESMTP id h69MB7305989; Wed, 9 Jul 2003 18:11:07 -0400 (EDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 09 Jul 2003 18:13:09 -0400
To: Al Morton <>,
From: Scott Poretsky <>
Subject: Re: [bmwg] IGP Data Plane Convergence
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Benchmarking Methodology Working Group <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


Thanks for the insightful comments.  See replies below.


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.


>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,
>bmwg mailing list

bmwg mailing list