3 ms·

If I'm not mistaken, I think the MTU for IPv6 is at least 1280? But possibly also going to end up as no more than that because IPv6 does not necessarily require

If I'm not mistaken, I think the MTU for IPv6 is at least 1280? But possibly also going to end up as no more than that because IPv6 does not necessarily require people to support more than that? If so, then that could mean that packet sizes are going to be constant over the next 20 years, all the while that protocols and pipes get many times faster and bigger. If I'm not mistaken, those smaller and smaller packet sizes (relative to faster and faster networks) are going to mean tremendous packet switching overhead (routing, encryption) especially in protocols such as QUIC which try to align encryption with packets. Sort of like a plane having to stop at every red light in a traffic grid designed for cars.

cm2187 11y ago
Are they really going to increase in speed? With 10GBit ethernet, we are getting close to the speed at which you transfer data in and out of RAM. I am sure we would like to have faster networks but will we be able to use faster networks (I mean for the end user)?
- corobo 11y ago
  > close to the speed at which you transfer data in and out of RAM On a single machine. There's still a bit of room for faster connectivity now that everything's hooked up to the internet and streaming ever-bigger HD video. Infrastructure devices might need a bit of an upgrade though when we hit their limits
pjc50 11y ago
https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981 : path MTU discovery SHOULD be implemented in IPv6.
- jorangreef 11y ago
  Thanks, that is my concern. I think the "SHOULD" should have been a "MUST" (or should still be changed to a "MUST") to ensure a forward upgrade path for larger MTU in future. Otherwise, the network is going to be limited by the lowest common denominator, namely those clients which do not implement any path MTU discovery because it's not a MUST, and only support an MTU of at least 1280 (but no more).
  - throwaway2048 11y ago
    You have to realize that RFCs are not a cudgel to bludgeon people into acting how you would like them to, that never ever works out in reality (at one point IPSEC was a mandatory MUST for ipv6 deployments) because people are free to just ignore them if it makes their life too difficult, and trust me they can and will, no matter what any standard says. RFCs should, and at least with the popular ones, generally do, reflect the status of how things actually work on the internet, not how we might wish they did. If your standards ignore reality, they in turn will be ignored. Rightly or wrongly a LOT of networks block ICMP wholesale, and thus block pmtud, it does not matter if some word in a text document changes somewhere, this will continue to be a reality, so you better be aware of it and be able to cope with it. Rough consensus and running code.
    - jorangreef 11y ago
      I doubt that "how things actually work on the internet" is "generally" reflected by RFCs. The history of the internet is people trying to work around and fix RFCs actually ("at least with the popular ones"). If you're going to say "SHOULD" you may as well leave it out because people won't follow it.
      - throwaway2048 11y ago
        You are still taking a way too strongly legalistic view of things, standards are not laws (usually). Its not a "everybody conforms to the spec 100% or its worthless" situation in the vast majority of cases. SHOULDs exist precisely because of situations like pmtud, you cannot gaurentee it will be supported, but when it is supported it is helpful and useful.
        jorangreef 11y ago
        Frankly, the original concern is that fixed packet sizes relative to increasing capabilities are not a good idea for future hardware and software performance (think silly window syndrome or allocating a million 1-byte buffers). It's a technical problem that needs a technical solution (preferably through clearer language describing the issue or else we need to rethink things). I guess most people are simply not writing protocols that will be influenced by these decisions, so they fail to see the impact. Furthermore, no one said this was about "cudgels" and "bludgeons" or being "too strongly legalistic" or writing "laws". Those are your words, not mine.

cm2187 11y ago

Are they really going to increase in speed? With 10GBit ethernet, we are getting close to the speed at which you transfer data in and out of RAM. I am sure we would like to have faster networks but will we be able to use faster networks (I mean for the end user)?

corobo 11y ago
> close to the speed at which you transfer data in and out of RAM On a single machine. There's still a bit of room for faster connectivity now that everything's hooked up to the internet and streaming ever-bigger HD video. Infrastructure devices might need a bit of an upgrade though when we hit their limits

pjc50 11y ago

https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981 : path MTU discovery SHOULD be implemented in IPv6.

jorangreef 11y ago
Thanks, that is my concern. I think the "SHOULD" should have been a "MUST" (or should still be changed to a "MUST") to ensure a forward upgrade path for larger MTU in future. Otherwise, the network is going to be limited by the lowest common denominator, namely those clients which do not implement any path MTU discovery because it's not a MUST, and only support an MTU of at least 1280 (but no more).
- throwaway2048 11y ago
  You have to realize that RFCs are not a cudgel to bludgeon people into acting how you would like them to, that never ever works out in reality (at one point IPSEC was a mandatory MUST for ipv6 deployments) because people are free to just ignore them if it makes their life too difficult, and trust me they can and will, no matter what any standard says. RFCs should, and at least with the popular ones, generally do, reflect the status of how things actually work on the internet, not how we might wish they did. If your standards ignore reality, they in turn will be ignored. Rightly or wrongly a LOT of networks block ICMP wholesale, and thus block pmtud, it does not matter if some word in a text document changes somewhere, this will continue to be a reality, so you better be aware of it and be able to cope with it. Rough consensus and running code.
  - jorangreef 11y ago
    I doubt that "how things actually work on the internet" is "generally" reflected by RFCs. The history of the internet is people trying to work around and fix RFCs actually ("at least with the popular ones"). If you're going to say "SHOULD" you may as well leave it out because people won't follow it.
    - throwaway2048 11y ago
      You are still taking a way too strongly legalistic view of things, standards are not laws (usually). Its not a "everybody conforms to the spec 100% or its worthless" situation in the vast majority of cases. SHOULDs exist precisely because of situations like pmtud, you cannot gaurentee it will be supported, but when it is supported it is helpful and useful.
      - jorangreef 11y ago
        Frankly, the original concern is that fixed packet sizes relative to increasing capabilities are not a good idea for future hardware and software performance (think silly window syndrome or allocating a million 1-byte buffers). It's a technical problem that needs a technical solution (preferably through clearer language describing the issue or else we need to rethink things). I guess most people are simply not writing protocols that will be influenced by these decisions, so they fail to see the impact. Furthermore, no one said this was about "cudgels" and "bludgeons" or being "too strongly legalistic" or writing "laws". Those are your words, not mine.