From owner-freebsd-net Mon Aug 27 19:49:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id A27A037B406; Mon, 27 Aug 2001 19:49:31 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.4/8.11.4) with ESMTP id f7S2nOZ62047; Mon, 27 Aug 2001 22:49:24 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200108280249.f7S2nOZ62047@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Harkirat Singh Cc: Mike Silbersack , Dave Zarzycki , Alfred Perlstein , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: RFC: SACK/FACK patch port to Current References: In-reply-to: Your message of "Mon, 27 Aug 2001 18:04:40 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2001 22:49:24 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > I agree with your comment that FCAK is only a retransmission algorithm and > many papers recommends that FACK+SACK improves the performance for > long-delay network (for more information look at 1996 SIGCOMM paper). Most of the hair in a TCP implementation is "only" the retransmission algorithm. Having been a co-author of a TCP/IP stack 20 years ago, and been through the evolution of TCP with Van Jacobson's work, I cringe everytime I see yet another hack in the FreeBSD TCP. It's hard to get right, even when you know what effect you're trying to achieve. Consider that much of the work that resulted in slow-start and other other related work that Van did was accompanied by a considerable of before and after testing to measure the effect. I sure hope someone has done that testing and analysis of this code and the effect on the FreeBSD TCP implementation. I don't think that a drive-by commit of some other related work without a commitment to understand the code in a very deep way is wise. If you consider the dynamic range that the TCP retransmit timers need to operate over, it's a truly frighting thing, and folks ought not to be anxious screw with the implementation lightly. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message