From owner-freebsd-current@FreeBSD.ORG Tue Mar 9 10:14:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10F2D16A4CE; Tue, 9 Mar 2004 10:14:22 -0800 (PST) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC2F643D48; Tue, 9 Mar 2004 10:14:21 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id C7E4377A6D5; Tue, 9 Mar 2004 13:14:19 -0500 (EST) To: Mike Silbersack From: Mark Allman In-Reply-To: <20040309031549.L49735@odysseus.silby.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Wild Horses MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 09 Mar 2004 13:14:19 -0500 Sender: mallman@guns.icir.org Message-Id: <20040309181419.C7E4377A6D5@guns.icir.org> X-Mailman-Approved-At: Wed, 10 Mar 2004 05:23:59 -0800 cc: Andre Oppermann cc: freebsd-net@freebsd.org cc: David Malone cc: freebsd-current@freebsd.org Subject: Re: My planned work on networking stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2004 18:14:22 -0000 --=-=-= > 1. Internal structures are updated to handle SACK, and the stack handles > the receive side of SACK properly. (The stack advertises itself as SACK > capable, of course.) > > 2. The transmit side of SACK is implemented. > > >From what I recall about SACK, the implementation of part 1 would be > straightforward to verify and therefore easy to integrate. The send > side would, of course, require more attention, and it would be more > likely to get it if it could be reviewed seperately. I think this is a nicely methodical approach. Just being able to generate SACK blocks to the sender provides a good win for receivers. I am no kernel guru, but I don't actually imagine that it is all that tough because all the information you'd need has to be tracked now to make sure you deliver data to the application correctly. The way tougher part is that you need a new data structure (a scoreboard) to track the peer's status if you're going to do something intelligent (e.g., rfc3517) with the information you're being sent. And, you have to add hooks to update the scoreboard, consult it when sending, consult it when making congestion control decisions, etc. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFATgl7WyrrWs4yIs4RAmLLAJ4qYwF3XxdRjflDLcNtPYn8u5CD8gCeIp/+ tuT6TV4Jab2kL4qXVPIWp3U= =X6Bo -----END PGP SIGNATURE----- --=-=-=--