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

"David Newman" <dnewman@networktest.com> Thu, 17 July 2003 15:35 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 LAA11645 for <bmwg-archive@lists.ietf.org>; Thu, 17 Jul 2003 11:35:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAmb-0000Mn-K8; Thu, 17 Jul 2003 11:35:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAmL-0000JL-56 for bmwg@optimus.ietf.org; Thu, 17 Jul 2003 11:34:45 -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 LAA11633 for <bmwg@ietf.org>; Thu, 17 Jul 2003 11:34:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAmK-0007FL-00 for bmwg@ietf.org; Thu, 17 Jul 2003 11:34:44 -0400
Received: from ns.networktest.com ([206.72.95.132] helo=networktest.com) by ietf-mx with esmtp (Exim 4.12) id 19dAm8-0007Ed-00 for bmwg@ietf.org; Thu, 17 Jul 2003 11:34:33 -0400
Received: from DUKE (ns.networktest.com [206.72.95.132]) by networktest.com (Postfix) with SMTP id D48793EE873; Thu, 17 Jul 2003 08:31:12 -0700 (PDT)
From: David Newman <dnewman@networktest.com>
To: "Perser, Jerry" <jerry.perser@spirentcom.com>, "BMWG (E-mail)" <bmwg@ietf.org>
Subject: RE: [bmwg] dsmterm-07 at 57th IETF - Changes to Channel Capacity
Date: Thu, 17 Jul 2003 08:31:37 -0700
Message-ID: <BAEALKMNKLEELDKGBICPGENFDDAA.dnewman@networktest.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <629E717C12A8694A88FAA6BEF9FFCD44031B3169@brigadoon.spirentcom.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Do you still need my input?

And what was the great rush to lose "channel capacity"? While I do not
object to the name change, your other coauthors might.  They should have had
a chance to weigh in.

dn

> -----Original Message-----
> From: bmwg-admin@ietf.org [mailto:bmwg-admin@ietf.org]On Behalf Of
> Perser, Jerry
> Sent: Thursday, July 17, 2003 2:09 AM
> To: BMWG (E-mail)
> Subject: [bmwg] dsmterm-07 at 57th IETF - Changes to Channel Capacity
>
>
> 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
>
>


_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg