RE: [bmwg] Meeting Minutes Review: IPsec Terminology

Sunil Kalidindi <> Wed, 29 October 2003 06:14 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id BAA26868 for <>; Wed, 29 Oct 2003 01:14:28 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1AEjaj-0006VE-Cw; Wed, 29 Oct 2003 01:14:01 -0500
Received: from ([] by with esmtp (Exim 4.20) id 1AEjaY-0006U4-C6 for; Wed, 29 Oct 2003 01:13:50 -0500
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA26847 for <>; Wed, 29 Oct 2003 01:13:40 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AEjaV-0002HI-00 for; Wed, 29 Oct 2003 01:13:47 -0500
Received: from ([] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEjaU-0002HF-00 for; Wed, 29 Oct 2003 01:13:46 -0500
Received: from ([] by manatick with esmtp (Exim 4.24) id 1AEjaW-0002Uu-Gq for; Wed, 29 Oct 2003 01:13:48 -0500
Received: by with Internet Mail Service (5.5.2653.19) id <VV0LWDWP>; Tue, 28 Oct 2003 22:08:59 -0800
Message-ID: <>
From: Sunil Kalidindi <>
To: 'Tim Van Herck ' <>, "' '" <>
Cc: "' '" <>, "' '" <>
Subject: RE: [bmwg] Meeting Minutes Review: IPsec Terminology
Date: Tue, 28 Oct 2003 22:08:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Benchmarking Methodology Working Group <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

We should do # 2.

I agree with Brian that we should be careful about defining a "standard"
mix. I dont think we know what that is - especially with IPSec VPNs. Even if
we know what it is on a *given network*, *today*, I think we all agree that
may not apply in a general sense.

To suggest that there is a "standard" will increase the confusion that
"IMIX" has already caused in the industry.

I run into several people every week who think that they just need to test
with this magical "IMIX" distribution but are not sure what it is.

For the marketing numbers, most people end up using the best case number

- Sunil

-----Original Message-----
From: Tim Van Herck
Sent: 10/28/2003 3:19 PM
Subject: Re: [bmwg] Meeting Minutes Review:  IPsec Terminology


> Also consider that the specified IMIX does not account for 4470 byte
> packets.  4470 is the default MTU on POS links.  

same argument goes if you enable jumboframes on GE links.

> I do recommend stating that "a mix of Packet Sizes can be used and
> reported with the results".  That could eliminate the argument about
> definition of "IMIX" and allow the document user to select the best
> for his/her network.  Is this a good solution?

Could be a good solution to avoid heated debates about the right 
packetsizes for sure. What we also can do is make the mix more 
futureproof and don't rely anymore on data extracted from studies.
What if we just define a mix that sweeps from the minimum allowed 
packetsize to the MTU of the egress interface and make sure that the 
ranges are reported. On top of getting a comparable result you will also

  exercise the entire datapath.

So, as far as I can see we have three ways out of this :

1. Imix is a strict defined packetmix
    - poses problems with newly introduced links and also IPv6, it
      will work with old data
    - has the advantage of providing an apples-to-apples comparison
2. Imix is -a- mix, user reports what it is
    - hard to compare results
    - probably will still use the old style IMIX distributions
3. Imix is a packetsweep (after renaming the mix)
    - good chance of comparable results
    - can be adjusted to the needs of the network
    - exercises the full datapath
    - more futureproof

Let the voting begin !


> Scott
> -----Original Message-----
> From: Talbert, Brian []
> Sent: Tuesday, October 28, 2003 11:03 AM
> To: 'Michele Bustos'; ''
> 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
> "Simple IMIX" referenced.   Though your definition here does seem to
> the Ixia IMIX test script which uses 64, 570, and 1518 as packet sizes
> (including Ethernet header).  Agilent sticks to IP (as should probably
> done here) but with some variance in the packet sizes, using 40, 576,
> 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
> provided does not appear to be directly based upon any data studies,
> 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
> well.  For one, the data from which these were based (the NLANR data)
> coming up on 3 years old and more importantly it represents
> Internet data.  This draft focuses on VPN traffic patterns, for which
> 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
> gives a rough idea of the "customer experience".  I suspect the appeal
> 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
> 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
> general Internet consumption.  So, how well does this data model
> VPN applications where the usage is quite differnet from general
> consumption?   VPNs bring the element of enterprise applications into
> foray and so an IMIX model based on general Internet traffic will
> correlation significance.   
> The alternative would be to define IMIX very generically and not
> specific packet distributions.  Do this looses the advangate of have
> cross-comparison but it does allow replication.   Also, while this
> 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
> testing only to find out later that the pattern had a smallest packet
> of 512 or that max size was reduced to avoid fragmentation effects,
> I think you pretty much already do this, though for clarity I would
> any specific references in the discussion and instead focus on issues
> 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
> think it would be good to rely on Agilent or another outside source
> definition.   This is how I would probably tackle it:
> =======================
> Mixed Packet Size Stream
> Definition:  A stream (per Network Layer Traffic Control Term draft??)
> packets with varying framesizes.
> Discussion:  Mixed packet size streams allow testing to be conducted
> 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
> that for some purposes a packet mix representing general Internet
> (Internet Mix, or IMIX) will be appropriate, while for other purposes
> packet mix representing other characteristics will be more appropriate
> 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
> possible.   The National Laboratory for Applied Network Research has
> collected data that could be used to correlate an Internet MIX with
> Internet traffic.  Other data collection efforts may be necessary to
> significantly correlate a mixed packet size stream to actual usage
> Measurment Units:  The units applicable to the underlying test to wich
> 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
> 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
> Office:  703-886-5812              Fax:   703-886-0535
> Email:     AIM:   wbriantalbert
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>-----Original Message-----
>>>From: [] On 
>>>Behalf Of Michele Bustos
>>>Sent: Thursday, October 23, 2003 9:58 PM
>>>To: ''
>>>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
>>>bmwg mailing list
> _______________________________________________
> bmwg mailing list

bmwg mailing list