RINA - scott whaps at the nanog hornets nest :-)

Sun Nov 7 00:21:06 UTC 2010

> 
> On the contrary.  You're proposing to fuck around with the one place
> on the whole Internet that has pretty clear and well adhered-to rules
> and expectations about MTU size supported by participants, and
> basically re-live the problems from MAE-East and other shared
> Ethernet/FDDI platforms with mismatching MTU sizes brought us during
> their existence.

Ok, there is another alternative.  Peering points could offer a 1500
byte vlan and a 9000 byte vlan one existing peering points and all new
ones be 9000 from the start.  Then there is no "fucking around" with
anything.  You show up to the new peering point, your MTU is 9000, you
are done.  No messing with anything.

Only SHORTENING MTUs in the middle causes PMTU problems.  Increasing
them does not.  And someone attempting to send frames larger than 1500
right now would see only a decrease in PMTU issues from such an increase
in MTU at the peering points, not an increase of issues.

> 
> These performance gains are minimal at best, and probably completely
> offset by the delays introduced by the packet loss that the probing
> will cause for any connection that doesn't live close to forever.

Huh?  You don't need to do probing.  You can simply operate in passive
mode.  Also, even if using active probing mode, the probing stops once
the MTU is discovered.  In passive mode there is no probing at all
unless you hit a black hole.

And the performance improvements I suppose are "minimal" if you consider
going from a maximum of 6.5Meg/sec for a transfer from LA to NY to 40Meg
for the same transfer to be "minimal"

>From one of the earlier linked documents:

(quote)
Let's take an example: New York to Los Angeles. Round Trip Time (rtt) is
about 40 msec, and let's say packet loss is 0.1% (0.001). With an MTU of
1500 bytes (MSS of 1460), TCP throughput will have an upper bound of
about 6.5 Mbps! And no, that is not a window size limitation, but rather
one based on TCP's ability to detect and recover from congestion (loss).
With 9000 byte frames, TCP throughput could reach about 40 Mbps.

Or let's look at that example in terms of packet loss rates. Same round
trip time, but let's say we want to achieve a throughput of 500 Mbps
(half a "gigabit"). To do that with 9000 byte frames, we would need a
packet loss rate of no more than 1x10^-5. With 1500 byte frames, the
required packet loss rate is down to 2.8x10^-7! While the jumbo frame is
only 6 times larger, it allows us the same throughput in the face of 36
times more packet loss.
(end quote)

So if you consider >5x performance boost to be "minimal" yeah, I guess.
Or being able to operate at todays transfer rates in the face of 36x
more packet loss to be "minimal" improvement, I suppose.