[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.