Subject: Re: [Fwd: Naming those hunks of data]

From: "Dale Lancaster" <[email-masked]>
Date: Wed, 30 Sep 1998 09:51:54 -0500

I've been listening quitely on the side.  I like the PDU, but it implies a
protocol specific data size when in reality for most performance
benchmarking, most packets are going to be full and you will be more
interested in the filesizes that were used.  A large HTTP file will produce
higher throughput than a bunch of smaller ones due to connection setup
overhead.

Benchmark Unit is cool.  How about merging the two: "Benchmark Data Unit".
The BDU could be a file, a packet, a "stream of bits", whatever, as long as
its defined.  Benchmark Unit doesn't really say what it represents, data?
time? protocol?.

regards,
dale
=============================================
Dale Lancaster
Director of Technical Marketing
AXENT Technologies
=============================================

-----Original Message-----
From: Kevin Dubray <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, September 30, 1998 9:17 AM
Subject: [Fwd: Naming those hunks of data]

>Jim McQuaid asked me to forward his reply...
>
>[email-masked] wrote:
>>
>> So, "benchmarking unit" *is* pretty colorless, although it would do the
>> job.  However, another thought is simply to refer to this as the "offered
>> load" and require exact description of the nature and size of this
offered
>> load {one packet, a stream of packets, a sequence of packet exchanges}.
>> Clearly the nature of this beast must be explicitly called out no matter
>> what the name.
>>
>> "Flow" by the way is defined in one of the RSVP RFCs I believe in a
>> 1242-ish kind of way and so should be fair game if used in the same way.
>>
>> Despite the logical generic aspect of PDU, I believe that the primary
>> association / connotation will be with a unit of data passed from one
layer
>> of the protocol stack to another, with a strong implication of single
>> packet scope.
>>
>> Jim McQuaid
>> NetScout Systems
>>
>> [email-masked] on 09/29/98 08:25:16 PM
>>
>> To:   Jim McQuaid/NetScout
>> cc:   [email-masked], [email-masked]
>> Subject:  Re: Naming those hunks of data
>>
>> David Newman wrote:
>> >>
>> >> With all due respect to Jeff (who's made invaluable contributions to
>> >> this effort), I'm leery of using the term PDU. It's nothing against
the
>> >> concept; what PDU describes is exactly what's needed here. My concern
is
>> >> that I've heard the term PDU used quite a bit in discussing ATM, but
>> >< rarely in IP circles (well, maybe by Scott Brim or Berry Kercheval,
but
>> >> they work with both ATM and IP). Since I'd like this document to be
>> >> technology-neutral, I'd prefer to use as generic--and as
>> >> all-encompassing--a term as possible.
>>
>> [email-masked] wrote:
>> >
>> > PDU has the scope of a single packet in most circumstances.  Therefore,
>> to
>> > describe something which might be multi-packet, you need a broader
term.
>> > So, agree on non-use of "PDU."
>>
>> Well, the notion of a PDU comes from the OSI architectural framework.
>> And it's generic in nature, not bound to an implementation or a
>> network layer packet.  Moreover, it is meant to convey an entity that
>> is passed between elements of the same kind.  So, I think the term
>> is quite accurate in it's suggested usage, though I can understand
>> why folks might like some differentiation.
>>
>> >
>> > "Flow" is another candidate.  "Transaction" implies exchange or
dialogue,
>> > packets in one direction resulting in some response(s) in the other
>> > direction.  Flow is unidirectional.  Packets flow in one direction or
the
>> > other.  So, if you want to describe an offered load which is
multipacket
>> > but unidirectional, I suggest flow.  If you want to accomodate (or
insist
>> > on) exchanges as the offered load, then transaction works.  "Flow" may
>> > offer additional advantages as marketectures unroll in the area of
>> per-flow
>> > policy at the firewall, etc.
>> >
>> > Jim McQuaid
>> > NetScout Systems
>> > 978-614-4116
>>
>> I don't like "flow," at least as a title.  The IESG had problems
>> with terms like "traffic class" and "service class" in
>> <draft-ietf-draft-mcast-05.txt>, citing overuse in network parlance.
>> I can only imagine the reception "flow" would get.
>>
>> I can see Jim's point with respect "transaction" if you restrict
>> the term to an explicit request/response paradigm.  There are many types
>> of transactions that are unacknowledged - a dialogue need not
>> take place between to entities in order for the event to be counted.
>> Then again, you could require an explicit acknowledgement or response
>> as a condition of counting. Why restrict the metric unduly with
>> methodological details?
>>
>> If "transaction" connotes something stronger than a counting unit
>> of an auditable event, (and I think that's what we're talking about
>> right?) how about something as simple like "benchmarking unit"?
>> Can't get any more generic or dimensionless than that. ;-)
>> Each metric's methodology with have to describe the BU relative to
>> that metric, but it helps from pigeonholing a metric in a measurement
>> unit that might not fit quite right...  However, David's concern
>> on the term's utility as a function of breath still holds.
>>
>> -Kevin
>