Re: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame
Yoshiaki Itou <itou@toyo.co.jp> Sat, 16 February 2019 05:38 UTC
Return-Path: <itou@toyo.co.jp>
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 215E4129A85 for <bmwg@ietfa.amsl.com>; Fri, 15 Feb 2019 21:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level:
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=toyo.onmicrosoft.com
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 hbaYxp9vG-Cq for <bmwg@ietfa.amsl.com>; Fri, 15 Feb 2019 21:38:09 -0800 (PST)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410043.outbound.protection.outlook.com [40.107.141.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2A71295D8 for <bmwg@ietf.org>; Fri, 15 Feb 2019 21:38:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toyo.onmicrosoft.com; s=selector1-toyo-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HXPT0Fex0Zy9Ko8M6y/cwveU6RNAd+OXtjvRJoopTrQ=; b=SUP5bdUzjC02hCm/K8pOGzFmwjRMQSNqPXg5RqhrakveCwx1JecW3WMz4oRKSUgQYOQ1zHiPoTIH66HEFA0x6bpDYG8mnVlu115lLUPHpusfCLBeO491p8QRAyvTzfiY2r1fPWmccgXi7V4dOuuginVoPj9tgBatVKMmvuiJFEE=
Received: from OSBPR01MB1701.jpnprd01.prod.outlook.com (52.134.227.14) by OSBPR01MB3302.jpnprd01.prod.outlook.com (20.178.96.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.19; Sat, 16 Feb 2019 05:38:03 +0000
Received: from OSBPR01MB1701.jpnprd01.prod.outlook.com ([fe80::2d83:a4e2:aeeb:7689]) by OSBPR01MB1701.jpnprd01.prod.outlook.com ([fe80::2d83:a4e2:aeeb:7689%6]) with mapi id 15.20.1622.018; Sat, 16 Feb 2019 05:38:03 +0000
From: Yoshiaki Itou <itou@toyo.co.jp>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>, Sarah B <sbanks@encrypted.net>, "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame
Thread-Index: AQHUjlZIXoGYVU1/Y0qtvVdWXzRGNaV9yAsQgAPnLYCAArgjIIAAXJgAgFmxToCAA+EdwA==
Date: Sat, 16 Feb 2019 05:38:02 +0000
Message-ID: <OSBPR01MB17016B1200927473EEA715C1E6610@OSBPR01MB1701.jpnprd01.prod.outlook.com>
References: <115C238D-07B4-49FB-A4C3-A2809795EF3F@encrypted.net> <TY2SPR01MB00100F0440A38AB4D523CEAAE6A10@TY2SPR01MB0010.jpnprd01.prod.outlook.com> <4D7F4AD313D3FC43A053B309F97543CF55803C90@njmtexg5.research.att.com> <TY2SPR01MB00104D8F5CD8B16B8D635311E6BD0@TY2SPR01MB0010.jpnprd01.prod.outlook.com> <4D7F4AD313D3FC43A053B309F97543CF558056FE@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF6BFD77E1@njmtexg5.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF6BFD77E1@njmtexg5.research.att.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=itou@toyo.co.jp;
x-originating-ip: [2400:4150:3de0:6700:bd39:46f7:7a5e:c68f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5df77c9c-72b2-44bd-d2ee-08d693d0eb65
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605103)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB3302;
x-ms-traffictypediagnostic: OSBPR01MB3302:
x-ms-exchange-purlcount: 8
x-microsoft-exchange-diagnostics: 1; OSBPR01MB3302; 23:WnuzMkkNj/3/ufLcqP0pIzoNFCjpRzLeimYnddAlbWj6qR5gqvwlrrNWoiBVEIXfdKqdF+ovFky3xlrTHjCDWoYb7ieQ7Gt7JqWfiQ3gOeTE1zAtaCbtXGuCbPE0ew6w4q4QHafXlgRVS6RdqBKkXuq3olDJHoup1nWJ4TmSEy73x04kcYRlC2anYeHCfDLF8HF80QQlHTU39ArN0gHjL4CUY6CW3v++ZSFelsVkKPBRN2MAMdzfkAUNj5Iusu7R/GEIOlnQsb9qIgQ4LnpU9S5nd+mKY87eT1BhuLFQSn6q1OexJfq6x7pRfy+3XAKmkHOMqryany5qPepF3r+Ksn5XzSAJup1AB5j65mJ1KfOL1Y9hH3390l0HkS0Z4RNmd+DMNzC3RWXi1kr+P380J5rgnQaMZChGBVoN0IUT58HzfPLgOa6l+3hTT0NMdtt8jd0XqIyewnm7OdaVEjR5eT+Qa6QeLbqbfbM9vPqlmPYUAHRn1NPgdg3dgCW43SrFY3cyzJsxevVRIHCvBrljAK6/omvvj9Et4IPzFMZrEorBO2PeDVCJTpO4NDjEo6k93BqlIX7ucklFEZVQ8Q16Js7TY2zMkb9lUv1vUSHHzIud7elZ85g8q50IcvLKFyMvCFSlbsq/U5K84TGI5oXlha8yiUZf++kasC+R85SptA1lp9bVVVg76mqrISLNAXwm8Xdw4WEplNLe1fw9Xhoxd8n3JKu92hmmZJAgfTxHNPOYLsAdXGBucRut2JH450RBwzTJNP24dPFQFDpcq/ScxZMtYh2uBzlQuAvreCchC52CX7hji48mGjYJ8zW9I+ZEIzBEBBQOT0AjpP06Y+47n2Lp9keQJeu9K7u+IQyM/AGKt0XEF1LPjTZjFl6vjcMSIJmiWoFhppP4T5p8uQux7ur4jiI2C9Ix2Wh4ubn1STli61/+Qb6SC4DgpmxsWn+tSTCJnK2NAqgaS06/NfLPWZZCqJ1lnroMIV7tGDIikZ+4XVxDLpL4JdIRMkb/w3FQqYkD7ljaFVxRhpZqpagSuHXCksCHX79aetaETsm0eiW7R1pe4TyECmWwtCrTQVOdlT+WkmFoE5g7dCcGMlQOFqtYgcb2iRB+DXxirU9p1aRagNUZPcJnhv2gEz28HQf7cCLHrTjo9iTRcPqBpkt4Ra6Oeg+XzLE43IymXca4kE8pR05s3AwPJDvvwFa+HkWbsZaRWaYHG1aZ4Hx1LExwrhbcb5CeK+3pFOcV5bhU5r5n2F+Z0EFBisIqJ1B93kJYDcY/TTs6Hq5Q6KZCNiS3g8cCGmBHNEzP1VuZR3vAvUqF+IAd19OaQbg4GrOKYWpQHXP6m3g/DjZA9UTy4NzoVt/5DOPNIeDJPwtzLIWmUWg=
x-microsoft-antispam-prvs: <OSBPR01MB3302F8CA63BCFE95AFB16A17E6610@OSBPR01MB3302.jpnprd01.prod.outlook.com>
x-forefront-prvs: 0950706AC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39850400004)(396003)(136003)(366004)(199004)(189003)(54896002)(6246003)(6306002)(68736007)(55016002)(9686003)(105586002)(2501003)(186003)(7736002)(6436002)(106356001)(229853002)(81156014)(8676002)(25786009)(81166006)(76176011)(7696005)(99286004)(8936002)(74482002)(53946003)(236005)(53936002)(102836004)(33656002)(97736004)(53546011)(6506007)(2906002)(66574012)(476003)(71190400001)(6116002)(446003)(11346002)(486006)(86362001)(93886005)(316002)(14454004)(5660300002)(21615005)(110136005)(74316002)(478600001)(966005)(14444005)(256004)(5024004)(46003)(606006)(71200400001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:OSBPR01MB3302; H:OSBPR01MB1701.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: toyo.co.jp does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Dl4HCPnHvgf+rQaO+RA175aZmx+P7UmkBpx7AgZoFi0pCHT0JaJ2IwPeh8tpkzagRFks+QCvGDiHWBvBpnx/V7u9OuXZ9rlUzXrsNwDQxVo55MGfYcngcesOvRE5DTegVUkQDTlYnoohckdwtS9jzrJw0vxXJjt+x4YqJ2JLGPRjJQXVapJ9wBgLJLAsYK8RkWaYXnpbS7lFHFW+0THIV8Pz1sv/uACuUerI2MK0/h1egX1zj/x3ByELvv1z8gFH3Gae1LFHCG5apQOzWU+d5MZbRuKxMxKWZMD3PRTskiM1cojw1Eqgpjtg6cSlTQCgcphW7JBNzXMEu8HItrj5d9xpMWHS8KJExVoWWSdB/PgO5g5zeVBoWLT7zJpUBnfB3argWWtQCdZHtwAHRwPcpTSEDe4sd2B94sXbnvO04e8=
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB17016B1200927473EEA715C1E6610OSBPR01MB1701jpnp_"
MIME-Version: 1.0
X-OriginatorOrg: toyo.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 5df77c9c-72b2-44bd-d2ee-08d693d0eb65
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2019 05:38:02.8881 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 40c50b8d-0fe2-4bba-8e02-5e19289bd70d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB3302
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/2Iihdqj7JR1jnlNMosaRKE5FbdE>
X-Mailman-Approved-At: Sat, 16 Feb 2019 05:10:31 -0800
Subject: Re: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 16 Feb 2019 05:38:14 -0000
Hello Morton-san, Thank you for your update. You already explained the model. Moreover, it is easy to understand if you add the following figure. Model: single ingress port and sinle egress port |------------ DUT --------| Generator -> Ingress -> Buffer -> HeaderProc -> Egress -> Receiver Best Regards, Yoshiaki Itou From: MORTON, ALFRED C (AL) <acm@research.att.com> Sent: Thursday, February 14, 2019 3:22 AM To: Yoshiaki Itou <itou@toyo.co.jp>; Sarah B <sbanks@encrypted.net>; bmwg@ietf.org Subject: RE: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame Hi Yoshiaki-san and BMWG, I have revised the draft (04) to include the points we agreed, below (at the end of section 5): https://datatracker.ietf.org/doc/draft-morton-bmwg-b2b-frame/ If there are other clarifications needed, we can discuss further. thanks and regards, Al (as a participant) From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL) Sent: Tuesday, December 18, 2018 11:40 AM To: Yoshiaki Itou <itou@toyo.co.jp<mailto:itou@toyo.co.jp>>; Sarah B <sbanks@encrypted.net<mailto:sbanks@encrypted.net>>; bmwg@ietf.org<mailto:bmwg@ietf.org> Subject: Re: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Hi Yoshiaki-san, Thank you again for your support, and for illustrating your understanding of the calculations in the b2b-frame draft. I think you have uncovered two details that I didn't describe in the Corrected DUT Buffer Time Calculation, which are: 1. The "Measured Throughput" is the RFC2544 Throughput Benchmark for the frame size tested, and MUST be expressed in Frames per second in this equation. 1. The "Max Theoretical Frame Rate" is a calculated value for the interface speed and link layer technology used, and MUST be expressed in Frames per second in this equation. These details would change the right-side of the slide you shared with us on bmwg-list. For example, the RFC 2544 Throughput Benchmark is based on the offered load on Ingress over a limited trial duration. The frame rate is not measured on egress, the receiver only evaluates if all frames sent to the ingress were received (no loss), after allowing the internal buffers to empty. Also, my simplified model of the DUT includes a packet header processing function with limited rate of operation (not shown in your slide): |------------ DUT --------| Generator -> Ingress -> Buffer -> HeaderProc -> Egress -> Receiver So, in the back2back frame testing, 1. the Ingress burst arrives at Max Theoretical Frame Rate, and initially the frames are buffered 1. a packet header processing function operates at approximately the "Measured Throughput", removing frames from the buffer. 1. Frames that have been processed are clearly not in the buffer, so the Corrected DUT buffer time equation estimates and removes the frames that the DUT forwarded on Egress during the busrt. There are some example calculations here: https://wiki.opnfv.org/display/vsperf/Traffic+Generator+Testing#TrafficGeneratorTesting-AppendixB:Back2BackTestingTimeSeries(fromCI)<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.opnfv.org_display_vsperf_Traffic-2BGenerator-2BTesting-23TrafficGeneratorTesting-2DAppendixB-3ABack2BackTestingTimeSeries-28fromCI-29&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=0OU4C4AqvLg_D7DELrCSk_F5msO3yBHvQJ_sXHbiArw&s=DAkdeAhmHqU_aSUZQvXoF3iKwtSZd0pjMkkXpobvhcc&e=> I propose to add the listed points to the explanation in the draft, as shown below: Implied DUT Buffer Time = Average num of Back-to-back Frames / Max Theoretical Frame Rate The formula above is simply expressing the Burst of Frames in units of time. Corrected DUT Buffer Time = Measured Throughput = Implied DUT Buffer Time * -------------------------- Max Theoretical Frame Rate | where: 1. The "Measured Throughput" is the RFC2544 Throughput Benchmark for the frame size tested, and MUST be expressed in Frames per second in this equation. 1. The "Max Theoretical Frame Rate" is a calculated value for the interface speed and link layer technology used, and MUST be expressed in Frames per second in this equation. | The term on the far right in the formula for Corrected DUT Buffer Time accounts for all the frames in the Burst that were transmitted by the DUT *while the Burst of frames were sent in*.. (I'll add some other clarifications, too) regards, Al From: Yoshiaki Itou [mailto:itou@toyo.co.jp] Sent: Tuesday, December 18, 2018 6:13 AM To: MORTON, ALFRED C (AL) <acm@research.att.com<mailto:acm@research.att.com>>; Sarah B <sbanks@encrypted.net<mailto:sbanks@encrypted.net>>; bmwg@ietf.org<mailto:bmwg@ietf.org> Subject: RE: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame Hello Morton-san, Thank you for your detailed explanation. I support your draft in the pre-requisites of the draft. May I understand "Corrected DUT Buffer Time" as attached ppt. Best Regards, Yoshiaki Itou From: MORTON, ALFRED C (AL) <acm@research.att.com<mailto:acm@research.att.com>> Sent: Monday, December 17, 2018 2:37 AM To: Yoshiaki Itou <itou@toyo.co.jp<mailto:itou@toyo.co.jp>>; Sarah B <sbanks@encrypted.net<mailto:sbanks@encrypted.net>>; bmwg@ietf.org<mailto:bmwg@ietf.org> Subject: RE: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame Hi Yoshiaki Itoh, Thank you for your past reviews and most recent comments. The main innovations of this draft: https://datatracker.ietf.org/doc/draft-morton-bmwg-b2b-frame/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmorton-2Dbmwg-2Db2b-2Dframe_&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=HS7Ed6lrlBb60NZsCWT7WGKCJJIeGwqkssw7Jo0fsCk&s=Oqg5iKz3YLnA2seSHeJEgwf-Ga7nAK8GargCnf52jKM&e=> (which is currently considered for WG adoption in BWMG, and comments on this call are appreciated) involve the pre-requisite testing for RFC 2544 Throughput that results in: 1. development of a correction factor for the calculation to remove the frames that were forwarded from the frames that were buffered, and give an accurate estimate of buffer size for the single port-pair case. 1. reduction of the back-to-back frame tests needed, where only packet rates that induce buffering would be tested. I shared test results that illustrate the value of these two innovations: https://wiki.opnfv.org/display/vsperf/Traffic+Generator+Testing#TrafficGeneratorTesting-AppendixB:Back2BackTestingTimeSeries(fromCI)<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.opnfv.org_display_vsperf_Traffic-2BGenerator-2BTesting-23TrafficGeneratorTesting-2DAppendixB-3ABack2BackTestingTimeSeries-28fromCI-29&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=0OU4C4AqvLg_D7DELrCSk_F5msO3yBHvQJ_sXHbiArw&s=DAkdeAhmHqU_aSUZQvXoF3iKwtSZd0pjMkkXpobvhcc&e=> and https://datatracker.ietf.org/meeting/100/materials/slides-100-bmwg-back-to-back-frame-benchmark-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_100_materials_slides-2D100-2Dbmwg-2Dback-2Dto-2Dback-2Dframe-2Dbenchmark-2D01&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=0OU4C4AqvLg_D7DELrCSk_F5msO3yBHvQJ_sXHbiArw&s=qzkaoZhPVRVlXREOzTML9dE6oU3H0ghVitwb7ItuTLI&e=> RFC2544 does not discuss either of these points, so this draft would update and expand the current test in the simplest way possible. However, the current draft benefits from your previous comments, specifically that we distinguish the scope of the back2back test from the RFC8239 multi-port testing and cases where line-rate switching is possible at the smallest frame sizes (both are out of scope, but there are still many places where the current back2back frame tests will be useful). The Pause method you are proposing has some interesting possibilities for new test methods, in the same scope of the multi-port scenarios addressed in RFC 8239 (Datacenter). We discussed this during our IETF-103 session. I think the WG really appreciates that you have shared your test results. There were several issues raised during the session, and further discussion would benefit from development of a procedure and other details usually found in an Internet Draft, such as new test equipment capabilities (ability to send "Pause"). I can help you with this documentation aspect, if you would like. It seems clear that we need a set of buffer measurement solutions that depend on the specific circumstances and scenarios to measure. Thanks again for reviewing the back-to-back frame draft, and for your contributions to the many WG discussions on buffer measurement. I hope you'll support my draft's first steps to better measurement, with many steps to follow. best regards, Al (as a participant/author) From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Yoshiaki Itou Sent: Friday, December 14, 2018 1:05 AM To: Sarah B <sbanks@encrypted.net<mailto:sbanks@encrypted.net>>; bmwg@ietf.org<mailto:bmwg@ietf.org> Subject: Re: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame Hello BMWG, I would like to comment on the definition of back-to-back Frame value. >5.2. Test for a Single Frame Size > >The Back-to-back Frame value is the longest burst of frames that the >DUT can successfully process and buffer without frame loss, The description of this back-to-back Frame value is exact. To explain more strictly: The Back-to-back Frame value is the longest burst of frames that the DUT can successfully process(forward not buffered) and buffer without frame loss, "Pause" method is a measuring the number of buffered frames only. https://datatracker.ietf.org/doc/minutes-103-bmwg/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_minutes-2D103-2Dbmwg_&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=HS7Ed6lrlBb60NZsCWT7WGKCJJIeGwqkssw7Jo0fsCk&s=MjJaOUmICdbkd2ls5SZN47QrTvYrHR76s8UZzrPbm4I&e=> 8. New Buffer assessment method for RFC 8239 Data Center Benchmarking Author: Yoshiaki Itou Mail List References: https://mailarchive.ietf.org/arch/msg/bmwg/lKiImpq8RlNapD8CVRG1dRZlMZ8<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bmwg_lKiImpq8RlNapD8CVRG1dRZlMZ8&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=HS7Ed6lrlBb60NZsCWT7WGKCJJIeGwqkssw7Jo0fsCk&s=sloQPaNgjEx7RZCURpl7ReYqeT2eytL6Rr1xQdyq_50&e=> https://mailarchive.ietf.org/arch/msg/bmwg/elCgGpsB-TH1zCwaRhzM7B2mW4g<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bmwg_elCgGpsB-2DTH1zCwaRhzM7B2mW4g&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=HS7Ed6lrlBb60NZsCWT7WGKCJJIeGwqkssw7Jo0fsCk&s=EsDXYSsfsoIkrcNSC0fp9qYEcx9kJXOq7pTu2Irbs7M&e=> Best Regards, Yoshiaki Itou From: bmwg <bmwg-bounces@ietf.org<mailto:bmwg-bounces@ietf.org>> On Behalf Of Sarah B Sent: Saturday, December 08, 2018 2:57 AM To: bmwg@ietf.org<mailto:bmwg@ietf.org> Subject: [bmwg] Call for Adoption: draft-morton-bmwg-b2b-frame Hello BMWG, At IETF103 in Bangkok Al Morton, author of the "back to back framework" draft, presented an update. https://datatracker.ietf.org/doc/draft-morton-bmwg-b2b-frame/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmorton-2Dbmwg-2Db2b-2Dframe_&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=HS7Ed6lrlBb60NZsCWT7WGKCJJIeGwqkssw7Jo0fsCk&s=Oqg5iKz3YLnA2seSHeJEgwf-Ga7nAK8GargCnf52jKM&e=> There has been sufficient interest, review, and comments on the draft, and I'd like to call for adoption of this draft by the WG. Please reply to this email before December 21, 2018 and indicate: (1) whether you support addition of the following milestone to the BMWG charter: date TBD: Updates for the Back-to-back Frame Benchmark in RFC 2544 (2) whether you support the adoption of draft-morton-bmwg-b2b-frame-03 as the basis document for this milestone (3) whether you commit to reviewing the WG document if adopted Thanks for your consideration of the draft! Kind regards, Sarah bmwg co-chair
- [bmwg] Call for Adoption: draft-morton-bmwg-b2b-f… Sarah B
- Re: [bmwg] Call for Adoption: draft-morton-bmwg-b… Yoshiaki Itou
- Re: [bmwg] Call for Adoption: draft-morton-bmwg-b… MORTON, ALFRED C (AL)
- Re: [bmwg] Call for Adoption: draft-morton-bmwg-b… Yoshiaki Itou
- Re: [bmwg] Call for Adoption: draft-morton-bmwg-b… MORTON, ALFRED C (AL)
- Re: [bmwg] Call for Adoption: draft-morton-bmwg-b… MORTON, ALFRED C (AL)
- Re: [bmwg] Call for Adoption: draft-morton-bmwg-b… Yoshiaki Itou
- Re: [bmwg] Call for Adoption: draft-morton-bmwg-b… MORTON, ALFRED C (AL)
- Re: [bmwg] Call for Adoption: draft-morton-bmwg-b… MORTON, ALFRED C (AL)