[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