GEORGESCU LIVIU MARIUS | 25 Mar 22:01 2015
Picon

Re: TCP incast generator


Hello BMWG,

Following the discussion about TCP capable traffic generators, here are more details about D-ITG (Distributed Internet Traffic Generator)

http://traffic.comics.unina.it/software/ITG/manual/

Best regards,

Marius Georgescu

On 03/24/15, Jacob Rapp <jrapp <at> vmware.com> wrote:

As discussed in the IETF 92 meeting, here is link to the TCP tool that I’ve found useful to generate TCP client/server traffic.

Jacob

_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/bmwg
Jacob Rapp | 24 Mar 15:35 2015

TCP incast generator

As discussed in the IETF 92 meeting, here is link to the TCP tool that I’ve found useful to generate TCP client/server traffic.

Jacob
_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/bmwg
Bhuvan (Veryx Technologies | 23 Mar 22:11 2015

Benchmarking Methodology for SDN Controller Performance - Updated Draft Version

Dear BMWG Members,

 

We have updated the draft (draft-bhuvan-bmwg-of-controller-benchmarking-01) about SDN Controller benchmarking addressing comments received in IETF-91 meeting and the mailing list. Thank you very much for providing your valuable comments. The latest drafts can be found here:

 

draft-bhuvan-bmwg-sdn-controller-benchmark-term-00

draft-bhuvan-bmwg-sdn-controller-benchmark-meth-00

 

Summary of Changes:

a.       Split into two different drafts (Terminology and Methodology)

b.      Defined an additional metric - Control Sessions Capacity

c.       Provided an example Benchmarking Methodology for OpenFlow Controller

d.      Addressed review comments from last IETF meeting and on the mailing list

 

Summary of Comments Addressed:

 

1.       The following changes have been made to address Al’s comments

a.        Updated the following SDN Terms - Flow, Learning Rate, Northbound interface, Path, and Cluster/Redundancy Mode in the terminology draft to provide more clarity and for consistency of terms with respect to other RFCs

b.      Updated the test setup section in methodology draft to show the the network path more explicitly between the nodes.

c.       Updated test traffic consideration section to provide references to default recommended traffic sizes.

d.      Renamed Measurement Accuracy section title to Measurement Specification Point and Recommendation.

e.      Recommended to capture HW specifications under Test Reporting section

f.        Benchmarking tests - Added text to capture test results for unsuccessful topology discovery.

g.       Added note to handle network latency while measuring Topology Discovery Time.

h.      Updated test procedure for Synchronous message processing time to handle re-transmissions and packet loss.

i.         Added pre-requisite to handle connection requirements between controller and SDN nodes while performing Synchronous message processing rate benchmarking test.

j.        Added provision to capture Loss Ratio for Synchronous message processing rate benchmarking test.

k.       Reworded the Performance to Speed under 3*3 matrix test coverage in terminology document

l.         Need to discuss about adding accuracy in 3*3 matrix

2.       Added Connection Recommendation section under Test Considerations to handle device failures and processing overheads on devices in the path to controller following the comments received from Andrew.

3.       Added clarification to Proactive Path Provisioning procedure for Path Provisioning Time benchmarking test following the comment received from Jay Karthik.

4.       Clarified the document scope for handling federation of controllers following the comment received from Ramakrishnan

5.       Added appendix to provide examples of measurement based on OpenFlow following the comment received from Marius Georgescu

6.       Added terminologies for SDN Application and Traffic Endpoint in terminology document following the comment received from Marius Georgescu

7.       Added note about sending invalid messages to controller while performing Exception Handling Benchmarking test following the comment from Scott Bradner.

 

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
Masakazu Shinohara | 17 Mar 06:11 2015
Picon

dcbench-def and dcbench-methodology

Hi BMWG

I would also support these documents.
That is really practical. I think that these documents are useful for
real environment.

Best regards.
--------------------------------------------------------------
Masakazu Shinohara
CyberAgent,Inc
DCS
Zip code 150-0045
Shibuya First Place Bldg, 8-16 Shinsen-cho
Shibuya-ku Tokyo
Mobile +81 80-6863-2356
Extension 62478
shinohara_masakazu <at> cyberagent.co.jp
--------------------------------------------------------------
Nwodo, John | 13 Mar 16:18 2015

Re: WG ADOPTION: dcbench-def and dcbench-methodology

Having read both documents, I would also like to add my support and also agree that both are useful to help practitioners evaluate vendor DC products using this understanding of metrics and methodology

 

John Nwodo, Vice President   
Morgan Stanley | Enterprise Infrastructure   
25 Cabot Square | Canary Wharf | Floor 04   
London, E14 4QA   
Phone: +44 20 7677-2581   
Mobile: +44 77990-74360   
John.Nwodo <at> morganstanley.com   

 

From: Richard Doty <rdoty <at> fxcm.com>
Date: March 6, 2015 at 08:01:39 PST
To: "bmwg <at> ietf.org" <bmwg <at> ietf.org>
Subject: Re: [bmwg] WG ADOPTION: dcbench-def and dcbench-methodology

I am in support of these documents & standards as they create a point of consistency for pragmatic reference and use.

 

Richard Doty

rdoty <at> fxcm.com

 

From: Ariel Gu <gurong <at> chinamobile.com>
Date: March 6, 2015 at 07:10:25 PST
To: "'Secher, Neal J'" <Neal.Secher <at> bnymellon.com>, <bmwg <at> ietf.org>
Subject: Re: [bmwg] WG ADOPTION: dcbench-def and dcbench-methodology

I would also support these documents, as I find that it has importance on
real practice.

Rong Gu
gurong_cmcc <at> outlook.com(gurong <at> chinamobile.com)

-----邮件原件-----
发件人: bmwg [mailto:bmwg-bounces <at> ietf.org] 代表 Secher, Neal J
发送时间: 201536 22:55
收件人: bmwg <at> ietf.org
主题: Re: [bmwg] WG ADOPTION: dcbench-def and dcbench-methodology

I would also like to add support as these documents are both useful and
necessary to help practitioners evaluate DC products.   

Neal Secher
Office   212-635-1317
Mobile 917-548-7903
neal.secher <at> bnymellon.com

-----Original Message-----
From: bmwg [mailto:bmwg-bounces <at> ietf.org] On Behalf Of Bhavani Parise
Sent: Thursday, March 05, 2015 1:57 PM
To: bmwg <at> ietf.org
Subject: Re: [bmwg] WG ADOPTION: dcbench-def and dcbench-methodology


+1 support the documents

regards,
Bhavani

On 3/4/15 4:36 AM, Fernando Calabria (fcalabri) wrote:


I support both documents.

 

Kind Regards

 

Fernando

 

 

 

 

On 3/3/15, 3:23 PM, "MORTON, ALFRED C (AL)" <acmorton <at> att.com> wrote:

 

BMWG,

 

We've been discussing a draft for Data Center Benchmarking for some

time.

 

Our new charter includes Data Center Benchmarking, so we ask everyone

to take a look (by March 18th) and express comments/support.

 

The latest drafts are here:

 

 

http://www.ietf.org/internet-drafts/draft-dcbench-def-02.txt

 

http://www.ietf.org/internet-drafts/draft-bmwg-dcbench-methodology-03

.txt

 

regards,

Al

bmwg co-chair

 

 

 

_______________________________________________

bmwg mailing list

bmwg <at> ietf.org

https://www.ietf.org/mailman/listinfo/bmwg

_______________________________________________

bmwg mailing list

bmwg <at> ietf.org

https://www.ietf.org/mailman/listinfo/bmwg

 


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

The information contained in this e-mail, and any attachment, is
confidential and is intended solely for the use of the intended recipient.
Access, copying or re-use of the e-mail or any attachment, or any
information contained therein, by any other person is not authorized. If you
are not the intended recipient please return the e-mail to the sender and
delete it from your computer. Although we attempt to sweep e-mail and
attachments for viruses, we do not guarantee that either are virus-free and
accept no liability for any damage sustained as a result of viruses.

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain
disclosures relating to European legal entities.

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



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

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




NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/bmwg
Ramki Krishnan | 12 Mar 07:04 2015

test -- please ignore

 

_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/bmwg
MORTON, ALFRED C (AL | 10 Mar 14:12 2015
Picon

Draft agenda for IETF-92 session

http://www.ietf.org/proceedings/92/agenda/agenda-92-bmwg

comments/bashes welcome,
Al
bmwg co-chair
Masakazu Shinohara | 10 Mar 00:35 2015
Picon

dcbench-def and dcbench-methodology

Hi BMWG

I would also support these documents.
That is really practical. I think that these documents are useful for
real environment.

Best regards.
--------------------------------------------------------------
Masakazu Shinohara
CyberAgent,Inc
DCS
Zip code 150-0045
Shibuya First Place Bldg, 8-16 Shinsen-cho
Shibuya-ku Tokyo
Mobile +81 80-6863-2356
Extension 62478
shinohara_masakazu <at> cyberagent.co.jp
--------------------------------------------------------------
Richard Doty | 6 Mar 17:01 2015

Re: WG ADOPTION: dcbench-def and dcbench-methodology

I am in support of these documents & standards as they create a point of consistency for pragmatic reference and use.

 

Richard Doty

rdoty <at> fxcm.com

 

From: Ariel Gu <gurong <at> chinamobile.com>
Date: March 6, 2015 at 07:10:25 PST
To: "'Secher, Neal J'" <Neal.Secher <at> bnymellon.com>, <bmwg <at> ietf.org>
Subject: Re: [bmwg] WG ADOPTION: dcbench-def and dcbench-methodology

I would also support these documents, as I find that it has importance on
real practice.

Rong Gu
gurong_cmcc <at> outlook.com(gurong <at> chinamobile.com)

-----邮件原件-----
发件人: bmwg [mailto:bmwg-bounces <at> ietf.org] 代表 Secher, Neal J
发送时间: 201536 22:55
收件人: bmwg <at> ietf.org
主题: Re: [bmwg] WG ADOPTION: dcbench-def and dcbench-methodology

I would also like to add support as these documents are both useful and
necessary to help practitioners evaluate DC products.   

Neal Secher
Office   212-635-1317
Mobile 917-548-7903
neal.secher <at> bnymellon.com

-----Original Message-----
From: bmwg [mailto:bmwg-bounces <at> ietf.org] On Behalf Of Bhavani Parise
Sent: Thursday, March 05, 2015 1:57 PM
To: bmwg <at> ietf.org
Subject: Re: [bmwg] WG ADOPTION: dcbench-def and dcbench-methodology


+1 support the documents

regards,
Bhavani

On 3/4/15 4:36 AM, Fernando Calabria (fcalabri) wrote:

I support both documents.

 

Kind Regards

 

Fernando

 

 

 

 

On 3/3/15, 3:23 PM, "MORTON, ALFRED C (AL)" <acmorton <at> att.com> wrote:

 

BMWG,

 

We've been discussing a draft for Data Center Benchmarking for some

time.

 

Our new charter includes Data Center Benchmarking, so we ask everyone

to take a look (by March 18th) and express comments/support.

 

The latest drafts are here:

 

 

http://www.ietf.org/internet-drafts/draft-dcbench-def-02.txt

 

http://www.ietf.org/internet-drafts/draft-bmwg-dcbench-methodology-03

.txt

 

regards,

Al

bmwg co-chair

 

 

 

_______________________________________________

bmwg mailing list

bmwg <at> ietf.org

https://www.ietf.org/mailman/listinfo/bmwg

_______________________________________________

bmwg mailing list

bmwg <at> ietf.org

https://www.ietf.org/mailman/listinfo/bmwg

 


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

The information contained in this e-mail, and any attachment, is
confidential and is intended solely for the use of the intended recipient.
Access, copying or re-use of the e-mail or any attachment, or any
information contained therein, by any other person is not authorized. If you
are not the intended recipient please return the e-mail to the sender and
delete it from your computer. Although we attempt to sweep e-mail and
attachments for viruses, we do not guarantee that either are virus-free and
accept no liability for any damage sustained as a result of viruses.

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain
disclosures relating to European legal entities.

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



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

_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/bmwg
Marius Georgescu | 6 Mar 03:32 2015
Picon

draft update

Dear BMWG Members,

I have updated the draft about IPv6 transition technologies benchmarking I presented in IETF91. Thank you very much for your comments and for the warm welcome. The new draft can be found here:


The overview of the changes according to the received feedback is:

# Following Kaname Nishizuka's comment about stateful vs stateless:
 
- the following text was added to Section 1.1:

Another important aspect by which the IPv6 transition technologies 
can be categorized is their use of stateful or stateless mapping algorithms. 
The technologies that use stateful mapping algorithms (e.g. Stateful NAT64 [RFC6146]) 
create dynamic correlations between IP addreesses or 
{IP address,transport protocol, transport port number} tuples, which are stored in 
a state table. The efficiency with which the state table is managed can be an 
important performance indicator. Hence, for the IPv6 transition technologies which 
are employing stateful mapping algorithms, additional benchmarking tests 
are RECOMMENDED.     

- added the following text in Section 4.2:

Considering that the stateful transition technologies need to manage the state 
table for each connection, a connection-oriented transport layer protocol 
needs to be used with the test traffic. Consequently, TCP traffic SHOULD 
be employed for the tests described in Section 7 of this document.

- added Section 7. Additional Benchmarking Tests for Stateful IPv6 Transition Technologies

# Following Scott Bradner's comment related to the 6 -> 4 vs 4 -> 6 translation 
performance of translation based transition technologies:

- the following text was added to Section 1.1:  

In the case of translation based transition technology, the DUT CE and DUT PE 
machines MAY be tested separately as well. These tests can represent a fine grain
 performance analysis of the IPvX to IPvY translation direction versus the 
IPvY to IPvX translation direction. The tests SHOULD follow the test setup 
presented in Figure 1.

# Following Andrew McGregor's comment about the need to test CE devices 
with more than one network flow:

- the following text was added to Section 8.1: 

This test setup can help to quantify the scalability of the PE device. 
However, for testing the scalability of the DUT CEs additional setups 
are needed. For encapsulation based transition technologies a m:n setup can be 
created, where m is the number of flows applied to the same CE device and n 
the number of CE devices connected to the same PE device.
For the translation based transition technologies the CE devices can be separately 
tested with n network flows using the test setup presented in Figure 3.

# Following comments from Al Morton, Scott Brandner and Andrew McGreogor about 
UDP vs TCP measurements:

- the following text was added to Section 4.3: 

Because of the simplicity of UDP, UDP measurements offer a more reliable basis 
for comparison than other transport layer protocols. Consequently, for the 
benchmarking tests described in Section 6 of this document UDP traffic 
SHOULD be employed. 
 

# the comment from Nalini Elkins about DNS lookup based measurements was noted. 
However I don't have a clear solution for now. Suggestions are welcome.

# Following Bhuvan Vengainathan's comment about MTU settings for the interfaces:

- the following text was added to Section 4.1:

In the context of frame size overhead MTU recommendations are needed in order 
to avoid frame loss due to MTU mismatch between the virtual 
encapsulation/translation interfaces and the physical network 
interface controllers (NICs). To avoid this situation, the larger MTU 
between the physical NICs and virtual encapsulation/translation interfaces 
SHOULD be set for all interfaces of the DUT and tester.

# Following Bhuvan Vengainathan's comment about handling the Multicast traffic

- the following text was added to Section 4:

Multicast IP traffic is outside of the scope of this document.

# Following Bhuvan Vengainathan's comment about the routing mode: 

- the following text was added to Section 3:

For the simple test setups described in the next two subsections, static 
routing MAY be employed.  However, for more complex test setups 
(e.g. scalability testing setup) dynamic routing is a more reasonable choice. 
However, the presence of routing and management frames can represent unwanted
 background data that can affect the benchmarking result. To that end, 
the procedures defined in [RFC2544] (Sections 11.2 and 11.3) related to 
routing and management frames SHOULD be used here as well.

# I am still considering a solution for the comments received from Bhuvan Vengainathan and  Al Morton about 
jitter.


# Editorial changes suggested by the RFC Editor Team 

Best regards,
Marius
_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/bmwg
stephane.litkowski | 5 Mar 18:00 2015

draft-litkowski-idr-bgp-timestamp-01.txt

Hi BMWG Folks,

I'm currently try to work on a solution to monitor propagation time within a BGP controlplane.
You will find below a draft reference.

I'm looking for your feedback on the proposed solution especially on it's accuracy.

Thanks in advance,

Stephane

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Thursday, March 05, 2015 17:58
To: Jeffrey Haas; LITKOWSKI Stephane SCE/IBNF; Keyur Patel; Keyur Patel; Jeff Haas; LITKOWSKI Stephane SCE/IBNF
Subject: New Version Notification for draft-litkowski-idr-bgp-timestamp-01.txt

A new version of I-D, draft-litkowski-idr-bgp-timestamp-01.txt
has been successfully submitted by Stephane Litkowski and posted to the IETF repository.

Name:		draft-litkowski-idr-bgp-timestamp
Revision:	01
Title:		Timestamp support for BGP paths
Document date:	2015-03-05
Group:		Individual Submission
Pages:		26
URL:            http://www.ietf.org/internet-drafts/draft-litkowski-idr-bgp-timestamp-01.txt
Status:         https://datatracker.ietf.org/doc/draft-litkowski-idr-bgp-timestamp/
Htmlized:       http://tools.ietf.org/html/draft-litkowski-idr-bgp-timestamp-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-litkowski-idr-bgp-timestamp-01

Abstract:
   BGP is more and more used to transport routing information for
   critical services.  Some BGP updates may be critical to be received
   as fast as possible : for example, in a layer 3 VPN scenario where a
   dual-attached site is loosing primary connection, the BGP withdraw
   message should be propagated as fast as possible to restore the
   service.  The same criticity exists for other address-families like
   multicast VPNs where "join" messages should also be propagated very
   fast.

   Experience of service providers shows that BGP path propagation time
   may vary depending on network conditions (especially load of BGP
   speaker on the path) and too long propagation time are affecting
   customer service.

   It is important for service providers to keep track of BGP updates
   propagation time to monitor quality of service for the customers.  It
   is also important to be able to identify BGP Speakers that are
   slowing down the propagation.

   This document presents a solution to transport timestamps of a BGP
   path.  The solution is targeted to be used using special identified
   beacon prefixes that are single-homed.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at tools.ietf.org.

The IETF Secretariat

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne
doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur,
veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant
susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be
protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Gmane