From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 12:51:58 2003 Return-Path: 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 5B8F716A545 for ; Tue, 21 Oct 2003 12:51:58 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90B5A43FBD for ; Tue, 21 Oct 2003 12:51:57 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.3) with ESMTP id h9LJpvsd057227; Tue, 21 Oct 2003 12:51:57 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id h9LJpvSX057226; Tue, 21 Oct 2003 12:51:57 -0700 (PDT) (envelope-from rizzo) Date: Tue, 21 Oct 2003 12:51:56 -0700 From: Luigi Rizzo To: Garrett Wollman Message-ID: <20031021125156.B50248@xorpc.icir.org> References: <20031021140013.47D17C6C538@guns.icir.org> <200310211904.h9LJ4BlP033154@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310211904.h9LJ4BlP033154@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Oct 21, 2003 at 03:04:11PM -0400 cc: freebsd-net@freebsd.org cc: mallman@icir.org Subject: Re: SACK? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Oct 2003 19:51:58 -0000 On Tue, Oct 21, 2003 at 03:04:11PM -0400, Garrett Wollman wrote: > < said: > > > Are there any plans to incorporate SACK in FreeBSD? > > We plan to add SACK to FreeBSD whan a compatible implementation is > available. in my book this reads as "we have no plans" :) And to follow up on the topic, since i wrote one implementation long ago -- my code was probably largely incomplete in the handling of retransmission, also because it predates a lot of research onand RFC's on the topic. I know of another implementation, whose author i forget, which Jitu Padhye tested briefly with tbit -- however that one seemed to process SACK correctly but broke the non-sack case. My strong feeling is that before adding SACK one should do: 1. a bit of refactoring of the TCP code so that some indecently long functions are split in more manageable chunks (e.g. tcp_input() is ~2000 lines now) and there is less overload in state variables so that changes do not risk to break everything. 2. restructure the buffer management so that ack and data processing does not require O(window_size) time as it does now (with very large windows this kills you). Once this is done, probably there is a point in adding SACK. cheers luigi