RE: [bmwg] Meeting Minutes Review: IPsec Terminology

Merike Kaeo <kaeo@merike.com> Tue, 28 October 2003 22:41 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 RAA03179 for <bmwg-archive@lists.ietf.org>; Tue, 28 Oct 2003 17:41:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEcWL-0000pS-De; Tue, 28 Oct 2003 17:41:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEcVv-0000nM-C1 for bmwg@optimus.ietf.org; Tue, 28 Oct 2003 17:40:35 -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 RAA03115 for <bmwg@ietf.org>; Tue, 28 Oct 2003 17:40:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEcVs-0001ac-00 for bmwg@ietf.org; Tue, 28 Oct 2003 17:40:32 -0500
Received: from [208.201.152.19] (helo=modus.surfnetusa.com) by ietf-mx with esmtp (Exim 4.12) id 1AEcVr-0001aU-00 for bmwg@ietf.org; Tue, 28 Oct 2003 17:40:32 -0500
Received: from seabreeze.merike.com (unverified [4.33.105.153]) by modus.surfnetusa.com (Vircom SMTPRS 2.1.258) with ESMTP id <B0020184318@modus.surfnetusa.com>; Tue, 28 Oct 2003 14:40:29 -0800
Message-Id: <5.2.1.1.2.20031028142807.00b4fbc8@mail.merike.com>
X-Sender: kaeo@merike.com@mail.merike.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Tue, 28 Oct 2003 14:40:18 -0800
To: sporetsky@quarrytech.com, brian.talbert@mci.com, mbustos@ixiacom.com, bmwg@ietf.org
From: Merike Kaeo <kaeo@merike.com>
Subject: RE: [bmwg] Meeting Minutes Review: IPsec Terminology
Cc: ipsec-term@external.cisco.com
In-Reply-To: <496A8683261CD211BF6C0008C733261A03DBCC6C@email.quarrytech. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

I think some packet sizes should be explicitly stated so that results would 
be comparable if different testing devices were used to test different 
products.  I personally like the idea of using 64-byte, 768-byte, 1518-byte 
and 4470-byte packets if for no other reason that it covers a mix.  Min and 
max mtu is always good to catch sw issues and then some mid-size packets 
give you feel for what performance curve looks like for a device.  The 
768-byte number can be removed or replaced with another size.....just threw 
it out there......somewhy I remember that looking at corporate network 
traffic data from a few years back produced a lot of traffic around that size.

- merike

