gmane.ietf.bmwg

WG adoption: Traffic Management Draft

Fernando Calabria (fcalabri — 2013-05-14T16:30:51

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

Adoption of traffic management draft

Vijay K. Gurbani — 2013-05-13T22:26:29

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

Comments on draft-constantine-bmwg-traffic-management-01

Gilles Forget — 2013-05-11T11:00:00

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
< at > : gilles.forget< at >sympatico.ca

Politique de Confidentialite des Courriels | Email Confidentiality Warning




_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

WG adoption: Traffic Management Draft

Sarah Banks — 2013-04-30T06:25:16

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/msg02758.html

Please read the draft and provide opinions on whether BMWG should adopt it as a chartered work item, by May 20th, 2013<x-apple-data-detectors://3>.

As always, please send all comments to the bmwg-list.

Thanks,
Sarah
BMWG co-chair

_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

Publication Request and Shepherding Form for IMIX draft

MORTON JR., ALFRED C (AL — 2013-04-29T17:36:51

BMWG,

Following Joel's WG consensus call, Lucien Avramov volunteered to
be the document shepherd for the IMIX draft, and he completed the
shepherd's form (attached). The IETF Last Call started last Monday,
and is still in progress.

Usually I send these forms to the WG, and that step
was delayed about a week, but here it is now.

In the future, Sarah and I will ask for other volunteers to
learn more about the IETF process through the role of shepherd,
and the shepherd role will be expanding a bit, too. For now,
I thank Lucien for his willingness to serve the BMWG in this
capacity (your work as shepherd is just beginning, Lucien!).

regards,
Al
bmwg co-chair
This is a Publication Request & document shepherding form for

IMIX Genome: Specification of variable packet sizes for additional testing
draft-ietf-bmwg-imix-genome-04

using the shepherding form dated 24 February 2012, now available from
http://www.ietf.org/iesg/template/doc-writeup.html

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational, as indicated on the title page.
All BMWG RFCs are traditionally Informational,
in part because they do not define protocols and
the traditional conditions for Stds track advancement
did not apply. However, they are specifications and
the RFC 2119 terms are applicable to identify the
level of requirements.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

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 device and deployment will not be appropriate for another.
However, the mix of sizes may be known and the tester may be asked to
augment the fixed size tests. To address this need, and the
perpetual goal of specifying repeatable test conditions, this draft
defines a way to specify the exact repeating sequence of packet sizes
from the usual set of fixed sizes, and other forms of mixed size
specification.

Working Group Summary:

WG Consensus was smooth after development over a reasonable period of time.

Document Quality:

There are many implementations of various test equipment that use IMIX.

Personnel:

Who is the Document Shepherd? Lucien Avramov
Who is the Responsible Area Director? Joel Jaeggli

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

In depth review of the draft and the meeting minutes from the IETF conferences regarding this draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Long standing reviews were constructive and agreeable, consensus is strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Based on idnits 2.12.16 < at > April 13, 2013
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
where the warning and comment stem from the document date, 12/12/12.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

N/A, no IANA considerations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None.
_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

New Co-Chair

MORTON JR., ALFRED C (AL — 2013-04-29T17:01:57

BMWG,

A long time ago (IAGFFA), Kevin Dubray asked me to join him as co-chair.

With the concurrence of our Area Directors, Sarah Banks will now join me 
as co-chair. She has accepted all the new responsibilities that the co-chair 
position entails. 

I'm very pleased to make this announcement, and I hope you'll join me
in welcoming Sarah in her new role.

Al
bmwg co-chair

WG Adoption: power benchmarking draft

MORTON JR., ALFRED C (AL — 2013-04-29T16:03:24

BMWG,

Following discussion and support at our session during IETF-86,
we now ask the BMWG mailing list for review & indications of
support for the following draft:

Benchmarking Power usage of networking devices
http://tools.ietf.org/html/draft-manral-bmwg-power-usage-04

Please read the draft and weigh-in on whether BMWG should adopt this 
draft as one of its chartered work items, by May 20, 2013.

Please send all comments to the bmwg-list.

thanks and regards,
Al
bmwg co-chair

Biggest Fake Conference in Computer Science

2013-04-27T17:13:36

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

Last Call: (IMIXGenome:Specification of variable packet sizes for additionaltesting)to Informational RFC

The IESG — 2013-04-22T18:57:17

The IESG has received a request from the Benchmarking Methodology WG
(bmwg) to consider the following document:
- 'IMIX Genome: Specification of variable packet sizes for additional
   testing'
  <draft-ietf-bmwg-imix-genome-04.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf< at >ietf.org mailing lists by 2013-05-06. Exceptionally, comments may be
sent to iesg< at >ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 appropriate for another.
   However, the mix of sizes may be known and the tester may be asked to
   augment the fixed size tests.  To address this need, and the
   perpetual goal of specifying repeatable test conditions, this draft
   defines a way to specify the exact repeating sequence of packet sizes
   from the usual set of fixed sizes, and other forms of mixed size
   specification.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-bmwg-imix-genome/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-bmwg-imix-genome/ballot/


No IPR declarations have been submitted directly on this I-D.

draft-constantine-bmwg-traffic-management-01.txt

Barry Constantine — 2013-04-19T11:44:54

Hi BMWG,

The new individual submission was posted today and we worked hard to incorporate many comments from Al, Gilles, and Shane received on the list.

The central focus of this revision was to augment the verification aspect of the first draft with capacity benchmarking for each traffic management area.

An example would include the area of traffic shapers; the capacity benchmarking section specifies various combinations of stress test including:

-        Single shaper per port, all ports active

-        Multiple shapers per port, single port active

-        Combination of the first two; multiple shapers per port and all ports active

We hope that this version aligns to the charter of the BMWG and that the group would accept this as a formal work item as discussed in Orlando.

Thank you,
Barry Constantine
_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

Traffic Management Benchmarking Alignment

Barry Constantine — 2013-03-26T12:47:22

Hi Folks,

First off, thanks to those that read this draft and provided feedback; the co-authors are working on some key revisions and hope to submit individual draft version 1 in mid-April.

One key point that Al made was that the work needed refinement to not only address traffic management verification testing, but to extend into the core scope of BMWG which includes capacity benchmarking, etc.

Our plan to accomplish this is summarized below and any feedback before we make the revisions will be appreciated.

Currently the draft is divided into several sections, each a specific traffic management function:

* Buffer / Queue testing

* Policing tests

* Shaping tests

* Congestion Management tests

Each individual test provides the test method and metrics that need to be measured in order to properly compare different vendor's performance.

What we propose to add is a scalability test to each individual section, which tests each traffic management function to the rated limits; i.e. if each port can perform shaping at egress simultaneously, then the shaping scalability test would provide the method to conduct that test

Scalability testing of a combination of traffic management functions would be a daunting task (i.e. hierarchical QoS policies) and would be outside the scope of this work. The draft may touch on the subject with general guidelines, but complex QoS policies would be deferred to potential follow-on drafts.

Thanks in advance for any feedback on this proposed alignment to BMWG charter.

Barry Constantine
_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

Draft Minutes for IETF-86

MORTON JR., ALFRED C (AL — 2013-03-17T11:13:02

BMWG,

The first draft if our meeting summary is here:
http://www.ietf.org/proceedings/86/minutes/minutes-86-bmwg

non-editorial comments to the list, please.
editorial comments to me. 
There's at least one Easter Egg for you to find...

Thanks to Barry Constantine for excellent work as 
Official Note Taker!

There may be a short pause in chair activity while 
I travel to another meeting and get it organized
(today), but I'd like to thank everyone who participated
for an extremely productive session that was supported
by people doing their homework (writing the drafts they
promised, reading drafts and posting comments on the list).

It works. It's both rewarding and exciting!

happy benchmarking,
Al
bmwg chair

draft-constantine-bmwg-traffic-management-00

Barry Constantine — 2013-03-06T19:01:17

Hello,

Al and I discussed some of the various means that comments have been arriving; some via list, some via email, and others via Word document.

Even though the work is personal submission at this point, Al indicated that it is preferred to get comments documented on the list.

So from Shane Amante, Level 3:

****

1) One thing that I think would be invaluable in this document is to state, in all sub-sections, to *not only* observe transmitted and dropped packets/bytes at the "Transmitting" and "Receiving" Test Host, *but also* and /most importantly/ make sure to observe that such counters exist on the DUT itself and in the appropriate MIB's on the device itself. I would state two reasons for that:

a) When the DUT is actually deployed to the field it is critical for operators to observe these counters to understand what the heck is happening to a customer's service; and,

b) For SP's, like Level 3, where we do usage-based billing on individual queues ... we need to ensure the counters are accurate, otherwise we don't get paid. :-) ... and, ultimately, we've all seen instances where some vendors do not implement any counters whatsoever (I can think of one vendor whose name starts with a letter between A & C being a prime example), which makes debugging problems in the field a royal PITA. Anyway, putting this in the document and emphasizing it over and over will give operators yet another sledgehammer to wield against network equipment vendors to implement counters and make sure they're accurate. :-)

2) In Section 1.1, Traffic Mgmt Overview, you talk about Traffic Classification, Policing, Shaping, Scheduling and Congestion Mgmt. While Section 6 does cover policing, shaping & congestion mgmt ... I didn't observe any discussion about traffic classification -or- scheduling in the doc. If that was your intent, then it would be useful to point out in Section 1.1 that those are beyond the scope of the doc, for future study or whatever.

3) In Section 3, I'm unclear why you mention "Firewalls". I think it might be better to change that from "firewalls" to "middleboxes", because (unfortunately) not only firewalls can do policing, etc., but there also exist devices do "WAN compression" that also perform similar functions. Thus, "middleboxes" captures a wider set of devices ...

4) Throughout the document, you talk about various measurements, burst sizes, etc., but I don't recall any conversation about whether and what type(s) of "overhead" may be included (or not) in each of these calculations. Now, I realize that every equipment vendor is different, but as you know some do include L2 framing overhead, some don't, some include L3 header overhead, etc. in these calculations. I think at least a "warning" of some type to the reader that they need to understand this is critical to ensuring accuracy of the tests. One place, of several, this is most apparent are, for example, Section 4.2 where you talk about "TCP Efficiency" and Transmitted & Retransmitted Bytes. What are you including in transmitted vs. retransmitted bytes, e.g.: TCP data segments or the full IP + TCP + data PDU?

