On Mon, Mar 08, 2004 at 10:24:31AM -0800, Kevin Oberman wrote: > > Date: Sun, 07 Mar 2004 23:50:11 +0100 > > From: Andre Oppermann <[EMAIL PROTECTED]> > > Sender: [EMAIL PROTECTED] > > > > David Malone wrote: > > > > > > On Mon, Mar 01, 2004 at 11:18:34PM +0100, Andre Oppermann wrote: > > > > [] automatically sizing TCP send buffers to achieve optimal performance > > > > over a wide range of bw*delay situations. (in progress) > > > > > > Hi Andre, > > > > > > This reminded me - do you know what happened to the plan to implement > > > SACK for FreeBSD? I'm working with a research group that's interested > > > in new high speed TCP techniques and they'd prefer to work with > > > FreeBSD, but they've been using Linux 'cos they need SACK. They > > > might actually be interested in spending some time implementing it, > > > if we weren't going to be clashing with anytone else. > > > > I don't know of any current project or effort to implement SACK on > > FreeBSD. It is not on my todo list and it doesn't fit there. But > > I'm available if someone wants to discuss specifics and implementation > > details. > > I know that our organization would love to see SACK. Much of the > high-performance network development that used to be on FreeBSD has > moved to Linux simply because SACK is essential. You can't run > trans-oceanic TCP streams of gigabit or more throughput without it. > > Unfortunately, SACK is often looked upon as a waste of effort to those > who use nets in more commercial forms where aggregation of lots of small > streams is how fat pipes are used. Research big science are about the > only ones who have a real need for this kind of performance and it's > growing fast. Without SACK, FreeBSD will be a non-starter for these > purposes.
I've got a co-worker who is part of a research group at ISI that is doing research on long fat pipes with large streams. They are intrested in doing a SACK implementation. I hope to have some more information later this week. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp00000.pgp
Description: PGP signature
