tcp_mtu_probing on by default?

[Martin Pool]

On 8 February 2012 02:01, Stéphane Graber <stgraber at ubuntu.com> wrote:
> On 02/07/2012 09:40 AM, Mathieu Trudel-Lapierre wrote:

>> The question would be how many people would benefit from this change?

It's hard to measure.  I have seen that it fixed problems for several
people having trouble with Ubuntu or having trouble talking to
Launchpad.  I think they often suspect it is a problem with Ubuntu
generically or with Launchpad (or whatever site) rather than with the
network.  I can't guess the prevalance; I would guess around 1% of
users hit it from time to time.

>> 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.

They're not people I know personally, they're asking on the net, and I
doubt they have the same ISP.  One person (a Canonical engineer)
yesterday was having this problem when connected from a hotel.  There
would be little payoff in him trying to explain the problem to the
hotel, even if in a sense it's their ISP's fault.

> I'm surprised this is actually still a problem for IPv4, mtu
> discovery/probing is a very important part of IPv6 (where it's enabled by
> default). Anyone actually requiring this with IPv4 has something seriously
> broken in their or their ISP's network. Typically a sign that ICMP is
> blocked somewhere.

Yes, over aggressive blocking of ICMP is the normal cause.  (Windows
calls this feature 'ICMP black hole detection'.)

There are a lot of misconfigured systems in the world.  I don't think
that eg hotel networks would care much about IPv6 correctness yet when
they mangle IPv4, DNS and HTTP so badly today.

> However, looking at the above description from Matt, setting the value to 1
> doesn't seem too risky. Though if we choose to do it, I'd suggest we do it
> as early as possible and carefully look for bugs.
> I'm guessing these bugs will be equally as difficult to find and debug as
> these that triggered this discussion.

-- 
Martin