3 ms·

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 feat

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.
    - nitrogen 7y ago
      In addition to that I believe I've read that SCTP can't traverse all of the networks that TCP and UDP can, so any universal datagram protocol will have to build on UDP.
    - touisteur 7y ago
      Ah, encryption, thanks. Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436 https://tools.ietf.org/html/rfc3436 don't know whether any userland lib supports this with sctp-over-UDP.
      - tialaramex 7y ago
        I explained the negative consequences of just layering TLS on top in my comment already. RFC3436 just makes pairs of SCTP streams (one in each direction) into a transport like TCP that TLS will run on top of. Each such stream-pair then does a TLS handshake. That's not what QUIC does. The entire QUIC connection, however many streams and in whichever direction, is encrypted. As a very simple example - suppose you spin up three parallel stream pairs to fetch three separate documents over a hypothetical HTTP-over-TLS-over-SCTP. With RFC 3436 you reveal to an on-path adversary that there are three streams, and they get to see how much data travelled over each stream. But with QUIC it's just an opaque pipe, the on-path adversary can see how much data was transmitted each way but can't determine whether that's one document in one stream, or ten documents in two streams or anything else.
        touisteur 7y ago
        Sorry I did not mean to say you were wrong, I just meant to say 'it exists', for reference. I understood your first explanation, didn't know whether this RFC encrypted substream by substream or the whole session (I should have read more before posting). Thanks for the clarification. And your patience.
- toast0 7y ago
  > maybe MP-TCP will land first and then who knows. I'm not a fan of Apple, but they've deployed MP-TCP in iOS. I'm not an iOS developer, but it looks relatively simple to enable if you're already using NSURLSession [1]. Having a server to talk to is another thing, of course. :) [1] https://developer.apple.com/documentation/foundation/nsurlsessionconfiguration/improving_network_reliability_using_multipath_tcp https://developer.apple.com/documentation/foundation/nsurlse...

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.
  - nitrogen 7y ago
    In addition to that I believe I've read that SCTP can't traverse all of the networks that TCP and UDP can, so any universal datagram protocol will have to build on UDP.
  - touisteur 7y ago
    Ah, encryption, thanks. Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436 https://tools.ietf.org/html/rfc3436 don't know whether any userland lib supports this with sctp-over-UDP.
    - tialaramex 7y ago
      I explained the negative consequences of just layering TLS on top in my comment already. RFC3436 just makes pairs of SCTP streams (one in each direction) into a transport like TCP that TLS will run on top of. Each such stream-pair then does a TLS handshake. That's not what QUIC does. The entire QUIC connection, however many streams and in whichever direction, is encrypted. As a very simple example - suppose you spin up three parallel stream pairs to fetch three separate documents over a hypothetical HTTP-over-TLS-over-SCTP. With RFC 3436 you reveal to an on-path adversary that there are three streams, and they get to see how much data travelled over each stream. But with QUIC it's just an opaque pipe, the on-path adversary can see how much data was transmitted each way but can't determine whether that's one document in one stream, or ten documents in two streams or anything else.
      - touisteur 7y ago
        Sorry I did not mean to say you were wrong, I just meant to say 'it exists', for reference. I understood your first explanation, didn't know whether this RFC encrypted substream by substream or the whole session (I should have read more before posting). Thanks for the clarification. And your patience.
toast0 7y ago
> maybe MP-TCP will land first and then who knows. I'm not a fan of Apple, but they've deployed MP-TCP in iOS. I'm not an iOS developer, but it looks relatively simple to enable if you're already using NSURLSession [1]. Having a server to talk to is another thing, of course. :) [1] https://developer.apple.com/documentation/foundation/nsurlsessionconfiguration/improving_network_reliability_using_multipath_tcp https://developer.apple.com/documentation/foundation/nsurlse...