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 current public implementation focus is media streaming, although the transport can be adapted to other applications that can tolerate or explicitly manage reordering. USTPS combines reliable recovery of missing packets, transport-level unordered behavior, and mandatory authenticated protection for application payload packets. 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 authenticated protection for DATA packets.
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.
Allow an existing session to survive a client path change when possible.

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

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, retransmission, and RTT sampling. 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 transport uses two inner wire formats. Plaintext control packets are serialized as human-readable ASCII records. Current public implementations use forms such as ACK: 10, ACK: 10 11 12, NACK: 42, HELLO: BASE64..., and CLOSE:. HELLO carries binary handshake material in Base64 when required. DATA packets use a binary frame format named UPACK, identified on the wire by the 4-octet marker UPAK. The UPACK DATA frame 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. Current public implementations protect DATA packets with an outer AEAD envelope identified by the magic value USS1. After decryption, DATA typically begins with UPAK, while plaintext control appears as readable ASCII control lines.

Handshake and Session Model A client begins by sending a plaintext HELLO carrying its X25519 public key and requested cipher. The server does not send application DATA immediately. Instead, it replies with a plaintext challenge containing a random token, a generated Base64 session identifier, the selected cipher, and the server public key. The client MUST answer with the received token. Only after that token round-trip succeeds does the server derive the AEAD session key and begin sending DATA. After validation, the session is tracked by the generated Base64 session identifier rather than solely by the original IP address and UDP source port. Subsequent keepalive or rebind messages MAY use the session identifier to resume an existing session after a path change or source-port change.

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) is used as a fallback if explicit retransmission requests are delayed or lost. Current implementations adapt RTO from measured RTT samples taken from non-retransmitted acknowledged packets.

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 for DATA packets. Implementations currently support ChaCha20-Poly1305, AES-256-GCM, and AES-128-GCM. Clients and servers perform an 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 for DATA, while readable plaintext control lines identify transport control and UPAK identifies decrypted binary DATA framing. 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.

Path Migration and Network Change Recovery Current public implementations support client-side path recovery. If the client detects that the active UDP path has stalled, it may recreate its UDP socket, resolve the server address again, and attempt to resume the existing session by the stored session identifier. If resume fails, the client may fall back to a fresh handshake. This behavior is intended to allow mobile or roaming devices to change networks without immediately forcing a client restart.

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, and cipher selection. 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. Implementations that support path migration or session resume MUST ensure that only holders of the valid session state can successfully resume the session.