Apple knows better (how big it is)

Last year, I've spent few months exchanging emails and packet dumps with Zoom's support. They provide videoconferencing software which gave me connectivity problems . Specifically, Zoom client, on my work Macbook, when connected to my home network, failed. To make reporting harded, Zoom's webpage did not open in Chrome on that laptop neither.

Perplexingly, my private Fedora laptop, on the same network, had no problems whatsoever. I'll spare the details of weeks-long investigation (no, it wasn't DNS' fault; nor Cloudflare's).

The problem source…

MacOS X DHCP client ignores Maximum Transfer Unit (option 26) from DHCP server!

I couldn't believe it, but there are tons of similar reports over the net. Apparently, Apple deems MTU information not trustworthy. Well, thank you 🍏, there went weeks of my time.

Why do I even have non-standard MTU in my network?

Since my ISP was acquired, I had to deal with blast-from-the-past networking. Plain, reliable Ethernet connection was replaced with PPPoE, lowering the MTU to 1492 bytes, bringing distaste and headaches.

Why other webpages and software continued working?

Most communications use TCP/IP protocol, which knows how to deal with decreased MTU. Modern pages (and Zoom) try to use QUIC protocol. It works over UDP. UDP has no mechanisms of Path MTU discovery and too big packets are just dropped. PMPTU for QUIC is still at a draft stage.

Why it started to happening recently?

Due to other circuimstances, I had disabled IPv6 connectivity for my work laptop around summer last year. I didn't noticed at the time, but before that, Zoom worked fine over IPv6. MTU information from RA is good enough for Apple, whereas from DHCP is a no-no.

Kudos for Zoom Support, for spotting the MTU problem in the end.

030/100 of #100DaysToOffload