MTU What are effects of changing it

There is a process called Path MTU Discovery and it works out what the MTU is between you and the destination. It works by sending out packets with the DF bit set and then successively reducing the MTU until it stops receiving ICMP messages saying the packet is too big. The issue is that too many networks and sites do a blanket block on ICMP so Path MTU Discovery ends up breaking and just assuming that your MTU is whatever its local interface MTU is. This generally is Ethernet so 1500.

You've lowered your MTU considerably according to your other post so there will be sites which are expecting you to have an MTU around or at 1500 but can't do Path MTU Discovery so they won't be able to work out that you don't accept that. This means that once you start sending/recieving large packets e.g. file downloads then your connection will appear to die. The initial handshake will probably go through because you're not sending/recieving packets that are actually that big.

You know, back in the days when we were all on 56K, 28.8K baud modems, the "windows" world had tricks to play around with MTU to get the best internet speeds as possible.

I consider those days kinda like nitpicking. There was software out there that would try to maximize your internet speeds by playing around with this.

Windows 7 from what I believe, automatically figures out your best speeds and will adjust, unlike XP. I think this is a pretty cool feature...

1500 bytes MTU to me is really the entire problem with the internet and networking as a whole. We keep upping the ante on switches 10/100/1000 yet we haven't dealt with the fundamental issue of packet size.

If the world ran on jumbo frames, holy cow, your 100 fast ethernet switch would feel like a 10gig switch!!!

Ryan82

One day when I have some free time, I am going to figure out exactly how to calculate the correct mtu and its associated mss sizes. We deal a lot with inline encryption devices as well as gre gre/ipsec tunnels so we have to adjust these values frequently. I found a cisco doc one time on figuring it all out but I fell asleep 3 sentences into it

Part of my problem is the distance I am from the ISP and ATT DSL is really crappy anyway. When I'm dl'ing a file it's not much faster than dial-up. To top that off half the times when it rains hard I'll lose my DSL anyway.
Changing the MTU to 1250, which is where packages started to not fragment, initially improved my internet performance. A few days later it's not so great (going to same sites even) so I've upped it to 1400 and going to see how it does.

earweed wrote: »

Part of my problem is the distance I am from the ISP and ATT DSL is really crappy anyway. When I'm dl'ing a file it's not much faster than dial-up. To top that off half the times when it rains hard I'll lose my DSL anyway.
Changing the MTU to 1250, which is where packages started to not fragment, initially improved my internet performance. A few days later it's not so great (going to same sites even) so I've upped it to 1400 and going to see how it does.

yeah, so it sounds like you're pretty far from the CO, maybe right at the outer edge of it? Especially if rain can make or break your connections.

What about satellite?

I'm leaning in that direction since that's my only other choice where I live. I'll still have the problem of losing the internet when it storms but I'll be expecting it. Part of the problem with satelite is I have so many big trees nearby that already cause problems for my directtv satelite reception. I'll lose signal easier during spring and summer than in the fall/winter.
I'm out at the very edge of ATT coverage. If I lived on the same street on the other side of the highway I'd have cable and that'd be great but they wont hook me up over here.

notgoing2fail wrote: »

1500 bytes MTU to me is really the entire problem with the internet and networking as a whole. We keep upping the ante on switches 10/100/1000 yet we haven't dealt with the fundamental issue of packet size.

If the world ran on jumbo frames, holy cow, your 100 fast ethernet switch would feel like a 10gig switch!!!

You sure you know what the benefit of jumbo frames are?

earweed wrote: »

Part of my problem is the distance I am from the ISP and ATT DSL is really crappy anyway. When I'm dl'ing a file it's not much faster than dial-up. To top that off half the times when it rains hard I'll lose my DSL anyway.

You've got a bad line. If SNR degrades that badly when it rains then it means there are exposed junctions somewhere between you and the CO that are letting in water. You need to attempt to get that resolved before investigating satellite or messing with the settings.

I've called multiple times. They have techs on the lines out here near where I live almost constantly. I've talked to a few of them and they say it's more how old the lines are. I've even had my land line have problems due to a bad connection while the DSL still worked (the tech said it happens sometimes)

earweed wrote: »

I've called multiple times. They have techs on the lines out here near where I live almost constantly. I've talked to a few of them and they say it's more how old the lines are. I've even had my land line have problems due to a bad connection while the DSL still worked (the tech said it happens sometimes)

Those telco guys should come with line detectors, surely they should be able to see that the quality of the line is low. But of course, when they come, it will probably show excellent!!

tiersten wrote: »

You sure you know what the benefit of jumbo frames are?

Well.....I know they are used more for SAN's. VMware likes to turn on jumbo frames for that.

I don't know the history of why we settled on 1500 bytes exactly, but I believe jumbo is 9000 bytes? Give or take a few...

If all routers/switches started off with 9000 bytes I'd think we'd have a faster internet no?

notgoing2fail wrote: »

I don't know the history of why we settled on 1500 bytes exactly

Larger means less overhead but more to retransmit if there is a problem. The larger frame also means increased latency due to time necessary to transmit.
Smaller means more overhead but less to retransmit if there is a problem.

1500 is a compromise value that was picked for the implementation of Ethernet. It isn't so massive that you spend all your time retransmitting corrupt packets whilst it also isn't so small that you burn a large percentage of your CPU cycles just processing the frames.

