[bmwg] Comments on SDN Benchmarking Drafts
"MORTON, ALFRED C (AL)" <acmorton@att.com> Sun, 20 August 2017 20:24 UTC
Return-Path: <acmorton@att.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1D9132193 for <bmwg@ietfa.amsl.com>; Sun, 20 Aug 2017 13:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zqhnkuELQSNz for <bmwg@ietfa.amsl.com>; Sun, 20 Aug 2017 13:24:53 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F050126CB6 for <bmwg@ietf.org>; Sun, 20 Aug 2017 13:24:53 -0700 (PDT)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7KKOWnl000853 for <bmwg@ietf.org>; Sun, 20 Aug 2017 16:24:52 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049287.ppops.net-00191d01. with ESMTP id 2cej6f7fng-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <bmwg@ietf.org>; Sun, 20 Aug 2017 16:24:51 -0400
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v7KKOooD085966 for <bmwg@ietf.org>; Sun, 20 Aug 2017 15:24:50 -0500
Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v7KKOkJ7085950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <bmwg@ietf.org>; Sun, 20 Aug 2017 15:24:47 -0500
Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint02.pst.cso.att.com (RSA Interceptor) for <bmwg@ietf.org>; Sun, 20 Aug 2017 20:24:38 GMT
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v7KKOc5v027924 for <bmwg@ietf.org>; Sun, 20 Aug 2017 15:24:38 -0500
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v7KKOUpP027611 for <bmwg@ietf.org>; Sun, 20 Aug 2017 15:24:34 -0500
Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id DFE00E018F for <bmwg@ietf.org>; Sun, 20 Aug 2017 16:24:29 -0400 (EDT)
Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Sun, 20 Aug 2017 16:24:29 -0400
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: Comments on SDN Benchmarking Drafts
Thread-Index: AdMZ8QBUeRNnNZyxTOyyOkQnmLTd2g==
Date: Sun, 20 Aug 2017 20:24:28 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF46C07A0F@njmtexg4.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [73.178.187.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-20_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708200335
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/wSPUcMkmi-EWTPypP6qT1Qp5s5Q>
Subject: [bmwg] Comments on SDN Benchmarking Drafts
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 20 Aug 2017 20:24:56 -0000
BMWG, First, a public thank you to Sarah for preparing and uploading our minutes from IETF-99, based on Marius' extensive and "cross-checked with the audio" meeting notes. If you missed the meeting or a trip to Prague, you can catch-up on our progress here: https://datatracker.ietf.org/meeting/99/materials/minutes-99-bmwg Thanks to you both! Now, as a participant, I'm responding to one of my Action Items by following-up with comments on the SDN Drafts. I have proposed text for the Terminology and Methodology drafts to cover one of my comments at the meeting, about more clearly including benchmarks for both: 1. Loss-free Asynchronous Message Processing Rate 2. Maximum Asynchronous Message Processing Rate I haven't suggested how the 3x3 matrix should be edited yet; these comments should be discussed first. The proposed text follows. thanks and regards, Al (participant) -=-=-=-=-=-=-=- Proposal Follows -=-=-=-=-=-=-=- Terminology: 2.3.1.3. Asynchronous Message Processing Rate OLD Definition: The maximum number of asynchronous messages (session aliveness check message, new flow arrival notification message etc.) that the controller(s) can process, defined as the iteration starting with sending asynchronous messages to the controller (s) at the maximum possible rate and ending with an iteration that the controller(s) processes the received asynchronous messages without dropping. NEW Definition: The number responses to asynchronous messages (such as new flow arrival notification message, etc.) for which the controller(s) performed processing and replied with a valid and productive (non-trivial) response message. OLD Discussion: As SDN assures flexible network and agile provisioning, it is important to measure how many network events that the controller can handle at a time. This benchmark is obtained by sending asynchronous messages from every connected Network Devices at the rate that the controller processes without dropping. This test assumes that the controller will respond to all the received asynchronous messages. NEW Discussion: As SDN assures flexible network and agile provisioning, it is important to measure how many network events that the controller can handle at a time. This benchmark is obtained by sending asynchronous messages from every connected Network Devices at the rate that the controller processes without dropping. This test assumes that the controller is respond to all the received asynchronous messages (and the messages can be designed to elicit individual responses). When sending asynchronous messages to the controller(s) at high rates, some messages or responses may be discarded or corrupted and require retransmission to to controller(s). Therefore, a useful qualification on Asynchronous Message Processing Rate is whether the in-coming message count equals the response count in each trial. This is called the Loss-free Asynchronous Message Processing Rate. Note that several of the early controller benchmarking tools did not consider lost messages, and instead report the maximum response rate. This is called the Maximum Asynchronous Message Processing Rate. To characterize both the Loss-free and Maximum Rates, a test could begin the first trial by sending asynchronous messages to the controller (s) at the maximum possible rate and record the message reply rate and the message loss rate. The message sending rate is then decreased by the step-size and and the message reply rate and the message loss rate are recorded. The test ends with a trial where the controller(s) processes the all asynchronous messages sent without loss. This is the Loss-free Asynchronous Message Processing Rate. The (intermediate) trial where the controller(s) produced the maximum response rate is the Maximum Asynchronous Message Processing Rate. Of course, the first trial could begin at a low sending rate with zero lost responses, and increase until the Loss-free and Maximum Rates are discovered. Measurement Units: Messages processed per second. See Also: None -=-=-=-=-=-=-=-=- Methodology (more substantial changes here, so OLD/NEW are not used) 5.1.3. Asynchronous Message Processing Rate Objective: This test will measure two benchmarks on Asynchronous Message Processing Rate using a single procedure. The two benchmarks are (see section 2.3.1.3 of [ref to Terminology]): 1. Loss-free Asynchronous Message Processing Rate 2. Maximum Asynchronous Message Processing Rate There two benchmarks are determined through a series of trials where the a number of messages are sent to the controller(s), and the responses from the controller(s) are counted over the trial duration. The message response rate and the message loss ratio are calculated for each trial. Reference Test Setup: The test SHOULD use one of the test setups described in section 3.1 or section 3.2 of this document in combination with Appendix A. Prerequisite: 1. The controller(s) MUST have successfully completed the network topology discovery for the connected Network Devices. 2. Choose and record the Trial Duration (Td), the sending rate step-size (STEP), the tolerance on equality for two consecutive trials (P%), and the maximum possible message sending rate (Ntx1/Td). Procedure: 1. Generate asynchronous messages continuously at the maximum possible rate on the established connections from all the emulated/simulated Network Devices for the given Trial Duration (Td). 2. Record the total number of responses received from the controller (Nrx1) as well as the number of messages sent (Ntx1) to the controller(s) within the trial duration(Td). 3. Calculate the Asynchronous Message Processing Rate (Tr1) and the Message Loss Ratio (Lr1). Ensure that the controller(s) have returned to normal operation. 4. Repeat the trial by reducing the asynchronous message sending rate used in last trial by the STEP size. 5. Continue repeating the trials and reducing the sending rate until both the maximum value of Nrxn and the Nrxn corresponding to zero loss ratio have been found. 4. The trials corresponding to the benchmark levels the MUST be repeated using the same asynchronous message rates until the responses received from the controller are equal (+/-P%) for two consecutive trials. 5. Record the number of responses received from the controller (Nrxn) as well as the number of messages sent(Ntxn) to the controller in the last trial. Calculations: Nrxn Asynchronous Message Processing Rate Trn = ----- Td Maximum Asynchronous Message Processing Rate = MAX(Trn) for all n Nrxn Asynchronous Message Loss Ratio Lrn = 1 - ----- Ntxn Loss-free Asynchronous Message Processing Rate = MAX(Trn) given Lrn=0 Reporting Format: The Asynchronous Message Processing Rate results MUST be reported in the format of a table with a row for each trial. The table should report the following information in addition to the configuration parameters captured in section 5, with columns: - Offered rate (Ntxn/Td) - Asynchronous Message Processing Rate (Trn) - Loss Ratio (Lr) - Benchmark at this iteration (blank for none, Maximum, Loss-Free) The results MAY be presented in the form of a graph. The X axis SHOULD be the Offered rate, and dual Y axes would represent Asynchronous Message Processing Rate and Loss Ratio, respectively. If this test is repeated with varying number of nodes over same topology, the results SHOULD be reported in the form of a graph. The X axis SHOULD be the Number of nodes (N), the Y axis SHOULD be the Asynchronous Message Processing Rate. Both the Maximum and the Loss-Free Rates should be plotted for each N. If this test is repeated with same number of nodes over different topologies, the results SHOULD be reported in the form of a graph. The X axis SHOULD be the Topology Type, the Y axis SHOULD be the Asynchronous Message Processing Rate. Both the Maximum and the Loss-Free Rates should be plotted for each topology. @@@@ Comment: I think we may not need: Tr1 + Tr2 + Tr3..Trn Average Asynchronous Message Processing Rate= -------------------- Total Test Iterations The last row of the table indicates the average Asynchronous Message Processing Rate.
- [bmwg] Comments on SDN Benchmarking Drafts MORTON, ALFRED C (AL)
- Re: [bmwg] Comments on SDN Benchmarking Drafts bhuvaneswaran.vengainathan