[bmwg] Resolution to WG Last Call: draft-ietf-bmwg-dsmterm-08.txt
"Perser, Jerry" <jerry.perser@spirentcom.com> Wed, 12 November 2003 23:10 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15615 for <bmwg-archive@lists.ietf.org>; Wed, 12 Nov 2003 18:10:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK47d-0008R6-VQ; Wed, 12 Nov 2003 18:10:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK46t-0008Q5-ST for bmwg@optimus.ietf.org; Wed, 12 Nov 2003 18:09:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15455 for <bmwg@ietf.org>; Wed, 12 Nov 2003 18:09:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK46q-0000dW-00 for bmwg@ietf.org; Wed, 12 Nov 2003 18:09:12 -0500
Received: from [199.1.46.3] (helo=brigadoon.spirentcom.com) by ietf-mx with esmtp (Exim 4.12) id 1AK46q-0000dD-00 for bmwg@ietf.org; Wed, 12 Nov 2003 18:09:12 -0500
Received: by brigadoon.spirentcom.com with Internet Mail Service (5.5.2655.55) id <WS3GSSMQ>; Wed, 12 Nov 2003 15:08:42 -0800
Message-ID: <629E717C12A8694A88FAA6BEF9FFCD44031B325D@brigadoon.spirentcom.com>
From: "Perser, Jerry" <jerry.perser@spirentcom.com>
To: "BMWG (E-mail)" <bmwg@ietf.org>
Date: Wed, 12 Nov 2003 15:08:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [bmwg] Resolution to WG Last Call: draft-ietf-bmwg-dsmterm-08.txt
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
Here is a summary of the status: - No consensus if Shannon's Channel Capacity applies to this I-D. Arguments on both side with no resolution. - Maximum Lossless Forwarding Rate is A) too long for most people to say (or type) and B) Deviates from RFC2285 discussion on "forwarding rate makes no explicit reference to frame loss". It was Argued the word 'no' does not represent a Boolean state (i.e. Yes/No). - Another term was proposed. From RFC2285 section 3.3.3, the discussion talks about "forwarding capacity of a DUT/SUT". It was proposed to used Forwarding Capacity in place of Channel Capacity. Pros are: 1. Does not have the problems cited for Channel Capacity or Maximum Lossless Forwarding Rate. 2. It is a term used in a BMWG document (RFC2285), but currently undefined in the IETF. 3. It follows other terms in the dsmterm-08 I-D that got a forwarding prefix: - Congestion was changed to Forwarding Congestion - Delay was changed to Forwarding Delay - Channel Capacity was changed to Forwarding Capacity Here is the proposed text for dsmterm-09: 3.2.1 Forwarding Capacity Definition: The number of packets per second that a device can be observed to successfully transmit to the correct destination interface in response to a specified offered load while the device drops none of the offered packets. Discussion: Forwarding Capacity measures the packet rate at the egress interface(s) of the DUT/SUT. In contrast, throughput as defined in RFC 1242 measures the frame rate at the ingress interface(s) of the DUT/SUT. Ingress-based measurements do not account for queuing of the DUT/SUT. Throughput rates can be higher than the Forwarding Capacity because of queuing. The difference is dependent upon test duration, packet rate, and queue size. Forwarding Capacity, as an egress measurement, does take queuing into account. Understanding Forwarding Capacity is a necessary precursor to any measurement involving Traffic Control Mechanisms. The accompanying methodology document MUST take into consideration Forwarding Capacity when determining the expected forwarding vectors. When the sum of the expected forwarding vectors on an interface exceeds the Forwarding Capacity, the Forwarding Capacity will govern the forwarding rate. This measurement differs from forwarding rate at maximum offered load (FRMOL) [Ma98] in that Channel Capacity requires zero loss. Measurement units: N-octet packets per second See Also: Throughput [Br91] Forwarding Rate at Maximum Offered Load [Ma98] ___________________________________________________________ Jerry Perser Spirent Communications Director of Test Methodology SmartBits Division Phone: 818.676.2320 26750 Agoura Road Lab: 818.676.2337 Calabasas, CA, 91302 Cell: 818.292.6457 Corp: 818.676.2300 _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg
- [bmwg] Resolution to WG Last Call: draft-ietf-bmw… Perser, Jerry