Re: [bmwg] Comment on meth-18.

"McLendon, John" <John.McLendon@spirent.com> Fri, 17 July 2009 18:33 UTC

Return-Path: <John.McLendon@spirent.com>
X-Original-To: bmwg@core3.amsl.com
Delivered-To: bmwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26BC28C324 for <bmwg@core3.amsl.com>; Fri, 17 Jul 2009 11:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.208
X-Spam-Level:
X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjUDwUnrz+Ds for <bmwg@core3.amsl.com>; Fri, 17 Jul 2009 11:33:41 -0700 (PDT)
Received: from smtp2-cal.SPIRENTCOM.COM (smtp2-cal.spirentcom.com [70.137.112.7]) by core3.amsl.com (Postfix) with ESMTP id C000A28C320 for <bmwg@ietf.org>; Fri, 17 Jul 2009 11:33:41 -0700 (PDT)
Received: from spccalexcbe01.AD.SPIRENTCOM.COM ([10.1.1.12]) by smtp2-cal.SPIRENTCOM.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 11:34:14 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Jul 2009 11:34:13 -0700
Message-ID: <03C9BAFF80BCD047AFBDFBB5B38A688CFD18DF@spccalexcbe01.AD.SPIRENTCOM.COM>
In-Reply-To: <00a301ca06f5$a52fd510$840efe90@emea.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [bmwg] Comment on meth-18.
Thread-Index: AcoFhX5d/L88OUFuStem1Mmgc3WxrgAEPfsgACVfQqAANqU5IA==
References: <200907151948.n6FJm39K015030@klph001.kcdc.att.com> <03C9BAFF80BCD047AFBDFBB5B38A688CF53BBA@spccalexcbe01.AD.SPIRENTCOM.COM> <00a301ca06f5$a52fd510$840efe90@emea.cisco.com>
From: "McLendon, John" <John.McLendon@spirent.com>
To: Kris Michielsen <kmichiel@cisco.com>, Al Morton <acmorton@att.com>, bmwg@ietf.org
X-OriginalArrivalTime: 17 Jul 2009 18:34:14.0935 (UTC) FILETIME=[2FAD8270:01CA070D]
Subject: Re: [bmwg] Comment on meth-18.
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bmwg>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2009 18:33:43 -0000

Hi Kris,
I'm still not sure what "discard" traffic means in terms of a test
device.
If the test device is monitoring both ports simultaneously (and all of
the testers I am knowledgeable about are capable of this), then my
understanding of the test scenario is that the test device either
detects/causes the switchover, captures the time of the Convergence
Event Instant onset, and can then apply the equation once full
convergence occurs. 

If this is correct, then nothing needs to be said about traffic received
by the tester on the Preferred Egress Interface unless one wishes to
measure the delta between the onset of the Convergence Event Instant and
the end of the Convergence Event, i.e. one wants to measure the time
between first packet loss and all traffic stopping on the Preferred
Egress Interface, i.e. the Ta/Tb/Ta'/Tb'/Ta"/Tb" timestamps in Figure 6.
In this case, one might want to state that the tester collects stats on
the both interfaces for the entire test, altho' this is implicit in the
equations and in Figure 6.

I also have one other comment - the current measurement period is
reported in seconds. The test devices I am aware of can capture the
timestamps with millisecond accuracy (presuming there is a minimum
transmission rate of at least two packets per millisecond for each
route). One might want to put in a MAY for this.

Make sense?
J...

-----Original Message-----
From: Kris Michielsen [mailto:kmichiel@cisco.com] 
Sent: Friday, July 17, 2009 11:46 AM
To: McLendon, John; 'Al Morton'; bmwg@ietf.org
Subject: RE: [bmwg] Comment on meth-18.

John,

Thanks for reviewing the draft!

What do you think of the following suggestion?
OLD:
For Convergence Events caused by the Tester, such as an IGP cost change,
the Tester may start to drop all traffic received from the
Preferred Egress Interface at the Convergence Event Instant to achieve
the same result.

NEW:
For Convergence Events caused by the Tester, such as an IGP cost change,
the Tester may start to discard all traffic received from
the Preferred Egress Interface at the Convergence Event Instant, or may
be able to separately observe packets received from the
Preferred Egress Interface prior to the Convergence Event Instant, to
achieve the same result.

Thanks,
Kris

> -----Original Message-----
> From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On 
> Behalf Of McLendon, John
> Sent: 16 July 2009 00:00
> To: Al Morton; bmwg@ietf.org
> Subject: [bmwg] Comment on meth-18.
> 
> Hi all,
> I have a comment on the following statement in Sec 4, top of pp. 9, in
> meth-18:
> 
> "For Convergence Events caused by the Tester, such as an IGP 
> cost change, the Tester may start to drop all traffic 
> received from the Preferred Egress Interface at the 
> Convergence Event Instant to achieve the same result."
> 
> The word "drop" implies that the test device forwards or 
> drops traffic.
> In my experience, test devices neither forward or drop 
> traffic. They may generate or analyze traffic, but a test 
> device dropping traffic doesn't seem helpful to the desired 
> measurement. Many test devices can bring a link down at the 
> physical layer.
> 
> J...
> 
> 
> 
> -----Original Message-----
> From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On 
> Behalf Of Al Morton
> Sent: Wednesday, July 15, 2009 3:48 PM
> To: bmwg@ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts
> 
> Comments on meth-18, all nits,
> Al (mostly as participant)
> 
> At 01:44 PM 7/14/2009, Al Morton wrote:
> >...This message begins a Last call on the IGP-Dataplane Convergence 
> >Time Benchmarking drafts.
> >
> >http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-term-18
> >http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-meth-18
> >http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-app-17
> >
> >The Last Call will end on July 31, 2009.
> 
> 
> Section 4, top of page 10,
> s/At least one condition need to /At least one condition needs to /
> 
> 
> 5.7.  Measurement Accuracy
> ...  When packet jitter is much less than the convergence
>     time, it is a negligible source of error and therefor it 
> will be s/therefor/therefore/
> 
> 5.9 Tester Capabilities
> Add "Also see section 6 for method-specific capabilities."
> 
> 6.1.3.  Measurement Accuracy
> 
>     TBD
> (can't leave this TBD, if there's no obvious material, delete 
> section ?)
> 
> 
> Section 7, Reporting Format
> 
>          Maximum Packet Delay Threshold      seconds
> this is called "Forwarding Delay Threshold" in the term doc, right?
> pick one for both...
> 
> Section 9, same as terms, use the standard BMWG paragraphs...
> 
> 
>     
> 
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg
> 
> <DIV><FONT size="1">
> 
> E-mail confidentiality.
> --------------------------------
> This e-mail contains confidential and / or privileged 
> information belonging to Spirent Communications plc, its 
> affiliates and / or subsidiaries. If you are not the intended 
> recipient, you are hereby notified that any disclosure, 
> copying, distribution and / or the taking of any action based 
> upon reliance on the contents of this transmission is 
> strictly forbidden. If you have received this message in 
> error please notify the sender by return e-mail and delete it 
> from your system. If you require assistance, please contact 
> our IT department at helpdesk@spirent.com.
> 
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, 
> United Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
> 
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West 
> Sussex, RH10 9XN, United Kingdom.
> 
> Or if within the US,
> 
> Spirent Communications,
> 26750 Agoura Road, Calabasas, CA, 91302, USA.
> Tel No. 1-818-676- 2300 
> 
> </FONT></DIV>
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg
> 


<DIV><FONT size="1">

E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. If you require assistance, please contact our IT department at helpdesk@spirent.com.

Spirent Communications plc,
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300 

</FONT></DIV>