5 ms·

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 high

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.
  - zamadatix 3y ago
    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!
    - sgtnoodle 3y ago
      That all sounds about right to me. What's the confusion?
      - zamadatix 3y ago
        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?
        sgtnoodle 3y ago
        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?

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.
- zamadatix 3y ago
  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!
  - sgtnoodle 3y ago
    That all sounds about right to me. What's the confusion?
    - zamadatix 3y ago
      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?
      - sgtnoodle 3y ago
        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?