Date: Tue, 22 Jan 2013 16:12:56 -0500 From: John Baldwin <jhb@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Message-ID: <201301221612.57067.jhb@freebsd.org> In-Reply-To: <50FEF81C.1070002@mu.org> References: <201301221511.02496.jhb@freebsd.org> <50FEF81C.1070002@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, January 22, 2013 3:35:40 pm Alfred Perlstein wrote: > On 1/22/13 12:11 PM, John Baldwin wrote: > > As I mentioned in an earlier thread, I recently had to debug an issue we were > > seeing across a link with a high bandwidth-delay product (both high bandwidth > > and high RTT). Our specific use case was to use a TCP connection to reliably > > forward a latency-sensitive datagram stream across a WAN connection. We would > > often see spikes in the latency of individual datagrams. I eventually tracked > > this down to the connection entering slow start when it would transmit data > > after being idle. The data stream was quite bursty and would often attempt to > > transmit a burst of data after being idle for far longer than a retransmit > > timeout. > > > > In 7.x we had worked around this in the past by disabling RFC 3390 and jacking > > the slow start window size up via a sysctl. On 8.x this no longer worked. > > The solution I came up with was to add a new socket option to disable idle > > handling completely. That is, when an idle connection restarts with this new > > option enabled, it keeps its current congestion window and doesn't enter slow > > start. > > > > There are only a few cases where such an option is useful, but if anyone else > > thinks this might be useful I'd be happy to add the option to FreeBSD. > > This looks good, but it almost sounds like a bug for TCP to be doing > this anyhow. > > Why would one want this behavior? > > Wouldn't it make sense to keep the window large until there was a > problem rather than unconditionally chop it down? I almost think TCP is > afraid that you might wind up swapping out a 10gig interface for a > modem? I'm just not getting it. (probably simple oversight on my part). > > What do you think about also making this a sysctl for global on/off by > default? No, I think this is the proper default and RFC 5681 makes this a SHOULD. The burst at line rate argument is a very good one. Normally if you have a stream of data your data rate is clocked by the arrival of return ACKs (once you have filled the window), and slow starts keeps you throttled at the beginning from flooding the pipe. However, if your connection becomes idle then you will accumulate a large number of ACKs and be able to "spend" them all at once when you get a burst of data to send. This burst can then use a higher effective bandwidth than the normal flow of traffic and could overwhelm a switch. Also, for the cases where this is most useful (high RTT), it is not at all unimaginable for network conditions to change dramatically. In my use case we have dedicated lines and control what goes across them so we don't have to worry about that, but the general use case certainly needs to take that into account. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301221612.57067.jhb>