On Mon, 26 Jul 1999, William D Ivancic wrote:
> >.....What i'm trying to say is why not attack the real problem. The root
> >cause for tcp's poor performace over satellite channels is that it fast
> >retransmits on receiving 3 duplicate acks (reducing its window), and as
> >the delay*bandwidth product over a satellite channel is large, the no. of
> >data packets in the end-to-end pipe are large, so a loss due to corruption,
> >results in a number of duplicates acks being generated, moving the
> >sender tcp to fast retranmission, and thus poor performance.
> >
> >ketan
>
> We can always engineer the optimum solution for a particular problem.
> However, TCP is a compromise that works in nearly all environments and
> works very well in many of those environments.
TCP is a compromise that works well in human-scale environments. At
the small end of the bandwidth*delay product, it's way too much
overhead for parallel processing. At the large end, it's too chatty
for deep space communications with half-hour or more propagation
delays.
If you're going to attack the real problem, make sure you identify it
as lack of SACK implementation first (RFC2581/2582/2018), because use
of SACK by both ends alters the response to corruption and decreases
the number of retransmits.
L.
<[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:55 EST