From owner-freebsd-net@FreeBSD.ORG Tue May 23 18:22:33 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 BFCCC16A55D for ; Tue, 23 May 2006 18:22:32 +0000 (UTC) (envelope-from mallman@icir.org) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F98943D5D for ; Tue, 23 May 2006 18:22:31 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k4NIMU8h040805; Tue, 23 May 2006 11:22:30 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 377FA77AC21; Tue, 23 May 2006 14:22:29 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D7EBC416C50; Tue, 23 May 2006 14:21:30 -0400 (EDT) To: mag@intron.ac From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Bad to the Bone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 23 May 2006 14:21:30 -0400 Sender: mallman@icir.org Message-Id: <20060523182130.D7EBC416C50@lawyers.icir.org> 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 Reply-To: mallman@icir.org 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:22:36 -0000 --=_bOundary Content-Type: text/plain Content-Disposition: inline > 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 --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEc1KqWyrrWs4yIs4RAng+AJ4mZ60q1p3C3x2DL3XFq1ozd+/WWACfbjfc sYUaTG9wJy+H3OegzC1YDIE= =6fQd -----END PGP SIGNATURE----- --=_bOundary--