Re: My planned work on networking stack

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