Date: Wed, 24 May 2006 02:52:44 +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: <20060523185536.75468F144A@smtp.263.net> In-Reply-To: <20060523182130.D7EBC416C50@lawyers.icir.org> References: <20060523182130.D7EBC416C50@lawyers.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you for your reminder. Actually, I understand you and
RFC 2018. What I really concern is how wide support (and being enabled
by default) SACK has obtained. For we do not always transfer data
between hosts running FreeBSD and maintained by network expert.
------------------------------------------------------------------------
From Beijing, China
Mark Allman wrote:
>
>> 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.
>
> One more time: see RFC2018.
>
> If you actually take a look at that you will see that it provides a way
> for the receiver to indicate that it has received all packets through
> [A] (via the cumulative acknowledgment field) and also that it has
> received [C] and [E] (using selective acknowledgments). (Knowing that
> [C] and [E] have arrived is basically the same as knowing that [B] and
> [D] didn't.)
>
> allman
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060523185536.75468F144A>