5) In Section 6.1, Policing Tests, there is the following statement, which I believe is False. (Policing can operate at Layer-2 -or- Layer-3):

---snip---

Policing tests will only use stateless traffic since a policer only

operates at Layer 2. Stateful TCP test traffic would not yield any

benefit to test a policer.

---snip---

6) In Section 6, you mention values for burst sizes, etc. As an example, in Section 6.1, there's the CBS value of 64KB. The question I have is: where did you come up with 64KB? In Section 6.2.2, Testing Queue with Stateful Traffic, there is a recommended (?) value of 32KB for Queue Length (QL). Again, where did this value come from?

7) In Section 6.2, Queue Tests, I have a few comments. I'm not sure I understand the proposed methodology for Queue Testing here. When I read this section, it sounds like you're proposing the testing of an individual queue on a physical port. However, I'm not sure that is useful, because in nearly all cases if you're only sending one class of traffic, then the /scheduling/ treatment out of the port will generally be FIFO, (the one exception is Cisco 7200 CBWFQ where they actually, by default, treat the SPQ with a policer to avoid starving inferior queues). Either I'm gravely misunderstanding what you're proposing -- which is very likely -- or, you may need to think about rewriting this section to discuss testing of /scheduling/ out the interface, i.e.: the competition between various types of queues and the various queue scheduling disciplines: CBWFQ, DWRR and HSPQ being (I think) three of the most prevalent and widely implemented across Cisco, Juniper & ALU, respectively. (FWIW, I think you or someone else made a similar comment to the above, but its at the bottom of Section 6.4.2).

8) One thing that I think is missing from the document is testing of policing/shaping/scheduling functions when going between vastly different media where buffer-size (queue-length) really matters. Specifically, think about 10 GbE uplinks on a PE feeding into a N x DS1/DS0 interface toward a customer. Or, even 10 GbE -> 1 GbE transitions on L2 ToR switches that barely have any buffer and what little they do have has a very small fixed amount allocated to physical ports where the rest of it is "dynamically allocated". In this case, you need to think about designing a test where you don't have a single 10 GbE sending traffic into a L2 switch and out a single 1 GbE interface as you may not be consuming all of the buffer on the switch. Rather, you need to understand the ASIC architecture a little bit and design the test such that you're fanning out the traffic, like you would see in the real-world, to help consume more of the shared buffer and understand if they will work (or not) for whatever applications/environment you have.

Anyway, I think the above is probably enough for you to chew on, for now.

Overall, I do think this will be a valuable document to the IETF and the community at large, so I'd encourage you to keep working on it. And, as you have future revisions I'd be happy to review them and provide comments.

***

All excellent comments and we are already discussing their incorporation.

Thank you,
Barry Constantine

_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

Software Update Doc

Sarah Banks — 2013-02-20T05:16:47

At IETF... 82? we discussed the idea of having a draft that characterizes a device under software upgrade. At long last, and 2 minutes late for cut off, we've worked out an initial draft. Since we missed the deadline, Al, our chair, suggested that we post the draft elsewhere, and submit the draft when submissions reopen on March 11. 

In the meantime, the draft we intent to upload can be found at:

http://www.encrypted.net/draft_issu_methodology-00.pdf

Abstract
Modern forwarding devices attempt to minimize any control and data
plane disruptions while performing planned software changes, by
implementing a technique commonly known as an In Service Software
Upgrade (ISSU).
This document specifies a set of common methodologies and procedures
designed to characterize the overall behavior of a Device Under Test
(DUT) subject to an ISSU event.

We welcome any comments, questions or suggestions you may have.

Regards,
Sarah (&Fernando &Gery)

draft-constantine-bmwg-traffic-management-00

Gilles Forget — 2013-02-20T01:53:02

Hello BMWG,

I support this work as a network specialist who has many times tested traffic management capabilities in both lab and field situations.

I think this -00 revision is a good start and here are my first comments:

1. Throughout the document, the words “network device” is referenced and other times “network node” is used.
Comment: In my opinion, "network device" seems more representative and should be consistently used.

2. Section 1.1. “Traffic policing: rate limits traffic that enters a router a…”
Comment: It could also be a switch or other network appliances, so I suggest replacing the word "router" by “network device".

3. In section 2, EIR and EBS should use the word “Excess” instead of “Exceeded” in their definitions.

4. Section 5.1 “Since iperf is a software based tool, there will be performance limitations at higher link speeds".
Comment: I would like to suggest replacing by “Since iperf is software based, there will be performance limitations at higher speeds (e.g. 1G, 10G, etc…)”

5. Section 5.5, “This interactive traffic is not uni-directional in nature but is chatty.
Comment: I would suggest, “These traffic are bi-directional and can be chatty at times.”

6. Section 6.1. “Policing tests will only use stateless traffic since a policer only operates at Layer 2 . Stateful TCP test traffic would not yield any benefit to test a policer.”
Comment: I’m not sure about this, I think a policer can operate at the packet layer also. And I can assure you that TCP traffic is affected by a policer.

7. In section 6.1, Tc and Te are defined, in my opinion this should be done in section 2 instead.

8. In sections 6.2.1, 6.2.2, and 6.3, QL, Ti, BB, BSA, NDE, SR, SBS are defined, in my opinion this should be done in section 2 instead.

9. Section 6.3.2 “By cumulative TCP window, this equates to:”
Comment: I would like to suggest, “The cumulative TCP Window Sizes* (RWND at the receiving end & CWND at the transmitting end) equates to:”

10. Section 6.3.2 “* TCP window size is used per RFC 6349 and is the minimum of the TCP WIN and the Send Socket Buffer (SSB )”
Comment: I would like to suggest. “* as described in section 3 of RFC6349, the SSB MUST be large enough to fill the BDP.”

11. Section 6.4. “AQM techniques vary, but the basic principal is to discard traffic before the queue overflows (FIFO). This discard in effect sends congestion notification warning to protocols such as TCP,”
Comment: This is not true when RFC3168 is not implemented. In fact it just causes packet discards forcing TCP to adjust its TCP CWND.

Regards,

Gilles Forget, CCNP.
T : 450-473-5718
C : 514-895-8212
< at > : gilles.forget< at >sympatico.ca

Politique de Confidentialite des Courriels | Email Confidentiality Warning

_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

Benchmarking Neighbor Discovery Problems

William Cerveny — 2013-02-19T22:22:30

[Posting to bmwg and v6ops]

At the IETF 85 BMWG meeting, Ron Bonica suggested a draft on neighbor
discovery benchmarking, highlighting on the problems discussed in RFC
6583, “Operational Neighbor Discovery Problems.” I’ve completed a draft,
but missed the submission deadline by an hour. Al Morton, the BMWG
chair, suggested I post the draft elsewhere, and submit the draft when
submissions have reopened March 11.

For now, the draft can be found at:

http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.txt
http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.html
http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.pdf

Abstract

This document is a benchmarking instantiation of RFC 6583: “Operational
Neighbor Discovery Problems”. It describes a general testing procedure
and measurements that can be performed to evaluate how the problems
described in RFC 6583 may impact the functionality or performance of
intermediate nodes.

