5 ms·

If I could go back in time, I would replace fragmentation with in-flight truncation. The receiver sees the exact MTU and can communicate it back to the sender a

• zokier 3y ago
  Why would that be preferable over having routers just drop oversized packets and send icmp message to sender?
  • kevincox 3y ago
    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.
    • amluto 3y ago
      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.
      • zamadatix 3y ago
        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.
        • toast0 3y ago
          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.
    • cesarb 3y ago
      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.
      • deleted 3y ago
        [deleted]
      • deleted 3y ago
        [deleted]
    • deathanatos 3y ago
      > 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.)
  • sgtnoodle 3y ago
    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.
    • Scubabear68 3y ago
      Wow, so no way to run TCP or otherwise get ACKs or NACK like packets back? Yikes.
      • jandrese 3y ago
        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.
    • zamadatix 3y ago
      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.
      • sgtnoodle 3y ago
        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.
• Szpadel 3y ago
  serious question, how would be different from sending packed with no-fragment bit set?
  • zamadatix 3y ago
    The behavior of DNF is you either forward the whole thing or drop the whole thing.
  • deathanatos 3y ago
    The DF bit will cause the packet to get dropped & an ICMP response to maybe get generated. If your route looks like this, E_a -- MTU 1500 --> R_1 -- MTU 1200 --> R_2 -- MTU 1000 -> E_b Where E_a & E_b are the endpoints, with two routers. There PMTU is 1000; if you first emit a 1500 B packet with DF, R_1 will drop it, and emit an ICMP with the next hop MTU of 1200. You then have to emit another packet, and get another ICMP response from R_2 with the MTU of 1000, and now you know the PMTU, but it takes two failures to get there. OP's suggestion is a single round trip: you emit a 1500 B packet, E_b receives a truncated 1000 B packet. E_b responds to E_a saying "that got truncated to 1000 B" and now E_a knows the PMTU, in a single shot. In an simple design, we can call the truncated packet "worthless" and force E_a to repeat it with the right PMTU, but it's still only too a single packet from E_a to elicit the right value for the PMTU from the network.
• zamadatix 3y ago
  Say the active L2 path between two routers was: router A <-> switch B <-> switch C <-> router D Router A still needs to have a reliable, actively updating, way to detect the path MTU to Router D because something could change and the path turns into: router A <-> switch E <-> switch C <-> router D where switch E has a different MTU than the other equipment. Now you could go even further back and say the same happens for anything IP transits on top of but then the folks at Xerox PARC would probably wonder why the hell you're trying to make their hubs so damn smart and expensive and the people after them would probably wonder why the hell you're telling them to throw backwards compatibility with all the previous gear out the window in the name of making MTU slightly simpler. It's a decent solution I think you just have the time backwards - it's something we should look to do as we move towards the future and the overhead of such logic is tiny to add to networking rather than something to wish we had in the past when even dumb hubs were expensively complicated. This does leave one case unhandled though: you end up with a low MTU path at some point, things update so your traffic is going over a high MTU path, you still need to have some algorithm to discover this or the connection never recovers the performance.
  • cesarb 3y ago
    This discussion is about truncating at L3, not L2; it assumes that the L2 MTU is fixed and known by every directly connected router, but a L3 packet transits over several L2 networks, each with its own MTU. A L2 network with variable MTU (or a MTU too small for Internet packets, like ATM) has its own independent segmentation and reassembly logic.
    • zamadatix 3y ago
      Well that's the thing, for the real world the L3's MTU is limited by the L2 MTU. If you can guarantee L2 MTU will be fixed and known for every device along the path then there is not really a need for a variable L3 MTU anymore and you've solved the problem by convincing everyone in the world they'll never need or want a different MTU again. Then someone gets the bright idea they can do something with tunnels and it starts back up. If you want a world where you can rely on an L2 to have a way to handle the MTU mismatch then nothing is being solved by this other than the ability to say "fragmentation is not not in the current abstraction layer anymore, it's now an annoying problem on the layer below it instead" :).
• akira2501 3y ago
  Truncation and encryption are an unfavorable mix.