Hacker News Reader

Comment by zokier | Hacker News Reader

Why would that be preferable over having routers just drop oversized packets and send icmp message to sender?

1. ICMP messages often don't reliably make it back to the sender. This is especially true with low level load balancers.

2. You at least get some information. Maybe half a packet is better than no packet.

3. You get an exact size limit of the entire path the packet took. Rather than just a "too big" of the first hop that wouldn't pass it.

Overall I think it is a pretty decent solution. Assuming that the IP header says the original size or similar so that the truncation can be easily detected.

I do see some flaws though:

1. Layered protocols would have to be more complex to deal with packet truncation. (Although I guess they could simply treat truncation the same as dropped to avoid extra complexity.)

2. Checksums at the end of a packet being dropped likely make the whole packet useless.

3. It may be better to get a quick rejection from a local router rather than the possibly far away peer.

I'll add an extra bonus: every now and then, an endpoint could append one extra bonus byte to a transmitted packet. That would probe for a potential increase in PMTU at very little cost.

Yeah, maybe a "contains MTU dummy data" bit at the start of the header which lets the receiving client know that this packet 1) May contain additional data after the real payload 2) If it does, send back an updated max packet size based on the amount that made it through.

IETF folks wouldn't like that much state in the IP protocol and it doesn't solve intermediate L2 loss (the real reason you have IP MTU differences) when switches are involved in the path though. That said, might make in interesting ICMP probing method.

In TCP, for packets without the urgent bit set, you could include the real size of the data in the urgent pointer field. The sender could occasionally send a local max MTU packet with at most the detected path mtu of data. The receiver could send a return indicator to confirm the received length if the urgent pointer field was set.

I'd add a fourth potential positive aspect of truncation: it could be implemented at full speed in the data path, instead of a separate process running on another CPU to generate, route, and send the ICMP packet.

All these advantages would come from truncation being "in-band", following the same path as the data packets, instead of being a special "out-of-band" message like ICMP packets are.

As for the flaws you listed:

1. The main complexity would come not from dealing with truncation itself (as you said, just treat it the same as a dropped packet), but from each protocol having to reflect the "truncated size" back to the original sender (like how ECN deals with marked packets).

2. The whole packet is not useless, the reason for truncating instead of turning it into an empty packet is to keep as much as possible of the higher layer headers. That is, most of the packet might be useless, but the higher layer headers at the start can be useful.

3. On the other hand, you might need several of these "quick" rejections before arriving at the ideal size.

> 3. You get an exact size limit of the entire path the packet took. Rather than just a "too big" of the first hop that wouldn't pass it.

ICMP does send the hop MTU, it's not just a "too big" signal. (But I do acknowledge that you're going for the PMTU in a single shot, and that's slightly neater.)

Both approaches seem like they wouldn't work with one-way routes? It's relatively rare, but I've worked on IP based telemetry systems with only one way, or highly asymmetric routes. Probably the most fun was tunneling IP from a space capsule, through the international space station's 1553-MIL-STD databus, through Houston, to California.

Wow, so no way to run TCP or otherwise get ACKs or NACK like packets back? Yikes.

Yeah. You wouldn't want to run TCP on those links anyway as the high latency and non-negligible loss rates would make TCP run like crap. This is where protocols like DTN are helpful, so long as you can interface your application with DTN. Fine for email, annoying for browsing, and painful for chat.

One way communication naturally makes it impossible to get any information back whatsoever so no dynamic solution is possible. Asymmetric should be able to be handled though, send and receive don't actually have to have the same MTU in this scenario.

The fallback for anything (one way, lazy, filtered connection, truly anything) is you always have your minimum MTU where the protocol is guaranteed to work at a given size and if it's not the protocol knows the solution will need to lie outside itself. IPv4/IPv6 already have this today.

My point is that fragmentation is a dynamic solution that works for one way links. It's really a very nice feature all things considered. As an embedded engineer that typically deals with controlled networks rather than the Internet, it means I can send up to a 64K UDP packet without overthinking it.

I think there is some confusion on what's happening in your example case. At minimum we know for sure this will happen:

- Local UDP socket bind receives a 65k payload to deliver

- Local IP stack looks at where this is going to go, sees it'll be going out an interface with 1.5k MTU

- Local IP stack creates 44 IP fragments of 1.5k and a final smaller fragment (Note: For IPv6 the IP stack must instead default to the safe-by-standard value of 1280 byte MTU since dynamic discovery could not be performed)

- 1.5k packets get sent to the network

I can guarantee these steps because no NIC or router uses 64k L2 frames for this to be able to reach the gateway unfragmented.

From here we run into a bit of a real world problem vs a theoretical how fragmentation could be done problem. The article touches on why a little bit: intermediate routers can fragment if they want but they aren't required to (overwhelming often they actually won't) but even fewer routers will bother re-fragmenting (what would need to be done here, as you already have 1.5k fragments) as it's significantly messier still. Even Linux won't re-fragment IP packets when doing pure software forwarding!

That all sounds about right to me. What's the confusion?

That's not a dynamic solution, the information is all static and local without any active MTU probing. Nothing about the other two probing methods changes the above steps in the one-way scenario, so why do you say they wouldn't work with one-way routes?

So the confusion is around the intended definition of the word "dynamic"? Sure, you can't rely on any feedback in a one way route situation.

My point is that IP fragmentation, as a method, gets packets through a network that would otherwise be truncated or dropped by other methods. It can also do it reasonably efficiently and conveniently, moreso than always assuming a worst case MTU at the application protocol layer.

I think what changes between methods is the use of fragmented packets to begin with? The whole premise is that IP fragmentation is bad because real world routers and firewalls don't support fragmentation properly. If fragmentation is deprecated, then wouldn't network stacks need to also start dropping oversized packets coming from user space applications?

Reply on news.ycombinator.com