On May 8, 2011, at 5:34 AM, Richard Scheffenegger wrote: > Goodput can really only be measured at the sender; by definition, any > retransmitted packet will reduce goodput vs throughput; In your example, > where each segment is retransmitted once, goodput would be - at most - 0.5, > not 1.0... IMHO defining the data volume after the bottleneck by itself as > goodput is also a bit short-sighted, because a good fraction of that data may > still be discarded by TCP for numerous reasons, ultimately (ie, legacy > go-back-n RTO recovery by the sender)...
Actually, I didn't say that every packet was retransmitted once. I said that every dropped packet was retransmitted once. And Goodput will never exceed the bit rate of the bottleneck in the path, apart from compression (which in effect applies a multiplier to the bottleneck bandwidth). > But back to my original question: When looking at modern TCP stacks, with > TSO, if the bufferbloat allows the senders cwnd to grow beyond thresholds > which allow the aggressive use of TSO (64kB or even 256kB of data allowed in > the senders cwnd), the effective sending rate of such a burst will be > wirespeed (no interleaving segments of other sessions). As pointed out in > other mails to this thread, if the bottleneck has then 1/10th the capacity of > the senders wire (and is potentially shared among multiple senders), at least > 90% of all the sent data of such a TSO segment train will be dropped in a > single burst of loss... With proper AQM, and some (single segment) loss > earlier, cwnd may never grow to trigger TSO in that way, and the goodput (1 > segment out of 64kB data, vs. 58kB out of 64kB data) is obviously shifted > extremely to the scenario with AQM... Again, possibly, but not necessarily. If we have a constrained queue and are using tail drop, it is possible for a single burst sent to a full queue to be entirely lost. The question is, in the course of a file transfer, how many packets are lost. Before you make sweeping statements, I would strongly suggest that you mock up the situation and take a tcpdump. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