As always, I’m interested in suggestions, and comments.

Regards,

Bill Cerveny
_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

draft-ietf-bmwg-ca-bench-meth-04.txt

Barry Constantine — 2013-02-07T17:39:48

Hi Mike and Sarah,

I have not looked at this draft in a few versions and really like how you all used Sandvine data for the example application traffic mix.

I looked at the Sandvine report before asking this question but could not find the answer; can you explain the Ave Flow Size in the table?

For example of the YouTube download listed at 5MB and 13.8% of traffic, does this mean that the average video session size is 5MB of which multitudes of the video sessions comprise the 13.8%?

Thank you,
Barry Constantine

JDSU Communications Test
Principal Member Technical Staff
301-325-7069

_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

WGLC on IMIX Genome Draft

MORTON JR., ALFRED (AL — 2013-02-06T20:41:14

BMWG,

A WG Last Call period for the Internet-Draft describing the
IMIX Genome:

http://tools.ietf.org/html/draft-ietf-bmwg-imix-genome-04

will be open from 6 Feb 2013 through 6 March 2013.

This is the first WGLC in the BMWG Last Call Process. See
http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html

Please read and express your opinion on whether or not this
Internet-Draft should be forwarded to the Area Directors for
publication as an Informational RFC.  Send your comments
to this list, bmwg< at >ietf.org

As previously agreed, AD Ron Bonica will call consensus 
or other result following the WG Last Call Period.

Al
bmwg chair

Brief WG Status

MORTON JR., ALFRED (AL — 2013-02-06T20:32:25

BMWG,

With a face-to-face meeting opportunity just around the corner,
it's time to briefly review our status.

There are (at least) two new work proposals in draft-form seeking 
your review:

http://tools.ietf.org/html/draft-constantine-bmwg-traffic-management-00.txt

http://tools.ietf.org/html/draft-manral-bmwg-power-usage-03.txt

There is a draft addressing a chartered item on data center bridges:

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

and another data center-oriented proposal in preparation.

Software Upgrade Benchmarking still has the attention of a 
few of our friends, with a draft in preparation.

*The bottom line:* 

As far as Chartered work goes:

 - revised drafts expected on Content Aware Benchmarking
 - extensive IETF Last Call comments on the SIP drafts
 - WGLC on the IMIX Genome draft to begin immediately

We've also received a liaisons from the MEF for Action:
https://datatracker.ietf.org/liaison/1236/
If folks have any comment on the Service Activation Testing
document they reference, please send them to the list.

Once we get an idea of hot topics for discussion,
we'll look at the agenda for a session in Orlando.

regards,
Al
bmwg chair

Power Benchmarking

Vishwas Manral — 2013-01-29T23:47:36

Hi folks,

We have received some new interest and have recently refreshed a long
dormant draft on Power Benchmarking.
https://tools.ietf.org/html/draft-manral-bmwg-power-usage-03

We would love to hear any comments and queries on the same.

Thanks,
Authors
_______________________________________________
bmwg mailing list
bmwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

Last Call: (Terminology forBenchmarking Session Initiation Protocol(SIP) NetworkingDevices) to Informational RFC

The IESG — 2013-01-16T21:48:38

The IESG has received a request from the Benchmarking Methodology WG
(bmwg) to consider the following document:
- 'Terminology for Benchmarking Session Initiation Protocol (SIP)
   Networking Devices'
  <draft-ietf-bmwg-sip-bench-term-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf< at >ietf.org mailing lists by 2013-01-30. Exceptionally, comments may be
sent to iesg< at >ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document provides a terminology for benchmarking the SIP
   performance of networking devices.  The term performance in this
   context means the capacity of the device- or system-under-test to
   process SIP messages.  Terms are included for test components, test
   setup parameters, and performance benchmark metrics for black-box
   benchmarking of SIP networking devices.  The performance benchmark
   metrics are obtained for the SIP signaling plane only.  The terms are
   intended for use in a companion methodology document for
   characterizing the performance of a SIP networking device under a
   variety of conditions.  The intent of the two documents is to enable
   a comparison of the capacity of SIP networking devices.  Test setup
   parameters and a methodology document are necessary because SIP
   allows a wide range of configuration and operational conditions that
   can influence performance benchmark measurements.  A standard
   terminology and methodology will ensure that benchmarks have
   consistent definition and were obtained following the same
   procedures.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-term/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-term/ballot/


No IPR declarations have been submitted directly on this I-D.