Al Morton | 13 Apr 14:01 2011
Picon

Draft Minutes from the IETF-80 session

BMWG,

First Draft Minutes are available:
http://www.ietf.org/proceedings/80/minutes/bmwg.html

Please send me any comments by April 20, 2011.

Thanks to Fernando C. for taking notes, and Matt Z. for
help filling-in and on jabber.

regards,
Al
bmwg chair
Internet-Drafts | 15 Apr 14:15 2011
Picon

I-D Action:draft-ietf-bmwg-ipflow-meth-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Benchmarking Methodology Working Group of the IETF.

	Title           : IP Flow Information Accounting and Export Benchmarking Methodology
	Author(s)       : J. Novak
	Filename        : draft-ietf-bmwg-ipflow-meth-01.txt
	Pages           : 31
	Date            : 2011-04-15

This document provides methodology and framework for quantifying 
performance impact of monitoring of IP flows on a network device and
export of this information to a collector. It identifies the rate at
which the IP flows are created, expired and successfully exported as
a new performance metric in combination with traditional throughput.

The metric is only applicable to the devices compliant with the
Architecture for IP Flow Information Export [RFC5470].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipflow-meth-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-bmwg-ipflow-meth-01.txt): message/external-body, 70 bytes
(Continue reading)

Jan Novak (janovak | 15 Apr 14:20 2011
Picon

New Version draft-ietf-bmwg-ipflow-meth-01.txt

Hi,

I have just re-submitted the Flow Monitoring Perf draft which addresses
the comments from WG LC reviews.

The reviewers captured numerous valid technical points which improved
the document - thanks everyone for that.

Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson

-----Original Message-----
From: bmwg-bounces <at> ietf.org [mailto:bmwg-bounces <at> ietf.org] On Behalf Of
Internet-Drafts <at> ietf.org
Sent: 15 April 2011 13:15
To: i-d-announce <at> ietf.org
Cc: bmwg <at> ietf.org
Subject: [bmwg] I-D Action:draft-ietf-bmwg-ipflow-meth-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Benchmarking Methodology Working Group
of the IETF.

	Title           : IP Flow Information Accounting and Export
Benchmarking Methodology
	Author(s)       : J. Novak
(Continue reading)

David Newman | 19 Apr 02:51 2011

Fwd: New Version Notification for draft-player-dcb-benchmarking-04

bmwg,

Version -04 of the DCB draft is now available here:

http://tools.ietf.org/html/draft-player-dcb-benchmarking-04

This version updates section 5.1.3.1, in which we recommend the use of
the cut-through (FIFO) method when comparing latency of devices with
cut-through and store-and-forward architectures.

Earlier versions of the draft recommended using the LILO method as
recommended in the RFC 4689 discussion of forwarding delay. LILO and
FIFO measurements should be virtually identical, but FIFO is more
consistent with the existing definitions in RFC 1242.

We welcome your comments on this draft, and (as Al requested) on whether
the bmwg should adopt this draft as a work item.

Timmons C. Player
David Newman

-------- Original Message --------
Subject: New Version Notification for draft-player-dcb-benchmarking-04
Date: Mon, 18 Apr 2011 13:47:42 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
To: dnewman <at> networktest.com
CC: timmons.player <at> spirent.com

A new version of I-D, draft-player-dcb-benchmarking-04.txt has been
successfully submitted by David Newman and posted to the IETF repository.
(Continue reading)

Vijay K. Gurbani | 22 Apr 20:20 2011

SIP work feedback from Prague

Scott: Thank you for your comments on the SIP work during
BMWG meeting in Prague.  Here is an attempt to close
the open issues.

To wit, you had indicated the following issues:

1) The 50% step rate --- clarify that the decrease in certain
  test cases of 50% applies to decreasing the previous rate
  by 50%, not the base rate one starts with.

2) When testing, do not stop at the first error, and instead,
  use a time slice to conduct the test.  This allows other
  latent behaviour in the device to become manifest, that would
  otherwise not if the testing stopped at the first error.

3) Indicate that the idea of the SIP tests is to run the tests
with a middle box device from Vendor-A and repeat the tests
with a middle box device from Vendor-B to obtain a comparison
of performance between Vendors A and B.

Issue (1) is fairly cut and dry; indeed, we will do the changes
you suggest.  The same goes for (3).

Carol and I had a long chat about issue (2).  The intent of the SIP
work in bmwg is to discover the highest request rate that can be
successfully processed by a system or device before the load overwhelms
the system or device.  In this thinking, we are interested in knowing
the maximum number of SIP requests (registrations, invitations with
and without media, instant messages, etc.) that a system or device
can process before the load overwhelms the system or device such that
(Continue reading)

Vijay K. Gurbani | 22 Apr 20:33 2011

SIP work feedback from Prague

Oops, sorry for the resend.  I forgot to add Scott
Bradner in the To list since he is the "Scott" I
mention below.

Scott: Thank you for your comments on the SIP work during
BMWG meeting in Prague.  Here is an attempt to close
the open issues.

To wit, you had indicated the following issues:

1) The 50% step rate --- clarify that the decrease in certain
  test cases of 50% applies to decreasing the previous rate
  by 50%, not the base rate one starts with.

2) When testing, do not stop at the first error, and instead,
  use a time slice to conduct the test.  This allows other
  latent behaviour in the device to become manifest, that would
  otherwise not if the testing stopped at the first error.

3) Indicate that the idea of the SIP tests is to run the tests
with a middle box device from Vendor-A and repeat the tests
with a middle box device from Vendor-B to obtain a comparison
of performance between Vendors A and B.

Issue (1) is fairly cut and dry; indeed, we will do the changes
you suggest.  The same goes for (3).

Carol and I had a long chat about issue (2).  The intent of the SIP
work in bmwg is to discover the highest request rate that can be
successfully processed by a system or device before the load overwhelms
(Continue reading)

Scott O. Bradner | 22 Apr 21:04 2011
Picon

Re: SIP work feedback from Prague

1 & 3 seem just fine

re #2 - this looks ok assuming the request process is single threaded
(send request, wait for response, delay to make sure rate is coreect, loop)

would this still work if the server is multi threaded and the response
latency is longer than the inter-request interval?

Scott
Vijay K. Gurbani | 22 Apr 21:36 2011

Re: SIP work feedback from Prague

On 04/22/2011 02:04 PM, Scott O. Bradner wrote:
> 1&  3 seem just fine

Scott: Thanks for a quick response.  I hope I have interpreted your
questions correctly and provided an answer in line with your
queries; if not, I apologize before hand and am afraid we'll have
to engage in a bit more email exchange.

That said, please see inline.

> re #2 - this looks ok assuming the request process is single threaded
> (send request, wait for response, delay to make sure rate is coreect,
> loop)

Most SIP test tools ("the request process" in your
response above) have the ability to send n requests/sec and
stop sending requests either after some number of seconds,
or when the maximum request limit has been reached (some
support both modes, the one we used supported sending
n req/s until you have sent N total requests, where
N > n).

Now, whether or not the request process is single
threaded or multi-threaded, or uses fork() to create
additional processes is probably not important as long as
the request process can send n req/sec and stop when
sending more requests after a certain --- well defined ---
point.

> would this still work if the server is multi threaded and the
(Continue reading)


Gmane