Re: [bmwg] Tsvart last call review of draft-ietf-bmwg-b2b-frame-03

"Black, David" <David.Black@dell.com> Tue, 24 November 2020 20:02 UTC

Return-Path: <David.Black@dell.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 9331A3A08FA; Tue, 24 Nov 2020 12:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=hBZI9sdy; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=q5yEb/9j
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 hpdYhphSNTNl; Tue, 24 Nov 2020 12:02:10 -0800 (PST)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 EECEF3A0DCA; Tue, 24 Nov 2020 12:01:39 -0800 (PST)
Received: from pps.filterd (m0170391.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AOK1HcW002227; Tue, 24 Nov 2020 15:01:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=tZ451cwslMzecvCua5pCbRbE+Ve4UYXyfLEtrJ6fPA4=; b=hBZI9sdyeoLW5paJ43dzNPeoujMFz1ZEw5+cHP07dA4KZDZ4DZb/aAH+fG55HjFJ/zGk AwIYiXlzJ9dNvSEbGkNT3fJzuE2Fmbsb7WZ4YSxENTd+bLXoQZHTQcSgEwkeWrgyXih6 0t7rNYbrodeuvOFvDgCyxa7pIJ4jnhROSZyr9nIjDQshLW4e14BimTV0JzlYh8K/UTcX ff0S7JzmS/91/TFAiu8XWUqJU6T+jtMklIFpEmbKOYJIN9rqkEeLa4Qbw3gAy4AZmd7Z kresiIhz/I1vb4jQyw2cULVGPZBSptfADNAyk/Fg6MLR7JTAL5q1gkT9UhHQKF0m5S1Y 2w==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 34xxx2b8p4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Nov 2020 15:01:39 -0500
Received: from pps.filterd (m0134318.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AOJrKPL148509; Tue, 24 Nov 2020 15:01:38 -0500
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2045.outbound.protection.outlook.com [104.47.66.45]) by mx0a-00154901.pphosted.com with ESMTP id 3513bkdxpa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Nov 2020 15:01:37 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QJ33FOEucrRec59AZFRyLtP2XM/JQQ3CQXF9VmpPYII2mgx+qh+NGFB8Q5qDuo4Z7qW6q1vzHI9uop4EcVl6v+ecBi7pWLKLZ5IQupgOPCXs//0/c6SuWQvF0BxRyG/MfgEbnDGRVx8aTKmItFL3wKr0tuYxaXKO6Qh9e9wYkztXGTp62GwbVOGmgpbbNLolfFiRYvq8ye1dGNVKzzivVEu0Ncom67a9ioP1+BGhLTw5HmZKXLDHiV2ARiNottmn+T1C34LM3+VnEYDb1BxvP0CyKR2ybpFHd9W3xlphkoTCYyfK3GkVJxX8qlteGZvUQerx8VB4NxCNkMEGz5WWHQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tZ451cwslMzecvCua5pCbRbE+Ve4UYXyfLEtrJ6fPA4=; b=R613q7qkSUMfGVFKaN3rVlGWKa1ZRcmdSfnuFw73mqPZUAv/Mnu+OhJnFVtC1AYIId/lwSguikWvdrk+Im4fZVleqY9hea6h1IGdAPRnqhm+YADXir6CVrhAuHlVXGKNankZqrCgDAbGH4zv3y80b9g+1eSOX4YIlHQkqceFs+H724q3he3RZaKJuMedddQaufH1cZuUiji5pb2mMXCCFPS0FwuF1aSJCdnq+jltt2Nn3l4YNDMX9wqjlTFaYmgW0MJFfZ1RTBaOm/mYDWoSUsLHf9HmvUyqyx90aopR357HEvFOR0EgNEACBJhkiJ5zGSB0mS5mitoUAhrt60b+vw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tZ451cwslMzecvCua5pCbRbE+Ve4UYXyfLEtrJ6fPA4=; b=q5yEb/9jZB7QhTbXTJx0fWx2hcCVl4rCQSbtM6qgROUjao2uAFB+6lTTuriDTa8KXBY6XulHDVRI1BBwOlc213wtZITZ1rJ5Az1S/yD1+SqnlzevbIswSDLN8fJi6EeR7YFum0YIBME1zbWqlBHqqrwq5BHyA9X9Blfvd2KijmY=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB4031.namprd19.prod.outlook.com (2603:10b6:208:1e0::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Tue, 24 Nov 2020 20:01:35 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::2853:5ccc:b023:dce4]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::2853:5ccc:b023:dce4%3]) with mapi id 15.20.3611.020; Tue, 24 Nov 2020 20:01:35 +0000
From: "Black, David" <David.Black@dell.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "bmwg@ietf.org" <bmwg@ietf.org>, "draft-ietf-bmwg-b2b-frame.all@ietf.org" <draft-ietf-bmwg-b2b-frame.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: Tsvart last call review of draft-ietf-bmwg-b2b-frame-03
Thread-Index: AQHWwnx0aANa5zmswk+xVn2oQ5//DqnXqHMQ
Date: Tue, 24 Nov 2020 20:01:35 +0000
Message-ID: <MN2PR19MB4045E52E2E321662721891C683FB0@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <160623159725.20249.9390987464844223889@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF014764C4F2@njmtexg5.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF014764C4F2@njmtexg5.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-11-24T19:19:28.7891058Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=1100f525-1dfb-44bb-91ef-4514e8ea6948; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
authentication-results: research.att.com; dkim=none (message not signed) header.d=none;research.att.com; dmarc=none action=none header.from=dell.com;
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 147dafad-5be7-4c98-2147-08d890b3bf33
x-ms-traffictypediagnostic: MN2PR19MB4031:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB403157CD761E0C99B7EEC69383FB0@MN2PR19MB4031.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: AxDRiHOVyLE7UevBAB7vBpZ+sL3YrEK+jpM1IBPvI3TjqUd3RNA9SqbOoanPoxl1oFkh7zEJlPjcU5JFGhf78mritFb0fbUORBnylfP9UIHaBOFuBcSw2J9Sj+Z5HspJOY3NmxeVaYob/EctSjpbsnJ5magp8eoRQ0IqJpJ9N5Lrr+BX6elDmxoD5QxVFzwopunouNDg/4dRR3SILl/6Az/U00gN+GZ+xlGTLGPMZgoD32hPuIExYOOwBpa67f0p4MudD1sNH8ZU71Di4vccyeW0dldEUQqGXVe7Eb2eI46fyyhwQXhYJRk0fUq1AvhNznF/qkRxakm6QbIyf956sSqPCPw27zNLL35vpfsm/UUcpfYop7ArcxF3cwyrEwvnGwW8kQR+c5ZIAwmTyu8jCA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(376002)(346002)(366004)(396003)(186003)(316002)(8936002)(786003)(55016002)(76116006)(66446008)(9686003)(33656002)(66556008)(7696005)(66946007)(64756008)(66476007)(8676002)(26005)(2906002)(6506007)(83380400001)(71200400001)(966005)(4326008)(86362001)(5660300002)(107886003)(478600001)(53546011)(52536014)(54906003)(110136005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?WG50NWVXRU9xMk11Y0t3L093VWJYdVRPWnBJRmVJcDdoQmhTRHVRUFAzbTlG?= =?utf-8?B?WVNoYlpyZGtubU51TTNkQmEwREh6UytvU3VqZU90bFl0cXZoUndzdGdKV09N?= =?utf-8?B?dk5rOFBIcFgvaXdhZjRadXVTdGIrODRsUG5LV1hJbjYzYVpyUVZHME5xRHgz?= =?utf-8?B?eGJnaDRMR2hZV2VnR2JOUkpEblhBcW1jNm5oOVVyb3Jrd29jbkZyQzQ2dW9C?= =?utf-8?B?YS9XbDBqa3pxOTRWeEJqd0lrUTYyMXg5RjRXOVN0VXhXZE15Sk9XS0hPcVFs?= =?utf-8?B?RktwZlFKZHZhbmEvS2lsVkNWRkwwZ0N0b0N3WGVBUjh1ZjJVN3ZmeEYyc1JE?= =?utf-8?B?aXpnblczSE5ETUJWZmZYMk5YZDJPdzcrY2o3aFB1K0JwcHI5VC9qVWtwK0FI?= =?utf-8?B?Ykw2dGR3U0dWTjl6TVk4K2krdUJtTHA5VDdNZFdiNG9TYmJhQWpWTDRzNnhV?= =?utf-8?B?S2dkbDdFN0VDdHU0TCtKM1RVbjBsRFFyVXVhVkJWRHF6SjJnZXlteHBtTkxr?= =?utf-8?B?MG83dHcxNCs4VXkwK1VBRGNTWXhKbit5Vzk2MWcvcnRacXMzcDdEVHgxMUtz?= =?utf-8?B?OWhGdWl3Q1hMeURneXhJeVB2RTZOTWxSTzQ3bzFCbzJ2NjNQL3FQYkM0S2E4?= =?utf-8?B?c0lGaHNzeW93NEdEdXgxMkd1Ny9vMk9uUm95cUpTZis5aSt4SU5BM29KSHJw?= =?utf-8?B?a1pWcVZmMnU1VFJzUnFQbFFtWTZnTUUrbXFZN3orSlJjbGsvblB4aE91YVN2?= =?utf-8?B?QlhZemVvOHFZZFpKWFBwWkZjdVZ2ay9XbWNxOE5OWURkbFMrRU1zdEdvYktI?= =?utf-8?B?dEFiRTNCcEYrdHV1UlY5dXJCbDRCQ2RUeVRhdmdBdXBpRys0eC84SFFLMmgr?= =?utf-8?B?VTdCSkRqc09qNURTMGFmb3B4SitPNnJnVk1MTEpnaktxeXl2VzVTb0pZWHA3?= =?utf-8?B?bDZsZElBZzl4MjhWQWZFaHJacGgyZjd4MnBqRlluMGRZNnNINXBmM1pEVXQz?= =?utf-8?B?dGpqR3l4QlhaMC8zcFgvTW80cEEyUzMvc3I4Z3FZUkdGdWtPMDUxQkRzT016?= =?utf-8?B?TmJwTnByVHgzUVZ2Uk5DQ0ZTMjRPc2Q0K0tNZEhUY0FUZVQ0d0lxYnYvNTJi?= =?utf-8?B?YndWSHgzb2xjcDlpYnMwejBXbzdDaTVlSnJLVnpPRUtGRlQ5dnRucmVkR1hO?= =?utf-8?B?MjE5VW8yRGZwZ2xzbXVsWCt5bTkxekUraWNleml3WEVENGtvNjJPWHdybWVx?= =?utf-8?B?R3pqQ2pzWXlZTXYzOWMwZVppbHJpSC9jTGkzNElkcWJYNTZldU8yQjJkaXl2?= =?utf-8?Q?qYg/WAD2ggUW4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 147dafad-5be7-4c98-2147-08d890b3bf33
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 20:01:35.2696 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HYn+mnyxZ81+O9Abw4zQKfHTRkyCS43BQIhx8DoRu0EssThJn7Kt3rjygkLIs3dDc1NwXa1j1Q/tbhrdJozsQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB4031
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-24_07:2020-11-24, 2020-11-24 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 adultscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011240117
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 bulkscore=0 suspectscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011240118
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/6PSwCGxGj1-MN6HH3omr_K1bYW8>
Subject: Re: [bmwg] Tsvart last call review of draft-ietf-bmwg-b2b-frame-03
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: Tue, 24 Nov 2020 20:02:13 -0000

Al,

> [acm] I agree with your observation that there are cases where trial duration
> should be increased to accommodate the encountered in the DUT, but not as a
> mandate for all testing. I have four factors in mind:
> 1. Some of the virtual network DUTs we are testing now have very small buffers,
> and the B2B stream of frames is quite short -- less than 2000 frames@10GE in
> some cases -- so 2 seconds fully sufficient.
> 2. The trial duration is a factor in total test duration, where each trial is one step in
> the Binary Search. We need to manage the tension between the time needed to
> reach a search result and confidence that we have depleted the queues.
> 3. The RFC 2544 Latency benchmark will tell us if bufferbloat is present.
> 4. The current text says "at least 2 seconds".
> 
> So I suggest adding the following text:
> 
>     The duration of the trial MUST be at least 2 seconds, to allow DUT
>     buffers to deplete. When RFC2544 Latency measurements indicate that
>     large buffers are present in the DUT, the trial duration SHOULD be
>     increased to ensure that buffer depletion takes place, without unduly
>     extending the total test time.

The overall approach of collecting evidence that there is a problem before increasing the 2 second minimum duration is fine, but the details appear to need more attention:

1. Obtaining the RFC 2544 Latency measurements would need to be added to Section 4 (Prerequisites) of this draft to ensure that the buffer size information is available.

2. I did not see any requirements in the RFC 2544 Latency test (Section 26.2) to deplete buffers.  Did I miss something?

3. I would think that the trial duration MUST be increased, not just SHOULD be increased if there is evidence of large buffer size, as buffer depletion appears to be a necessary characteristic of this B2B measurement.

It also looks like the link to the entire slide deck didn't make it into my original review correctly - that slide deck is at: http://www.taht.net/~d/lca_tcp3.odp .  In addition to slide 6 from this slide deck (Figure 1 in the APNIC blog), slide 14 is also relevant to this discussion.

Thanks, --David

> -----Original Message-----
> From: MORTON, ALFRED C (AL) <acm@research.att.com>
> Sent: Tuesday, November 24, 2020 11:11 AM
> To: Black, David; tsv-art@ietf.org
> Cc: bmwg@ietf.org; draft-ietf-bmwg-b2b-frame.all@ietf.org; last-call@ietf.org
> Subject: RE: Tsvart last call review of draft-ietf-bmwg-b2b-frame-03
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David, Thanks for your review and comment!
> 
> Please see a proposed resolution below, [acm] Al
> 
> > -----Original Message-----
> > From: David Black via Datatracker [mailto:noreply@ietf.org]
> > Sent: Tuesday, November 24, 2020 10:27 AM
> > To: tsv-art@ietf.org
> > Cc: bmwg@ietf.org; draft-ietf-bmwg-b2b-frame.all@ietf.org; last-
> > call@ietf.org
> > Subject: Tsvart last call review of draft-ietf-bmwg-b2b-frame-03
> >
> > Reviewer: David Black
> > Review result: Ready with Issues
> >
> ...
> >
> > This draft updates the back-to-back frame testing procedure in RFC
> > 2544 to take account of experience.
> >
> > The draft is in good shape, with one notable exception in Section 5.2:
> >
> >    The duration of the trial MUST be at least 2 seconds, to allow DUT
> >    buffers to deplete.
> >
> > That duration of 2 seconds has been carried forward from RFC 2544
> > without change.  A 2 second duration may have been sufficient to
> > deplete buffers in 1999, but that is no longer reliably the case.  For
> > example, on-site measurement of the network for the 2020 Linux
> > Conference in Australia indicated a at least 1.6 seconds of buffering,
> > as indicated by Figure 1 at
> > https://urldefense.com/v3/__https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/__;!!BhdT!wOuQE0NajXs4dT7tdIMVQU5FFpb0JiU0-yK2DOVVn0ecoYjf7mFEABLmlwDk$ ,
> > which is slide 6 in from the complete slide deck at:
> > https://urldefense.com/v3/__https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/__;!!BhdT!wOuQE0NajXs4dT7tdIMVQU5FFpb0JiU0-yK2DOVVn0ecoYjf7mFEABLmlwDk$
> > .  Experience with bufferbloat suggests that one network device was
> > primarily responsible.  Also, see slide 14 in that slide deck.
> >
> > That 1.6 seconds measured on an actual network is entirely too close
> > to 2 seconds for confidence that buffers will be depleted in any tested device.
> > Hence, the 2 second minimum duration ought to be increased by at least
> > a factor of 10.  I'd suggest changing it to 30 seconds or 60 seconds
> > as convenient round numbers, and providing the rationale that
> > increased buffering in WiFi devices, e.g., home "routers," as
> > indicated by experience with bufferbloat measurements, is the reason for the
> increased duration.
> >
> [acm]
> [acm] I agree with your observation that there are cases where trial duration
> should be increased to accommodate the encountered in the DUT, but not as a
> mandate for all testing. I have four factors in mind:
> 1. Some of the virtual network DUTs we are testing now have very small buffers,
> and the B2B stream of frames is quite short -- less than 2000 frames@10GE in
> some cases -- so 2 seconds fully sufficient.
> 2. The trial duration is a factor in total test duration, where each trial is one step in
> the Binary Search. We need to manage the tension between the time needed to
> reach a search result and confidence that we have depleted the queues.
> 3. The RFC 2544 Latency benchmark will tell us if bufferbloat is present.
> 4. The current text says "at least 2 seconds".
> 
> So I suggest adding the following text:
> 
>     The duration of the trial MUST be at least 2 seconds, to allow DUT
>     buffers to deplete. When RFC2544 Latency measurements indicate that
>     large buffers are present in the DUT, the trial duration SHOULD be
>     increased to ensure that buffer depletion takes place, without unduly
>     extending the total test time.
> 
> I hope this suggestion resolves your issue; thanks for highlighting it!
> Al