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
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.
(Continue reading)
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)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)
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)
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)
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
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)
RSS Feed6 | |
|---|---|
8 | |
20 | |
14 | |
15 | |
9 | |
17 | |
9 | |
4 | |
13 | |
12 | |
3 | |
3 | |
15 | |
19 | |
5 | |
8 | |
5 | |
23 | |
30 | |
27 | |
33 | |
24 | |
29 | |
5 | |
8 | |
21 | |
8 | |
4 | |
13 | |
36 | |
16 | |
1 | |
17 | |
47 | |
7 | |
21 | |
20 | |
14 | |
10 | |
8 | |
8 | |
5 | |
33 | |
9 | |
16 | |
37 | |
1 | |
5 | |
13 | |
27 | |
16 | |
9 | |
12 | |
21 | |
23 | |
6 | |
1 | |
22 | |
6 | |
12 | |
47 | |
66 | |
24 | |
3 | |
27 | |
21 | |
5 | |
12 | |
31 | |
61 | |
15 | |
7 | |
12 | |
77 | |
41 | |
6 | |
4 | |
31 | |
38 | |
6 | |
14 | |
31 | |
47 | |
43 | |
19 | |
18 | |
12 | |
10 | |
5 | |
26 | |
3 | |
1 | |
8 | |
22 | |
8 | |
6 | |
6 | |
12 | |
3 | |
1 | |
10 | |
51 | |
1 | |
10 | |
21 | |
11 | |
6 | |
44 | |
4 | |
14 | |
16 | |
2 | |
55 | |
36 | |
5 | |
6 | |
31 | |
18 | |
73 | |
37 | |
75 | |
64 | |
33 | |
10 | |
9 | |
13 | |
9 | |
23 | |
10 | |
7 | |
2 | |
9 |
