6 ms·

sctp (https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...) has both reliable deli

sctp (https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...) has both reliable delivery and transport level message framing. multistream, multipath, and linux and bsd support. not much uptake though. maybe if the quic people had built on it instead of udp

kev009 8y ago
It's used in SIGTRAN/SS7 so just about any phone call, cell session etc is sctp. As an aside rrs, the primary author of spec, book, and reference implementation, still occasionally works on the FreeBSD sctp and has recently rewritten the FreeBSD TCP stack over the past few years. It's called RACK, and there's another extension in the pipe called BBR with incorporates ideas from Google's work. A very amazing person! * https://penturalabs.wordpress.com/2013/11/24/what-is-sigtran-ss7-sctp/ https://penturalabs.wordpress.com/2013/11/24/what-is-sigtran... * https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_stacks/rack.c https://github.com/freebsd/freebsd/blob/master/sys/netinet/t...
lallysingh 8y ago
It's used in WebRTC data channels, atop of UDP and DTLS. It's not used above raw IP because few intermediate routers support it.
pilif 8y ago
> maybe if the quic people had built on it instead of udp Then QUIC would be as dead in the water as sctp is: between all the middleboxes currently running the internet it’s impossible to pass any low level protocol that wasn’t in use in the late 90ies when firewalls started to happen. As a matter of fact, quic is an attempt to get sctp like semantics going over a protocol that has a chance of being transmittable over the internet. In order for sctp to gain uptake, we need to collectively update all routers, firewalls, OSes and applications. In order for quic to gain uptake, we need to update applications.
- kev009 8y ago
  QUIC is kind of like a relaxed TCP over UDP. You can do SCTP over UDP (aka WebRTC), and TCP over UDP to gain those application-managed benefits with varying upper level trade offs. SCTP has pretty wide support, but it's kind of like an IPv6-lite in terms of re-education and that is the barrier to move forward if to supplant or scalably supplement TCP for the web.