At 05:17 PM 10/28/2003 -0500, sporetsky@quarrytech.com wrote:
>Also consider that the specified IMIX does not account for 4470 byte
>packets.  4470 is the default MTU on POS links.
>
>I do recommend stating that "a mix of Packet Sizes can be used and MUST be
>reported with the results".  That could eliminate the argument about
>definition of "IMIX" and allow the document user to select the best "IMIX"
>for his/her network.  Is this a good solution?
>
>Scott
>
>-----Original Message-----
>From: Talbert, Brian [mailto:brian.talbert@mci.com]
>Sent: Tuesday, October 28, 2003 11:03 AM
>To: 'Michele Bustos'; 'bmwg@ietf.org'
>Cc: Ipsec-Term@External. Cisco. Com (E-mail)
>Subject: RE: [bmwg] Meeting Minutes Review: IPsec Terminology
>
>
>The definition seems to draw from Agilent's Journal of Internet Test
>Methodologies.  That is about the only source where I have seen the term
>"Simple IMIX" referenced.   Though your definition here does seem to draw
>the Ixia IMIX test script which uses 64, 570, and 1518 as packet sizes
>(including Ethernet header).  Agilent sticks to IP (as should probably be
>done here) but with some variance in the packet sizes, using 40, 576, and
>1500.
>
>In any event, I will again raise caution about trying to define IMIX or at
>least to give reference to any particular distribution.  The distribution
>provided does not appear to be directly based upon any data studies, but
>rather taken from 3rd party sources, be it Agilent or Ixia.  And that may in
>itself be fine if so recorded (as examples) but there is concern here as
>well.  For one, the data from which these were based (the NLANR data) is
>coming up on 3 years old and more importantly it represents generalized
>Internet data.  This draft focuses on VPN traffic patterns, for which there
>isn't necessarily any correlation at all to the NLANR data.
>
>=================================================
>To echo (quite literally) my previous sentiments:
>
>  Well, I'm not sure that someone must state it in an RFC ... not at
>least in so far as it defines a specific pattern.  First, why do we all use
>IMIX?  I use it because our sales engineers and marketing folks don't want a
>lot of information.  They want a single number that they can quote that
>gives a rough idea of the "customer experience".  I suspect the appeal is
>similar for vendors, and IMIX is OK for this purpose.  So the question
>becomes, would a standardized IMIX fairly represent the "customer
>experience".  Well, if that standard includes a specific packet size pattern
>then it would be fair assuming that the customer experience closely
>resembles the source of the model data.   And we know a few things about the
>model data: it is several years old and was only then representative of
>general Internet consumption.  So, how well does this data model represent
>VPN applications where the usage is quite differnet from general Internet
>consumption?   VPNs bring the element of enterprise applications into the
>foray and so an IMIX model based on general Internet traffic will loose
>correlation significance.
>
>The alternative would be to define IMIX very generically and not include
>specific packet distributions.  Do this looses the advangate of have easy
>cross-comparison but it does allow replication.   Also, while this doesn't
>standardize everyone on the exact same mix, it would at least allow for you
>to stipulate that the IMIX pattern (packet sizes and interleave) be
>documented.  This would still go a long way as I see many reports of "IMIX"
>testing only to find out later that the pattern had a smallest packet size
>of 512 or that max size was reduced to avoid fragmentation effects, etc.
>
>I think you pretty much already do this, though for clarity I would avoid
>any specific references in the discussion and instead focus on issues such
>as:
>
>1.  General distribution of packet sizes
>2.  Interleaving of packets
>3.  Correlation to actual data
>etc.
>
>If you definately think it is best to go forward with referencing IMIX
>in the meth then you should probably have it defined in the term. I don't
>think it would be good to rely on Agilent or another outside source for
>definition.   This is how I would probably tackle it:
>
>
>=======================
>Mixed Packet Size Stream
>
>Definition:  A stream (per Network Layer Traffic Control Term draft??) of
>packets with varying framesizes.
>
>Discussion:  Mixed packet size streams allow testing to be conducted using
>traffic patterns that simulate those observed in live networks.  Such
>streams can be used to analyze forwarding rates, throughput, and other
>metrics in a scenario that best represents the specific deployment
>utilization of a device.
>
>The particular distribution of packet sizes and how they are interleaved may
>vary depending upon expected operational use of a device.  It is conceivable
>that for some purposes a packet mix representing general Internet traffic
>(Internet Mix, or IMIX) will be appropriate, while for other purposes a
>packet mix representing other characteristics will be more appropriate (for
>examplle, a VPN Mix, VoIP Mix, etc.).   In all cases, however, it is
>important the the specific packet sizes, thier distribution ratios, and how
>they are interleaved be as closely correlated to the operational usage as
>possible.   The National Laboratory for Applied Network Research has
>collected data that could be used to correlate an Internet MIX with general
>Internet traffic.  Other data collection efforts may be necessary to
>significantly correlate a mixed packet size stream to actual usage patterns.
>
>Measurment Units:  The units applicable to the underlying test to wich the
>mixed packet size stream is being applied.
>==========================
>
>
>
>This approach to defining a "MIX" allows for the flexiblity for the
>individual tester to define a mix that meets thier own needs and alows it to
>be applied to a variety of metrics.  You could for instance further define a
>"VPN MIX Throughput" or "Internet with G.729 MIX Forwarding Rate".   It also
>opens the doors to require in a meth (or here if that seems more
>appropriate) that any type of MIX must be defined in results to include:
>
>1.  Packet sizes within the stream
>2.  Distribution ratios of the packet sizes
>3.  Interleaving characteristics
>???4.  Targeted operational use?
>???5.  Correlation to targeted use
>
>
>
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Brian Talbert
>UUNET Access Engineering
>MCI
>
>Office:  703-886-5812              Fax:   703-886-0535
>Email:   brian.talbert@mci.com     AIM:   wbriantalbert
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
> >>-----Original Message-----
> >>From: bmwg-admin@ietf.org [mailto:bmwg-admin@ietf.org] On
> >>Behalf Of Michele Bustos
> >>Sent: Thursday, October 23, 2003 9:58 PM
> >>To: 'bmwg@ietf.org'
> >>Cc: Ipsec-Term@External. Cisco. Com (E-mail)
> >>Subject: [bmwg] Meeting Minutes Review: IPsec Terminology
> >>
> >>
> >>To address the issues raised at the last meeting regarding
> >>the IPsec Term draft.
> >>
> >>>The current draft defined IMIX (Internet Mix for traffic synthesis),
> >>>but did not include the reference that Michele Bustos
> >>provided on the
> >>>list. There was a comment suggesting that this is a good
> >>definition to
> >>>include, with the caveat that no one mix of packet sizes represents
> >>>Internet usage.
> >>
> >>We eliminated the NLARR reference from the draft for several
> >>reasons. The reference never actually refers to IMIX, and
> >>they never suggest any frame
> >>sizes or traffic patterns.
> >>
> >>If anyone can provide a reference for IMIX specifically, we
> >>would be happy to investigate it.
> >>
> >>Michele Bustos
> >>Ixia
> >>mbustos@ixiacom.com
> >>
> >>
> >>_______________________________________________
> >>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
>
>_______________________________________________
>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