Summary
draft-ietf-tiptop-quic-profile-00recommends that deep-space QUIC can take expected RTT, pacing, window and other settings from a schedule-driven management or control plane because ordinary feedback arrives too late and can mistake store-and-forward delay for congestion.- Once a mission schedule drives transport behaviour, operators need a versioned schedule-to-transport receipt showing who authorized the plan, which path and interval it covers, how settings were derived, what assumptions and priorities it contains, and how stale or conflicting plans are handled.
The packet moves because the calendar says so
Picture a Mars relay with ten minutes of surface visibility in an orbit lasting almost two hours. A sender on Earth does not open its rate because a fresh acknowledgement revealed spare capacity. It sends because an operations system says the relay, antenna, spectrum assignment and downstream path will be available during a named interval. When the interval closes, the same system may drive the rate to zero and preserve the connection across the blackout.
That is not a failure of feedback. It is an admission that feedback cannot govern the useful timescale. By the time a congestion signal completes a planetary round trip, the contact that produced it may already be over.
The mechanism sits at the centre of QUIC Profile for Deep Space. Revision 00 became a TIPTOP working-group document on 10 September 2026, replacing the individual draft-many-tiptop-quic-profile. The draft is intended as Informational guidance, remains work in progress and makes no IANA request. Working-group adoption establishes a forum for refinement. It does not prove implementation, IETF-wide consensus or the correctness of every recommended setting.
Its central observation is concrete. Terrestrial QUIC stacks normally begin with assumptions measured in milliseconds and use acknowledgements, round-trip estimates, loss and ECN to adapt. Deep-space paths can add minutes of propagation, hours between contacts and storage delays inside relays. A delay produced by waiting for an orbiter’s next pass is not necessarily evidence that a queue has filled. Yet a closed-loop controller can read it as congestion because the transport sees elapsed time, not the mission’s orbital reason for it.
The first RTT is an authorized assumption
Before the first acknowledgement returns, QUIC has no measured RTT for the connection. RFC 9002 uses an initial estimate to derive its early loss timers. The TIPTOP profile says the default 333 milliseconds can be disastrously small when the expected round trip is minutes or hours. In the draft’s intermittent Earth–Mars example, the maximum value includes both propagation and the time until the next relay contact.
Set the estimate too low and the sender transmits useless probes or closes before the peer’s first response can arrive. Set it far too high and one lost Initial packet can delay recovery for hours. The draft therefore recommends a value high enough to survive establishment but close to the maximum expected RTT rather than padded by a large arbitrary multiple.
The word “expected” carries the governance burden. Someone selects the orbital data, contact cadence, relay path and safety margin. Someone decides whether the maximum means worst geometry, worst scheduled gap or a contractual availability envelope. The resulting number is operationally necessary, but it is not a measurement produced by QUIC. It is an authorized assumption that will later be replaced by observations if the connection survives long enough to make them.
The same distinction applies to max_idle_timeout. Its effective value is the minimum chosen by the two peers. One side can therefore terminate a connection even when the other has planned for a longer blackout. A valid local configuration is not proof of a compatible end-to-end plan.
Open loop does not mean no control
The draft’s most consequential step is its treatment of congestion control. Normal Internet control is closed loop: a sender reacts to evidence returned by the path. That model protects sharing among flows without requiring a central allocator to know the network in advance. In deep space, the document says, access is already highly coordinated. Antennas must point at one another; spectrum, compute, storage and physical equipment are scheduled; agencies and companies must arrange activities across time.
The profile therefore says deep-space QUIC stacks should be configurable for rate-based open-loop congestion control. Window, pacing rate, expected RTT and related values can be governed by schedule-driven management or control-plane cues. A route orchestrator may also supply path MTU and a time-varying acknowledgement policy. The draft’s cited simulations show why this matters: sending faster than a slow downstream hop does not improve completion time; it merely fills the scarce buffer on the relay.
Open loop is sometimes misheard as absence of governance. Here it means that governance moves. The decision no longer emerges only from an endpoint algorithm observing the path. It arrives from the organisation that built the schedule. The schedule chooses which flow may occupy a pass, how much relay memory it may consume and which risk margin outranks another mission’s claim.
QUIC still provides end-to-end loss recovery. Reliability is not the same as timely or fair access. The draft reports cases where delivery remains reliable while conventional CUBIC takes longer or misses orbital opportunities. A packet that eventually arrives can still have displaced another transfer, exhausted a buffer or consumed the only useful contact window.
A contact plan becomes executable policy
A planning file may begin as a prediction: antenna A can see orbiter B from 14:06 to 14:16; the Earth trunk has one rate; the surface link has another; a conjunction will suspend interplanetary traffic. Once those fields set QUIC pacing and windows, their role changes. They become executable policy.
That transition creates four questions that a syntactically valid plan cannot answer.
First is authority. Which mission operations centre may change the rate for a shared relay? Is the originator the spacecraft operator, the ground network, a commercial capacity provider or a cross-agency scheduler? A stack can authenticate a file without knowing whether its signer had the right to allocate the disputed pass.
Second is scope. A path can change while a long-lived connection persists. The initial route may use one orbiter and the next contact another. A schedule valid for a mission is not automatically valid for every peer, direction, service class or transport instance.
Third is time. Ephemerides and maintenance plans evolve. A plan can be genuine and still be stale. Its issue time, activation time, expiry and superseding version matter separately, especially when commands must be uploaded before a long communications blackout.
Fourth is conflict. Two independently authorized plans may each be internally correct while claiming the same antenna, spectrum block, downstream link or relay buffer. Transport code cannot resolve institutional priority by selecting the newest timestamp or the largest rate.
The schedule-to-transport receipt
I would make every consequential plan projection produce a compact, versioned receipt. It need not expose sensitive mission details to every observer, but the accountable operators should be able to reconstruct why a sender behaved as it did.
The receipt should bind the issuing organisation and approving role; the mission, endpoints and intended path; the schedule identifier and parent dataset; effective interval and expiry; the observations, ephemeris or contractual capacity used; the selected RTT range, pacing rate, congestion window, ACK policy, idle timeout and MTU; the equations and margins used to derive them; relay capacity and buffer reservations; service priority and conflict rule; the software projection that converted the plan into stack settings; and the fallback selected if the plan is absent, rejected or stale.
Supersession must be explicit. A later plan should point to the version it replaces, state whether already-open connections are updated, and preserve the previous command long enough for audit. Both peers should record the values they actually accepted, because the effective timeout and some negotiated limits depend on both sides.
Measured results belong in a separate section of the receipt. Actual RTT samples, contact start and end, loss, bytes sent, buffer peaks and missed opportunities can test the planning model. They must not silently overwrite the assumptions that caused the original decision. Otherwise a post-mission dashboard can make a bad forecast appear as though it had always contained the later truth.
Coordination is part of the protocol’s operating surface
The TIPTOP charter anticipates coordination with QUIC, TLS, TVR, DNSOP, DTN, CCSDS, space agencies and private operators. The draft itself reaches into several neighbouring surfaces: scheduled attributes, acknowledgement frequency, careful resume, key updates and store-and-forward behaviour. This is precisely where provenance is easiest to lose. One document defines a timer, another exposes it through an API, a scheduler supplies a value and a mission rule authorizes the schedule.
A useful implementation should expose not only that initial_rtt equals a number, but why that number is active and until when. It should reject a plan outside its scope, disclose when it fell back to terrestrial defaults, and make a conflict visible instead of blending two inputs. The management plane needs an acknowledgement from the transport projection, not merely evidence that a schedule was published.
This does not require a central controller for the interplanetary Internet. Different operators can retain their own decision rights. Interoperability requires the boundary between them to be legible: who stated the path, who accepted it, which parameters followed and which observations later challenged it.
What the evidence does not establish
The reviewed material does not show that a deployed mission has suffered harm from a forged or stale QUIC schedule. The simulations are controlled experiments, not a census of flight implementations. The profile is revision 00 of an active Internet-Draft and can change, expire or be replaced. Its references to open-loop control do not prove that one algorithm will suit every lunar, Martian or cruising-spacecraft path.
Nor does this article claim that closed-loop congestion control should disappear. Short lunar paths with continuous connectivity can behave differently from intermittent Mars relays; the draft itself treats scenarios separately. Feedback remains valuable once it arrives. The narrow claim is that whenever an external schedule becomes a live transport input, the chain of authority and derivation becomes part of network correctness.
Deep space makes that boundary visible because the timescales are extreme. Yet the lesson is familiar on Earth: automation does not remove discretion. It moves discretion into the data that automation trusts. In this case, the first act of congestion control may happen before the first packet leaves—inside the mission plan.
Sources
- IETF Datatracker — QUIC Profile for Deep Space
- Revision history
- Frozen revision 00
- Draft source repository
- TIPTOP working-group charter
- I-D announcement for the working-group draft
- Working-group adoption call
- Outcome of the adoption call
- TIPTOP minutes from IETF 126
- Deep-space characteristics and use cases
- IP architecture for deep space
- RFC 9000 — QUIC
- RFC 9002 — QUIC loss detection and congestion control
- RFC 9308 — Applicability of QUIC
- RFC 9959 — Careful Resume
- QUIC acknowledgement frequency draft
- YANG model for scheduled attributes
- BBR congestion-control draft
- IANA QUIC registry
- Deep-space QUIC simulation workbench
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
