tcp hostcache and ip fastforward for review

[Haesu]

I agree in that flow cache is bad and it should not be used.
It only takes x num. of kpps with diverse destinations to knock off a router running flow based caching.

Extreme switches use flow based caching (called ipfdb) and any DoS attack that uses
diverse destinations will kill it pretty quickly..

-hc

-- 
Haesu C.
TowardEX Technologies, Inc.
Consulting, colocation, web hosting, network design and implementation
http://www.towardex.com | haesu at towardex.com
Cell: (978)394-2867     | Office: (978)263-3399 Ext. 170
Fax: (978)263-0033      | POC: HAESU-ARIN

On Wed, Nov 12, 2003 at 11:36:27AM +0100, Andre Oppermann wrote:
> popsong old wrote:
> > 
> > --- Andre Oppermann <oppermann at pipeline.ch> wrote:
> > > > BTW, we'll get even better performance if we keep both
> > > > interfaces' MAC addresses in cache (and call
> > > > ifp->if_start directly). This requires to keep
> > > > ethernet header in mbuf untouched and is only relevant
> > > > in ethernet though. I implemented such layer 2 cache
> > > > in a local version of IPFilter and got some good
> > > > results.
> > >
> > > I don't understand why you want to do that unless you
> > > are doing bridging. We have to look up the mac address
> > > of the next hop anyway. If that is not already in the
> > > routing table it needs to do a arp lookup.
> > >
> > > --
> > > Andre
> > 
> > Ah, my fault. I didn't read your patch carefully and assumed that ip
> > fastforward do flow caching as ip_flow does. However, I think ip flow
> > caching is a good thing and maybe implementing it in ip fastforward is
> > a good idea.
> 
> Please explain why flowcaching is good. Cisco did away with it
> quite some time ago because it didn't scale at all. Plus it is
> very complex in the context of the BSD network stack.
> 
> For IP fastforward we look at one thing, that is the destination IP
> address. In a flow cache we need look at the destination IP address
> and the destination host. Then we have to make a hash based cache
> of size n. Problem number one: Is it really faster to look into the
> hash table than the routing table? Problem number two: Is there any
> caching effect at all in the hash table? Answer number one: No, it
> is not faster on today's hardware. And if we don't find it in the
> hash table we have to do the routing table lookup anyway. Answer
> number two: Unless you have only a couple of flows the hit rate is
> very low. If you have a couple of flows only then the routing table
> stays in L1/2 cache of the CPU anyway as does the routing table. No
> gain there. With too many flows you simply start thrashing the hash
> table for no benefit.
> 
> -- 
> Andre
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"