Hacker News Reader

Comment by mhandley | Hacker News Reader

For 802.11, the biggest overhead is not packet headers but the randomized medium aquisition time so as to minimize collisions. 1500 bytes is way too small here with modern 802.11, so if you only send one packet for each medium aquisition, you end up with something upwards of 90% overhead. The solution 802.11n and later uses here is to use Aggregate MPDUs (AMPDUs). For each medium aquisition, the sender can send multiple packets in a contiguous burst, up to 64 KBytes. This ends up adding a lot of mechanism, including a sliding window block ack, and it impacts queuing disciplines, rate adaptation and pretty much everything else. Life would be so much simpler if the MTU had simply grown over time in proportion to link speeds.

View on HN

> Life would be so much simpler if the MTU had simply grown over time in proportion to link speeds.

The problem is that the world went wireless, so maximum link speeds grew a lot but minimum link speeds are still relatively low. A single 64kB packet tying up a link for multiple milliseconds—unconditionally delaying everything else in the queue by at least that much—is not what we want.

> The problem is that the world went wireless, so maximum link speeds grew a lot but minimum link speeds are still relatively low.

I would argue: the problem is that the MTU isn't negotiated at all, but especially not based on link availability.

IPv6 tries to solve this with path MTU discovery.

Yes, but IPv6 is still at a higher level than Ethernet, Wifi, et al and is therefore subject to the limitations of the lower level framing

Sure, I mean that's what pMTUd is all about. One big difference with IPv6: Routers can't fragment packets. They either send or they don't.

I thought so too, but apparently there is an IPv6 fragmentation extension and it's implemented by several operating systems.

Only the endpoints can fragment.

Sure?

At this point 1500 is the standard, we can’t ever hope to increase it without a way to negotiate the acceptable value across the entire transmission path - that’s what IPv6 gives us.

I'm not sure that negotiating the acceptable value across the entire transmission path is a reasonable thing to do. I'm not sure that IPv6 _should_ be aware of a minimum/maximum MTU of underlying transmission path particularly since that path can often change transparently and each segment is subject to different requirements.

Especially since there are a lot of low latency applications (games, etc.) that take advantage of being able to fit data in a single packet that will not be held up due to other applications sharing the link that might try to stuff larger packets down the link.

802.11 AMPDUs already tie up the link for ~4ms in normal operation. Without this, the medium acquisition overheads kill throughput. But you're correct that a single 64KB packet sent at MCS-0 would take a lot longer than that.

802.11 already includes a fragmentation and reassembly mechanism at the 802.11 level, distinct from any end-to-end IP fragmentation. Unlike IP fragmentation, fragments are retransmitted if lost. So you could use 802.11 fragmentation for large packets sent at slow link speeds to avoid tying up the link for a long time.

Is there a way to set a bigger MTU with wireless, like it is with wired ethernet?

> Life would be so much simpler if the MTU had simply grown over time in proportion to link speeds.

For every thing besides real-time maybe.

The M in MTU stands for maximum, not mandatory.

It ends up being mandatory if you're sharing a non-MIMO link with other systems that are using large packets.

Tell that to NetworkManager

I understand. I have architected networks for over a decade now. The real issue is serialization delay. If I have a tiny voice packet that has to wait to be physically transmitted behind a huge dump truck packet (big), it can still be a problem even with high speed links with regards to microbursts.

A single gigabit link can sends something in the order of 80,000 packets per second. If packets had a 9000 byte MTU, that would still be 12,000 packets per second. Having your smaller packets wait a at most an extra 0.02 milliseconds to be serialised onto a 1 gigabit physical link seems... rather unlikely to be a problem in the real world?

Reply on news.ycombinator.com