From owner-freebsd-net Fri Jun 8 7:37:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id E76ED37B401 for ; Fri, 8 Jun 2001 07:37:16 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 93348 invoked by uid 1000); 8 Jun 2001 14:37:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 14:37:15 -0000 Date: Fri, 8 Jun 2001 09:37:15 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <3B20A02E.B1507A80@mindspring.com> Message-ID: <20010608080013.F93237-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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. Can anyone who's familiar with FreeBSD boxes which serve as routers confirm how route changes affect their cloned routes? > 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. I fail to see how basing a patch for FreeBSD on FreeBSD is a strike against it. If you have a new route table, please post information about it so that we can all see how it wll affect this patch and others. > 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... Why would changing ISN generation affect keepalive packets? I haven't changed how connection setup works whatsoever. > 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. This patch doesn't add per-connection state. The additional 16 bits added to the route structure were already present as unused space. > 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). Go read RFC 793, or this chunk of code from tcp_input.c: /* * If a new connection request is received * while in TIME_WAIT, drop the old connection * and start over if the sequence numbers * are above the previous ones. */ if (thflags & TH_SYN && tp->t_state == TCPS_TIME_WAIT && SEQ_GT(th->th_seq, tp->rcv_nxt)) { iss = tcp_next_isn(taop); tp = tcp_close(tp); goto findpcb; } I didn't create this behavior; it's been part of *BSD for a very long time. We must respect it, as we cannot change it now. > 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. Any package that depended on predictable sequence numbers would've broken twice in the last 9 months already. If there were any complaints at those times, they didn't appear on the lists, and didn't lead to the ISN generation being changed then. If you're in one of the above classes of people, I'd like to hear from you to better understand the issue; the NECP RFC draft didn't appear to have any information on this topic, as far as I could tell. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message