|
Shortcuts
|
MTU, what difference does it make ?An Editorial by Philip Filipov2000-11-12 (updated: 2011-01-10) by Philip Tags: MTU, packet, datagram, MSS, latency, ping, throughput Packet size, often referred to as MTU (Maximum Transmission Unit) is the greatest amount of data that can be transferred in one physical frame on the network. For Ethernet, the MTU is 1500 bytes, for PPPoE 1492, dial-up connections often use 576. Each transmission unit consists of header and actual data. The actual data is referred to as MSS (Maximum Segment Size), which defines the largest segment of TCP data that can be transmitted. Essentially, For the purposes of this article and all comparisons I'll make the following assumptions:
Packet size vs. latency Let's examine a transfer of 1,500,000 bytes of data using different packet size over a T1 line (T1=1,544,000 bits/sec) using the following formula: ( MSS + header ) * 8 bits/byte Then, using different MTU values, we can calculate the relevance of packet size to latency. If MTU = 1500, then: (1460+40) * 8 / 1,544,000 = 7.772 ms delay per hop If MTU = 576, then: (536+40) * 8 / 1,544,000 = 2.924 ms delay Assuming a transfer over 10 hops, the 1500 MTU would wield 77.72 ms delay, while a 576 MTU would take 29.24 ms to transfer over a T1 line. It is obvious then that smaller packets will be transmitted faster, simply because of the throughput limitation of the line. It's however somewhat moot point in large transfers, all that's illustrated above is the fact that transferring more data takes more time :)
Throughput vs. packet size Using the same formula from our previous example, let's assume we need to transfer 1 MByte file over the same T1 line. 1MByte = 1024 KB = 1,048,576 bytes. If MTU = 1500, then: (1460+40) * 8 / 1,544,000 = 7.772 ms delay per hop
If MTU = 576, then: (536+40) * 8 / 1,544,000 = 2.924 ms delay per hop.
The difference comes from the fact that when using larger packets the overhead is smaller. To transfer 1 MByte, if using MTU of 1500 there are 719 * 40 = 28,760 bytes of overhead, while if using MTU of 576 1957 * 40 = 78,280 bytes, additional 49,520 bytes of headers transferred each MByte. For our 10-hop transfer, the additional overhead accounts for just a fraction of a second, however it makes a difference if you consider large transfers over long periods of time. This difference is a also higher in practice, considering TCP options and the fact that modern TCP/IP implementations tend to use larger headers (additional 12 bytes header space for Timestamps for example). Also, the above example uses best case scenario, not considering higher latency and congestion.
Final Thoughts Generally, it's logical to assume larger packets are better, because of all the following factors:
However, if pure throughput is not the ultimate goal, smaller packets might be more "responsive" since they take less time to travel throughout the network. That effect might be preferred in some applications and online gaming, at the expense of throughput. Ultimately, packet size should be decided based on the type of the desired result, considering the underlying network as well, to avoid negative factors such as fragmentation of packets. Still one has to realize the fact that larger packets will still transmit more useful data than smaller packets, and that there is no single "best" solution for all applications. Regards, Philip
User Reviews/Comments:
rate:
avg:
by
Mike - 2006-01-26 19:29
Thanks a lot for the easy to read explanation
even for dummies :) thnks
is it a good design to consider only mtu+header? or is it better to consider mtu+header+payload to measure the right mtu/latency/throughput requirements?
MSS = payload... So MSS + headers = payload + headers = MTU
OK,
take it from an experience tech.... if your websites start to load, and it fails after about 15 seconds, and all looks good, strat dropping your MTU setting in your router by factors of 8 until it starts working properly. This is very evident with PPPOE and the first versions of linksys routers. This is especiually important if outlook or outlook express is properly configured but you are getting errors with email. If all else fails, give it a try. I does work in many "last ditch fix attempts"
Is the computation/result based on Round-trip delay?
Thanks
Now I can understand it. Although, this MTU size packets, do generally have an effects on downloading and uploading time when downgrading the MTU. I have done some test, let alone I'm not the tech expert, but I do have experience with computers and modem/routers. I have my MTU size packets at 666, which is the devils number of the beast. But it works flawlessly. I use to have it as default at 1492, but it started to slow down the paging on the websites. So there for, do your own test and see what fits best for you. It also does help the latency time, small MTU size packets, the less latency time there will be. Thank you for the article.
There's some major flaws in the calculations here.
Most T1s are 1536, not 1544. 1544 is an HDLC T1, most Ts use frame relay, which is only 1536. Delay per hop has nothing to do with how much you are downloading. From a router's perspective it's dealing with a single frame over and over. It doesn't care if that one frame is going to be followed by XXXXXX more frames. The time it takes to download is simply determined by available bandwidth and overhead, number of hops plays no role aside from queuing. Queuing delays are dependent on how the network was designed/configured, and can be vastly different on each network your data traverses. By the formula posted, if you set up 100 routers in a single room and routed from one end to the other it would take several minutes for a packet to go from one end to the other. Now you will see delay if using non wire speed routers, but most core routers on the internet are wire speed--meaning there is no delay other than the time it takes electricity to travel across the interface (speed of light). But even non wire speed routers will deliver a packet across those 100 routers in under a 1000ms, most likely under 100ms. The reasons lowering MTU may improve your latency is because a network your packets are traversing is using a smaller MTU than 1500, or because your smaller packet is being used as filler for another stream that doesn't fill a frame, like perhaps ACK packets. Since your packet is small it can be squeezed in and car pool with others rather than waiting for its own limo. Another factor not considered in this formula is that some Tier 1 and Tier 2 providers use MTUs much higher than 1500--thus the car pool analogy above. It's not uncommon for a DS3 frame relay link to use an MTU of 4000. Another factor not taken into consideration is that there are more hops than you can see in a traceroute. Bridges will not show in a traceroute, but are the same equipment used as routers in most cases, just set to bridge mode. And bridges can do transparent queuing, which means they'de add the same delay described in this formula...if it were accurate. If you want to set your MTU for optimal performance, just do a ping with a payload equal to your MTU, if ping times increase above a normal ping lower your MTU, when ping times drop to about normal, you found the right MTU. No need for this erroneous formula...which is easily disproved by this procedure since increasing ping payload simulates a large download. I mean, I own a small fixed wireless company covering hundreds of square miles and when I ping a customer through 7 hops it doesn't take more than 15ms or so, depending on the link quality. Good effort, but obviously written by somebody with little or no layer 2 knowledge or network architecture experience. Remember, all networks function at layer 2, not layer 3. IP traffic (layer 3) just rides along layer 2 networks--there are exceptions like MPLS, but you can't get MPLS to the home yet, so... Later.
Please do not take the above out of context. The formula above is correct, and intended to illustrate the relationship between packet size and latency, given a fixed bandwidth. It is not indended to consider all other factors that may also affect the connection, such as all types of router overhead, queuing, OSI layers, switching delay, speed of light, type of connection, moon phase, etc.
If you are transfering data through a router/device with Gigabit capacity (or wire speed, or optical), it will not experience the above delay to transfer that amount of data because of its higher capacity (Gigabit vs. T1). However, in a shared user environment any one client/datastream will not be able to use the full capacity of that router either, so the above theory becomes very relevant. If you have a fixed slice of the available capacity through a device, or series of devices (1Mbit in the above example), regardless of their hardware, considering only that information, the formula above illustrates the effects of packet size to latency through that network segment. You can apply it to different capacity, packet sizes, etc., the specific numbers are only relevant as an example.
Hi, I'm using LTE - 4G network with limited 31
mbit/s downstream. Can u tell me on my mail what MTU size I have to put? I can't calculate. Best regards
(1st packet * 10 hops * 7.772ms delay) + 718 * 7.772 = 5.658 seconds
I'm lost a little on this part, can someone explain to me why you would only take the first packet and calculate the hops, and not the other 718? When I see this I think of this as only 1 packet taking the 10 hops and 718 packets are only doing 1. Can someone explain this please, and thank you. Everything else makes perfect sense!
(1st packet * 10 hops * 7.772ms delay) + 718 * 7.772 = 5.658 seconds
I understand everything else in this post, just this part confuses me, when I see this you are only counting 1 packet at 10 hops and 718 packets in just 1 hop. Why would you do this? Don't all 719 packets need to have 10hops?? So Wouldn't the equation be more like ...719*10hops*7.772ms delay ? This is confusing , can someone explain please and thank you! and this part, which is the same question (1st packet *10 hops * 2.924ms delay) + 1956 * 2.924 = 5.748 sec
Actually I just figured it out! lol I'm going to school to be a Network professional, and all these things I'm very interested to learn about, So I was just sitting here boggling my mind and I figured it out.... While your sending your 719 packets you are only counting that first hop because that router is sending out that data to the other routers while it is receiving as well, so once it receives all the packets then you will have to wait for the last packet to traverse 10 routers, haha! Took me like 15min of thinking, but I got it by myself, thanks for the guide, it helped me out in more ways then one.
pretty good explanation :)
I'm not sure why your formula says "first packet" * 10hops * latency it looks like you are multiplying "first packet" by something (even though it is just an indication that you count every hop for the first packet... "first packet" is not a value and should not appear as one in the equation, if you know what I mean?) I would add that another reason why a smaller MTU can be beneficial, is that sometimes TCP packets are marked as "do not fragment", which means that if they encounter on their way a router that has a smaller MTU than their side, then they are rejected, and the sender has to send again with a smaller MTU (until it finds a MTU small enough to go through all routers). For this reason a smaller MTU might save you some re-transmission and make some applications more responsive
Hi there, first off thanks for this explanation, this makes sense to me now...This may be a slight deviation from the topic at hand - and if there is a better answer somewhere, I am very open I just haven't found any info that works for me.
I have recently began testing of a mobile router unit that is programmed to run on machine-to-machine data using cellular data transmission with large packet sizes. I was told that standard speed test results will be inaccurate because of the larger data packet sizes, but I this doesn't sound like accurate information to me. I'm NOT a network professional and, although I've been in telecom and have a reasonable understanding about how these systems work, I'm not qualified or knowledgeable enough to know if this is just a way to explain away slower data speeds or if the packet sizes would impact either a flash-based speed test (like ookla) or the wealth of other HTML5 data speed tests... Can anyone give me a clear answer? Thanks so much!
Standard web-based speed tests will approximate your browsing experience and file transfers in a standard Ethernet TCP/IP environment, i.e. up to 1500-byte packets.
The underlying backbone network will repackage your data, for example, ATM networks use 53 byte cells (5-byte headers and 48-byte payload). Still, that should not affect your end result/bandwidth, as that is your real measurement, that IS the speed you see at your end between those particular endpoints.
|