Date: Wed, 12 Nov 2003 14:55:29 -0500 From: Haesu <haesu@towardex.com> To: Andre Oppermann <oppermann@pipeline.ch>, freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review Message-ID: <20031112195529.GA48020@scylla.towardex.com> In-Reply-To: <3FB20D2B.73624906@pipeline.ch> References: <20031112024507.89398.qmail@web10007.mail.yahoo.com> <3FB20D2B.73624906@pipeline.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031112195529.GA48020>