This is an issue that would be helped by good ECN and new sender code,
if the sender then could assume lack of ECN implies error loss -- thus
keep sending with no backoff. In simple loss cases on normal WANs, <1%
loss gives >20% slowdown in typical, current TCP throughput.
Alex
Jamshid Mahdavi wrote:
>
> "ketan bajaj" <[email protected]> writes:
>
> > Still we don't have a protocol which is completely transparent and preserves
> > all existing semantics of tcp.
> > 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.
>
> In the absense of explicit information, the sender *must* assume that
> a lost packet is an indication of congestion. You can't change this
> aspect of TCP, although you could try to find a way to let the sender
> know that a particular packet loss was due to corruption rather than
> congestion.
>
> Alas, I think this is probably not the only cause of poor TCP
> performance over satellite...
>
> --J
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:55 EST