RE: [ns] goodput calculation

[Michael Welzl <michael@tk.uni-linz.ac.at>]

> > I think the reason for all the issues Lloyd brought up is that
> > there is no such thing as a "correct definition of goodput".
> > But I would say that goodput should always be related to a
> > bandwidth measurement - bytes / interval. That is suggested by
> > the similarities betweeen the names "throughput" and "goodput".
> 
> Things like slowstart play havoc with division over a measurement
> interval.

True if the interval is small. If you measure throughput or goodput
over a period of 10 minutes, it gives you an idea of the "quality" of
a congestion control mechanism. And this is what I, for instance, am
interested in.


> [..]
> > This definition should conform with how Lloyd defines goodput as
> > he is interested in how much is actually handed to the application.
> > Which is a sensible way to define goodput.
> > 
> > Still, it is not always defined like that - that depends on the
> > context. For instance, papers which do not consider retransmissions
> > may define goodput as "throughput seen by the receiver" as opposed
> > to "throughput used by the sender".
> 
> no retransmissions == no drops signalled back to the receiver. what
> papers are these?

I didn't have any particular paper in mind - but if you want to examine
the behaviour of TFRC vs. RAP, there is feedback but no retransmission.
Even if you would study the "goodput" of TCP in this context, you would
probably want to ignore retransmissions as you are only interested in
how many (packets / time) are transmitted using the TCP congestion
avoidance & control algorithms in comparison with the other mechanisms.


> > Come to think of it, the only actual difference is at which network
> > layer your "receiver" is located.
> 
> And where in the network. You've forgotten about drops en route
> again...

?
en route = layer 3
at receiver because of buffer overflow, reordering, ... = layer 4

You keep confusing me    :(

Cheers,
Michael