Re: [bmwg] Comments on SDN Benchmarking Drafts

bhuvaneswaran.vengainathan@veryxtech.com Tue, 22 August 2017 16:34 UTC

Return-Path: <bhuvaneswaran.vengainathan@veryxtech.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 8916313235A for <bmwg@ietfa.amsl.com>; Tue, 22 Aug 2017 09:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rOAx3retiY1V for <bmwg@ietfa.amsl.com>; Tue, 22 Aug 2017 09:34:21 -0700 (PDT)
Received: from smtpout4.netcore.co.in (nm237108.nsmailserv.com [202.162.237.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2883A1326E8 for <bmwg@ietf.org>; Tue, 22 Aug 2017 09:34:16 -0700 (PDT)
Received: from smtpin5.netcore.co.in (unknown [192.168.2.96]) by cf3.netcore.co.in (Postfix) with ESMTP id 25F0B120048; Tue, 22 Aug 2017 22:04:05 +0530 (IST)
Received: from cloudmail14.netcore.co.in (cloudmail12.netcore.co.in [202.162.231.3]) by smtpin5.netcore.co.in (Postfix) with ESMTP id 03C464A544; Tue, 22 Aug 2017 22:04:08 +0530 (IST)
Mime-Version: 1.0
Date: Tue, 22 Aug 2017 16:34:08 +0000
Content-Type: multipart/alternative; boundary="----=_Part_270_100360405.1503419648"
Message-ID: <1b32258ddde9b548fadf203e5e00664a@cloudmail14.netcore.co.in>
X-Mailer: AfterLogic webmail client
From: bhuvaneswaran.vengainathan@veryxtech.com
To: "MORTON, ALFRED C (AL)" <acmorton@att.com>
Cc: "bmwg@ietf.org" <bmwg@ietf.org>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF46C07A0F@njmtexg4.research.att.com>
References: <4D7F4AD313D3FC43A053B309F97543CF46C07A0F@njmtexg4.research.att.com>
X-Priority: 3 (Normal)
X-SMTP30-MailScanner-Information: Please contact the ISP for more information
X-MailScanner-ID: 03C464A544.A7539
X-SMTP30-MailScanner: Found to be clean
X-MailScanner-From: bhuvaneswaran.vengainathan@veryxtech.com
X-Cloudmilter-Processed: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/SzUL-1GGnMFVDBTRymZaZDPNdbE>
Subject: Re: [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: Tue, 22 Aug 2017 16:34:25 -0000

Hi Al,
Thank you for sharing your comments on the terminology and methodology draft.
All your comments are valid and we will revise the draft based on your feedback.
Best Regards,
Bhuvan
On Mon, Aug 21, 2017 at 01:55 AM, "MORTON, ALFRED C (AL)"  wrote:
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 (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 mailing list
bmwg@ietf.org (mailto:bmwg@ietf.org)
https://www.ietf.org/mailman/listinfo/bmwg (https://www.ietf.org/mailman/listinfo/bmwg)

DISCLAIMER: Privileged and/or Confidential information may be
contained in this message. If you are not the addressee of this message,
you may not copy, use or deliver this message to anyone. In such
event,you should destroy the message and kindly notify the sender by
reply e-mail.
It is understood that opinions or conclusions that do not relate to the
official business of the company are neither given nor endorsed by the
company.