Date: Sat, 9 Jun 2001 13:29:06 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Mike Silbersack <silby@silby.com> Cc: Terry Lambert <tlambert2@mindspring.com>, freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed Message-ID: <20010609132906.C87114@sunbay.com> In-Reply-To: <20010608080013.F93237-100000@achilles.silby.com>; from silby@silby.com on Fri, Jun 08, 2001 at 09:37:15AM -0500 References: <3B20A02E.B1507A80@mindspring.com> <20010608080013.F93237-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 08, 2001 at 09:37:15AM -0500, Mike Silbersack wrote: > > On Fri, 8 Jun 2001, Terry Lambert wrote: > > > OK, I read the code. Not to poop the party, but off the top > > of my head, I have several major objections: > > > > 1) You stole the space reserved for the cache status > > flags; calling it 'tao_flags' would have been more > > honest. > > rmx_filler still has extra space in it, there's no problem fitting in > tao_flags when and if it becomes used. > > > 2) This doesn't work right for cloned routes. > > On the contrary, it only works for cloned routes. > > > 3) This blows up if you delete and re-add the default > > route, and the route in question is a clone of the > > default. > > Yes, this will cause the cloned route to get blown away, and the ISN > reset. This is only a minor issue, and can be ignored unless a host sees > frequent route changes. Even if the cloned route is blown away > frequently, this will simply cause the algorithm to revert to totally > random ISNs, which isn't the end of the world. > This still could be handled. When the parent (or even this particular) route is deleted, it is only deleted from the routing table and is marked as "down". TCP's PCB still holds on it. On the next socket write, ip_output() sees that the route is no longer "up", and reallocates the new route. tcp_output() could check that the cached route is still up before passing it to ip_output(), and reallocate the route preserving the old value of ISN (thus avoiding the re-randomization of the latter). Alternatively, ip_output() could probably do this. Just an untested idea. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010609132906.C87114>