Date: Fri, 22 Nov 2002 11:11:57 -0800 (PST) From: Nate Lawson <nate@root.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: hackers@freebsd.org Subject: Re: Changing socket buffer timeout to a u_long? Message-ID: <Pine.BSF.4.21.0211221057170.71270-100000@root.org> In-Reply-To: <3DDD83CA.4A910E59@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Nov 2002, Terry Lambert wrote: > Nate Lawson wrote: > > On Thu, 21 Nov 2002, Terry Lambert wrote: > > > FWIW: upping the roll-over rate is not a good reason to increase > > > the size of fields, unless you want to increase the TCP sequence > > > number filed to 64 bits? ...it has exactly the same issues at > > > high data rates. > > > > That's what the timestamp option does and I think it was a good idea, > > given the range of systems TCP needs to work well on. > > Setting your HZ to 100,000 instead of 100, and then complaining > because a timer field with a resolution specified in ticks instead > of an interval length can't handle a value which is way to large > for a fast transport seems a bit silly to me. That's not what I was saying. I was addressing a particular point he raised -- questioning whether the sequence number of TCP should be increased to 64 bits due to rollover. I pointed out that it already has two modes: 32 bit sequence or 64 bit TS/sequence combo. The nice thing about the latter being an option is that it allows the implementer to choose which they want to support. In an embedded app, I'm not going to do 64 bit math, hence it is good that this is an option, not an automatic increase to 64 bits for the sequence field across the board. I agree that timers should be interval based, not counters that are dependent on a variable system event clock. But I was not saying anything about that in the previous message. > PS: Adding *any* TCP options is bad karma, for networking equipment; > the cost in terms of in transit overhead is immense, if you are > trying to use the code later to build a switch or a load balancer. > Doing that sort of thing is fine -- as long as you know beforehand > that what you are doing is making the code less general purpose, > and everyone buys into that idea. As a member of the e2e camp, I'd say that any device which is looking at sequence space is implicitly an endpoint and has to accept the processing limitations as such. MITM devices (load balancers, firewalls, etc.) are IMO a poor workaround for the fact that most endpoints have a closed OS with weak software management tools. Every endpoint should have MAC capability with per-application filters on network traffic and single system image features for load balancing. Add in robust management tools and you get all the features of network devices without MITM. This is the direction I hope FreeBSD continues in. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211221057170.71270-100000>