peterwwillis 8y ago
> maybe if the quic people had built on it instead of udp I've noticed that all modern protocols are designed by lower-tier engineers in teams in departments in corporations that want new functionality in some product they make, but can't wait to propose a modification to an internet or web standard that will take 5 years to get adopted by all the vendors and service providers they want to use it, and they refuse to make a native app to do it. This gives you protocols like WebSockets, WebRTC, QUIC. On the application side you get things like WebAssembly. So a few companies are slowly cobbling together their distributed operating system for web applications called a "web browser". I think the unspoken plan is to subvert all native computing platforms by evolving web browsers into a reinvented Java-esque application platform. But ironically I don't think this was intentional. I think everyone's just lazy and reinventing every wheel to fit their niche, which just happens to be web apps. In 10+ years there may be a new platform and paradigm, and all this stuff will be obsolete, even though it'll do basically the same things.
- dagenix 8y ago
  I don't see how any of this is true. The problem with SCTP is that middleboxes don't understand it and tend to drop it. This create an unfortunate situation where middleboxes refuse to support it because no-one uses it and no-one uses it because middleboxes refuse to support it. You can't just create a standard that says everyone should support SCTP and make everyone do it - standards already say that middleboxes should support it and they don't. Its bizarre that you picked WebSockets, WebRTC, and QUIC as examples of how no one supports the standardization process. WebSockets were standardized via RFC 6455 in 2011, WebRTC via W3C, work with starting in ~2011, and QUIC implemented in 2012, with IETF standardization currently underway. These are all 6+ year investments by their sponsors.
  - wtallis 8y ago
    The sane development path would have been to build QUIC as a thin layer on top of SCTP, with a fallback to UDP implemented only if it proved necessary. I don't think the middlebox problem is a showstopper for a limited-audience experimental protocol like QUIC, and a successful QUIC-over-SCTP experiment could have gotten rid of the middlebox worries (by either motivating people to get rid of the broken middleboxes, or by proving they weren't common enough to care about), in much the same way that Apple's limited deployment of ECN has eliminated the worries about middleboxes that kill ECN flows. As for WebSockets, WebRTC, and WebAssembly, the fact that they've been standardized within their insular niche says nothing about the extent to which they duplicate functionality that has long existed outside the browser as part of the host OS or as libraries that use the low-level networking constructs that any native application has access to (but JavaScript didn't).
MertsA 8y ago
I really wish QUIC, WebRTC, etc would have standardized on SCTP over UDP for IPv4 and raw SCTP for IPv6. We don't need to reinvent the wheel, and we had (still have?) a bonafide opportunity to get out in front of the situation with IPv6. If we got actual adoption of SCTP before ye olde middlebox vendors started mucking things up on IPv6 like on IPv4 we wouldn't have to tunnel a protocol that was standardized over 18 years ago just to be able to use it on the internet. Things like multihoming make even more sense with IPv6 and the explosion of mobile devices. It just kills me inside that we already solved this problem in a way that's just about transparent to most all applications but it looks like we're never going to get widespread support because some middleboxes and NAT implementations couldn't be bothered to support it.

kev009 8y ago

It's used in SIGTRAN/SS7 so just about any phone call, cell session etc is sctp. As an aside rrs, the primary author of spec, book, and reference implementation, still occasionally works on the FreeBSD sctp and has recently rewritten the FreeBSD TCP stack over the past few years. It's called RACK, and there's another extension in the pipe called BBR with incorporates ideas from Google's work. A very amazing person! * https://penturalabs.wordpress.com/2013/11/24/what-is-sigtran-ss7-sctp/ https://penturalabs.wordpress.com/2013/11/24/what-is-sigtran... * https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_stacks/rack.c https://github.com/freebsd/freebsd/blob/master/sys/netinet/t...

lallysingh 8y ago

It's used in WebRTC data channels, atop of UDP and DTLS. It's not used above raw IP because few intermediate routers support it.

pilif 8y ago

> maybe if the quic people had built on it instead of udp Then QUIC would be as dead in the water as sctp is: between all the middleboxes currently running the internet it’s impossible to pass any low level protocol that wasn’t in use in the late 90ies when firewalls started to happen. As a matter of fact, quic is an attempt to get sctp like semantics going over a protocol that has a chance of being transmittable over the internet. In order for sctp to gain uptake, we need to collectively update all routers, firewalls, OSes and applications. In order for quic to gain uptake, we need to update applications.

kev009 8y ago
QUIC is kind of like a relaxed TCP over UDP. You can do SCTP over UDP (aka WebRTC), and TCP over UDP to gain those application-managed benefits with varying upper level trade offs. SCTP has pretty wide support, but it's kind of like an IPv6-lite in terms of re-education and that is the barrier to move forward if to supplant or scalably supplement TCP for the web.

peterwwillis 8y ago

> maybe if the quic people had built on it instead of udp I've noticed that all modern protocols are designed by lower-tier engineers in teams in departments in corporations that want new functionality in some product they make, but can't wait to propose a modification to an internet or web standard that will take 5 years to get adopted by all the vendors and service providers they want to use it, and they refuse to make a native app to do it. This gives you protocols like WebSockets, WebRTC, QUIC. On the application side you get things like WebAssembly. So a few companies are slowly cobbling together their distributed operating system for web applications called a "web browser". I think the unspoken plan is to subvert all native computing platforms by evolving web browsers into a reinvented Java-esque application platform. But ironically I don't think this was intentional. I think everyone's just lazy and reinventing every wheel to fit their niche, which just happens to be web apps. In 10+ years there may be a new platform and paradigm, and all this stuff will be obsolete, even though it'll do basically the same things.

dagenix 8y ago
I don't see how any of this is true. The problem with SCTP is that middleboxes don't understand it and tend to drop it. This create an unfortunate situation where middleboxes refuse to support it because no-one uses it and no-one uses it because middleboxes refuse to support it. You can't just create a standard that says everyone should support SCTP and make everyone do it - standards already say that middleboxes should support it and they don't. Its bizarre that you picked WebSockets, WebRTC, and QUIC as examples of how no one supports the standardization process. WebSockets were standardized via RFC 6455 in 2011, WebRTC via W3C, work with starting in ~2011, and QUIC implemented in 2012, with IETF standardization currently underway. These are all 6+ year investments by their sponsors.
- wtallis 8y ago
  The sane development path would have been to build QUIC as a thin layer on top of SCTP, with a fallback to UDP implemented only if it proved necessary. I don't think the middlebox problem is a showstopper for a limited-audience experimental protocol like QUIC, and a successful QUIC-over-SCTP experiment could have gotten rid of the middlebox worries (by either motivating people to get rid of the broken middleboxes, or by proving they weren't common enough to care about), in much the same way that Apple's limited deployment of ECN has eliminated the worries about middleboxes that kill ECN flows. As for WebSockets, WebRTC, and WebAssembly, the fact that they've been standardized within their insular niche says nothing about the extent to which they duplicate functionality that has long existed outside the browser as part of the host OS or as libraries that use the low-level networking constructs that any native application has access to (but JavaScript didn't).

MertsA 8y ago

I really wish QUIC, WebRTC, etc would have standardized on SCTP over UDP for IPv4 and raw SCTP for IPv6. We don't need to reinvent the wheel, and we had (still have?) a bonafide opportunity to get out in front of the situation with IPv6. If we got actual adoption of SCTP before ye olde middlebox vendors started mucking things up on IPv6 like on IPv4 we wouldn't have to tunnel a protocol that was standardized over 18 years ago just to be able to use it on the internet. Things like multihoming make even more sense with IPv6 and the explosion of mobile devices. It just kills me inside that we already solved this problem in a way that's just about transparent to most all applications but it looks like we're never going to get widespread support because some middleboxes and NAT implementations couldn't be bothered to support it.