Date: Wed, 24 May 2006 02:06:20 +0800 From: mag@intron.ac To: mallman@icir.org Cc: freebsd-net@freebsd.org, Marcin Jessa <lists@yazzy.org> Subject: Re: How to Quicken TCP Re-transmission? Message-ID: <20060523181419.DB5DDF1056@smtp.263.net> In-Reply-To: <20060523130745.94E5D41696D@lawyers.icir.org> References: <20060523130745.94E5D41696D@lawyers.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060523181419.DB5DDF1056>