notgoing2fail wrote: »

but I believe jumbo is 9000 bytes? Give or take a few...

Anything above 1500 is technically a jumbo frame. The 9000 value is just what the various manufacturers have agreed upon as what is the mainstream jumbo frame. The actual number was decided by the people designing/implementing Internet2 but it is yet another number that was just picked out of the air following some discussion.

There are devices which support jumbo frames but a MTU less than 9000 and some devices which support MTUs significantly larger than 9000. If you want most GigE+ devices to work together nicely with jumbo frames then you'll stick with 9000.

notgoing2fail wrote: »

If all routers/switches started off with 9000 bytes I'd think we'd have a faster internet no?

Not really. The benefit of jumbo frames is mainly that you have less overhead when transferring large amounts of data. This is because the CPU has to deal with fewer packets that are larger than many small packets. If your CPU bound then yes, jumbo frames will increase your throughput but if you're not then it won't help at all and will actually be detrimental.

It is great for storage networks because all you're going to be doing on there is sending very large amounts of data around. You don't want to burn up valuable CPU cycles processing these frames either. TOE cards are popular in this particular area.

If you use jumbo frames then everything on that subnet needs to be jumbo frame capable and have the same MTU set. You can't mix and match devices that support jumbo frames. This means that if you want jumbo frames then everything needs to be GigE or better since you can't get jumbo frames for Ethernet/Fast Ethernet. WiFi is out of the window already since you can't change that.

Switching over to jumbo frames for the internet is never going to happen. You'd have to redesign and reimplement everything so you might as well start from scratch i.e. Internet2.

Jumbo frames for the average home/business network is also a non starter because you'll be guaranteed that not everything on there will be GigE+ and support jumbo frames.

tiersten wrote: »

Larger means less overhead but more to retransmit if there is a problem. The larger frame also means increased latency due to time necessary to transmit.
Smaller means more overhead but less to retransmit if there is a problem.

1500 is a compromise value that was picked for the implementation of Ethernet. It isn't so massive that you spend all your time retransmitting corrupt packets whilst it also isn't so small that you burn a large percentage of your CPU cycles just processing the frames.

Anything above 1500 is technically a jumbo frame. The 9000 value is just what the various manufacturers have agreed upon as what is the mainstream jumbo frame. The actual number was decided by the people designing/implementing Internet2 but it is yet another number that was just picked out of the air following some discussion.

There are devices which support jumbo frames but a MTU less than 9000 and some devices which support MTUs significantly larger than 9000. If you want most GigE+ devices to work together nicely with jumbo frames then you'll stick with 9000.

Not really. The benefit of jumbo frames is mainly that you have less overhead when transferring large amounts of data. This is because the CPU has to deal with fewer packets that are larger than many small packets. If your CPU bound then yes, jumbo frames will increase your throughput but if you're not then it won't help at all and will actually be detrimental.

It is great for storage networks because all you're going to be doing on there is sending very large amounts of data around. You don't want to burn up valuable CPU cycles processing these frames either. TOE cards are popular in this particular area.

If you use jumbo frames then everything on that subnet needs to be jumbo frame capable and have the same MTU set. You can't mix and match devices that support jumbo frames. This means that if you want jumbo frames then everything needs to be GigE or better since you can't get jumbo frames for Ethernet/Fast Ethernet. WiFi is out of the window already since you can't change that.

Switching over to jumbo frames for the internet is never going to happen. You'd have to redesign and reimplement everything so you might as well start from scratch i.e. Internet2.

Jumbo frames for the average home/business network is also a non starter because you'll be guaranteed that not everything on there will be GigE+ and support jumbo frames.

Wow, very impressive write up. Good stuff my friend. I'm going to have to jot this one down. So bigger doesn't always mean better!

I had assumed increasing the payload would allow faster internet, I was thinking in the context of downloading a large file.

It will be interesting to see how IPv6 deals with MTU. I vaguely read up on it so I can't recall exactly what changes were made....

notgoing2fail wrote: »

I had assumed increasing the payload would allow faster internet, I was thinking in the context of downloading a large file.

Its not quite as simple as I described to be honest since what I described is mostly for the LAN world. The WAN world is more complicated and does follow what you want to do sort of.

The MTU does become important when you're talking about TCP over WAN links. The RTT of your connection will greatly affect the throughput of your TCP connection due to the windowing it does. In a LAN environment, the RTT is generally so small that you'll be limited by other factors like the previous mentioned CPU usage. In a WAN environment however, the RTT becomes significant due to the sudden increase in time, the general slowness of the WAN links and the normally unavoidable packet loss.

The window parameters set how much data can be in flight at any point in time. If the RTT is high then it will be waiting a lot for the ACKs to come back even if the link is free. If you want to increase the throughput then you reduce the RTT, increase the window size or increase the size of each frame.

Reducing the RTT is difficult since you're running into processing delays and pure laws of physics. Increasing the window is easy to do and will be compatible with existing software/hardware but if you're getting lots of corrupt/lost packets then the connection will be adversely affected. Increasing the MTU isn't easy to do because of all the compatibility issues and it all depends on the exact attributes of the WAN link as to whether it will even do anything.