Subject: RE: [bmwg] Meeting Minutes Review: IPsec Terminology

From: "Talbert, Brian" <[email-masked]>
Date: Tue, 28 Oct 2003 16:02:44 +0000

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:   [email-masked]     AIM:   wbriantalbert
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of Michele Bustos
>>Sent: Thursday, October 23, 2003 9:58 PM
>>To: [email-masked]'
>>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
>>[email-masked]
>>
>>
>>_______________________________________________
>>bmwg mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/bmwg
>>

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Tim Van Herck <[email-masked]>
Date: Tue, 28 Oct 2003 15:00:42 -0800

Brian,

> done here) but with some variance in the packet sizes, using 40, 576, and

The Agilent journal indeed specifies 3 different types of IMIX traffic 
with an increasing correlation to the NLANR sample data but it is far 
from the only source that defines IMIX as a some sort of packetsize 
distribution. You can find short definitions of the term in several test 
reports (e.g. Tolly group). Most definition agree on the 7:4:1 ratio but 
I've seen some diffs in the used packetsizes, especially the 570 byte one.

> rather taken from 3rd party sources, be it Agilent or Ixia. 

I agree, the NLANR study does NOT go near the topic of suggesting a mix 
that can be used for simulations. I just lists the distribution 
percentages and protocols that were captured during the sample time. 
There are indeed a large set of vendors and ISP's who started using -a- 
definition of IMIX but then when reporting results, omit to say what 
IMIX meant for them. That's why I feel we need to standardize this, even 
if this means that we have to define a new mix alltogether. But the 
ipsec methodology (and not only that document) will require some mix to 
work with besides fixed packet sizes.

> 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.

That is correct, the information is getting slightly dated already

> This draft focuses on VPN traffic patterns, for which there isn't
 > necessarily any correlation at all to the NLANR data.

Focus is NOT on VPN traffic but rather the behavior of the IPSEC tunnels 
when generalized Internet data is secured. So we want to see how a 
crypto stack/engine behaves when a simulated load is offered to it.

> resembles the source of the model data. 

That is exactly where the problem is these days. You will e.g. see a 
throughput number with IMIX traffic but then you start wondering what 
IMIX is for that specific vendor.

> And we know a few things about the

I also remember that some vendors where using an mix called EMIX, short 
for Enterprise MIX or E-commerce MIX. That one used a mix that included 
much more larger packets and very small packets for terminal like 
transactions. But it's even harder to find any reference on that one.

> of 512 or that max size was reduced to avoid fragmentation effects, etc.

Correct, or sometimes they will call a sweep from 64-1518 also IMIX 
which then completely trows of any means to compare results. That's why 
will will need a strict definition of IMIX but maybe we need to deviate 
from the way it has been used in the past.

> definition.   This is how I would probably tackle it:

	Tim-

---

From: Tim Van Herck <[email-masked]>
Date: Tue, 28 Oct 2003 15:00:42 -0800

Brian,

	Tim-