5 ms·

Considering the MTU issues: Does anyone know why this was not solved in IP (and IPv6) by the following method: 1) There is a field MTU in the IP header. 2) Th

by ambrop7 10y ago

Considering the MTU issues: Does anyone know why this was not solved in IP (and IPv6) by the following method: 1) There is a field MTU in the IP header. 2) The sending host sets MTU := <MTU of the outgoing link>. 3) Any router on the path sets MTU := min(MTU, <MTU of outgoing link>). 4) The receiving host instantly knows the MTU of the path (the MTU field). This seems like a much simpler, more reliable and more efficient system than PMTU discovery: no problems with firewalls blocking ICMP, no additional delay due to too large packets. All at the cost of a single minimization operation at the router. The IP header checksum would need to be recalculated, but, due to the simplicity of the IP checksum, fixing it up changing one word is trivial (AFAIK). I can imagine a potential issue with adding that to IPv6 when it was designed, that IPv6 should be tunnelable over IPv4 which doesn't have this, but still surely there are ways to deal with that.

vbernat 10y ago
A path may not be symmetric.
- 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-...
magnat 10y ago
IP is based on packet switching and has no concept of a circuit/connection. Each subsequent packet sent between same endpoint can take different path with different PMTU. Also, dedicating even two bytes in each and every IP packet just for MTU would be quite an overhead, especially since IP already has a mechanism (fragmentation) to deal with this.
- ambrop7 10y ago
  > no concept of a circuit/connection This is true but I don't see how that is relevant here. My proposal does not change this. It's just about a field in the header and logic required at routers for updating it. > Each subsequent packet sent between same endpoint can take different path with different PMTU. That is true for the existing Internet as is, and is also an issue for PMTU discovery. It's not a new issue caused by this proposed design. It can be addressed in the similar way as it is now (I don't know exactly how it is...). I don't buy the "quite an overhead" argument - it wasn't a problem to extend the IP header from 20 to 40 bytes going from IPv4 to IPv6. For this you'd need just 2 bytes. There may also be a different but similar approach: have routers truncate (not drop) too large packets but leave the "packet length" field intact. Upon seeign a truncated packet the receiver would know that the packet is too large, and what the path MTU is (the size of the packet).
  - magnat 10y ago
    If there is no circuit concept in the IPv4 and IPv6, then the value of the field could (in principle) vary wildly from packet to packet. In real life condition it most likely wouldn't - and even if it would, maybe that would be actually better than transparently fragmenting packets just because MTU changed after higher level connection has been established. IPv6 packet header is significantly simplified when compared to IPv4. Although it is twice as large, almost all non-essential fields have been moved to extension headers. I guess it wouldn't hurt too much if there was an optional header with PMTU updated by all supporting routers along the path, especially when there is no checksum field in IPv6 packet.
    - lucb1e 10y ago
deleted 10y ago
[deleted]
xenadu02 10y ago
In reality the MTU is 1500 because the odds of all devices on a given path supporting anything larger is almost zero. The only way IPv6 could have helped was mandating a larger fixed known MTU... say 4096 or 8192.
zrm 10y ago
> 1) There is a field MTU in the IP header. You don't need this in every packet, you only need it in one packet (or once every few minutes). Instead of putting a field in every packet that only <1% of them need, we could create an out of band message to notify when the MTU has been exceeded. And the endpoint that needs to know that is the sender, so that's who you would send it to. Which is what they did. That works perfectly well, the problem is that many misconfigured firewalls drop the ICMP messages. No one predicted that level of incompetence when the protocols were being designed.

by ambrop7 10y ago

vbernat 10y ago

A path may not be symmetric.

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-...

magnat 10y ago

IP is based on packet switching and has no concept of a circuit/connection. Each subsequent packet sent between same endpoint can take different path with different PMTU. Also, dedicating even two bytes in each and every IP packet just for MTU would be quite an overhead, especially since IP already has a mechanism (fragmentation) to deal with this.

ambrop7 10y ago
> no concept of a circuit/connection This is true but I don't see how that is relevant here. My proposal does not change this. It's just about a field in the header and logic required at routers for updating it. > Each subsequent packet sent between same endpoint can take different path with different PMTU. That is true for the existing Internet as is, and is also an issue for PMTU discovery. It's not a new issue caused by this proposed design. It can be addressed in the similar way as it is now (I don't know exactly how it is...). I don't buy the "quite an overhead" argument - it wasn't a problem to extend the IP header from 20 to 40 bytes going from IPv4 to IPv6. For this you'd need just 2 bytes. There may also be a different but similar approach: have routers truncate (not drop) too large packets but leave the "packet length" field intact. Upon seeign a truncated packet the receiver would know that the packet is too large, and what the path MTU is (the size of the packet).
- magnat 10y ago
  If there is no circuit concept in the IPv4 and IPv6, then the value of the field could (in principle) vary wildly from packet to packet. In real life condition it most likely wouldn't - and even if it would, maybe that would be actually better than transparently fragmenting packets just because MTU changed after higher level connection has been established. IPv6 packet header is significantly simplified when compared to IPv4. Although it is twice as large, almost all non-essential fields have been moved to extension headers. I guess it wouldn't hurt too much if there was an optional header with PMTU updated by all supporting routers along the path, especially when there is no checksum field in IPv6 packet.
  - lucb1e 10y ago

deleted 10y ago

[deleted]

xenadu02 10y ago

In reality the MTU is 1500 because the odds of all devices on a given path supporting anything larger is almost zero. The only way IPv6 could have helped was mandating a larger fixed known MTU... say 4096 or 8192.

zrm 10y ago

> 1) There is a field MTU in the IP header. You don't need this in every packet, you only need it in one packet (or once every few minutes). Instead of putting a field in every packet that only <1% of them need, we could create an out of band message to notify when the MTU has been exceeded. And the endpoint that needs to know that is the sender, so that's who you would send it to. Which is what they did. That works perfectly well, the problem is that many misconfigured firewalls drop the ICMP messages. No one predicted that level of incompetence when the protocols were being designed.