[hylaride]

I'm having flashbacks to 1990s-era PPPoE, where the slightly smaller MTU had issues with some server OS's that had TCP/IP stacks that didn't support or ignored MTUs smaller than 1500 bytes and bulk data transfers would get messed up. I don't remember which ones, but it was some commercial UNIX.

[toast0]

Windows clients don't request the MTU from dhcp either, so that's also fun.

After hitting broken pmtud enough, I resolved to make a browser based test, and eventually I did. http://pmtud.enslaves.us/

But that wouldn't help this investigation, since there's no attempt to find the path mtu in webrtc-rs (or general webrtc)

[wmf]

Weren't T1s running 576 MTU back then?

[hylaride]

IIRC, T-lines had no inherent MTU. The MTU is determined by whatever layer-2 encapsulation ran over the T1:

PPP → default MTU 1500 Cisco HDLC → 1500 Frame Relay → typically 1500+ (often configurable higher)

So a typical IP MTU on a T1 link was 1500 bytes, same as Ethernet — chosen partly so packets could traverse Ethernet ↔ T1 boundaries without fragmenting.

576 is from RFC 791 (IPv4):

* Every IP host must be able to reassemble a datagram of at least 576 bytes.

* 576 became the conventional default MTU for "non-local" destinations — i.e., when a host didn't know the path MTU and wanted a value virtually guaranteed not to be fragmented anywhere. (576 − 20 IP − 20 TCP = 536 bytes of payload, the classic TCP default MSS.)

You'd also see 576 as a common default on dial-up/PPP links and X.25, which is probably the source of the association — not T1.

But re-assemble didn't necessarily mean transmit. My understanding (and this is quoting from memory from over 20 years ago) is that some commercial UNIXs from eons ago didn't ever really test dialup or other other such settings as they were often in more commercial settings and other protocols were often used before everything converged on IP. I'm sure these were also unpatched machines.

It was just annoying enough where some random connections didn't work very well.