From owner-freebsd-net@FreeBSD.ORG Tue May 23 18:14:23 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 700C516A770 for ; Tue, 23 May 2006 18:14:23 +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 74A8C43D53 for ; Tue, 23 May 2006 18:14:21 +0000 (GMT) (envelope-from nitro@263.net) Received: from intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with SMTP id DB5DDF1056 for ; Wed, 24 May 2006 02:14:19 +0800 (CST) X-KSVirus-check: 0 References: <20060523130745.94E5D41696D@lawyers.icir.org> In-Reply-To: <20060523130745.94E5D41696D@lawyers.icir.org> From: mag@intron.ac To: mallman@icir.org Date: Wed, 24 May 2006 02:06:20 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20060523181419.DB5DDF1056@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:14:23 -0000 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 > > >