Check out my first novel, midnight's simulacra!

MTU

From dankwiki
Revision as of 15:16, 2 May 2023 by Dank (talk | contribs) (Created page with "quoth farnz [https://lwn.net/Articles/885256/ on lwn]: "In large part, we have the problems we have with MTU because most of our link layers now simulate a 1980s 10BASE5 network, just at very high speeds. A switched 100GBASE-LR4 network is designed to present the appearance of a single 10BASE5 segment (via switch behaviour); an 802.11 network tunnels 10BASE5 compatible networking over an RF link layer where the "true" packet size (via aggregation) is variable but can go...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

quoth farnz on lwn:

"In large part, we have the problems we have with MTU because most of our link layers now simulate a 1980s 10BASE5 network, just at very high speeds. A switched 100GBASE-LR4 network is designed to present the appearance of a single 10BASE5 segment (via switch behaviour); an 802.11 network tunnels 10BASE5 compatible networking over an RF link layer where the "true" packet size (via aggregation) is variable but can go as high as 1 MiB.

As a result, we have point to point links at the L1 level (in both WiFi and wired Ethernet), which are used to emulate a bus network topology at L2. If we'd done things very differently, we'd be presenting those P2P links directly to the L3 system, and the "switch" or "AP" equivalent would be able to offer different MTUs to different clients, and send PMTU discovery messages back instantly if you're going to a lower MTU path attached to the same switch.

It's worth noting that IPv6 (a late 1980s/early 1990s design) has vestigial support for this; a router can indicate that no other hosts are on-link, and thus force you to send everything via the router. If you're directly attached via P2P links to an IPv6 router, you could thus have different MTUs on all the P2P links, and the router would be able to control path MTU as appropriate."