Practical way to tackle WiFi dropout and slow performance issue in OS X El Capitan

There is a couple of occasions that I need to do have an upgrade on Mac OS X. Chances are I completely forget those tweaking tips and hope things will be resolved in next version. Something like WiFi connection tweaking I can remind from the forum. An explanation can help me remind those things I should do every single time when I need to do an OS X upgrade.

We can find all kinds of topics regarding WiFi dropout issue on OS X and someone may suggest standard procedure to get around this. For WiFi settings, Apple would like to stick to standard MTU size at 1500 bytes for Ethernet network. But, why?

With WiFi connection, we can do a ping test like this:

$
$
$ ping -D -s 1500 google.com
PING google.com (203.5.76.246): 1500 data bytes
ping: sendto: Message too long
ping: sendto: Message too long

Note:
Option -D suppresses fragmentation for the packet (force to transmit whole packet at a time)
Option -s 1500 specify the packet size, i.e., 1500 bytes

Problem is there is an overhead added on top of packet size for every transmission. That is why we get 'Message too long' responses from there.

To rectify this problem, let's do the math:

Optimum MTU size = Packet size + Overhead

What about the overhead? The overhead would be 28 bytes because 20 bytes are reserved for the IP header and 8 bytes must be allocated for the ICMP Echo Request header.

So, maximum packet size permitted in each network packet is actually:

Optimum MTU size = Non-fragmented Packet size +  28 bytes

Here we say MTU size will theoretically be 1500. Packet size allowed would be

(1500 -28)=1472 bytes

But, is it practical? Let's test this.

To test this magic number, issue the following command in Terminal:

$
$
$ ping -D -s 1472 google.com
PING google.com (203.5.76.246): 1472 data bytes
1480 bytes from 203.5.76.246: icmp_seq=0 ttl=56 time=7.787 ms
1480 bytes from 203.5.76.246: icmp_seq=1 ttl=56 time=4.838 ms
1480 bytes from 203.5.76.246: icmp_seq=2 ttl=56 time=4.360 ms
1480 bytes from 203.5.76.246: icmp_seq=3 ttl=56 time=6.184 ms

Packets are now transmitted successfully with this payload (1472). Therefore, we can be sure the optimum MTU payload size would be 1500 (luckily a theoretical value this time) just for this particular WiFi network.

With no fragmentation happening, each packet should be theoretically transmitted as a whole and not broken in parts. This can improve the network speed effectively in an ideal signal condition.

Just remind that the size of payload can be different across various locations and wireless routers. You might need to find the smallest optimum payload which sits within the size range of successful transmission for most networks you'll be connecting, either at home or office. Try stepping down the value until you find transmission works for all the networks you have tried.

Apply this payload value in Network settings panel and hopefully it'll help reduce the number of WiFi dropout and improve the WiFi network speed.

In-depth look into Path MTU Discovery

Recently, I have been searching for a ultimate solution to remedy those situations whereas TCP traffic doesn't come through at the client side. The symptom could be occasional blank page on the browser.

It points me back to study the root cause of broken router or mis-configured firewall settings. For security reasons, some network administrator would make prudent settings to block ICMP traffic from the WAN whereas ICMP (type 3, code 4) packet is one key element in traditional Path MTU Discovery (PMTU-D) process initiated by the server.

Normally, MTU size is default to 1500 bytes at perfect network environment, especially the LAN. It's not the case in a real world situation where MTU size may vary. PMTU-D helps solve this problem in most cases. However, firewall administrator may simply block ICMP packet for security purposes. ICMP packet is useful for getting feedback from the destination for adjusting a possible MTU size to let the traffic come through without defragmentation, i.e., no further DF flag is required during the communication.

Hopefully, IETF Working Group has worked out another way to detect MTU without the need of ICMP packet. Packetization Layer Path MTU Discovery (PLPMTUD, RFC 4821) can work over the network layer above IP, i.e., TCP or UDP. This makes PLPMTUD can work independent of ICMP messages. It starts probing from a small packet size set as inital MSS, then increase progressively to a larger size until a packet loss happens. The optimum size will be used as MTU for that particular connection.

On Linux, there are several network parameters for tweaking:

/proc/sys/net/ipv4/tcp_mtu_probing
/proc/sys/net/ipv4/tcp_base_mss
/proc/sys/net/ipv4/ip_no_pmtu_disc


Possible values of tcp_mtu_probing are:
0: Don't perform PLPMTUD
1: Perform PLPMTUD only after detecting a "blackhole" in old-style PMTUD
2: Always perform PLPMTUD, and use the value of tcp_base_mss as the initial MSS.

Setting tcp_mtu_probing to 1 makes sure that PLPMTUD will start only when black hole router is detected along the way to the destination IP.

Default value of tcp_base_mss is 512 and is supposed to remain the same.

ip_no_pmtu_disc is default to 0 whereas traditional PMTUD can be used at all time. Setting this to 1 seems to make it totally skip the old fashioned way to detect MTU size by using ICMP message.

Ref:
http://kb.pert.geant.net/PERTKB/PathMTU
http://www.znep.com/~marcs/mtu/
http://kerneltrap.org/mailarchive/linux-net/2008/5/24/1928074/thread