RINA - scott whaps at the nanog hornets nest :-)
niels=nanog at bakker.net
Sat Nov 6 18:55:06 CDT 2010
* gbonser at seven.com (George Bonser) [Sun 07 Nov 2010, 00:30 CET]:
>Re: large MTU
>One place where this has the potential to greatly improve
>performance is in transfers of large amounts of data such as vendors
>supporting the downloading of movies, cloud storage vendors, and
>movement of other large content and streaming. The *first* step in
>being able to realize those gains is in removing the "low hanging
>fruit" of bottlenecks in that path. The lowest hanging fruit is the
>peering points. Changing those should introduce no "new" problems
>as the peering points aren't currently the source of MTU path
>discovery problems and increasing the MTU removes a discovery issue
>point, only reducing the MTU would create one.
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
>In transitioning from SONET to Ethernet, we are actually reducing
>potential performance by reducing the effective MTU from >4000 to <2000.
>So even increasing bandwidth is of no use if you are potentially
>reducing performance end to end by reducing the effective maximum MTU of
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.
I'm not even going to bother commenting on your research link from
production traffic in *1998*.
"It's amazing what people will do to get their name on the internet,
which is odd, because all you really need is a Blogspot account."
-- roy edroso, alicublog.blogspot.com
More information about the NANOG