Date: Fri, 08 Jun 2001 02:51:42 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Silbersack <silby@silby.com> Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed Message-ID: <3B20A02E.B1507A80@mindspring.com> References: <20010608005234.W92206-200000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack wrote: > Q: How does this new patch generate sequence numbers? > > A: In short, the patch provides a seperate sequence number > space for each host. These sequence spaces have no > relation to the sequence spaces of other hosts, and > are re-randomized whenever a host becomes idle. > > Q: How is this done? > > A: We are able to store a 16-bit variable which corresponds > to the upper 16 bits of a host's sequence number in the > cloned route entry for that host, thanks to extra space > which exists in the routing metric structure. 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. 2) This doesn't work right 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. 4) Your claim of "extra space" comes because you are allocating these things with a cruddy allocator; some of us aren't wasting the same space in our kernel that the rest of you are, and don't intend for that practice to continue for the rest of you very much longer. 5) This blows up for keepalive packet sends, which use preallocated tcptemplate structures, which get a copy of the first header in when setting up a connection; check the keepalive sequence numbers using your new scheme... 6) This adds per-connection state, which is evil when you want a lot of connections: the way to get a lot of connections is to remove as much per-connection state as possible, which in turn reduces your per-connection resource costs, and that in turn increases the number of connections you are capable of sustaining with a constant set of resources. 7) The "monotonicity in TIME_WAIT" problem you mention is not really a problem. It is the 2*MSL value of 30 seconds and a tcp_timer that controls that; the sequence number is irrelevent (if you can prove your claim of "funky" in a bit more detail than simply calling it that, I would be willing to withdraw this objection; but I think the other six stand on ther own, still). I'm sure anyone with an "IP failover" or "IP takeover" product could probably come up with several other major objections; I don't know if anyone has implemented NECP sevices on FreeBSD, or "Direct Server Return" switch hacking of packets with Apache on FreeBSD cooperation, but I would be surprised if people who have would not also have objections. Is there any way you could do this using the ip/port pair as the means of preterbation instead? That might not be as aggregious, though I suspect it would still cause problems in two of the cases... even if it did get rid of the per-connection state information. -- Terry 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?3B20A02E.B1507A80>