How to Quicken TCP Re-transmission?

[mag at intron.ac]

     Actually, TCP is a single sliding window protocol, which limits its
performance on seriously lossy and long delay transmission media.
     We assume that a sender has sent packets [A] [B] [C] [D] [E] while
the receiver has received packets [A] [C] [E]. With TCP the receiver can
only tell the sender that [A] has reached. If the receiver can notify
the sender that both [B] and [D] should be re-sent, the performance will
be better.
------------------------------------------------------------------------
                                                From Beijing, China

Mark Allman wrote:

> 
>> 1. Receiver should tell sender to re-send as soon as possible.
>>    (But TCP makes receiver purely passive)
> 
> This isn't really going to help you at all.  With SACK (especially, but
> even without it) the receiver isn't really in a whole lot better
> position than the sender to judge when a packet is actually lost.  Some
> people have worked on SNACKs (selective NEGATIVE acknowledgments), but
> my opinion is that the results (that I have seen) show them to be fairly
> equivalent to SACK in terms of performance.
> 
>> 2. Receiver should tell sender what is really necessary to re-send.
>>    (Sometimes only a single ACK number of TCP cannot include enough
>>     information)
> 
> RFC2018.  (Which provides more than a single ACK number.  But, this
> doesn't make the receiver tell the sender what to resend.  The logic
> still resides at the sender.)
> 
> allman
> 
> 
>