Re: [bmwg] RFC 8239 buffering testing results

"MORTON, ALFRED C (AL)" <acm@research.att.com> Tue, 17 July 2018 18:12 UTC

Return-Path: <acm@research.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 257F8130EF4 for <bmwg@ietfa.amsl.com>; Tue, 17 Jul 2018 11:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 fvucgt5fZbyi for <bmwg@ietfa.amsl.com>; Tue, 17 Jul 2018 11:12:26 -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 118A7130E47 for <bmwg@ietf.org>; Tue, 17 Jul 2018 11:12:26 -0700 (PDT)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w6HHGBrc024931; Tue, 17 Jul 2018 13:19:54 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049287.ppops.net-00191d01. with ESMTP id 2k9m5t9e00-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jul 2018 13:19:54 -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 w6HHJr3a052525; Tue, 17 Jul 2018 12:19:53 -0500
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w6HHJjtJ052379; Tue, 17 Jul 2018 12:19:45 -0500
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id 231A840002AE; Tue, 17 Jul 2018 17:19:45 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30496.vci.att.com (Service) with ESMTP id F0B4940002AC; Tue, 17 Jul 2018 17:19:44 +0000 (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 w6HHJhVL018242; Tue, 17 Jul 2018 12:19:44 -0500
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id w6HHJbMx017956; Tue, 17 Jul 2018 12:19:37 -0500
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id 47EC4E2520; Tue, 17 Jul 2018 13:17:50 -0400 (EDT)
Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0399.000; Tue, 17 Jul 2018 13:19:16 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Jacob Rapp <jrapp@vmware.com>, Yoshiaki Itou <itou@toyo.co.jp>, "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: [bmwg] RFC 8239 buffering testing results
Thread-Index: AdQSk3wi6Fwy2EbaTkCf8NykKEWJqALM7rsAAAqkBwA=
Date: Tue, 17 Jul 2018 17:19:35 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF4A93A014@njmtexg4.research.att.com>
References: <OSBPR01MB1701B890AEC4E4AC02FD011DE6420@OSBPR01MB1701.jpnprd01.prod.outlook.com> <8AB0F2CF-FCC3-4644-937E-30DF1A46D2EB@vmware.com>
In-Reply-To: <8AB0F2CF-FCC3-4644-937E-30DF1A46D2EB@vmware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.147.119]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF4A93A014njmtexg4researc_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-17_04:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807170180
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/4tX0jUhsjM-xFiNQvldHjaCgE8E>
Subject: Re: [bmwg] RFC 8239 buffering testing results
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 18:12:29 -0000

Thanks for replying on this thread Jacob.

Incidentally, I added the Section 3 Scope paragraph
delineating the RFC 8239 methods out-of-scope
*after* Yoshiaki and I exchanged several messages.

Al

From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Jacob Rapp
Sent: Tuesday, July 17, 2018 12:11 PM
To: Yoshiaki Itou <itou@toyo.co.jp>; bmwg@ietf.org
Subject: Re: [bmwg] RFC 8239 buffering testing results

Thanks for reaching out.
Over the years of using these tests myself, I find many different switch architectures may measure differently, but this is expected. The tests themselves were designed to test the actual buffer available for use under various combination of oversubscribing ports, which your test results are reporting. For example, some switches have dedicated buffer for every 4 ports, so if you are testing across the boundaries of these various buffer chips, you may see some “interesting results”. Another example would be when a switch goes from cut-through to store-and-forward operation after a given frame size (we cover this in a different section). Another example would be a switch architecture that uses ingress buffering vs. egress buffering. “Interesting results” are also valid results and the goal of these tests were to flush out the “interesting results” so when evaluating different DUTs you have the complete story vs. what a data sheet will claim on buffer size.

As for the draft-morton-bmwg-b2b-frame-02, it has a different goal and specifically calls out : “Section 3 of [RFC8239] describes buffer size testing for physical
   networking devices in a Data Center.  The [RFC8239] methods measure
   buffer latency directly with traffic on multiple ingress ports that
   overload an egress port on the Device Under Test (DUT), and are not
   subject to the revised calculations presented in this memo.”

Thanks,

--
Jacob

From: bmwg <bmwg-bounces@ietf.org<mailto:bmwg-bounces@ietf.org>> on behalf of Yoshiaki Itou <itou@toyo.co.jp<mailto:itou@toyo.co.jp>>
Date: Tuesday, July 3, 2018 at 2:06 AM
To: "bmwg@ietf.org<mailto:bmwg@ietf.org>" <bmwg@ietf.org<mailto:bmwg@ietf.org>>
Subject: [bmwg] RFC 8239 buffering testing results

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation