<br><font size=2 face="sans-serif">Large MTUs enable significant throughput
performance enhancements for large data transfers over long round-trip
times (RTTs.) The original question had to do with local subnet to local
subnet where the difference would not be noticable. But for users transferring
large data sets over long distances  (e.g. LHC experimental data from
CERN in France to universities in the US) large MTUs can make a big difference.</font>
<br>
<br><font size=2 face="sans-serif">For an excellent and detailed (though
becoming dated) examination of this see:</font>
<br>
<br><font size=2 face="sans-serif">"Raising the Internet MTU"
Matt Mathis, et. al. </font>
<br>
<br><font size=2 face="sans-serif">http://www.psc.edu/~mathis/MTU/<br>
<br>
Joe<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Stephen Wilcox <steve@telecomplete.co.uk></b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-nanog@merit.edu</font>
<p><font size=1 face="sans-serif">04/12/2007 01:45 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Keegan.Holley@sungard.com</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">NANOG list <nanog@merit.edu></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: Thoughts on increasing MTUs on the
internet</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
On Thu, Apr 12, 2007 at 11:34:43AM -0400, Keegan.Holley@sungard.com wrote:<br>
> <br>
>    I think it's a great idea operationally, less work for
the routers and more<br>
>    efficient use of bandwidth.   It would also be useful
to devise some way to<br>
>    at least partially reassemble fragmented frames at links
capable of large<br>
>    MTU's.  <br>
<br>
I think you underestimate the memory and cpu required on large links to
be able to buffer the data that would allow a reassembly by an intermediate
router<br>
<br>
>    Since most PC's are on a subnet with a MTU of 1500 (or
1519) packets<br>
>    would still be limited to 1500B or fragmented before
they reach the higher<br>
>    speed links.  The problem with bringing this to
fruition in the internet is<br>
>    going to be cost and effort.  The ATT's and Verizons
of the world are going<br>
>    to see this as a major upgrade without much benefit or
profit.  The Cisco's<br>
>    and Junipers are going to say the same thing when they
have to write this<br>
>    into their code plus interoperability with other vendors
implementations of<br>
>    it.<br>
<br>
I dont think any of the above will throw out any particular objection..
I think your problem is in figuring out a way to implement this globally
and not break stuff which relies so heavily upon 1500 bytes much of which
does not even cater for the possibility another MTU might be possible.<br>
<br>
Steve<br>
<br>
<br>
> <br>
>    Iljitsch van Beijnum <iljitsch@muada.com><br>
>    Sent by: owner-nanog@merit.edu<br>
> <br>
>    04/12/2007 05:20 AM<br>
> <br>
>                    
                     
                     
       To<br>
> <br>
>    NANOG list <nanog@merit.edu><br>
> <br>
>                    
                     
                     
       cc<br>
> <br>
>                    
                     
                     
  Subject<br>
> <br>
>    Thoughts on increasing MTUs on the internet<br>
> <br>
>    Dear NANOGers,<br>
>    It irks me that today, the effective MTU of the internet
is 1500<br>
>    bytes, while more and more equipment can handle bigger
packets.<br>
>    What do you guys think about a mechanism that allows
hosts and<br>
>    routers on a subnet to automatically discover the MTU
they can use<br>
>    towards other systems on the same subnet, so that:<br>
>    1. It's no longer necessary to limit the subnet MTU to
that of the<br>
>    least capable system<br>
>    2. It's no longer necessary to manage 1500 byte+ MTUs
manually<br>
>    Any additional issues that such a mechanism would have
to address?<br>
</tt></font>
<br>