The protocol that ALMOST replaced TCP!

Technological concepts and motivation

UDP vs TCP reliability tradeoffs

• UDP is framed as “unreliable” mainly because it does not guarantee delivery, ordering, or congestion control.
• UDP can still drop malformed packets via a checksum (integrity check), but otherwise it may drop or reorder data depending on network conditions and buffering limits.
• The video explores why UDP has become dominant for real-time apps, even though UDP “fails” some reliability expectations.

Why real-time apps prefer UDP

• For audio/video, late packets become stale; waiting for retransmission can be worse than skipping ahead.
• TCP’s strict “all bytes in order” behavior is highlighted as a poor fit for real-time streaming when packet loss occurs.

OSI transport-layer refresher (where protocols sit)

The talk repositions transport protocols within the OSI model, emphasizing:

• Network layer: routes packets between hosts using IP addresses.
• Transport layer: provides application multiplexing (e.g., via port numbers) so multiple applications can share a host.

UDP demo / experiment (packet loss, reordering, buffering)

A chat-like app is implemented over UDP, with each chat message = one UDP packet.

Observed behaviors in the demo:

• On wired Ethernet / low sending rates: 0% loss, no reordering.
• On Wi‑Fi / higher rates: still succeeds at moderate speeds, then:
• With aggressive sending and insufficient receiver buffering: packet loss occurs because excess packets get discarded by buffers.

Key takeaway: UDP lacks mechanisms to regulate sending rate; TCP and other protocols try to avoid overrunning network capacity by pacing/retransmission/flow control.

TCP guarantees and downsides

TCP provides stronger guarantees than UDP:

• Connection establishment
• Reliable delivery (connection closes if it can’t deliver)
• In-order delivery
• Application multiplexing via ports

Implementation detail from the demo:

• TCP is byte-stream oriented, so it does not preserve message boundaries.
• The demo adds an explicit message length prefix so the receiver can reconstruct chat messages from the byte stream.

Head-of-line (HOL) blocking problem (core critique)

TCP’s in-order requirement causes HOL blocking:

• If a large transfer (e.g., hundreds of MB file) shares the same TCP stream, smaller real-time messages behind it must wait.
• In real-time voice/video, this can mean dropping the session, not just delaying messages.

Practical mitigation mentioned:

• Browsers often open multiple sessions/connections to avoid one stream’s blocking affecting everything.

Why SCTP was considered as “TCP but better”

The video credits SCTP (Stream Control Transmission Protocol) as a protocol designed to address TCP’s problems:

• Connection-oriented like TCP
• Reliability and ordering
• Message boundaries (optional/message-based API behavior)
• Stream multiplexing: ordering is enforced per stream, not across the entire connection—intended to avoid TCP’s HOL blocking.
• Validity/expiration concept: applications can specify how long data remains valid so stale data can be dropped instead of retransmitted.
• Native multihoming/multipath capability: can use multiple IP addresses per host.

SCTP demo outcome

• A chat demo is run over SCTP with a file transfer placed on a different SCTP stream.
• Result: the file transfer completes without blocking chat messages (demonstrating the HOL issue is mitigated by stream-level ordering).

Why SCTP isn’t everywhere (NAT as the deciding factor)

Two major historical reasons are given:

1. Network Address Translation (especially IPv4/NAPT) broke SCTP traversal on the public internet.
2. SCTP’s packet characteristics make NAT rewriting harder:
   • SCTP uses a stronger checksum (Ethernet CRC / Castagnoli variant), meaning NAT can’t safely “just edit ports” without recomputing checksums.
   • SCTP can also involve multihoming, meaning NAT would need to mangle more transport-layer details, not just ports.

Conclusion: SCTP worked in environments without problematic NAT behavior, but couldn’t cross typical NAT boundaries well, blocking broad adoption.

Historical/standards analysis: OSI transport protocols vs Internet TCP/IP

The video includes a historical argument:

• OSI transport-layer committee design produced multiple transport protocols (TP0–TP4), causing fragmentation/messiness.
• The legacy telephone network (frame relay/ISDN) eventually had to shift toward Internet protocols as IP won.

Then SCTP is placed as a modern Internet transport intended for telecom signaling/data transport.

Where SCTP is used successfully (niche wins)

Telecom and mobile networks

• LTE/5G control plane signaling uses SCTP between network components.
• It “works amazingly well” because these networks can avoid NAT issues.

Other referenced SCTP-adjacent uses

• Diameter (instead of RADIUS) over SCTP
• SIP / VoLTE uses SCTP for certain signaling paths

WebRTC and QUIC as “SCTP-inspired” alternatives

WebRTC

• Uses UDP + DTLS (not SCTP directly), but encapsulates multiplexed streams.
• Uses SCTP for control/auxiliary signaling inside DTLS over UDP.

QUIC

• Presented as modern SCTP-like ideas rebuilt in user space.
• Designed to reduce TCP’s web performance issues, notably head-of-line blocking.
• Because SCTP struggles with NAT/firewalls and QUIC needs broad internet traversal, QUIC uses UDP and implements features in user space (including stream multiplexing and encryption).
• QUIC includes TLS during connection setup, and stream-level isolation avoids whole-connection blocking.

Product/repository/demo-related information (developer angle)

• Demos are said to be available on the speaker’s GitHub.
• Demos are written in pure C, mostly single-file builds.
• Platform notes:
  • Tested on Linux; may require libsctp-dev headers for SCTP.
  • SCTP is in the Linux kernel, but may be optional depending on distro/cloud image.
  • BSD/Linux: good SCTP support; Windows/macOS: less support.

---

Main speakers/sources

• Primary source: the YouTube presenter/author (speaker running the “transport lab” demos; mentions “Professor Appl” as a segment).
• Technical sources referenced historically/standard-wise:
  • IETF (IPv6/IPNG, IPv4 scaling/NAT context)
  • OSI bodies: ITU + ISO (committee-driven transport protocols TP0–TP4)
  • DARPA and European collaborators (internet modernization context)
  • Telecom standards context (SIGTRAN mention)
• No direct external reviewers are cited; the speaker conducts hands-on protocol experiments.