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

From: [email-masked]
Date: Wed, 30 Sep 1998 22:41:34 -0400

Colleagues,
     
     I, too, have been listening quietly to this discussion; however, I 
     believe the time has come for me to break my silence.  While I 
     understand the reticence with which David views the term PDU, I assert 
     that, as a descriptive term, it conveys an unambiguous meaning.  This 
     once said, I agree with the points raised concerning the quantitative 
     characterization of the offered load.  In specific, I would urge that 
     measurements based on PDUs, or BDUs or any other DUs for that matter, 
     be made given an "existing connection."  The task of defining of the 
     term "existing connection" I will leave to deeper thinkers; however, I 
     believe that I can propose some of the attributes of an "existing 
     connection."
     
     1. All security associations have been checked and verified
     2. All connection oriented hands have been shaken
     3. There be some means of ascertaining the effects of lower layer      
         errors, e.g. SONET BIP errors
     
     The time required for 1 and 2 will, of course, have to be 
     characterized, but it seems to me that there should be some sort of 
     raw data statistic which characterizes the throughput of a protocol 
     specific offered load.
     
     Regards,
     
     Jeff

______________________________ Reply Separator _________________________________
Subject: Re: [Fwd: Naming those hunks of data]
Author:  Non-HP-dlancaster ([email-masked]) at HP-USA,mimegw2
Date:    9/30/98 10:51 AM

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
>