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

Sat Nov 6 23:55:06 UTC 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 
their existence.

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

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

	-- Niels.

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