[e2e] 10% packet loss stops TCP flow

[Christian Huitema]

> There've been a lot of people asking the question whether TCP can
> eliminate the value of link level protocols as optimizations.

This was hotly debated in the early 80's, part of the X.25 vs. TCP-IP
debate, and a few more.

The key variable is the number of bits in transit on the flow being
controlled. This variable conditions the amount of memory required at
each control point for retransmission and reordering buffers. The
product of this variable by the loss rate is the "average number of
errors in transit", and it conditions whether simple protocols can be
used (e.g. go-back-N), or whether more sophisticated algorithms are
required (e.g. selective ACK). The average number of error in transit
also conditions the average retransmission delay (go-back-N) or the
average reordering delay (selective ACK).

The number of bits in transit is the product of the data rate by the
transmission delays. If there was single flow in transit, hop-by-hop
control would be more efficient than end-to-end, since the end-to-end
delay is the sum of the link delay. However, there are usually multiple
flows in transit, and the data-rate per end-to-end flow can be much less
than the link data rate. As a rule of thumb, if the number of flows per
hop exceeds the number of hops per flow, the bandwidth-delay product per
average end-to-end flow will be less than the bandwidth-delay product
per average link, and end-to-end control will result in better
performance.

-- Christian Huitema