# Solved: MTU vs. Fragmentation Threshold? Please explain!



## mybest2U (Aug 10, 2007)

Would somebody please clearly explain to me the difference between MTU (maximum transmission unit for a TCP/IP packet) versus the fragmentation threshold setting when using 802.11 networks?

I know that fragmentation threshold seems to apply to the 802.11 protocol layer, so if I set it below the MTU, will it then effectively limit my MTU to the same value? e.g. if MTU=1500 and I set fragmentation threshold to 1400, is my MTU then effectively 1400? 

And is it possible to set the fragmentation threshold above the MTU value?

Thanks for any help!


----------



## O111111O (Aug 27, 2005)

They're mutually exclusive from each other. Fragment threshold is access-point centric (802.11), MTU is IP header based..... Difference between layer2 and layer3 in a nutshell.

Yes, fragment threshold can be above MTU, and MTU can be above fragment threshold.

A bit more detail below if you wish to read.

Fragmentation threshold is between your access point and you. If your MTU is lower than your fragment threshold then YOU WILL NEVER see 802.11 fragments.

If your MTU is higher than your frag threshold, AND the payload is large enough then your access-point will force a fragment and the frame will be split up between host and AP to be reassembled upon delivery.

You generally want your MTU to be whatever the maximum MTU is of your AP/LAN/Internet connection. This is generally 1500 bytes, however in some cases where PPPOE/ATMOE/VPLSOE or other carrier-to-carrier encapsulation is used.

Why would you want fragmentation?

