3 ms·

It's a shame because the datagram paradigm is so much more elegant. In real world cases you end up having to emulate it by putting length prefixed data in TCP s

It's a shame because the datagram paradigm is so much more elegant. In real world cases you end up having to emulate it by putting length prefixed data in TCP streams, reducing TCP timeouts, constantly reconnecting sockets (with the latency penalty), etc. Really, the only thing that's missing from UDP is (optional) backpressure. A lot of software can handle out-of-order datagrams with no performance penalty (like file uploads, etc.). This is especially annoying when you're operating in an environment with link aggregation where the interface insists on limiting your bandwidth to a single link.

simcop2387 1y ago
This is one reason that I'm still upset about the failure that SCTP has ended up. It really did try to create a new protocol for dealing with exactly all of these issues but support and ossification basically meant it's a non-starter. I'd have loved if it was a mandatory part of IPv6 so that it'd eventually get useful support but I'm pretty sure that would have made IPv6 adoption even worse.
- Veserv 1y ago
  Well we have QUIC now which layers over UDP and is functionally strictly superior to SCTP as SCTP still suffered from head-of-line blocking due to bad acknowledgement design.
- lxgr 1y ago
  As long as you're fine with UDP encapsulation, you can definitely use SCTP today! WebRTC data channels do, for example.
lxgr 1y ago
> the only thing that's missing from UDP is (optional) backpressure. The lack of congestion control seems significant too. Most message-oriented protocols layered on top of UDP end up adding that back at the application layer as a consequence.
klabb3 1y ago
Agreed but I think it’s better to use streams and deliver messages reliably and in order today, despite the extra effort. For instance, TLS is stateful. If you want to deliver unannounced (stateless) datagrams to a server, you’d technically be able to use the servers pubkey but you’d have to sacrifice forward secrecy. Making business logic with dropped packets and OOO delivery is also very difficult depending on domain. Personally I would like to see faster bootstrap and especially resumes of streams to eliminate handshake cost. For instance: - resume with last shared secret for 0rtt handshake (I believe Quic supports this) - allow the dialer to queue/send data before ack (this is an API-breaking change on sockets, but worthwhile imo - it makes socket FSM on app layer easier to use because it never needs to be nil

simcop2387 1y ago

This is one reason that I'm still upset about the failure that SCTP has ended up. It really did try to create a new protocol for dealing with exactly all of these issues but support and ossification basically meant it's a non-starter. I'd have loved if it was a mandatory part of IPv6 so that it'd eventually get useful support but I'm pretty sure that would have made IPv6 adoption even worse.

Veserv 1y ago
Well we have QUIC now which layers over UDP and is functionally strictly superior to SCTP as SCTP still suffered from head-of-line blocking due to bad acknowledgement design.
lxgr 1y ago
As long as you're fine with UDP encapsulation, you can definitely use SCTP today! WebRTC data channels do, for example.

lxgr 1y ago

> the only thing that's missing from UDP is (optional) backpressure. The lack of congestion control seems significant too. Most message-oriented protocols layered on top of UDP end up adding that back at the application layer as a consequence.

klabb3 1y ago

Agreed but I think it’s better to use streams and deliver messages reliably and in order today, despite the extra effort. For instance, TLS is stateful. If you want to deliver unannounced (stateless) datagrams to a server, you’d technically be able to use the servers pubkey but you’d have to sacrifice forward secrecy. Making business logic with dropped packets and OOO delivery is also very difficult depending on domain. Personally I would like to see faster bootstrap and especially resumes of streams to eliminate handshake cost. For instance: - resume with last shared secret for 0rtt handshake (I believe Quic supports this) - allow the dialer to queue/send data before ack (this is an API-breaking change on sockets, but worthwhile imo - it makes socket FSM on app layer easier to use because it never needs to be nil