tcp_mtu_probing on by default?
mathieu.tl at gmail.com
Tue Feb 7 14:40:28 UTC 2012
On Mon, Feb 6, 2012 at 6:15 PM, Martin Pool <mbp at canonical.com> wrote:
> I have helped a few people recently who were having path MTU discovery
> problems, causing bulk TCP transfers to hang quasi-intermittently.
> Once you know the likely cause it's fairly easy but it's a fairly
> annoying problem for someone who doesn't recognize it.
> There is a kernel sysctl "sudo sysctl -w net.ipv4.tcp_mtu_probing=1"
> that seems fairly effective at detecting when the problem is occurring
> and automatically fixing it. This implements RFC 4821. It is off by
> default in the kernel. I haven't seen any reports of problems caused
> by turning it on, but there may be some.
> I wonder if Ubuntu should turn it on in /etc/sysctl.d?
Admittedly I haven't really looked much into this and whether it's
likely to cause issues in some environments, but setting it to 1
indeed seems relatively safe.
0 - Disabled
** 1 - Disabled by default, enabled when an ICMP black hole detected
2 - Always enabled, use initial MSS of tcp_base_mss.
This s hould help those network paths for which fragmentation is
required.On the other hand, enabling this will cause more
retransmissions of segments in this case, which would mean an increase
in traffic. I don't think it's likely to be huge, but just something
to keep in mind.
The question would be how many people would benefit from this change?
I'd be tempted to say it probably doesn't affect all that many people
in general. If you've found a lot of people who had this issue, maybe
it's worth also trying to figure out if they have the same ISP, if
they try to connect to the same place, etc. in case it's an issue
outside their network.
Mathieu Trudel-Lapierre <mathieu.tl at gmail.com>
Freenode: cyphermox, Jabber: mathieu.tl at gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93
More information about the Ubuntu-devel-discuss