I don't understand all these terms that are used. MTU size? I shall google it and see if I am able to decipher anything.
MTU=Maximum Transmission Unit. MSS=Maximum Segment Size.
Its the largest frame size that the network supports. On Windows XP, it can be set on a per-interface basis by adding a new registry setting for each interface.
The default MTU for most ethernet interfaces (and that includes most WiFi) is 1500 bytes. I often reduce this down to 1400 or even lower. When you have lower speed links (<10Mbps) and trying to prioritise small packets such as voice, its best to drop the MTU considerably to ensure the high-priority smaller Voice packets don't get cuaght behind a large (say 1500 byte) packet that is taking its time to serialise out the interface.
I know I am going back to the same question but can anyone explain why I am able to use Flyertalk and another forum but not AFF. Isn't the software essentially the same? I am sure the answer is not simple but what could possibly be the conflict?
FT and AFF are hosted by different providers. There are several things that could be different that could trigger your symptom is there is an MTU mismatch problem:
The FT systems have be set to use a reduced MTU/MSS.
All the ISPs in the path between you and FT servers may be carrying a larger MTU than your PC and/or not blocking the ICMP fragmentation messages back to your PC, while there may be one or more ISPs in the path to AFF that is reducing the MTU and blocking the ICMP message from getting back to you.
There are two things to understand about MTU. When a TCP session starts, a SYN exchange occurs. One of the things the two end-devices do is tell each other their Maximum Segment Size (MSS) and the lowest value is used for the duration of the conversation. Some WAN optimisation devices will play around with this SYN exchange supposedly to improve the network performance or control the use the bandwidth.
Once this MSS is determined by the end stations, they start actually sending each other packets. In most cases of web surfing, the packets from you to the internet are small, while the response packets are often larger and more likely to reach the MSS limit. When one of the end stations needs to send more data than can find into one frame it must split it into multiple frames. So its possible that in your surfing experience, the first time you try to send a 1500 byte packet is when doing an activity such as posting on AFF. So no problems reading AFF since all the bigh packets are from the server back to you.
Now when you (or any device) sends a packet, every router along the path must handle the packet. If any router along the path needs to send the packet out an interface that has a smaller MTU than the size of the packet, it has to fragment the packet into multiple frames, which it can do automatically. However, there is a field in the IP header that carries a series of flags. One of these flags is called the "Don't Fragment Bit" (or DFB). If the application decides to set this bit, it is telling all the routers along the path not to fragment this frame. So if a router receives a packet from you and the DFB is set and it exceeds the MTU of the outgoing interface, it MUST drop the frame and send back to the source device an ICMP message with a specific code that says "this packet has the DFB set and exceeds my MTU - my MTU is xx_ bytes". The source device would normally resent the data in smaller packets that are less than xx_ bytes in size and should remember this path MTU limit for the duration of the session.
However, several years ago some bright spark hackers found they could bring a server to its knees by sending lots of ICMP Echo Requests (essentially a PING) to it from a dummy source address. This was known as The Ping Of Death.
Next, some bright spark security "guru" decided the best way to protect everyone from The Ping of Death was to block ALL ICMP messages on the network. So this does protect from the PoD, but has all sorts of other issues as ICMP can now no longer do its stuff.
So if there is a firewall anywhere between the AFF server and your PC that is blocking the ICMP message about a router dropping the large packet that needs to be fragmented (and the new MTU to use for that destination), the message just never gets through and its just like the packet was lost in the ether.
So if your path to FT does not need to fragment or does not block the ICMP messages when fragmentation is required, then all works. And if your path to AFF does need to fragment and something does block the ICMP messages when fragmentation is required, then it fails.
I used to get this using my WiFi and telstra DSL and the Amex site. I would log in and click around, but as soon as I tried to view my transactions, it would just hang. But if I went via the corporate VPN (still same WiFi and ADSL) it would work. This was because the VPN itself reduced the MTU (53 bytes overhead for IPSec) and all was ok. My fix was to reduce my WiFi interface MTU down to 1400 bytes and all was fine.
I see this same MTU and firewalls blocking ICMP messages all the time. Its thing on my problem diagnosis list when the symptoms seem to be inconsistent delivery of packets.
Back in the mid 1990s I remember being hauled over to Perth on a Sunday to help with a "huge" network problem at a very large and important customer. After jumping on a plane at no notice and making my way to the customer's site and a 5 min brief on the "problem", I asked to see one of the servers. I quick test with a few well compiled ping commands and I knew the cause. I adjusted the MTU of the server and rebooted the server (with permission) and the "huge problem" went away. I then told them to get the security admin to allow ICMP Type 3, Code 4 through the firewall and then they could reset the MTU back to default. An hour later I was being driven back to the airport by some pretty relieved, yet embarrassed, techs that had been trying to resolve the problem since Friday and had been given an ultimatum that it MUST be fixed by Monday morning.
