- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: Utilization affect on throughput [7:76157] posted 09/27/2003
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

At 4:38 AM +0000 9/27/03, Zsombor Papp wrote:
>It appears to me that, according to the definitions you provided, most of
>the things you listed under the "throughput is also affected by many
>factors" label should affect only goodput, not throughput. If you really
>think that throughput is affected by
>- client PC performance
>- server performance
>- too many users sharing the server
>- software performance, including OS, protocol stack, applications
>- bad routing
>- errors [that don't affect the L2-L3 headers]
>- sun spots [that don't affect the L2-L3 headers]
>- etc :)
>then I would be curious to know how you differentiate between throughput and

Most of these do not affect goodput, but other measures of _system_ 
performance. I say "most", because resource sharing can affect local 
queueing, as can software performance.  Bad routing causing 
nondelivery or misdelivery has the same effect as an error.  Errors 
affecting >L3 headers are likely to be protocol or implementation 

One of the concepts in the CCITT/ITU X.140 architecture and X.130 
series standards, as well as ANSI X3.102, is "interface 
responsibility."  In these standards (I'm a coauthor), we address 
"user oriented network performance".  There is a concept of 
"interface responsibility", a dimensionless coefficient that is used 
for such things as throughput and delay, derating the measured value 
to consider times when the network was ready to transfer data but a 
host wasn't ready to send or receive it.

>(As a side note, according to my fainting -- and not necessarily correct --
>memories, the word "goodput" first appeard in relation with IP over ATM (ie.
>AAL5) networks. There the throughput was measured in cells per second, but
>one dropped cell made the transmission of several other cells pointless
>since the IP packet couldn't be reassembled at the end. Thus the goodput was
>significantly different than the throughput. The meaning of these terms have
>surely changed since then, and this is just a side note anyway, so don't let
>it interfer with your efforts towards defining throughput and goodput... :)
>Having said that, I agree that goodput (meaning the actual error-free
>application data transmitted end-to-end, per unit of time) is a useful term,
>because that's what actually describes the users' experience. It would be
>great if we could design networks that meet specified goodput criteria, but
>that's pretty hard, exactly because of the many things affecting it.

Part of the problem is that users (and sales) would like to see a 
single number, but performance is far too complex to be reduced, 
usefully, to a single number. In my most recent work on eBGP 
convergence, we have have to go to a long list of parameters 
rather than a single number. Quite frankly, the authors of this 
document were all affiliated with vendors, and were trying to come up 
with meaningful numbers rather than the handwaving of sales.

>To bring up an extreme (but increasingly relevant) example, the "goodput" of
>a VoIP network is usually measured based on statistical evaluation of the
>users' (subjective) opinion. Wanna bet when we will be able to design a
>network that meets a given MOS value? :)

Realistically, you can't, unless you can establish strong correlation 
between a _set_ of quantifiable parameters and MOS. Also, when 
speaking of these parameters, a simple scalar number is often not 
enough.  To be useful in any sort of design model, for example, error 
rate has to be characterized in some manner that describes its 
burstiness.  Equally spaced errors at an aggregate rate of 1 in 
10,000 bits would make communications impossible, because they'd 
smash just about every frame (assuming 1500 byte MTU).  A periodic 
burst of 1000 errored bits, however, could be handled by 
retransmission, or, in the case of voice, the ability of the brain to 

>Priscilla Oppenheimer wrote:
>  >
>>  Zsombor Papp wrote:
>>  >
>>  > Howard C. Berkowitz wrote:
>>  > >
>>  > > At 10:43 PM +0000 9/26/03, Zsombor Papp wrote:
>>  > > >Priscilla Oppenheimer wrote:
>>  > > >>  Sphon says it nicely: "throughput is a measure of how
>>  much
>>  > > data
>>  > > >>  can be passed across a medium in a stated period of
>>  time.
>>  > > >>  Capacity and throughput are similar, but not the same.
>>  > > Capacity
>>  > > >>  is the actual amount of resources available across a
>>  given
>>  > > path."
>>  > > >
>>  > > >OK, then I guess I meant capacity all along when I said
>>  > > throughput. Based on
>>  > > >the above definition, I think we can say that
>>  > > >throughput==amount_of_data/(amount_of_data/capacity +
>>  delay).
>>  > > So yes, if
>>  > > >delay goes up, then throughput goes down.
>>  > > >
>>  > > >I will note however that "throughput" as defined above is
>>  not
>>  > > very useful
>>  > > >from a network design point of view, because it obfuscates
>>  > the
>>  > > two things
>>  > > >that a network design can account for: delay and capacity.
>>  > >
>>  > > But isn't throughput, or that terrible term goodput,
>>  valuable
>>  > > as the
>>  > > definition of the target for which you have to tune delay
>>  and
>>  > > capacity?
>>  >
>>  > If you have realistic examples where the requirement is
>>  defined
>>  > in terms of throughput (instead of in terms of capacity and/or
>>  > delay), I will be interested to hear it.
>>  Users aren't often clueful enough to specify requirements in
>>  terms of throughput, but perhaps they should be, and a network
>>  designer should certainly consider it.
>>  A lot of users are clueful enough to measure throughput after
>>  the design is in place and complain if it doesn't match
>>  expectations. Sometimes the complaints are due to not
>>  understanding that throughput != bandwidth, but sometimes the
>>  complaints are due to the fact that the designer didn't
>>  understand that and threw raw network bandwidth at the problem
>>  without considering that throughput is also affected by many
>>  factors, including:
>>  client PC performance
>>  server performance
>>  too many users sharing the server
>>  software performance, including OS, protocol stack, applications
>>  internetwork device performance
>>  bad routing
>>  satellite delays
>>  errors
>>  sun spots
>>  etc.
>>  etc.
>>  etc.
>>  Throughput is important for lots of applications. For others,
>>  such as voice, delay is more important. Both throughput and
>>  delay are network design requirements. Capacity is more of a
>>  design solution.
>>  >
>>  > You will have to define what goodput means before I comment on
>>  > that. :)
>>  Goodput is a measure of the error-free application-layer data
>>  that can be sent per time unit. Despite it being an awful word,
>>  it's a useful concept, and the word has actually caught on
>>  since it was first bandied about a number of years ago. Even
>>  experts like Geoff Huston use it. Google it for more info?
>>  Gotta run.  Thanks for an interesting discussion.
>>  Priscilla
>>  >
>>  > Thanks,
>>  >
>>  > Zsombor
>**Please support GroupStudy by purchasing from the GroupStudy Store:
>FAQ, list archives, and subscription info: 

Message Posted at:
**Please support GroupStudy by purchasing from the GroupStudy Store:
FAQ, list archives, and subscription info: