Thoughts on increasing MTUs on the internet

Gian Constantine constantinegi at corp.earthlink.net
Thu Apr 12 14:04:22 UTC 2007


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

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.

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

Gian Anthony Constantine


On Apr 12, 2007, at 7:50 AM, Saku Ytti wrote:

>
> On (2007-04-12 11:20 +0200), Iljitsch van Beijnum wrote:
>
>> What do you guys think about a mechanism that allows hosts and
>> routers on a subnet to automatically discover the MTU they can use
>> towards other systems on the same subnet, so that:
>> 1. It's no longer necessary to limit the subnet MTU to that of the
>> least capable system
>>
>> 2. It's no longer necessary to manage 1500 byte+ MTUs manually
>
> To me this sounds adding complexity for rather small pay-off. And
> then we'd have to ask IXP people, would the enable this feature
> if it was available? If so, why don't they offer high MTU VLAN
> today?
> And in the end, pay-off of larger MTU is quite small, perhaps
> some interrupts are saved but not sure how relevant that is
> in poll() based NIC drivers. Of course bigger pay-off
> would be that users could use tunneling and still offer 1500
> to LAN.
>
> IXP peeps, why are you not offering high MTU VLAN option?
> From my point of view, this is biggest reason why we today
> generally don't have higher end-to-end MTU.
> I know that some IXPs do, eg. NetNOD but generally it's
> not offered even though many users would opt to use it.
>
> Thanks,
> -- 
>   ++ytti

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070412/6309bb58/attachment.html>


More information about the NANOG mailing list