Subject: Re: Naming those hunks of data

From: [email-masked]
Date: Tue, 29 Sep 1998 08:26:51 -0400

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

"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

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 29 Sep 1998 20:25:16 -0400

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.

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

> policy at the firewall, etc.

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