Date: Mon, 10 Nov 2003 13:45:48 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Andre Oppermann <oppermann@pipeline.ch> Cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review Message-ID: <20031110133307.R1101@odysseus.silby.com> In-Reply-To: <3FAF62BE.BEA1B3EE@pipeline.ch> References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> <3FAF62BE.BEA1B3EE@pipeline.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Nov 2003, Andre Oppermann wrote: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > > > This should help make synfloods with random source addresses less > > damaging. > > The cache will only be updated if the tcp connection is being closed. > All updates are done in tcp_drop. The T/TCP updates have to be done > inline during connection setup. I've converted all places which > updated the T/TCP rtmetrics in routing table with updates to the > hostcache. Good, that's exactly how it should work. > > Would it be possible to provide a way for netstat to view the host cache > > table? I think that it would be useful. > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > Syncache ain't visible via netstat either. So far you had to use > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > sure whether netstat is the right place for it. But I can do that > in a second step. Ok, that should be good enough for now. > The actually solves the problem. Let me explain in more detail. When > we get so many small packets per second the CPU will become pretty > saturated. Depending on how much data is sent it can go on for minutes > or hours. This code jumps in there and disconnects the within a second. > Of course someone can immediatly reconnect and do it again. But that > needs the 3WHS again and gives some delay. In the end this code is > like the ICMP rate limiter code. It there to migitate a problem to > manageable level, not to make it go away. Ok, so the problem is that the sockbuf chain keeps getting longer, causing the delay to grow as more fragments pile in... I see now. I drop my objection to it. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031110133307.R1101>