From owner-freebsd-net@FreeBSD.ORG Tue May 23 18:55:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDCE916A835 for ; Tue, 23 May 2006 18:55:38 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C81DE43D48 for ; Tue, 23 May 2006 18:55:37 +0000 (GMT) (envelope-from nitro@263.net) Received: from intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with SMTP id 75468F144A for ; Wed, 24 May 2006 02:55:36 +0800 (CST) X-KSVirus-check: 0 References: <20060523182130.D7EBC416C50@lawyers.icir.org> In-Reply-To: <20060523182130.D7EBC416C50@lawyers.icir.org> From: mag@intron.ac To: mallman@icir.org Date: Wed, 24 May 2006 02:52:44 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20060523185536.75468F144A@smtp.263.net> Cc: freebsd-net@freebsd.org, Marcin Jessa Subject: Re: How to Quicken TCP Re-transmission? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2006 18:55:38 -0000 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 > > >