Subject: [Int-area] Quick MTU measurements

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Dec 2014 15:58:13 +0100

Hi all,

We had some discussions on MTU issues on the v6ops list, which prompted me to do some quick measurements, please see:

Maximum packet sizes on the internet 
http://www.bgpexpert.com/article.php?article=151

Internet packet sizes part 2: IPv4 path MTU discovery is dead
http://www.bgpexpert.com/article.php?article=152

Quick summary: all IPv6 hosts and 99.7% of IPv4 hosts advertise they can handle at least 1280 bytes in their TCP MSS and about 65% can handle 1500.

In almost a week, I didn't get a single IPv4 too big, so it seems that in practice, IPv4 PMTUD is no longer used. (Please confirm with a larger dataset before taking any actions based on this!) However, depending on PMTUD doesn't lead to obvious problems with IPv6.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Dec 2014 16:02:33 +0100

On 18 Dec 2014, at 15:58, Iljitsch van Beijnum <[email-masked]> wrote:
> 
> However, depending on PMTUD doesn't lead to obvious problems with IPv6.

I’m not sure I parse this correctly, but I can attest that, in many cases, PMTUD most certainly does *not* work with IPv6 as deployed today.

Grüße, Carsten

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Dec 2014 16:10:25 +0100

On 18 Dec 2014, at 16:02, Carsten Bormann <[email-masked]> wrote:

> I can attest that, in many cases, PMTUD most certainly does *not* work with IPv6 as deployed today.

My computers at home have an MTU of 1500 but I use a tunnel with a 1480 MTU. I'm not having obvious problems. Maybe two or three times a week some page won't load, but 99% of the time reloading fixes this. IPv6 PMTUD black hole? I have no idea. But _if_ I'm having IPv6 PMTUD issues, those are it.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Dec 2014 16:22:16 +0100

> On 18 Dec 2014, at 16:10, Iljitsch van Beijnum <[email-masked]> wrote:
> 
> My computers at home have an MTU of 1500 but I use a tunnel with a 1480 MTU. I'm not having obvious problems. Maybe two or three times a week some page won't load, but 99% of the time reloading fixes this.

I have seen many pages persistently not loading on v6 enabled networks.  E.g., from wikipedia or ietf.org.
Going to IPv4 only or setting the MTU to 1400 fixes this.

(Germany is quite far along with deploying v6, so that may be one reason I’m seeing this more often.)

> IPv6 PMTUD black hole? I have no idea. But _if_ I'm having IPv6 PMTUD issues, those are it.

Yes, most likely.

It seems to me that best practice for an IPv6 content provider is to set their MTU to ~ 1400.
This clips off most of the problem (tunnels rarely dip under 1400).

Grüße, Carsten

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Dec 2014 16:42:49 +0100

> I have seen many pages persistently not loading on v6 enabled networks.  E.g., from wikipedia or ietf.org.

I've not seen that. Both of those send me 1480-byte IPv6 packets even though my MSS is 1440 (= 1500).

Are you sure too bigs are generated properly and not filtered at your end?

> It seems to me that best practice for an IPv6 content provider is to set their MTU to ~ 1400.

That is a terrible practice, as we now can't move to bigger packet sizes and also everyone comes up with their own limit so now there's really no telling what's going to work and what isn't.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Dec 2014 16:49:47 +0100

> Are you sure too bigs are generated properly and not filtered at your end?

Oh, I’m terribly sure they are filtered somewhere.  I even had a ticket with IETF staff finding where they are lost.
We found some problem in an AT&T segment of the path at the time, but diagnosing this wasn’t high enough on the list, so we never pinpointed the exact location.

> That is a terrible practice,

Yes.
It also works rather well.

As long as nobody switches on PLPMTUD (RFC 4821), I don’t see a real alternative.
(And if you want to unpaint us out of the 1400 corner, switching that on is the obvious way.)

Grüße, Carsten

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Dec 2014 16:14:53 +0000

Hi,

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: Thursday, December 18, 2014 7:50 AM
> To: Iljitsch van Beijnum
> Cc: [email-masked]
> Subject: Re: [Int-area] Quick MTU measurements
> 

This is an example of MTU clamping in practice. Once the MTU is clamped,
it is very hard to unclamp it at a later time. Then, there is no path forward
for larger packet sizes.

> (And if you want to unpaint us out of the 1400 corner, switching that on is the obvious way.)

Right, we will want to have MTU diversity and the ability to use larger
packet sizes. RFC4821 or something very much like it is the way forward.

Thanks - Fred
[email-masked]

> Grüße, Carsten
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Dec 2014 08:21:27 +1300

> It also works rather well.

Not if the path is actually limited to 1280 by a tunnel, which is
far from uncommon. In any case, my experience a few years ago was that
the problem was not MTU detection but failure of MSS negotiation;
the server refused to drop its MSS below 1440.

So then, the terrible practice turns out to be for the server to set
their MTU to 1280.

    Brian