Date: Tue, 22 Jan 2013 22:37:49 +0100 From: Andre Oppermann <oppermann@networx.ch> To: Alfred Perlstein <bright@mu.org> Cc: John Baldwin <jhb@freebsd.org>, net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Message-ID: <50FF06AD.402@networx.ch> 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 22.01.2013 21:35, 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. It's not a bug. It's by design. It's required by the RFC. > Why would one want this behavior? Network conditions change all the time. Traffic and congestion comes and goes. Connections can go idle for milliseconds to minutes to hours. Whenever "enough" time has passed network capacity probing has to start anew. > 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). The very real fear is congestion meltdown. That is the reason we ended up with TCP's AIMD mechanism in the first place. If everybody were to blast into the network anyone will suffer. The bufferbloat issue identified recently makes things even worse. > What do you think about also making this a sysctl for global on/off by default? Please don't. The correct fix is either a) to use the initial window as the restart window (up to 10 MSS nowadays); b) to use a decay mechanism based on the time since the last network condition probe. Even the latter must decay to initCWND within at most 1MSL. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50FF06AD.402>