3 ms·

To me, this says a lot about expectations of conformance when many different entities need to implement the same spec. As the size of the spec or the number of

To me, this says a lot about expectations of conformance when many different entities need to implement the same spec. As the size of the spec or the number of entities grow, the probability of nonconformance approaches one. Then you end up with two specs: the ivory tower one, and the usable, actually implemented, lowest common denominator one. This problem seems especially acute when there are multiple hops on the path that are able to interpret (and fuck up with) data flowing through that hop. Especially when the owners of those hops don't have a direct economic connection to the entities dealing with their failures. This seems to argue in favor of something like QUIC. You use an extremely simple protocol for the transport (basically, "try to send this data to that address"). You hide the complex parts of the protocol in an encrypted channel so that only the economically connected stakeholders have to conform. This aligns incentives better than in the case of TCP and probably gives you better outcomes in the long run.

kevingadd 7y ago
The downside to QUIC is that all the other nodes in the chain lose the ability to do useful things. Of course in the long run it's turned out that Google et al do not want anyone else doing useful stuff, but for quite a while it was very useful to be able to have stuff in the middle like a caching proxy. Alas, that era is over. As an admin it's appealing to be able to have stuff like deep packet inspection to give me info on network traffic, but the price we pay collectively for that being possible is way too high so it was inevitable we'd lose it.
- kevin_thibedeau 7y ago
  The upside to QUIC is that all the other nodes in the chain lose the ability to do useful things. This behavior is why we can't use SCTP everywhere and can't deploy new protocols on top of IP.
  - touisteur 7y ago
    But I thought you could use SCTP over UDP (works, I tried). If QUIC is another layer above SCTP it feels like wasted effort. SCTP is really interesting and featureful. Multi-homing, parallel streams, datagram oriented...
    - pas 7y ago
      QUIC is basically SCTP over UDP. It has substreams (like HTTP/2, but it eliminates the TCP level head-of-line blocking), there's a multipath extension (proposal from 2018) - but maybe MP-TCP will land first and then who knows.
      - touisteur 7y ago
        Thanks for this answer but I still don't understand, sorry. What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? It's already in the kernel, seems to have had its own share of CVEs that it should now be relatively trustable? But it's also available in userland, especially over UDP. Performance is fine, from my benchmarks. Ease of use is (to me) far better than TCP and all the socket-hand-holding you need to do (if you don't use zmq because tired of writing the same all the time). Flexibility of substreams is amazing. Multi-homing is great so you can bond links at the applicative level (so, higher decoupling instead of ip-bonding). I'm genuinely curious as to why they haven't just taken SCTP as is, and added the extensions (?) they need.
        tialaramex 7y ago
        > What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? SCTP isn't encrypted. Because "Pervasive Monitoring is an Attack" new IETF protocols should be encrypted or explain why they can't be. HTTP/2 for example is in effect always encrypted (the document explains how one could in theory build an unencrypted variant but nobody implements that). > I'm genuinely curious as to why they haven't just taken SCTP as is, and added the extensions (?) they need. If you "just" drop the encrypted transport on top you either have to do all the work to deliver features like substreams yet again, or else all the metadata in the layer that's not encrypted is left unprotected and you'll regret that.
- asdfasgasdgasdg 7y ago
  Yeah, what's useful today will be ossified in ten or twenty years. That's kind of the point I was making (which you note in your second paragraph). If you want a healthy ecosystem you have to remove the ability of economically-disconnected middlemen to screw with your protocol. And the best way to do that is to make it as dead simple as possible, so there is very little leeway in implementation.

kevingadd 7y ago

The downside to QUIC is that all the other nodes in the chain lose the ability to do useful things. Of course in the long run it's turned out that Google et al do not want anyone else doing useful stuff, but for quite a while it was very useful to be able to have stuff in the middle like a caching proxy. Alas, that era is over. As an admin it's appealing to be able to have stuff like deep packet inspection to give me info on network traffic, but the price we pay collectively for that being possible is way too high so it was inevitable we'd lose it.

kevin_thibedeau 7y ago
The upside to QUIC is that all the other nodes in the chain lose the ability to do useful things. This behavior is why we can't use SCTP everywhere and can't deploy new protocols on top of IP.
- touisteur 7y ago
  But I thought you could use SCTP over UDP (works, I tried). If QUIC is another layer above SCTP it feels like wasted effort. SCTP is really interesting and featureful. Multi-homing, parallel streams, datagram oriented...
  - pas 7y ago
    QUIC is basically SCTP over UDP. It has substreams (like HTTP/2, but it eliminates the TCP level head-of-line blocking), there's a multipath extension (proposal from 2018) - but maybe MP-TCP will land first and then who knows.
    - touisteur 7y ago
      Thanks for this answer but I still don't understand, sorry. What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? It's already in the kernel, seems to have had its own share of CVEs that it should now be relatively trustable? But it's also available in userland, especially over UDP. Performance is fine, from my benchmarks. Ease of use is (to me) far better than TCP and all the socket-hand-holding you need to do (if you don't use zmq because tired of writing the same all the time). Flexibility of substreams is amazing. Multi-homing is great so you can bond links at the applicative level (so, higher decoupling instead of ip-bonding). I'm genuinely curious as to why they haven't just taken SCTP as is, and added the extensions (?) they need.
      - tialaramex 7y ago
        > What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? SCTP isn't encrypted. Because "Pervasive Monitoring is an Attack" new IETF protocols should be encrypted or explain why they can't be. HTTP/2 for example is in effect always encrypted (the document explains how one could in theory build an unencrypted variant but nobody implements that). > I'm genuinely curious as to why they haven't just taken SCTP as is, and added the extensions (?) they need. If you "just" drop the encrypted transport on top you either have to do all the work to deliver features like substreams yet again, or else all the metadata in the layer that's not encrypted is left unprotected and you'll regret that.
asdfasgasdgasdg 7y ago
Yeah, what's useful today will be ossified in ten or twenty years. That's kind of the point I was making (which you note in your second paragraph). If you want a healthy ecosystem you have to remove the ability of economically-disconnected middlemen to screw with your protocol. And the best way to do that is to make it as dead simple as possible, so there is very little leeway in implementation.