Subject: RE: [bmwg] Is the BMWG a proper home for this I-D?ch

From: [email-masked]
Date: Mon, 4 Oct 2004 15:05:08 -0400

Russ,

As interesting as this paper is, I always found it to be a tough fit for the
BMWG.  This proposed work item has no related terminology or methodology
draft.  The tests are not clearly described in the paper and refer to the
need to simulate hundreds of nodes for a lab benchmark test.  I went through
the thread from last April '04 (6 months ago) and read numerous responses in
objection to this becoming a work item.  My mind is open to be changed so
can you please clearly explain what is being benchmarked, how it is being
benchmarked, and why you think this is appropriate for the BMWG.

Scott

-----Original Message-----
From: Russ White [mailto:[email-masked]]
Sent: Monday, October 04, 2004 11:00 AM
To: Jim McQuaid
Cc: Howard C. Berkowitz; [email-masked]
Subject: RE: [bmwg] Is the BMWG a proper home for this I-D?ch

Okay, it's been a couple of months since we've talked about this.... Have 
we reached any concensus on it? If BMWG isn't going to take it on, I need 
to get with the ADs and see what can be done about pushing it as an 
individual contribution (though I still think it's more benchmarking 
related than real world testing, after re-reading it).

If anyone would like to contribute more considerations, to make the draft 
"wider," those would be welcome, too.

:-)

Russ

On Wed, 7 Apr 2004, Jim McQuaid wrote:

> You make an excellent point (can it be tested with created traffic or does
> it require live network traffic in some form).  That's the "bench" in
> benchmark; it can be done with lab equipment.
>
> I would agree with that distinction.  On the other hand, if there is
> enthusiasm to do this work within BMWG, tthat may be more important than
> legalisms, however sound.
>
> Jim McQuaid
>
> -----Original Message-----
> From: Howard C. Berkowitz [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2004 9:29 AM
> To: [email-masked]
> Subject: RE: [bmwg] Is the BMWG a proper home for this I-D?
>
>
> At 10:56 AM +0000 4/7/04, Jim McQuaid wrote:
>> <sorry for the blank reply>
>>
>> At the time the IPPM was "spun off" of the BMWG, the general
understanding
>> was that BMWG would look at "things" more or less in isolation, although
>> that concept is somewhat elastic.  IPPM would look at end to end network
>> kinds of performance issues.
>>
>> It seems clear to me that convergence is a performance characteristic of
>> complete networks and primarily an end to end or at least, core element
to
>> core element characteristic.
>>
>> My thought would be that this is interesting and useful work but not
>> necessarily for BMWG.
>>
>> Jim McQuaid
>
>
> I don't completely disagree with you.  I do feel that single-platform
> performance definition and benchmarking is definitely within the
> scope of BMWG, and some of my comments relating to clarifying test
> methods (e.g., black box vs. white box vs. passive analysis)
> definitely can be applied to one box.  BMWG has always looked at
> forwarding plane performance of single boxes, and I really don't
> think we are straying far to look at there control plane performance.
>
> You are correct that IPPM, as well as some of the internet
> scalability issues both in the IETF and IRTF, are probably better
> places for end-to-end convergence.
>
> At least in the case of BGP, however, there is a meaningful
> intermediate level that isn't single box and isn't end-to-end:
> convergence within an AS, and conceivably subsets thereof such as
> route reflector clusters.  Similar points can be made about
> intra-area convergence in OSPF and ISIS.  Where do these fit?
>
> I'm inclined to say BMWG, and let me suggest what might be a very
> crude rule of thumb in saying BMWG or not-BMWG.  Many of the
> Internet-wide experiments have to rely on sampling live data, with
> perhaps some selective probes.  Single-box, or small-system-of-boxes
> measurement, plausibly can be done with an artificial benchmark in a
> testing lab.
>
> Given the name of this group, perhaps, then, the decision if
> something belongs here depends on asking the question early, "can the
> measurement be made with a synthetic benchmark and test equipment,"
> or does some of it really have to come from sampling and probing live
> networks?  If the former, it's BMWG eligible. If the latter, it's
> interesting, might even warrant BMWG liaison and/or help in placing
> it elsewhere, but shouldn't stay in BMWG.
>
>
>
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bmwg
>
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bmwg
>

__________________________________
[email-masked] CCIE <>< Grace Alone

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

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

---

From: Russ White <[email-masked]>
Date: Mon, 4 Oct 2004 15:50:50 -0400 (Eastern Daylight Time)

> As interesting as this paper is, I always found it to be a tough fit for 
> the BMWG.  This proposed work item has no related terminology or 
> methodology draft.  The tests are not clearly described in the paper and 
> refer to the need to simulate hundreds of nodes for a lab benchmark test. 
> I went through the thread from last April '04 (6 months ago) and read 
> numerous responses in objection to this becoming a work item.  My mind is 
> open to be changed so can you please clearly explain what is being 
> benchmarked, how it is being benchmarked, and why you think this is 
> appropriate for the BMWG.

I suppose the question comes down to this: Is it worth having informational 
documents that provide general background and knoweldge gained from 
experience to people writing other testing documents, and actually running 
tests? Is the only thing the WG can publish actual tests, or can it also 
publish documents explaining how to test, in general, and other work in the 
area of benchmarking?

I would think informational documents about how to test in general, about 
methods and mechanisms, would also be useful.

:-)

Russ