2 ms·

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 diffe

by 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
    > [better than] transparently fragmenting packets In v6 there is no fragmentation anymore if I remember correctly, it would just get dropped (or maybe trigger an ICMP error, I don't know).
mcguire 10y ago
Additionally, this would tell the receiver the sender->receiver MTU, which doesn't do much good since the receiver->sender path may not be symmetric. You'd need four bytes, and 32 bits is a large chunk of the IP header. You could use options, but you still have to deal with broken firewall hardware.

by magnat 10y ago

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
  > [better than] transparently fragmenting packets In v6 there is no fragmentation anymore if I remember correctly, it would just get dropped (or maybe trigger an ICMP error, I don't know).

mcguire 10y ago

Additionally, this would tell the receiver the sender->receiver MTU, which doesn't do much good since the receiver->sender path may not be symmetric. You'd need four bytes, and 32 bits is a large chunk of the IP header. You could use options, but you still have to deal with broken firewall hardware.