3 ms·

Actually, the mistake in IP was in not encrypting the next layer, so that networks can block transport protocol innovation by filtering anything other than TCP

by ajb 2y ago

Actually, the mistake in IP was in not encrypting the next layer, so that networks can block transport protocol innovation by filtering anything other than TCP and UDP. This is the mistake that quic has fixed.

Ekaros 2y ago
I think that one can be forgiven for pure lack of processing power... We forget just how under powered even host machines were and how resource hungry encryption is...
d-z-m 2y ago
QUIC still runs over UDP. Are you referring to MASQUE?
- ajb 2y ago
  I should perhaps have said "works round" rather than fixes - yes, it has to run over UDP but the quic team had an explicit goal of not allowing the network to interfere further : see sec 3.3 and 7.5 of https://dl.acm.org/doi/pdf/10.1145/3098822.3098842 https://dl.acm.org/doi/pdf/10.1145/3098822.3098842 This now means that innovations based on Quic can occur
  - mycall 2y ago
    Since both QUIC and UDP are transport layers, does this mean that once switches and ISPs start supporting QUIC along side UDP and TCP, that a new version of QUIC can be released which doesn't require UDP?
    - ajb 2y ago
      Switches don't need to change anything to support QUIC, precisely because it uses UDP. So, the deployment of QUIC doesn't involve any technical changes that would enable a version of QUIC that worked directly over IP. It's possible that the defeat of middleboxes would change the motivation of ISPs to filter out alternate protocol numbers, meaning that there might be less resistance to getting them to allow that in the future - but doing so is still a big exercise. Also, the overhead of a UDP packet is 8 bytes total, in 4 16-bit fields: - source port - dest port - length - checksum So, we can save a max of 8 bytes per packet - how many of these can we practically save? The initial connection requires source and dest ports, but also sets up other connection IDs so theoretically you could save them on subsequent packets (but that's pure speculation, with zero due diligence on my part). It would require operational changes and would make any NATs tricky (so practically only for IPv6) Length and checksum maybe you can save - QUIC has multiple frames per UDP datagram so there must be another length field there (anyway, IETF is busily inventing a UDP options format on the basis that the UDP length field is redundant to packet length, so can be used to point at an options trailer). QUIC has integrity protection but it doesn't seem to apply to all packet types - however I guess a checksum could be retained for those that don't only. So in sum maybe you could save up to 8 bytes per packet, but it would still be a lot of work to do so (removing port numbers especially)
DoneWithAllThat 2y ago
This was absolutely not feasible at the time IP was being developed. There simply wasn’t enough computational power available or good encryption algorithms invented yet. And you can make a reasonable argument that that’s not the responsibility of that layer of the stack.
LtWorf 2y ago
Encryption without authentication is rather useless. Just slows things down for no advantage.

by ajb 2y ago

Ekaros 2y ago

I think that one can be forgiven for pure lack of processing power... We forget just how under powered even host machines were and how resource hungry encryption is...

d-z-m 2y ago

QUIC still runs over UDP. Are you referring to MASQUE?

ajb 2y ago
I should perhaps have said "works round" rather than fixes - yes, it has to run over UDP but the quic team had an explicit goal of not allowing the network to interfere further : see sec 3.3 and 7.5 of https://dl.acm.org/doi/pdf/10.1145/3098822.3098842 https://dl.acm.org/doi/pdf/10.1145/3098822.3098842 This now means that innovations based on Quic can occur
- mycall 2y ago
  Since both QUIC and UDP are transport layers, does this mean that once switches and ISPs start supporting QUIC along side UDP and TCP, that a new version of QUIC can be released which doesn't require UDP?
  - ajb 2y ago
    Switches don't need to change anything to support QUIC, precisely because it uses UDP. So, the deployment of QUIC doesn't involve any technical changes that would enable a version of QUIC that worked directly over IP. It's possible that the defeat of middleboxes would change the motivation of ISPs to filter out alternate protocol numbers, meaning that there might be less resistance to getting them to allow that in the future - but doing so is still a big exercise. Also, the overhead of a UDP packet is 8 bytes total, in 4 16-bit fields: - source port - dest port - length - checksum So, we can save a max of 8 bytes per packet - how many of these can we practically save? The initial connection requires source and dest ports, but also sets up other connection IDs so theoretically you could save them on subsequent packets (but that's pure speculation, with zero due diligence on my part). It would require operational changes and would make any NATs tricky (so practically only for IPv6) Length and checksum maybe you can save - QUIC has multiple frames per UDP datagram so there must be another length field there (anyway, IETF is busily inventing a UDP options format on the basis that the UDP length field is redundant to packet length, so can be used to point at an options trailer). QUIC has integrity protection but it doesn't seem to apply to all packet types - however I guess a checksum could be retained for those that don't only. So in sum maybe you could save up to 8 bytes per packet, but it would still be a lot of work to do so (removing port numbers especially)

DoneWithAllThat 2y ago

This was absolutely not feasible at the time IP was being developed. There simply wasn’t enough computational power available or good encryption algorithms invented yet. And you can make a reasonable argument that that’s not the responsibility of that layer of the stack.

LtWorf 2y ago

Encryption without authentication is rather useless. Just slows things down for no advantage.