4 ms·

Good observation. But it's not a deal-breaker. The receiving host can report that MTU back to the sender (to which it would really apply in case of asymmetric p

by ambrop7 10y ago

Good observation. But it's not a deal-breaker. The receiving host can report that MTU back to the sender (to which it would really apply in case of asymmetric paths), e.g. as part of the TCP handshake in a TCP option, and possibly subsequently if it changes. I'm sure there are details that would have to be ironed out. Like what happens if the MTU of the path is then reduced (does this result in dropped packets and leads to a stall? - possible fix is to say the packets are truncated instead allowing the MTU to be propagated).

vbernat 10y ago
IP is stateless. Paths are changing. First packet has to be able to reach its final destination. Overall, the solution seems to quickly become complicated and routers need to modify headers and recompute checksums, something that was removed from IPv6.
- ambrop7 10y ago
  Yes. If the path changes to one with a lower MTU, there might be a problem. Could be solved by truncating the packet instead of dropping it. Actually, I think this would be an even better approach. No extra field in the IP header, just truncation of packets that are too large, without changing the packet length field in the IP header. Upon seeing a truncated packet, the receiver could inform the sender of the detected path MTU (the length of the received packet). EDIT: Well, if the MTU in the other direction also decreased, we might have an issue, as the stack might decline to interpret the transport layer payload. Don't know how to solve that right now, but probably there are ways. Maybe some mechanism to allow the protocol layer (TCP) to still successfully validate the TCP checksum knowing that the packet was truncated.
  - lucb1e 10y ago
    You're receiving lots of criticism from people that (correctly) see issues with your proposal. I just wanted to say that I like your thinking. Rather than going "doesn't work because scenario x" you work the problem and try to find something that does work. It sounds like a good idea, an MTU header in IP. The header can be extended if I remember correctly, so it might even be feasible to implement with backwards compatibility (avoiding another v6 to v7 transition). I don't know how v6 was designed exactly, but if it's open, did you search back to see if someone proposed this and why it was rejected (if ever proposed)?
vitus 10y ago
Some middleboxes try to "understand" TCP, and by that I mean they strip out TCP options [0]. Ditto with IP [1]. Options are just not a reliable mechanism for critical protocol features, these days. [0] http://conferences.sigcomm.org/imc/2011/docs/p181.pdf http://conferences.sigcomm.org/imc/2011/docs/p181.pdf [1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-...

by ambrop7 10y ago

vbernat 10y ago

IP is stateless. Paths are changing. First packet has to be able to reach its final destination. Overall, the solution seems to quickly become complicated and routers need to modify headers and recompute checksums, something that was removed from IPv6.

ambrop7 10y ago
Yes. If the path changes to one with a lower MTU, there might be a problem. Could be solved by truncating the packet instead of dropping it. Actually, I think this would be an even better approach. No extra field in the IP header, just truncation of packets that are too large, without changing the packet length field in the IP header. Upon seeing a truncated packet, the receiver could inform the sender of the detected path MTU (the length of the received packet). EDIT: Well, if the MTU in the other direction also decreased, we might have an issue, as the stack might decline to interpret the transport layer payload. Don't know how to solve that right now, but probably there are ways. Maybe some mechanism to allow the protocol layer (TCP) to still successfully validate the TCP checksum knowing that the packet was truncated.
- lucb1e 10y ago
  You're receiving lots of criticism from people that (correctly) see issues with your proposal. I just wanted to say that I like your thinking. Rather than going "doesn't work because scenario x" you work the problem and try to find something that does work. It sounds like a good idea, an MTU header in IP. The header can be extended if I remember correctly, so it might even be feasible to implement with backwards compatibility (avoiding another v6 to v7 transition). I don't know how v6 was designed exactly, but if it's open, did you search back to see if someone proposed this and why it was rejected (if ever proposed)?

vitus 10y ago

Some middleboxes try to "understand" TCP, and by that I mean they strip out TCP options [0]. Ditto with IP [1]. Options are just not a reliable mechanism for critical protocol features, these days. [0] http://conferences.sigcomm.org/imc/2011/docs/p181.pdf http://conferences.sigcomm.org/imc/2011/docs/p181.pdf [1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-...