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

George Bonser gbonser at seven.com
Sat Nov 6 23:30:31 UTC 2010


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.

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.

In that diagram on Phil Dykstra's page linked to earlier, even though
the number of packets on that OC3 backbone were mostly (by a large
margin) le 1500 bytes, the majority of the TRAFFIC was carried by
packets ge 1500 bytes.

http://sd.wareonearth.com/~phil/pktsize_hist.gif

" The above graph is from a study[1] of traffic on the InternetMCI
backbone in 1998. It shows the distribution of packet sizes flowing over
a particular backbone OC3 link. There is clearly a wall at 1500 bytes
(the ethernet limit), but there is also traffic up to the 4000 byte FDDI
MTU. But here is a more surprising fact: while the number of packets
larger than 1500 bytes appears small, more than 50% of the bytes were
carried by such packets because of their larger size."

[1] the nature of the beast: recent traffic measurements from an
Internet backbone
http://www.caida.org/outreach/papers/1998/Inet98/






More information about the NANOG mailing list