Thoughts on increasing MTUs on the internet

Thu Apr 12 14:28:46 UTC 2007

On 12-apr-2007, at 16:04, Gian Constantine wrote:

> I agree. The throughput gains are small. You're talking about a  
> difference between a 4% header overhead versus a 1% header overhead  
> (for TCP).

6% including ethernet overhead and assuming the very common TCP  
timestamp option.

> One could argue a decreased pps impact on intermediate systems, but  
> when factoring in the existing packet size distribution on the  
> Internet and the perceived adjustment seen by a migration to 4470  
> MTU support, the gains remain small.

Average packet size on the internet has been fairly constant at  
around 500 bytes the past 10 years or so from my vantage point. You  
only need to make 7% of all packets 9000 bytes and you double that.  
This means that you can have twice the amount of data transferred for  
the same amount of per-packet work. If you're at 100% of your CPU or  
TCAM capacity today, that is a huge win. On the other hand, if you  
need to buy equipment that can do line rate at 64 bytes per packet,  
it doesn't matter much.

There are other benefits too, though. For instance, TCP can go much  
faster with bigger packets. Additional tunnel/VPN overhead isn't as bad.

> Development costs and the OpEx costs of implementation and support  
> will, likely, always outweigh the gains.

Gains will go up as networks get faster and faster, implementation  
should approach zero over time and support shouldn't be an issue if  
it works fully automatically.

Others mentioned ICMP filtering and PMTUD problems. Filtering  
shouldn't be an issue for a mechanism that is local to a subnet, and  
if it is, there's still no problem if the mechanism takes the  
opposite approach of PMTUD. With PMTUD, the assumption is that large  
works, and extra messages result in a smaller packet size. By  
exchanging large messages that indicate the capability to exchange  
large messages, form and function align, and if an indication that  
large messages are possible isn't received, it's not used and there  
are no problems.