[bmwg] dsmterm-07 at 57th IETF - Changes to Channel Capacity

"Perser, Jerry" <jerry.perser@spirentcom.com> Thu, 17 July 2003 09:13 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24723 for <bmwg-archive@lists.ietf.org>; Thu, 17 Jul 2003 05:13:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4ou-0000Jf-VS; Thu, 17 Jul 2003 05:13:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4ol-0000JT-80 for bmwg@optimus.ietf.org; Thu, 17 Jul 2003 05:12:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24690 for <bmwg@ietf.org>; Thu, 17 Jul 2003 05:12:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4oi-0003aO-00 for bmwg@ietf.org; Thu, 17 Jul 2003 05:12:48 -0400
Received: from [199.1.46.3] (helo=brigadoon.spirentcom.com) by ietf-mx with esmtp (Exim 4.12) id 19d4oX-0003Yo-00 for bmwg@ietf.org; Thu, 17 Jul 2003 05:12:37 -0400
Received: by brigadoon.spirentcom.com with Internet Mail Service (5.5.2655.55) id <3FBP0HGF>; Thu, 17 Jul 2003 02:08:32 -0700
Message-ID: <629E717C12A8694A88FAA6BEF9FFCD44031B3169@brigadoon.spirentcom.com>
From: "Perser, Jerry" <jerry.perser@spirentcom.com>
To: "BMWG (E-mail)" <bmwg@ietf.org>
Date: Thu, 17 Jul 2003 02:08:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [bmwg] dsmterm-07 at 57th IETF - Changes to Channel Capacity
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>

Based on the comments at the BMWG meeting and a follow-up meeting, I have
some proposed changes to dsmterm-07 term 'Channel Capacity'.  The new text
is below.  The summary is:

1. Name change from 'Channel Capacity' to 'Maximum Lossless Forwarding
Rate'.

2. The discussion (paragraph 2) discusses the effect of queing on ingress
measurements; where this metric is a egress measurement and is not affected.

3. The discussion (paragraph 3) better states why you should measure Maximum
Lossless Forwarding Rate first and how ths metric should be used in the
methodology.

Jerry.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

3.2.1 Maximum Lossless Forwarding Rate

  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 at which
    none of the offered packets are dropped by the device.

  Discussion:
    Maximum lossless forwarding rate 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 numbers can be higher than Maximum
    lossless forwarding rate because of queuing.  The difference
    is dependent upon test duration, packet rate, and queue size.   
    Maximum lossless forwarding rate, as an egress measurement,
    does take queuing into account.  

    Understanding Maximum lossless forwarding rate is a necessary
    precursor to any measurement involving Traffic Control
    Mechanisms.  The accompanying methodology document MUST take
    into consideration Maximum lossless forwarding rate when
    determining the expected forwarding vectors.  When the sum on
    the expected forwarding vectors on an interface exceeds the
    Maximum lossless forwarding rate, the interface's performance
    will supersede the Traffic control mechanisms' performance.
  
    This measurement differs from forwarding rate at maximum
    offered load (FRMOL) [Ma98] in that Maximum lossless
    forwarding rate is intolerant of 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