[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The IPv4 Internet MTU
Hi,
Rémi Denis-Courmont <rdenis@simphalempin.com> writes:
> Le Monday 24 September 2007 11:57:00 Arnaud Ebalard, vous avez écrit:
>> At the moment, my conclusion is that you have 2 solutions to
>> solve the issue:
>>
>> 1) setting up a relay at the edge of the site with a higher MTU value
>> and statically configure clients
>> 2) setting up a relay at the edge of the site _and_ a server that the
>> clients will use to acquire an higher MTU from.
>
> After some more not-so-long thinking, what about:
> 3) get rough consensus that there are no paths on the IPv4 Internet with a MTU
> larger or equal to 1308 bytes (the current "outer" Teredo MTU), but smaller
> than 1348 bytes (or any slightly bigger value)? Then, it is safe to update
> everything to a bigger inner MTU of 1320 bytes (or more); it will not cause
> any extra on-path fragmentation. In fact, it will even diminish the
> overhead.
What would be the precise drawbacks of setting the MTU for Teredo to
1472 (1500 - teredo overhead) or something just below that (to deal with
common other encapsulation on the path, which will most of the time
appear at both ends, like with PPPoE or similar things)?
If the bet is fair, there would only be a limited amount of
fragmentation while still providing clients with a better initial MTU
(more efficient and with more potential).
I won't say that what i described in my previous email (Tunnel mode
IPsec over Teredo) is the worst case scenario in term of MTU usage by a
client but it's a good starting point of the kind of MTU everyone would
be happy to consider as available on the IPv4 Internet. Let's call that
value A. Just for the discussion, let's set it to 1408 (1280 + 60 + 40 +
20 + 8, 60 is some reasonable value for ESP).
Then, taking the problem in the reverse direction, by temporarily
considering an initial MTU of 1500 for the path and removing the kind of
encapsulation that the network can "consume" (PPPoE, IPsec in tunnel
mode (IPv4 for outer header), ..., ?) we could get a value B. Again, for
the discussion, with both PPPoE and IPsec in tunnel mode, we can
probably consider 1412 (1500 - 60 - 20 - 8) as an initial value.
Now, it seems to me that considering sth in [A,B] is simply making a
reasonable bet that this value of IPv4 MTU should work on all pathes in
the IPv4 Internet and with all kinds of encapsulations at the
client. Here, something in [1408, 1412].
This silly idea gets me to a default MTU for Teredo interfaces in [1380,
1384]. I know it looks like cooking but it seems a fair bet and it
provides in default cases almost a 10% boost of TCP MSS value for Teredo
clients without obvious drawbacks.
Comments welcome. Errors correction too.
> So my naive question of the day is:
> Does anyone have any practical case for an IPv4 path MTU within
> [1308;1348[ ?
or [1308, 1410[ ? ;-)
Regards,
a+