UDP Speedy Transmission Protocol Secure (USTPS)

Introduction USTPS is an experimental transport that runs directly over UDP. It was designed for applications that prefer continuing delivery of later packets even when earlier packets are temporarily missing. Its main target in current implementations is media streaming, although the transport itself can be adapted for other applications that can tolerate or explicitly manage reordering. USTPS combines three properties: reliable recovery of missing packets, transport-level unordered behavior, and mandatory authenticated encryption. Unlike TCP, USTPS does not force byte-stream ordering in the transport. Unlike QUIC streams, USTPS does not define per-stream in-order delivery semantics in the transport itself. Instead, it exposes both a packet sequence number and an application-facing stream position so that upper layers may reconstruct ordered output when needed.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Design Goals USTPS has the following goals:

Run directly over UDP.
Provide packet-level authenticated encryption.
Recover missing packets with selective retransmission.
Accept and process later packets even when earlier packets are missing.
Expose sufficient metadata for an application to rebuild ordered output if required.

USTPS is not intended to emulate TCP semantics. In particular, it does not provide transport-layer ordered byte-stream delivery.

Transport Overview Each USTPS DATA packet contains a transport sequence number (seq) and a stream position (stream_pos). The sequence number is used for reliability functions such as acknowledgement, gap detection, and retransmission. The stream position identifies where the payload belongs in the application's logical byte stream. Upon reception of DATA packets, a receiver SHOULD acknowledge unique packets and MAY immediately pass packet payload upward, even when a lower sequence number has not yet arrived. If an application requires ordered output, it MUST use stream_pos to reconstruct that order. Example arrival order:

Packet Format The inner USTPS transport packet begins with the magic value UST1, meaning "UDP Speedy Transmission Protocol, version 1". The transport packet fields are:

Magic: 4 octets
Type: 1 octet
Flags: 1 octet
Sequence: 32 bits
Stream Position: 64 bits
Payload Length: 16 bits
Payload: variable

Packet types currently used by implementations include DATA, ACK, RETRANSMIT_REQUEST, HELLO, and CLOSE.

Reliability Model USTPS uses selective retransmission. A sender stores transmitted packets in a retransmission buffer until they are acknowledged or otherwise retired. A receiver detects gaps in observed sequence numbers and requests retransmission only for missing packets. USTPS intentionally avoids Go-Back-N behavior. Later packets are not discarded solely because an earlier packet is missing. Retransmission timeout (RTO) may be used as a fallback if explicit retransmission requests are delayed or lost.

Head-of-Line Blocking USTPS is designed to avoid transport-level Head-of-Line blocking. A missing packet does not prevent receipt, acknowledgement, buffering, or application visibility of later packets. This differs from TCP, where the transport enforces ordered byte-stream delivery, and from individual QUIC streams, which remain in-order within each stream. If an application chooses to emit only ordered output, any waiting that occurs is an application-layer decision, not a USTPS transport requirement.

Security Model USTPS uses mandatory AEAD at the packet layer. Implementations currently support ChaCha20-Poly1305, AES-256-GCM, and AES-128-GCM. A client and server perform an ephemeral X25519-based key exchange when a client joins, and a separate session key is derived per client session. The outer secure envelope begins with the magic value USS1, meaning "UDP Speedy Secure, version 1". In current implementations, USS1 identifies the encrypted/authenticated outer framing, while UST1 identifies the decrypted inner transport packet. Implementations described by this document use a persistent server host key and Trust On First Use (TOFU) on the client side to detect unexpected server key changes across reconnects.

Operational Notes USTPS has been implemented and exercised as a Beta-grade experimental protocol. Current public code and testing are primarily focused on streaming over local networks and over public Internet paths where UDP is available. Current implementations are multi-client and perform per-client session key derivation. Current public implementations also expose knobs such as simulated packet loss, output buffering delay, cipher selection, and optional congestion control. These are implementation details and not normative wire requirements unless later specified.

IANA Considerations This document has no IANA actions.

Security Considerations USTPS relies on correct AEAD use, correct nonce handling, correct key derivation, and authenticated peer identity checks. Implementations MUST ensure nonce uniqueness for a given key. Implementations SHOULD authenticate server identity changes using a trust model such as TOFU or a stronger out-of-band validation method. Because USTPS is unordered, applications that require ordered interpretation MUST reconstruct order using application-visible metadata such as stream_pos. Applications that incorrectly treat physical arrival order as logical order may mis-handle retransmitted data.