| Internet-Draft | USTPS | June 2026 |
| x1co | Expires 19 December 2026 | [Page] |
This document describes UDP Speedy Transmission Protocol Secure (USTPS), an experimental transport built directly on UDP for low-latency and loss-tolerant applications. USTPS provides authenticated encryption for DATA packets, readable plaintext control records authenticated by HMAC where applicable, binary UPACK DATA framing, selective retransmission, out-of-order acceptance, adaptive retransmission timeout, optional congestion control, and application-visible stream position metadata. USTPS is intentionally unordered at the transport layer and is designed to avoid transport-level Head-of-Line blocking.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
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. Current public implementations focus primarily on streaming, but the transport can also be adapted to other applications that either tolerate reordering or explicitly rebuild logical order at a higher layer.¶
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 a single in-order byte stream in the transport itself. Unlike an individual QUIC stream, USTPS does not define in-order transport semantics inside the transport. Instead, it exposes both a packet sequence number and an application-facing stream position so that upper layers can reconstruct ordered output only when needed.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the following terms:¶
seq: transport sequence number used for acknowledgement, loss detection, retransmission, and RTT measurement.¶
stream_pos: application-facing byte position indicating where a payload belongs in the logical ordered byte stream.¶
UPAK.¶
USTPS has the following goals:¶
USTPS is not intended to emulate TCP semantics. In particular, it does not provide transport-layer ordered byte-stream delivery. Optional congestion control, when implemented, changes only the sender rate policy and does not turn USTPS into a TCP-like ordered transport.¶
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.¶
The current public implementation uses a 32-bit monotonically increasing transport sequence space starting from 1 for each fresh session, and a 64-bit monotonically increasing stream_pos starting from 0 for each fresh logical stream. Sequence numbers are scoped to one session and are not meaningful across session resets.¶
Example arrival order:¶
Physical arrival: 1 2 3 5 6
Missing packet : 4
Receiver action: accept 5 and 6, request retransmission of 4
Later arrival : 4
Logical order : 1 2 3 4 5 6
¶
USTPS uses three practical wire layers in current public implementations:¶
Current public implementations serialize transport control packets as readable ASCII records. Typical forms include:¶
ACK: 10 MAC:<tag>¶
ACK: 10 11 12 MAC:<tag>¶
NACK: 42 MAC:<tag>¶
NACK: 42 43 44 MAC:<tag>¶
HELLO: BASE64...¶
CLOSE:¶
ACK and NACK records remain plaintext for observability and debugging, but current implementations authenticate them with an HMAC derived from session state. The MAC:<tag> value is verified before the control record reaches the transport state machine.¶
Current implementations batch up to 128 acknowledged or missing sequence numbers in one control record.¶
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:¶
Packet types currently used by implementations include DATA, ACK, RETRANSMIT_REQUEST, HELLO, and CLOSE.¶
In the current public implementation, the maximum UPACK payload is 1200 octets. The fixed UPACK header consumes 20 octets: 4 octets magic, 1 octet type, 1 octet flags, 4 octets sequence number, 8 octets stream position, and 2 octets payload length.¶
Current public implementations protect DATA packets with an outer AEAD envelope identified by the magic value USS1, meaning "UDP Speedy Secure, version 1". After decryption, DATA typically begins with UPAK, while plaintext transport control remains readable ASCII.¶
The current public implementation uses a 12-octet AEAD nonce and a 1-octet cipher identifier in the outer envelope. The nonce is generated randomly for each transmitted encrypted packet. Nonce uniqueness for a given key is mandatory; reuse of a nonce with the same key is forbidden.¶
USTPS is designed to avoid relying on IP fragmentation. In the current public implementation, the transport payload limit is intentionally kept small enough to fit comfortably inside common Internet UDP paths.¶
For the current public implementation, the effective encrypted DATA datagram is composed of:¶
USS1 envelope magic¶
This yields a maximum encrypted USTPS DATA payload of approximately 1253 octets before outer IP and UDP headers. With IPv4 and UDP headers, this is approximately 1281 octets on the wire; with IPv6 and UDP headers, approximately 1301 octets. This stays below the IPv6 minimum path MTU of 1280 only if the application payload is reduced somewhat, so implementations that require strict IPv6-minimum compliance SHOULD lower the application payload ceiling accordingly.¶
Current public implementations do not implement transport-layer fragmentation or transport-layer PMTU discovery. Instead, they use a fixed conservative payload ceiling. Applications or future versions MAY add explicit PMTU probing and dynamic payload sizing, but this is outside the current public implementation model.¶
If the underlying IP layer fragments a datagram anyway, loss of any fragment causes the entire UDP datagram to be lost and later recovered through normal USTPS selective retransmission.¶
A client begins by sending a plaintext HELLO carrying its X25519 public key, requested AEAD cipher, and requested congestion-control mode. The server does not send application DATA immediately. Instead, it replies with a plaintext challenge containing:¶
The client MUST answer with the received token and matching session metadata. Only after that token round-trip succeeds does the server derive the AEAD session key and begin sending DATA.¶
The retry token proves reachability of the apparent source IP address and UDP port before the server starts sending encrypted payload data. In current public implementations, the resulting session is bound to the IP address and UDP source port that successfully completed the challenge. The session identifier remains useful as a label, but is not currently accepted from a different source address for path migration.¶
A conforming implementation based on the current public model SHOULD behave roughly as follows:¶
Client -> HELLO(client_pub, requested_cipher, requested_cc)
Server -> CHALLENGE(token, session_id, selected_cipher, negotiated_cc, server_pub)
Client -> CHALLENGE-REPLY(token, session_id, selected_cipher, negotiated_cc, client_pub)
Server -> derive session key
Server -> SESSION(session_id, selected_cipher, negotiated_cc, server_pub)
Client -> derive session key
Data path -> encrypted DATA packets begin
¶
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.¶
Only the missing packets are retransmitted. Receipt of later packets does not require discarding or rewinding already accepted later packets.¶
A receiver implementation SHOULD:¶
seq values to detect duplicates¶
stream_pos if required by the application¶
If a packet arrives with a seq that has already been accepted in the current session, it is a duplicate and SHOULD be ignored except for any minimal bookkeeping the implementation uses to refresh acknowledgement state. If a packet arrives with a very old seq that has already aged out of the receiver's recent history window, the implementation MAY ignore it silently.¶
Current public implementations retain a bounded recent sequence history and periodically discard stale entries from that history. This prevents unbounded memory growth and limits the impact of delayed very-old packets from earlier portions of the session.¶
A sender implementation SHOULD:¶
seq to each DATA packet¶
If a packet has already been retired from the retransmission buffer, a later stale ACK or stale NACK for that packet MUST NOT recreate it artificially. Late control records referring to already-retired packets are therefore harmless and are simply ignored by the current public implementation.¶
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.¶
USTPS Congestion is OPTIONAL in current implementations.¶
When enabled, it adjusts the sender's effective send window and burst size without changing USTPS reliability semantics, unordered delivery semantics, or selective retransmission behavior.¶
Current public implementations negotiate congestion-control mode during the handshake. Server policy may be auto, on, or off. Client preference may be on or off. With server policy auto, the server follows the client request. With server policy on or off, the server forces the final mode.¶
Current public implementations start from normal transport speed and back off only after sustained congestion signals. Isolated loss events are intentionally tolerated so that a single loss event is less likely to be treated the same way as true persistent congestion.¶
Current implementations examine a combination of measured RTT inflation, retransmission timeout events, and explicit retransmission pressure. Congestion control therefore affects only the sender rate policy; it does not alter the unordered transport model or the selective-repeat recovery model.¶
USTPS uses mandatory AEAD for DATA packets. Implementations currently support ChaCha20-Poly1305, AES-256-GCM, and AES-128-GCM. A user-facing naming convention MAY map to those cipher suites as follows:¶
Current public implementations default to chacha20 when a different explicit choice is not forced by configuration.¶
Clients and servers perform an X25519-based key exchange when a client joins, and a separate session key is derived per client session.¶
ACK and NACK records remain plaintext in current implementations for observability and debugging, but they are authenticated with an HMAC derived from the session key. This is intended to reduce off-path forged ACK or NACK attacks while preserving readable control format.¶
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.¶
The retry token is a random reachability challenge value. It is not reused as an AEAD key, not reused as an HMAC key, and not reused as a packet nonce. Its role is limited to proving that the apparent source endpoint can receive and return server-issued challenge material before the server begins sending encrypted DATA.¶
Earlier experimental implementations attempted client path migration and session resumption across source IP address or UDP port changes. Current public implementations removed that behavior because it created practical reliability and security problems, including migration floods, stale sessions that appeared recovered but stopped delivering data, long silent periods followed by gap-only behavior, and ambiguity between a legitimate roaming client and spoofed packets claiming an existing session identifier.¶
Current public implementations therefore use a simpler model: complete the retry-token challenge on the current source IP address and UDP port, bind the resulting session to that endpoint, and reconnect cleanly if the endpoint changes.¶
An implementation that needs ordered application output SHOULD keep a reorder buffer keyed by stream_pos, not by seq. The sequence number exists for transport reliability logic; it is not the application's authoritative logical ordering key.¶
An implementation that can consume unordered chunks directly MAY process payloads immediately without ordered release.¶
Applications that bridge USTPS into a TCP-like local compatibility socket should understand that any ordered byte stream visible on that local side is an application choice above USTPS, not transport-level ordering inside USTPS.¶
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, stream container choice, and optional congestion-control policy. These are implementation details and not normative wire requirements unless later specified.¶
This document has no IANA actions.¶
USTPS relies on correct AEAD use, correct nonce handling, correct key derivation, authenticated peer identity checks, and correct validation of the retry-token challenge before encrypted DATA is sent. 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.¶
Because current public implementations keep ACK and NACK records in plaintext, implementations that follow this model SHOULD authenticate those control records, for example with an HMAC derived from session state.¶
Implementations that expose optional congestion control SHOULD avoid treating an isolated single loss event as automatically equivalent to sustained path congestion.¶
Because current public implementations do not perform transport-level PMTU discovery, operators deploying USTPS across unusual tunnels or paths with reduced MTU may need a smaller application payload ceiling to avoid excessive IP fragmentation.¶