As I recall the 1280 figure was arrived at a long long time ago, before ‘broadband’ ie DSL and it was arrived at by thinking about links that include those long forgotten now such as X25. I use 1408 because it’s faster than 1500, because it’s an exact number of completely filled ATM cells on my ADSL2 links with the overheads that I have with PPPoEoA. It needs to be so low because of the 1440 MTU in my stupid 3G USB NIC that the Firebrick uses for failover, then that minus 20 for IPv6 tunnelling in IPv4 and then it’s the largest ATM sweet-spot below that. But as Chrys says, there’s something to be said for having a reduced LAN MTU in IPv6, but I don’t see the need to go down quite as far as 1280, but then it matters little anyway. I would still recommend thinking about something like 1400 on IPv6.
I do still remain a big fan of 9k. Partly irrationally!
I understand, but don’t accept Alex’s point about unreliable links dropping a packet that can either be 1500 bytes or 9k. We aren’t talking about corruption, because future networks are all perfect, and if you still have DSL for the next few days, get G.INP / PhyR as you need a per-link-hop L2 retx protocol which has very low RTT, just over the one single link. Without L2ReTX, DSL is inferior to dialup, seeing as all modems 32 years ago had L2 retx and very good it was too. That case makes Alex’s point about small MTUs and thus small PDUs perfectly; those 1990s dialup modem L2retx protocols used iirc 64 bytes as the DTU, that way they could cope with very unreliable links and the time cost of retransmitting a lost DTU was low. Also the probability of getting a DTU is really kept low if the DTU is corrupted in 1 bit and then same again when you retry, then seem again, so you never ever get anywhere.
Legitimate router drops I will talk about next. One packet’s cost is the time it takes transport protocols to ramp up again; it’s not the cost of the time to transmit one PDU, be it 9k or 1500 bytes, because networks are so ridiculously fast now compared to when the internet was around in the 1980s with 9600 bps dialup modem links, or 32k / 64kbps if you were lucky. In 1994 I had an X.25 link at work to another site, was put in by BT and it was 9600 bps even then. No dialup. My point is that as speeds go up, other design parameters should scale up to suit. And the number of PDUs that need to be sent, and number of io operations needed to be initiated in order to send a medium-large block of data is a bit silly now. Also routers can have GB of RAM in them if they wish, for buffers. Of course huge buffers per flow are evil as we know; bad queuing hell. The interplanetary network protocol or ‘bundle’ network assumes that routers will have huge amounts of non-volatile storage, so not just loads of RAM but gigantic hard disks too. (Because unlike the internet, a bundle protocol router can be charged with long-term custody over a bundle, holding on to it and ensuring it gets to its destination some day. I’ve forgotten what the correct term for this optional feature is; it’s negotiated if a sender asks for it.)
Anyway, if we were designing a network layer nowadays, no way would I even think of something as small as 1.5 kB; at least 4kB would cross my mind, then 16kB or 60kB (NOT 64*1024=65536 !). I would be thinking about current and
future RAM architectures, page sizes and cache friendliness related size numbers.
Btw, I wonder what max L4 PDU size QUIC uses in IPv4 and IPv6?
Author
Topic: HTTP/3 QUIC explained in a way even I can understand :p (Read 2920 times)