Date: Tue, 02 Mar 2004 14:56:28 +0100 From: Andre Oppermann <andre@freebsd.org> To: Wes Peters <wes@softweyr.com> Cc: freebsd-current@freebsd.org Subject: Re: My planned work on networking stack Message-ID: <4044928C.AF49FD38@freebsd.org> References: <4043B6BA.B847F081@freebsd.org> <200403011507.52238.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wes Peters wrote: > > > [] automatically sizing TCP send buffers to achieve optimal performance > > over a wide range of bw*delay situations. (in progress) > > What a wonderful idea. Can't wait for the bikesheds... What bikesheds? > > [] establish a testbed for testing and qualification of TCP performance > > and optimizations over a wide range of network conditions (types, > > speeds, packet loss ratios, out of order, etc). (started) > > Be sure to coordinate with the donations officer for help in getting > equipment you may need. My plan is to do it with a couple of boxes and dummynet. The harder part is not to make the setup but to figure out what network conditions to simulate and how often they happen. If you have any traffic generators spare I'd be interested surely. ;-) > > [] move IPv4 routing to its own optimized routing table structure and > > add multi-path and policy-routing options. (planned) > > Will the table code in PF be helpful in this area? They seem to have > developed a reasonably small notation for CIDR-type address ranges and code > that does best-fit matching. Maybe. I'll evaluate the various available implementations and research in that area when I get to it. However the multi-path and policy-routing stuff will be part of the routing engine and not any of the firewalling systems. They may have an option to tag a packet with a certain policy to override the routing system. > > [] other stuff that I happen to stumble over... ;-) > > Wowsers. I can't wait to hear more. When do you expect to have a design > for the ARP stuff and TCP buffer sizing, since they are underway? The ARP stuff is pretty simple and is a hash list IP->MAC per ethernet (actually 802.1) broadcast domain. The harder part is to move all the code to one place from it's various net/* and netinet/* files. As a nice side effect we get per-MAC accounting (octets, frames) for free. TCP buffer sizing involves mainly two areas. One is good RTT measurements to be able to estimate the bw*delay product well and the other is information about memory (mbuf) usage in the networking system to do the right thing if memory gets low. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4044928C.AF49FD38>