RE: [bmwg] Meeting Minutes Review: IPsec Terminology

[Merike Kaeo <[e-mail]>]

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, [e-mail] 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:[e-mail]]
>Sent: Tuesday, October 28, 2003 11:03 AM
>To: 'Michele Bustos'; '[e-mail]'
>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:   [phone]
>Email:   [e-mail]     AIM:   wbriantalbert
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
> >>-----Original Message-----
> >>From: [e-mail] [mailto:[e-mail]] On
> >>Behalf Of Michele Bustos
> >>Sent: Thursday, October 23, 2003 9:58 PM
> >>To: '[e-mail]'
> >>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
> >>[e-mail]
> >>
> >>
> >>_______________________________________________
> >>bmwg mailing list
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/bmwg
> >>
>
>_______________________________________________
>bmwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/bmwg
>
>_______________________________________________
>bmwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/bmwg


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