The only reason you would be interested in fragmentation is if your wireless network is in a noisy area (alot of other AP's), you see ALOT of loss during an action such as a file transfer, and/or you have a large amount of workstations in your WIFI network.

The reason for this is fairly straightforward: 
If your MTU is 1500 bytes and you're receiving data over your wireless network and there's a wireless collision caused by another transmitting station or otherwise, the entire frame is lost and the source station will have to retransmit it (i.e. no ACK received, retransmission) This greatly slows throughput if it happens often.

If your MTU is 1500 bytes, and you fragment threshold is 576 bytes [mere examples], then your AP will force fragments between itself and the wireless device. The payload from the AP is split into multiple 576 byte chunks (3 wireless frames), and are then subsequently reassmbled.

The reason this CAN speed things up, is in a wireless network where RTS/CTS aren't used [this is really the recommended approach], a wireless workstation needs 34us to sense a channel, 16us RTS, data transmission of roughly 600us for full payload, 16us for ack, 34us for DIFS, and roughly another 9us for another slot time.

With a fragmented payload, the time-in flight for a full frame can be reduced, as well as the DIFS time. (i.e. -400us for payload, -34us for DIFS). This also allows other devices to essentially interleave their transmissions within available slots.

Hope this helps.


----------



## mybest2U (Aug 10, 2007)

Thanks so much for the detailed reply, O111111O! 

To make sure I understand it right, let's consider the example of using a DSL modem along with a router. If I remember correctly, 1492 is the largest MTU you can use with 802.11 (did I get that right?), so there is no need to set my router's MTU for anything higher than 1492, correct? But now let's say that if my MTU for my wireless card is set at 1500, then I run a risk of fragmenting IP packets (since 802.11 has a max of MTU of 1492), correct?

NOW... if I set my fragmentation threshold to say, 1400, that will not affect the final IP packet size, which would be 1492 (limited by my router), even though my card is set for an MTU of 1500 (and even tho fragmentation is set at 1400).

Can I therefore conclude that setting the fragmentation threshold to a value below the max MTU will not necessarily limit the final IP packet size, and I can still get IP packet fragmentation in the aforementioned case? This is how I understood your explanation, but correct me if I'm wrong.


----------



## O111111O (Aug 27, 2005)

mybest2U said:


> Thanks so much for the detailed reply, O111111O!
> 
> To make sure I understand it right, let's consider the example of using a DSL modem along with a router. If I remember correctly, 1492 is the largest MTU you can use with 802.11 (did I get that right?), so there is no need to set my router's MTU for anything higher than 1492, correct? But now let's say that if my MTU for my wireless card is set at 1500, then I run a risk of fragmenting IP packets (since 802.11 has a max of MTU of 1492), correct?


Nope, actual MTU for 802.11 is ~2300 bytes..... This doesn't usually matter as unless all of your traffic is wireless<>wireless [i.e. mesh network], you're limited by the lowest common denominator.

I'm guessing that you have your MTU set to 1492 due to the fact that you're using PPPOE/ATMOE/VPLSOE or some other form of Ethernet encapsulated interface handed off to you by your ISP.



mybest2U said:


> NOW... if I set my fragmentation threshold to say, 1400, that will not affect the final IP packet size, which would be 1492 (limited by my router), even though my card is set for an MTU of 1500 (and even tho fragmentation is set at 1400).


Yes, pretty much. Wireless fragment is split/reassembled at a lower layer before IP even comes into the picture. 
Having said that, I'd suggest that the Fragment size chunk if you REALLY need to fragment be split into evenly divisible chunks of your denominator MTU.



mybest2U said:


> Can I therefore conclude that setting the fragmentation threshold to a value below the max MTU will not necessarily limit the final IP packet size, and I can still get IP packet fragmentation in the aforementioned case? This is how I understood your explanation, but correct me if I'm wrong.


Yes.

IP Fragmentation isn't really caused by your wireless. Fragmentation is usually caused by an upper layer [MTU] IP header issue.

A good example is the MTU of 1492. Setting this MTU requires PMTUD to work, PMTUD requires ICMP unreachables. If unreachables don't occur, then the payload has to be fragmented. Generally the lowest common denominator is 1500 bytes for MTU on any given interface nowadays. Some exceptions like ethernet encapsulated carrier-carrier circuits [PPPOE] throw a wrench in this.

Read this document: http://www.cisco.com/warp/public/105/pmtud_ipfrag.html

This really pertains to path MTU detection when using IPSEC/GRE, but it's very applicable.


----------



## mybest2U (Aug 10, 2007)

Thanks again for more detailed info, 01111110. I think I understand it a lot better now. 

This is slightly off topic from my original post, but my DSL modem uses PPPoE and has MTU set to 1492. Is this right? Or can I set it to 1500? Also, my router is set as a DHCP client of the modem, and not set up for a PPPoE bridge. Does this then make my max MTU for the router 1492? i.e. is there an extra 8 bits of header info? Or can I set my router's MTU to 1500 and still be OK even with a DHCP connection to my modem? 

If I'm pushing my luck here asking too many questions, I'll understand if you don't want to reply, but I really appreciate your patience and help so far!


----------



## JohnWill (Oct 19, 2002)

1492 is correct for PPPoE. There is indeed an extra 8 bytes (not bits) of header info.


----------



## O111111O (Aug 27, 2005)

mybest2U said:


> Thanks again for more detailed info, 01111110. I think I understand it a lot better now.
> 
> This is slightly off topic from my original post, but my DSL modem uses PPPoE and has MTU set to 1492. Is this right? Or can I set it to 1500? Also, my router is set as a DHCP client of the modem, and not set up for a PPPoE bridge. Does this then make my max MTU for the router 1492? i.e. is there an extra 8 bits of header info? Or can I set my router's MTU to 1500 and still be OK even with a DHCP connection to my modem?
> 
> If I'm pushing my luck here asking too many questions, I'll understand if you don't want to reply, but I really appreciate your patience and help so far!


Yep, like John said. 8 bytes for the PPP encapslation [not header info] Your carrier is wrapping your layer2 network inside of another layer3 network, ergo the 8 byte overhead.

This effectively means that the MTU end-to-end for you is 1492 bytes. Every time you add a layer of encapsulation, your effective payload is reduced.


----------

