[bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance
"Tassinari, Mark A" <mark.tassinari@hp.com> Fri, 25 April 2014 23:11 UTC
Return-Path: <mark.tassinari@hp.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5C81A0415 for <bmwg@ietfa.amsl.com>; Fri, 25 Apr 2014 16:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.572
X-Spam-Level:
X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdSMDX5GqQtg for <bmwg@ietfa.amsl.com>; Fri, 25 Apr 2014 16:11:02 -0700 (PDT)
Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com [15.201.208.53]) by ietfa.amsl.com (Postfix) with ESMTP id AD2121A0673 for <bmwg@ietf.org>; Fri, 25 Apr 2014 16:11:02 -0700 (PDT)
Received: from G4W6310.americas.hpqcorp.net (g4w6310.houston.hp.com [16.210.26.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3425.houston.hp.com (Postfix) with ESMTPS id BB6DA139 for <bmwg@ietf.org>; Fri, 25 Apr 2014 23:10:55 +0000 (UTC)
Received: from G9W3617.americas.hpqcorp.net (16.216.186.52) by G4W6310.americas.hpqcorp.net (16.210.26.217) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 25 Apr 2014 23:08:45 +0000
Received: from G9W0735.americas.hpqcorp.net ([169.254.11.138]) by G9W3617.americas.hpqcorp.net ([16.216.186.52]) with mapi id 14.03.0169.001; Fri, 25 Apr 2014 23:08:45 +0000
From: "Tassinari, Mark A" <mark.tassinari@hp.com>
To: "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance
Thread-Index: Ac9ecGt5dB0hc1KSRza1QkEtI5opNw==
Date: Fri, 25 Apr 2014 23:08:44 +0000
Deferred-Delivery: Fri, 25 Apr 2014 23:08:05 +0000
Message-ID: <B5838747F54175449562AA808237BE1446D3ABC6@G9W0735.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [15.201.58.26]
Content-Type: multipart/alternative; boundary="_000_B5838747F54175449562AA808237BE1446D3ABC6G9W0735americas_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/U5MYtm_FDvv5dmq0OAbIxko9_UQ
X-Mailman-Approved-At: Sat, 26 Apr 2014 06:19:27 -0700
Subject: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2014 23:11:09 -0000
Hello Bhuvan, Standardizing on a set of controller performance tests is a great idea and the OpenFlow SDN Controller Performance draft is a good start. I'd like to submit some comments and questions. - The Test Setup section is unclear about where virtualization is permitted but this can have a dramatic effect on the results. I believe the benchmark test should require the controller and any virtual switches to be on separate servers. - I'm curious to know why the number of switches in the tests are not defined - not even to require more than one. There is way to know if the tests were executed the tests under the same conditions which makes comparison much less meaningful. - What is the numerator (OFRi) in the Flow setup rate formula defined in Section 6.1.1.1.4? Is it the sum of all packet_out and flow mod messages sent by the controller? - The test does not specify whether throughput results are verified to be lossless (every packet_in results in a packet_out). Since TCP is the specified connection it may not matter but I thought I'd toss it out for discussion. - The Reactive Mode Flow setup in section 6.1.1.2.2 is a little unclear. If the objective is to have the 10% of all "specified" switches that are connected send Packet_In messages I'd rephrase the second sentence to state "Load controller with Packet-In messages from all connected controllers for a specified interval." Regards, Mark
- [bmwg] Benchmarking Methodology for OpenFlow SDN … Bhuvan (Veryx Technologies)
- [bmwg] FW: Benchmarking Methodology for OpenFlow … Banks, Sarah
- [bmwg] FW: Benchmarking Methodology for OpenFlow … Bhuvan (Veryx Technologies)
- [bmwg] Benchmarking Methodology for OpenFlow SDN … Tassinari, Mark A
- Re: [bmwg] Benchmarking Methodology for OpenFlow … Bhuvan (Veryx Technologies)