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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
