http://permalink.gmane.org/gmane.ietf.bmwg hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.bmwg/2517 <pre>Thanks Lucien -- this draft is certainly useful. Please find comments below. of the first bit of the input frame reaches the input port and ending when the start of the first bit of the output frame is seen on the output port. Please add the cut-through switching aspect for additional clarity. Given the wide variation in servers, adapters, OS, Virtualized/non-virtualized environments etc. it may be hard to benchmark goodput. Perhaps a useful metric to benchmark would be the tcp performance in a pure test environment. Need to cover buffering per priority (typically 8 priorities) besides port and global. Thanks, Ramki -----Original Message----- From: bmwg-bounces&lt; at &gt;ietf.org [mailto:bmwg-bounces&lt; at &gt;ietf.org] On Behalf Of Lucien Avramov (lavramov) Sent: Wednesday, June 05, 2013 11:07 AM To: bmwg&lt; at &gt;ietf.org Subject: [bmwg] new draft for data center benchmarking: draft-dcbench-def Hi BMWG, At IETF 86, Jacob presented the idea for a data center benchmarking definition and methodology. Our goal is to cr</pre> ramki Krishnan 2013-06-18T17:37:18 http://permalink.gmane.org/gmane.ietf.bmwg/2517 <pre>Thanks Lucien -- this draft is certainly useful. Please find comments below. of the first bit of the input frame reaches the input port and ending when the start of the first bit of the output frame is seen on the output port. Please add the cut-through switching aspect for additional clarity. Given the wide variation in servers, adapters, OS, Virtualized/non-virtualized environments etc. it may be hard to benchmark goodput. Perhaps a useful metric to benchmark would be the tcp performance in a pure test environment. Need to cover buffering per priority (typically 8 priorities) besides port and global. Thanks, Ramki -----Original Message----- From: bmwg-bounces&lt; at &gt;ietf.org [mailto:bmwg-bounces&lt; at &gt;ietf.org] On Behalf Of Lucien Avramov (lavramov) Sent: Wednesday, June 05, 2013 11:07 AM To: bmwg&lt; at &gt;ietf.org Subject: [bmwg] new draft for data center benchmarking: draft-dcbench-def Hi BMWG, At IETF 86, Jacob presented the idea for a data center benchmarking definition and methodology. Our goal is to cr</pre> ramki Krishnan 2013-06-18T17:37:18 http://permalink.gmane.org/gmane.ietf.bmwg/2516 <pre>Hi BMWG, At IETF 86, Jacob presented the idea for a data center benchmarking definition and methodology. Our goal is to create data center specific benchmarking guidance as this differs in multiple areas from usual general purpose benchmarking. Thanks to the feedback, we adopted the recommendation to break our work into multiple drafts. The first draft explaining the concepts and definitions relative to data center benchmarking of network equipment is posted here: http://www.ietf.org/id/draft-dcbench-def-00.txt Please provide non-editorial comments to the list and editorial comments directly to me. We are looking forward to hear from you. Cheers, Lucien </pre> Lucien Avramov (lavramov 2013-06-05T18:06:56 http://permalink.gmane.org/gmane.ietf.bmwg/2515 <pre>Hello BMWGers. We've updated http://www.ietf.org/id/draft-banks-bmwg-issu-meth-01.txt to -01, incorporating feedback from the -00 version. Please review and provide your feedback and comments to us. Thanks! Regards, Sarah </pre> Sarah Banks 2013-06-04T23:06:32 http://permalink.gmane.org/gmane.ietf.bmwg/2514 <pre> 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 : IMIX Genome: Specification of variable packet sizes for additional testing Author(s) : Al Morton Filename : draft-ietf-bmwg-imix-genome-05.txt Pages : 10 Date : 2013-06-03 Abstract: Benchmarking Methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, and so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX". The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropr</pre> internet-drafts< at >ietf.org 2013-06-03T22:07:06 http://permalink.gmane.org/gmane.ietf.bmwg/2513 <pre>ok please remind fellow ADs to include authors on their comment/discuss e-mails, so we don't have to go check the evaluation record. Al </pre> MORTON JR., ALFRED C (AL 2013-06-03T21:19:22 http://permalink.gmane.org/gmane.ietf.bmwg/2512 <pre>I've put it in ad followup needed. if you're going to do another edit please do so quickly. </pre> joel jaeggli 2013-06-03T21:15:30 http://permalink.gmane.org/gmane.ietf.bmwg/2511 <pre>I just checked the IESG evaluation record, and there are a few more comments I'll try to include in the revision. </pre> MORTON JR., ALFRED C (AL 2013-06-03T21:05:44 http://permalink.gmane.org/gmane.ietf.bmwg/2510 <pre>yes </pre> joel jaeggli 2013-06-03T20:33:42 http://permalink.gmane.org/gmane.ietf.bmwg/2509 <pre>Hey Joel, we agreed to several changes that have only appeared in a preliminary version (the diffs I sent to Benoit in reply to comments). I need to upload the revised version ASAP, I suppose... Al </pre> MORTON JR., ALFRED C (AL 2013-06-03T19:55:30 http://permalink.gmane.org/gmane.ietf.bmwg/2508 <pre>Thanks guys. They should all be this easy to sponsor. joel On 6/3/13 12:36 PM, The IESG wrote: </pre> joel jaeggli 2013-06-03T19:52:39 http://permalink.gmane.org/gmane.ietf.bmwg/2507 <pre>The IESG has approved the following document: - 'IMIX Genome: Specification of variable packet sizes for additional testing' (draft-ietf-bmwg-imix-genome-04.txt) as Informational RFC This document is the product of the Benchmarking Methodology Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-bmwg-imix-genome/ Technical Summary Benchmarking Methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, and so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX". The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking devi</pre> The IESG 2013-06-03T19:36:01 http://permalink.gmane.org/gmane.ietf.bmwg/2506 <pre>Hi Al, Thanks for the quick reaction. All my points are addressed with your temp version. Regards, Benoit </pre> Benoit Claise 2013-05-28T21:52:43 http://permalink.gmane.org/gmane.ietf.bmwg/2505 <pre>Hi Benoit, thanks for your comments, minimal replies where needed below. Al ... acm - I have added the sentence above (with slight clarification, see below), and appended the following sentence to the scope and goals in section 2, which should help to clarify the role of the document: Thus, the requirements presented in this specification, expressed in [RFC2119] terms, are intended for those performing/reporting laboratory tests to improve clarity and repeatability. acm - it is, but it evolved from a constraint when jumbo sizes were not included. Removed that last two bullets, above. &lt;editorial change fixed&gt; acm - Address + (Port AND/OR Blade) acm - the sentence that covers this now reads: If z (MTU) is used, the tester MUST specify the length of the MTU in the report. (so the MTU semantic remains in the table) acm - even if a sequence of different sizes is too long to describe, the packet sizes are usually chosen from bins in a histogram and therefore some summarization of leng</pre> MORTON JR., ALFRED C (AL 2013-05-28T17:34:33 http://permalink.gmane.org/gmane.ietf.bmwg/2504 <pre>Benoit Claise has entered the following ballot position for draft-ietf-bmwg-imix-genome-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of this document. However, I have some remarks/questions. Please engage in the discussion. - z=MTU is seen as valuable, so MTU MUST be specified if used. Where? by whom? The tester? Following Section 4 " The tester MUST complete the following table" example", you might need something such as: If the z (MTU) is used, the tester MUST specifiy the MTU value in the report - While this approach allows some f</pre> Benoit Claise 2013-05-28T14:00:14 http://permalink.gmane.org/gmane.ietf.bmwg/2503 <pre>Hello BMWG, With discussion at the previous IETF-86 session, we're now asking the BMWG mailing list for reviews, comments and indication of support for the following draft: Traffic Management Benchmarking http://tools.ietf.org/html/draft-constantine-bmwg-traffic-management-01 + support .. Rgds </pre> Fernando Calabria (fcalabri 2013-05-14T16:30:51 http://permalink.gmane.org/gmane.ietf.bmwg/2502 <pre>Sarah: I support the adoption of draft-constantine-bmwg-traffic- management as a chartered work item. With the need for services that purport to switch data-centers or server farms or VPNs depending on traffic patterns, a draft such as this could provide some repeatability to better understand traffic management. Thanks, - vijay </pre> Vijay K. Gurbani 2013-05-13T22:26:29 http://permalink.gmane.org/gmane.ietf.bmwg/2501 <pre>I support this draft. It is important to get traffic-management benchmarking consistent. I have read 01 and have some more comments as well: Main comment: For congestion management(6.4.1) tests there should be some considerations for marking (ECN) vs. a dropping. -- Jacob From: Sarah Banks &lt;sbanks&lt; at &gt;aerohive.com&lt;mailto:sbanks&lt; at &gt;aerohive.com&gt;&gt; Date: Monday, April 29, 2013 11:25 PM To: "bmwg&lt; at &gt;ietf.org&lt;mailto:bmwg&lt; at &gt;ietf.org&gt;" &lt;bmwg&lt; at &gt;ietf.org&lt;mailto:bmwg&lt; at &gt;ietf.org&gt;&gt; Subject: [bmwg] WG adoption: Traffic Management Draft Hello BMWG, With discussion at the previous IETF-86 session, we're now asking the BMWG mailing list for reviews, comments and indication of support for the following draft: Traffic Management Benchmarking http://tools.ietf.org/html/draft-constantine-bmwg-traffic-management-01 Co-author Barry Constantine sent an email to the BMWG list on April 19th, when he submitted the aforementioned -01 revision of the draft, with great notes describing the update: http://www.ietf.org/mail-archive/web/bmwg/current</pre> Jacob Rapp (jarapp 2013-05-13T21:29:03 http://permalink.gmane.org/gmane.ietf.bmwg/2500 <pre>Hello Sarah &amp; bmwg, Pls take this email as my full support for adopting ‘[bmwg] draft-constantine-bmwg-traffic-management-01.txt’ into the RFC repository as a chartered work item. I have been involved in numerous traffic management benchmark scenarios and find the outlined draft very useful. Best regards Reinhard Schrage t: +49 (0) 5137 909540 m: +49 (0) 172 26.36.046 &lt;mailto:reinhard&lt; at &gt;schrageconsult.com&gt; reinhard&lt; at &gt;schrageconsult.com From: bmwg-bounces&lt; at &gt;ietf.org [mailto:bmwg-bounces&lt; at &gt;ietf.org] On Behalf Of Sarah Banks Sent: 30 April 2013 08:25 To: bmwg&lt; at &gt;ietf.org Subject: [bmwg] WG adoption: Traffic Management Draft Hello BMWG, With discussion at the previous IETF-86 session, we're now asking the BMWG mailing list for reviews, comments and indication of support for the following draft: Traffic Management Benchmarking &lt;http://tools.ietf.org/html/draft-constantine-bmwg-traffic-management-01&gt; http://tools.ietf.org/html/draft-constantine-bmwg-traffic-m</pre> Reinhard Schrage 2013-05-13T11:12:29 http://permalink.gmane.org/gmane.ietf.bmwg/2499 <pre>As I posted on mailing list,I support this draft as WG item. http://www.ietf.org/mail-archive/web/bmwg/current/msg02748.html I read 01,I have comments. Is it possible to add measurement method that how to calculate configured shaping rate on devices? There are some implementations for ethernet shaping. 1)count Data,FCS,Ethernet header 2)count Data,FCS,Ethernet header,Preamble + SFD,Inter Frame Gap If the packet length was changed,2) result is constant but 1) would be differed without configuration change. Regards, -Shishio (2013/04/19 21:24), MORTON JR., ALFRED C (AL) wrote: </pre> Shishio Tsuchiya 2013-05-13T02:48:54 http://permalink.gmane.org/gmane.ietf.bmwg/2498 <pre>Hello, I want to mention my support for this draft. I'm involved with traffic management issues in my work and I'm convinced that this document will become a useful guide for the industry. I was involved in version 00 review and my comments are incorporated in the current version. I plan to follow this draft and bring more comments along the way. I recommend BMWG to adopt this draft as a chartered work item. Thanks. Gilles Forget, CCNP. T : 450-473-5718 C : 514-895-8212 &lt; at &gt; : gilles.forget&lt; at &gt;sympatico.ca Politique de Confidentialite des Courriels | Email Confidentiality Warning _______________________________________________ bmwg mailing list bmwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/bmwg </pre> Gilles Forget 2013-05-11T11:00:00 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.bmwg