Check out the new USENIX Web site. next up previous
Next: Putting it all together Up: Loss deduction algorithm Previous: Forward loss

Reverse Loss

Deriving the loss rate in the reverse direction, from target to source, is somewhat more problematic. While the source host can count the number of acknowledgments it receives, it is difficult to be certain how many acknowledgments were sent. The ideal condition, which we refer to as ack parity is that the target sends a single acknowledgment for every data packet it receives. Unfortunately, most TCP implementations use a delayed acknowledgment scheme that does not provide this guarantee. In these implementations, the receiver of a data packet does not respond immediately, but instead waits for an additional packet in the hopes that the cost of sending an acknowledgment can be amortized [Bra89]. If a second packet has not arrived within some small timeout (the standard limits this delay to 500ms, but 100-200ms is a common value) then the receiver will issue an acknowledgment. If a second packet does arrive before the timeout, then the receiver will issue an acknowledgment immediately. Consequently, the source host cannot reliably differentiate between acknowledgments that are lost and those which are simply suppressed by this mechanism.

An obvious method for guaranteeing ack parity is to to insert a long delay after each data packet sent. This will ensure that a second data packet never arrives before the delayed ack timer forces an acknowledgment to be sent. If the delay is long enough, then this approach is quite robust. However, the same delay limits the technique to measuring packet losses over long time scales. If we wish to investigate shorter time scales, or the correlation between the sending rate and observed losses, then this mechanism is insufficient. We will discuss alternative mechanisms for enforcing ack parity in section  4.


next up previous
Next: Putting it all together Up: Loss deduction algorithm Previous: Forward loss
Stefan Savage
8/31/1999