QUIC Profile for Deep Space
draft-ietf-tiptop-quic-profile-00
| Document | Type | Active Internet-Draft (tiptop WG) | |
|---|---|---|---|
| Authors | Marc Blanchet , Wesley Eddy | ||
| Last updated | 2026-09-10 | ||
| Replaces | draft-many-tiptop-quic-profile | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-tiptop-quic-profile-00
Internet Engineering Task Force M. Blanchet
Internet-Draft Viagenie
Intended status: Informational W. M. Eddy
Expires: 14 March 2027 Aalyria Technologies
10 September 2026
QUIC Profile for Deep Space
draft-ietf-tiptop-quic-profile-00
Abstract
Deep space communications involve long delays (e.g., the Earth to
Mars one-way delay is ~4-20 minutes) and often intermittent
communications. In this context, the default transport parameters of
QUIC stacks, tuned for the terrestrial Internet, are not suitable for
deep space. This document defines a QUIC profile for deep space. It
provides guidance on how to estimate and set transport parameters,
advice to space mission operators and application developers on how
to configure QUIC for the deep space use case, and guidance to QUIC
stack developers on properly exposing the required transport
parameters in their API.
Status of This Memo
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 14 March 2027.
Copyright Notice
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.
Blanchet & Eddy Expires 14 March 2027 [Page 1]
Internet-Draft QUIC Profile for Deep Space September 2026
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Path Characteristics Calculations . . . . . . . . . . . . . . 4
2.1. RTT Calculation . . . . . . . . . . . . . . . . . . . . . 4
2.2. Bandwidth-Delay Product (BDP) Calculation . . . . . . . . 4
3. Connection Establishment . . . . . . . . . . . . . . . . . . 5
3.1. Initial RTT . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Connection Establishment with a Known Peer . . . . . . . 6
3.3. Connection Migration and 0RTT . . . . . . . . . . . . . . 7
4. Connection Maintenance . . . . . . . . . . . . . . . . . . . 7
4.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Keep Alive and Middleboxes . . . . . . . . . . . . . . . 8
4.3. Application Considerations . . . . . . . . . . . . . . . 8
5. Bandwidth Management . . . . . . . . . . . . . . . . . . . . 8
5.1. Congestion Control . . . . . . . . . . . . . . . . . . . 9
5.1.1. Window Size . . . . . . . . . . . . . . . . . . . . . 11
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Max Data . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Sending Pace . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 13
6. Reliable Delivery under Loss and Intermittence . . . . . . . 13
6.1. Acknowledgement Frequency . . . . . . . . . . . . . . . . 14
6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 15
6.3. Relay Buffering and Store-and-Forward Durability . . . . 15
6.4. Intermittence Awareness . . . . . . . . . . . . . . . . . 16
7. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Applicability of the QUIC Profile for Some Example
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Earth to Cruising Spacecraft (CS) . . . . . . . . . . . . 18
8.2. Earth-Moon with Full Connectivity (LF) . . . . . . . . . 18
8.3. Earth-Moon with Intermittent Connectivity (LI) . . . . . 19
8.4. Earth-Mars with Full Connectivity (MF) . . . . . . . . . 19
8.5. Earth-Mars with Intermittent Connectivity (MI) . . . . . 20
8.6. Solar Conjunction (SC) . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
Blanchet & Eddy Expires 14 March 2027 [Page 2]
Internet-Draft QUIC Profile for Deep Space September 2026
11.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Deep space communications involve long delays (e.g., ~4-20 minutes
one way between Earth and Mars) and intermittent communications
caused by orbital dynamics, such as when an orbiter passes over a
rover every 6 hours for a duration of 15 minutes.
The default transport parameters of typical QUIC stacks, tuned for
the terrestrial Internet, assume low latency, such as 100-200 ms, and
relatively continuous connectivity. Therefore, parameters such as
initial_rtt and maximum_idle_timeout have default values that are
typically not suitable for deep space.
Space missions are scheduled in advance, and parameters such as the
maximum round-trip time or bandwidth are known and determined in
advance. Given the relatively low bandwidth in space and the
intermittent communications, bandwidth is very precious, and
therefore any unneeded communication should be minimized as much as
possible. Use cases and requirements for deep space IP are further
discussed in [I-D.ietf-tiptop-usecase].
As described in [I-D.ietf-tiptop-ip-architecture], packets may be
stored at either layer 2 or layer 3 by orbiters during the periods
where connectivity to the next hop is not possible.
To better illustrate the implications for various transport
parameters, this document refers to the connectivity scenarios
described in [I-D.ietf-tiptop-usecase], using their two-letter
acronyms: Earth to cruising spacecraft (CS), Earth-Moon with full
connectivity (LF), Earth-Moon with intermittent connectivity (LI),
Earth-Mars with full connectivity (MF), Earth-Mars with intermittent
connectivity (MI), and solar conjunction (SC).
This document discusses how to configure a number of QUIC transport
parameters. The parameter names are from the IANA registry
[iana_quic_transport].
1.1. Requirements Language
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.
Blanchet & Eddy Expires 14 March 2027 [Page 3]
Internet-Draft QUIC Profile for Deep Space September 2026
2. Path Characteristics Calculations
This section describes how to calculate the path characteristics of a
mission, which are then used to set the transport parameters
discussed in the following sections.
2.1. RTT Calculation
A QUIC stack continuously estimates the round-trip time (RTT) between
the two peers over the lifetime of the connection. This estimate
drives loss detection [RFC9002]: both the time threshold after which
a sent packet is declared lost and its data retransmitted, and the
probe timeout (PTO) after which a probe is sent when no
acknowledgement arrives, are derived from the RTT estimate. Using
the Earth-Mars with intermittent connectivity (MI) scenario described
in [I-D.ietf-tiptop-usecase], it is necessary to prime the QUIC stack
with the right initial values, to avoid, for example, the probe
timeout firing and sending probes about one second after a packet is
sent, based on the default initial RTT of 333 ms, while the expected
RTT is 2 hours.
A space application designer should calculate the maximum RTT for its
mission. Using the MI scenario, the maximum RTT due to the maximum
two-way delay is 48 minutes and the maximum RTT due to the overpass
frequency is 6 hours; therefore, the maximum RTT is 6 hours 48
minutes.
A space application designer should calculate the minimum RTT for its
mission. Using the MI scenario, the minimum RTT due to the minimum
two-way delay is 8 minutes and the minimum RTT due to the overpass
frequency is 0, assuming direct line of sight for the whole path;
therefore, the minimum RTT is 8 minutes.
2.2. Bandwidth-Delay Product (BDP) Calculation
A QUIC stack, like any transport stack, manages the pacing of packets
sent from the source to avoid overloading the network, creating
congestion, or overwhelming the other peer.
A space application designer should calculate the bandwidth-delay
product (BDP) of the whole path for its mission. The minimum BDP
should be calculated with the minimum RTT and the minimum bandwidth
used during those times. The maximum BDP should be calculated with
the maximum RTT and the maximum bandwidth.
Blanchet & Eddy Expires 14 March 2027 [Page 4]
Internet-Draft QUIC Profile for Deep Space September 2026
3. Connection Establishment
This section discusses the parameters and mechanisms related to
establishing a QUIC connection in deep space.
3.1. Initial RTT
To prime the QUIC stack with the expected RTT of the mission, an
application should set the Initial RTT on connection establishment to
the maximum RTT as calculated in Section 2.1.
If the configured initial RTT is too low, then retransmissions of the
initial packet will be sent before the acknowledgement is received,
and therefore extra bandwidth will be used. If the actual one-way
delay is long enough, such as when communicating with Mars, then not
only will retransmissions occur, but the connection will be closed by
the client before the acknowledgement is received; therefore, no QUIC
connection is possible. In long one-way delay scenarios, setting the
initial_rtt properly is mandatory. Simulations
[deepspace_simulations][johannes_frisch] show that with a one-way
delay of 15 seconds or more and a default initial RTT of 333 ms, the
initial RTT MUST be set for the connection not to time out during the
establishment period. This 15-second threshold comes from the
max_idle_timeout, which is set to 30 seconds by default in many QUIC
stacks: with a one-way delay of 15 seconds or more, the RTT reaches
or exceeds 30 seconds, so the connection is torn down by the idle
timeout before the peer's first response can arrive (see
Section 4.1).
These simulations [deepspace_simulations] further show that an Earth
to Mars direct connection with a 4-minute one-way delay (8-minute
RTT) and default parameters never completes its handshake: the client
retransmits the initial packet and then closes the connection long
before the first response arrives. Once the initial_rtt is set above
the real RTT, the handshake completes in a single round-trip, and the
same configuration scales without modification up to an Earth to
Voyager link with an approximately two-day RTT. For intermittent
relayed paths, the initial_rtt should be primed with the maximum RTT
that includes the store-and-forward contact gap, as computed in
Section 2.1, and not merely the propagation delay.
Blanchet & Eddy Expires 14 March 2027 [Page 5]
Internet-Draft QUIC Profile for Deep Space September 2026
If the configured initial RTT is too high, then when a packet is
lost, the retransmission will be started later than the optimal time;
therefore, the total time to transmit all the data, including
recovery of the losses, will be longer than if it were set properly,
but the QUIC stack will still converge and deliver reliable data. As
the initial RTT is only used to prime the RTT at the beginning of the
connection, the real measured RTT will replace the too-high initial
value.
However, this self-correction does not apply during connection
establishment, which is the case where an over-set initial_rtt is
most costly. Before the first acknowledgement is received there is
no measured RTT sample, so QUIC's probe timeout (PTO, [RFC9002]) is
derived entirely from initial_rtt and evaluates to three times
initial_rtt. Loss of a handshake packet therefore delays the entire
connection by one such PTO, a cost that is linear in initial_rtt and
cannot be replaced by a measured sample because none exists yet.
Simulations [deepspace_simulations] of a direct Earth to Mars
connection at the longest one-way delay (22 minutes, a 44-minute RTT)
in which the very first Initial packet is lost show this directly:
with initial_rtt set to ten times the one-way delay (about five times
the real RTT), the lost Initial is recovered only after an 11-hour
PTO, so the handshake that otherwise completes in one 44-minute round
trip instead completes in 11 hours 44 minutes; the connection still
establishes and delivers reliably, but the single lost packet costs
three times the over-provisioned initial_rtt. Had initial_rtt been
primed at the real RTT, the same loss would have cost roughly 2.2
hours. Operators should therefore set initial_rtt high enough to
establish the connection (per the requirement above) but close to the
maximum expected RTT, and avoid padding it by a large multiple, so
that recovery from any establishment-phase loss is not needlessly
inflated.
The initial_rtt transport parameter is specified in [RFC9002].
3.2. Connection Establishment with a Known Peer
If a new connection is set up with a known peer, the other peer can
provide to the connecting peer some configuration parameters based on
the previous connections, using the careful resume mechanism
[RFC9959]. Simulations have shown its usefulness for Moon scenarios
[natia_piotrowski].
Blanchet & Eddy Expires 14 March 2027 [Page 6]
Internet-Draft QUIC Profile for Deep Space September 2026
3.3. Connection Migration and 0RTT
QUIC connection migration enables a client to restore the connection
after a change in its IP address or port, as seen by the server. The
migration requires 1 RTT to complete. However, given previously
exchanged security credentials, data can be sent in the initial
packet that re-establishes the connection, a process known as 0RTT.
However, 0RTT is subject to replay attacks [RFC9001], which means
that if it is used, the application should be careful about what is
sent in the 0RTT initial packet, following the guidance provided in
section 5.6 of [RFC9001]. A maximum time is also set for using 0RTT,
as discussed in Section 7. An application or mission may also decide
to disable the use of 0RTT given the security risks.
4. Connection Maintenance
This section discusses keeping a QUIC connection alive over long
delays and intermittence.
4.1. Idle Timeout
To prevent the QUIC stack from terminating a connection due to a lack
of activity from the other peer, an application should set the Idle
Timeout on connection establishment to at least the maximum RTT as
calculated in Section 2.1. This is a minimum: as discussed below, a
larger value may be needed, since the application may not be sending
data for periods longer than the maximum RTT.
If the configured idle timeout is too low, then the other peer may
terminate the connection before all the data is received. In this
case, the QUIC stack on the sender side will need to reestablish the
connection, possibly using the 0RTT mechanism, and resend the data
that was not previously acknowledged. The application shall still
recover and provide full data reliability, but at the expense of more
total time and extra bandwidth. If the configured idle timeout is
too high, then the other peer will close its side of the connection
later than needed in the event of a lost connection. In this case,
the resources used by keeping the connection open, such as memory,
will not be released as quickly as they could be if the idle timeout
were properly set.
The effective idle timeout is the minimum of the max_idle_timeout of
both peers; therefore, careful configuration is needed on both peers.
Simulations [deepspace_simulations] illustrate this boundary
precisely: with the default 30-second idle timeout, a connection
whose RTT is 29.8 seconds completes, whereas an otherwise identical
connection at a 30-second RTT is torn down before each response
Blanchet & Eddy Expires 14 March 2027 [Page 7]
Internet-Draft QUIC Profile for Deep Space September 2026
arrives. In intermittent scenarios, the gap that matters is not the
RTT but the entire blackout between contacts; therefore the
max_idle_timeout MUST exceed the longest expected contact gap, or
keep alives MUST be sent within it.
The max_idle_timeout transport parameter is specified in section 8.2
of [RFC9000].
4.2. Keep Alive and Middleboxes
As discussed in section 10.1 of [RFC9000], a peer can send PING
frames as connection keep-alives, timed, accounting for delay and
intermittence, to arrive before the max_idle_timeout is triggered.
For example, some QUIC stacks [quinn_keepalive] can be configured
with a keep-alive interval.
On the terrestrial Internet, keep-alives are particularly useful to
prevent middleboxes from timing out the UDP mapping too early,
typically after 30 seconds, as discussed in section 3.2 of [RFC9308].
However, in deep space, given long delays and disruptions, such small
middlebox timeouts will effectively prevent connections from
succeeding. Therefore, middleboxes are not recommended in deep space
or, if used, should be properly configured with much larger timeouts.
4.3. Application Considerations
On the terrestrial Internet, the cost, in time or bandwidth, of re-
establishing a connection to the same peer is very low, since it is
re-established very quickly and without much use of bandwidth.
Therefore, applications are often designed in a pattern of
establishing a connection, sending a query, getting the response,
closing the connection, and redoing the whole process for the next
query. In deep space, the cost, especially the delay, of re-
establishing a connection is very high in the presence of long RTTs
or intermittence. Therefore, applications should be carefully
designed not to close connections after a single query-response
exchange if new queries are possible in the future.
5. Bandwidth Management
Given the scarcity of bandwidth in deep space, this section discusses
the parameters and mechanisms that govern the use of the available
bandwidth.
Blanchet & Eddy Expires 14 March 2027 [Page 8]
Internet-Draft QUIC Profile for Deep Space September 2026
5.1. Congestion Control
In the Internet stack, congestion control (CC) in transport protocols
is crucial to sharing network resources among concurrent traffic
flows. Minimizing congestion is necessary in order to prevent
unnecessary queueing latency and packet drops. Problems with typical
Internet congestion control algorithms in deep space settings can
include: (1) assumptions of timely in-band feedback/information, (2)
interpretation of large delays as congestion/loss, and (3) lack of
knowledge about overall network state and management decisions.
Internet transport protocols use estimates of loss events, round-trip
latency, and Explicit Congestion Notification (ECN)
[RFC3168][RFC8087][RFC8311] to sense congestion. All of these
methods operate in a "closed loop" fashion on the scale of RTTs, in
order to react responsively in normal Internet conditions. When the
RTTs are many minutes or more in some deep space scenarios, this is
not effective in quickly detecting and reacting to congestion.
Instead of relying on in-band closed loop detection and response to
congestion, deep space congestion control could be assisted by
management/control plane information, as deep space access,
networking, and mission operations are substantially coordinated, in
contrast to normal Internet access.
[I-D.ietf-tiptop-ip-architecture] discusses that, given intermittent
connectivity in deep space, nodes may need to temporarily store
either L2 frames or L3 packets when links are down, until the link is
up again. This behavior will be interpreted by various CC algorithms
as congestion. However, this interpretation is not necessarily
correct, since the delays generated are due to waiting for a lower-
layer transmission opportunity, not necessarily to a lack of capacity
when it becomes available to transmit.
Deep space networking differs from traditional Internet use, because
it is highly coordinated. Antennas must be physically pointed and
tracked, and operations centers must work together across agencies,
companies, etc. in order to manage resources (including spectrum
usage, physical systems, compute and storage, etc.) and orchestrate
configurations and activities over time. Planning and scheduling are
significant activities and result in the ability to understand
traffic flow needs and allocate capacity for application flows,
unlike in the traditional Internet.
Blanchet & Eddy Expires 14 March 2027 [Page 9]
Internet-Draft QUIC Profile for Deep Space September 2026
Other space-oriented transport protocols, such as SCPS-TP, have
included rate-based open loop congestion control algorithms. These
algorithms send at pre-determined rates, without necessarily
requiring in-band feedback, with the rate information over time
provided by variables managed through an external scheduling system
or other means.
Therefore, QUIC stacks for deep space should be configurable to use
rate-based open-loop congestion control, which allows relevant
configuration variables such as the window, pacing rate, expected
RTT, and others to be governed by schedule-driven management/control
plane cues, rather than closed-loop in-band probing/estimation.
Simulations [deepspace_simulations] quantify the cost of running a
conventional loss-based controller on such links by transferring the
same lossy multi-packet workload twice, once with CUBIC and once with
congestion control disabled, across six regimes spanning Earth to
Moon and Earth to Mars at both the closest and farthest one-way
delays, over both continuous and intermittent relayed paths, with a 5
percent loss applied to the downlink the controller governs. The
choice of controller does not affect reliability: every run delivered
100 percent of its requests, because end-to-end delivery is a
property of QUIC's own loss recovery, not of the congestion
controller. The choice affects only completion time, and CUBIC is
always slower, never faster, because it misreads the channel loss as
congestion and multiplicatively reduces its window on every loss,
then re-grows it over the minutes-long round trips.
On a continuous lossy link the penalty is a steady factor of roughly
1.5 (from +46 percent at the Moon to +60 percent at the closest Mars
distance) independent of distance: each multi-packet response that
the open-loop arm ships in about one round trip is instead slow-
started by CUBIC over several round trips, while each loss cuts the
window it had just grown. Under intermittent store-and-forward the
penalty is far larger and is counted in missed contact passes rather
than round trips, because the open-loop sender arrives at pass-open
with a full window and drains the queue within the pass, whereas
CUBIC arrives with a small, loss-shrunk window, cannot fill the pass,
and the remainder waits for the next orbit. The cost reached a
factor of about 3.6 at Mars and a factor of about 12 at the Moon,
where the round trip is tiny relative to the orbit and the open-loop
arm finishes all of its work inside the first pass; the harm
therefore scales with how bursty the contact is, not with the loss
rate, and is worst precisely where open-loop control is most
efficient. CUBIC also raises the total packet count (about +30
percent in one Mars run) through window probing and extra recovery
round trips, spending more of the scarce return channel for a slower
transfer, and its conservative initial window can further delay
Blanchet & Eddy Expires 14 March 2027 [Page 10]
Internet-Draft QUIC Profile for Deep Space September 2026
connection establishment, which on the farthest intermittent path
waited additional contact windows before reaching the connected
state. Operators whose stack cannot disable congestion control
should budget for at least this 1.5-fold time penalty on continuous
lossy links and several missed orbits per transfer on intermittent
ones, and size idle timeouts accordingly.
5.1.1. Window Size
A QUIC stack manages the pacing of the source by the window size. A
typical value used for the Internet is 2 times the BDP. In space,
careful consideration is required. Too low a BDP means that the
source node may not be sending enough packets to completely use the
network and the available bandwidth of the links, which is suboptimal
given the scarcity of communications in space. Therefore, an
application should not use a BDP lower than the minimum BDP as
calculated in Section 2.2. Too large a BDP may use too much of the
bandwidth of the links.
Since packets may be stored at either layer 2 or layer 3 by
intermediate nodes, the maximum storage of in-flight packets in these
intermediary nodes is to be considered. Therefore, space operations
should properly identify the best window size based on the minimum
and maximum BDP and the storage size of the intermediary nodes for
the mission/application. As those parameters are known in advance
for a mission, they can be set appropriately by the application on
connection establishment.
When a relayed path includes a downstream link slower than an
upstream one, for example a fast Earth to orbiter trunk feeding a
slower orbiter to surface proximity link, the source outbound rate,
whether governed by the pacing rate, the window, or an explicit
outbound rate limit, SHOULD be set to the rate of the slowest
downstream link. Simulations [deepspace_simulations] show that a
rate set above the slowest link does not increase the end-to-end
throughput, which is bounded by that link, but instead forces the
intermediary node to buffer the excess: a rate limit at twice the
slow-link rate caused the orbiter to buffer approximately half of
each transfer, whereas matching the rate to the slow link reduced the
peak buffer to a single packet, with an identical total transfer
time. Sizing the outbound rate to the bottleneck thus bounds the in-
network storage required at store-and-forward nodes, which is a
scarce resource on spacecraft.
Blanchet & Eddy Expires 14 March 2027 [Page 11]
Internet-Draft QUIC Profile for Deep Space September 2026
5.2. Flow Control
A receiver can tell the source how much data it is willing to accept
by sending the Max Data parameters. As discussed above for window
size, too low a value would not fully use the bandwidth of the
network.
5.2.1. Max Data
initial_max_data is the maximum number of bytes that can be sent on a
connection [RFC9000]. initial_max_stream_data is similar but per
stream. Given the BDP of a typical deep space connection,
applications should set these parameters to sufficiently large values
so that the source is capable of sending data while the bandwidth is
available.
The various initial_max_data transport parameters are specified in
section 8.2 of [RFC9000].
5.3. Packet Size
There are pros and cons to sending large packets. Sending smaller
packets means using more bandwidth because of multiple headers,
unless header compression is used; however, when a packet is lost,
the cost of that loss, in the amount of data to retransmit, is
smaller than with larger packets, an important consideration in space
where retransmissions are costly. Sending larger packets means more
efficient use of bandwidth, but in the presence of significant packet
loss, it may in fact result in using more bandwidth than smaller
packets, since the larger lost packets have to be retransmitted.
5.4. Sending Pace
In the Internet context, QUIC stacks may elect not to wait long to
add more frames to a single packet, in order to deliver data faster
to the receiving endpoint. By contrast, for deep space applications,
where transmission times are many orders of magnitude longer than on
the Internet, a QUIC stack may be configured to wait "a bit more" to
add more frames to a single packet. For example, before sending a
packet, a QUIC stack may wait until it has processed all incoming
packets, in case that processing adds more frames to the response
packet. See Section 13 of [RFC9000] for more information.
Blanchet & Eddy Expires 14 March 2027 [Page 12]
Internet-Draft QUIC Profile for Deep Space September 2026
5.5. Padding
When the QUIC frames do not fully use the packet Maximum Transmission
Unit (MTU), padding to fill the MTU can be used to make traffic
analysis more difficult, as discussed in section 8.2 of [RFC9002].
However, this consumes more bandwidth, which is an important
consideration in deep space. Therefore, a mission or application
should weigh the advantages and disadvantages of padding.
5.6. Path MTU Discovery
To find the optimum MTU, some QUIC stacks implement Path MTU
discovery [RFC8899] by sending increasingly larger packets until the
maximum MTU is found, which involves packet loss when the limit is
reached. Given that in deep space the MTUs of all links on the paths
are typically known in advance, and that probing is inefficient and
not timely in this context, the application developer may elect to
disable the path MTU discovery mechanism and set the real path MTU at
connection establishment, by setting the max_udp_payload_size
transport parameter, specified in section 18.2 of [RFC9000], to the
known path MTU minus the IP and UDP header sizes.
For instance, a 1280 byte path MTU might be assumed, based on
knowledge of the network design and assurance from network providers
that this would be supported without fragmentation, after accounting
for any encapsulation present on the scheduled paths.
Given coordination between the small number of network operators
involved in an end-to-end path, support for large MTUs might be
coordinated and known in advance. This could be desirable for
efficiency, but is out of scope of this document.
Since scheduled paths may change over time, to enable the use of a
known optimal value at any time, the path MTU can also be exposed by
an implementation as a dynamically managed parameter, set according
to a schedule.
6. Reliable Delivery under Loss and Intermittence
This section discusses the mechanisms involved in delivering data
reliably over lossy and intermittent deep space paths:
acknowledgements, loss recovery, and in-network buffering.
Blanchet & Eddy Expires 14 March 2027 [Page 13]
Internet-Draft QUIC Profile for Deep Space September 2026
6.1. Acknowledgement Frequency
QUIC stacks have various mechanisms to trigger acknowledgements
(ACKs), as described in [RFC9000] and [I-D.ietf-quic-ack-frequency].
There are advantages to sending "frequent" acknowledgements, such as
enabling the source to free the memory used by acknowledged frames
earlier. However, this uses more capacity for sending ACKs, and
could be problematic in cases of very low link bandwidth or network
path capacity asymmetry. The latter case was tested and is discussed
in [johannes_frisch].
Adjusted ACK frequency information is provided to a QUIC peer through
an in-band signal in a QUIC ACK_FREQUENCY frame extension to the QUIC
base specification. Usage needs to be negotiated via transport
parameters on connection establishment, and desired values need to be
provided (e.g. directly by an application or supplied to the stack
via a management system). The max_ack_delay and ack_delay_exponent
transport parameters are specified in section 8.2 of [RFC9000], and
requested max_ack_delay changes are provided in ACK_FREQUENCY frames.
The optimal ACK frequency is related to the bandwidth asymmetry
between the directions of data and acknowledgement flow. This may
vary over time, but also can be known in advance by a route
orchestrator or other management system. In order to optimize
performance, ACK frequency may be exposed as a dynamically controlled
or time-varying parameter.
Simulations [deepspace_simulations] sweeping the ACK frequency
extension parameters (the ack-eliciting threshold and the maximum
acknowledgement delay) across direct and intermittent Earth-Moon and
Earth-Mars paths, with multi-packet bulk responses, show that
batching acknowledgements removes 80 to 99 percent of the return-path
ACK packets in every regime, and also reduces the store-and-forward
backlog held at a relay. A safe setting across all regimes is an
ack-eliciting threshold of approximately 10 packets combined with a
max_ack_delay of approximately one tenth of the RTT: the threshold is
then reached within each multi-packet response, so acknowledgements
still fire promptly and the reduction comes at no cost in completion
time. Raising the threshold beyond the length of a response makes
the receiver fall back on the max_ack_delay timer; this is harmless
on short-RTT links, but where the RTT is comparable to the contact
pass a held acknowledgement can miss its pass and cost a whole orbit,
or trip the sender's probe timeout. An over-aggressive max_ack_delay
of several RTTs always increases completion time (from +16 to +143
percent in these runs); the max_ack_delay must remain well below one
RTT.
Blanchet & Eddy Expires 14 March 2027 [Page 14]
Internet-Draft QUIC Profile for Deep Space September 2026
6.2. Forward Error Correction (FEC)
CCSDS deep space links use Forward Error Correction (FEC) at layer 2,
as specified in the TM and TC Synchronization and Channel Coding
Recommended Standards [CCSDS_TM_CC][CCSDS_TC_CC], using a pipeline of
codecs, enabling a low frame error rate in the presence of a higher
signal bit error rate. While FEC for QUIC has been defined
[I-D.michel-quic-fec], it remains to be seen whether it is really
needed for deep space.
Simulations [deepspace_simulations] quantify the cost of end-to-end
recovery and inform this trade-off. Because QUIC loss recovery is
clocked by the RTT, a single lost packet is recovered in
approximately one to two RTTs regardless of distance: a fast
retransmit when a following acknowledgement exposes the gap, or a
probe timeout otherwise. Its wall-clock cost therefore grows
linearly with the RTT, from under two seconds at the Moon to
approximately sixteen minutes (two RTTs) at Mars for a single lost
response. At interplanetary distances, link-layer or transport-layer
FEC is therefore very valuable, as it greatly reduces the packet
losses that the transport would otherwise have to recover through
costly end-to-end retransmissions.
6.3. Relay Buffering and Store-and-Forward Durability
Intermittent relay scenarios rely on IP-layer store-and-forward at
intermediate nodes: a relay (for example an orbiter) buffers packets
that arrive while a downstream link is down and forwards them when
contact resumes. This buffer is operational state that a relay may
lose while it still holds in-flight data, for example because of a
reboot, a power cycle, a radiation-induced single-event upset, memory
corruption, or an on-board memory reset. The QUIC connection runs
end-to-end and does not itself observe such a loss; its loss
detection and retransmission mechanisms will recover the lost data,
but the cost of that recovery, as discussed below, ranges from
negligible to several orbital periods depending on the path
characteristics.
Simulations [deepspace_simulations] stress this case by clearing the
relay buffer at random times while it is non-empty, across the same
low-orbit relay topologies used elsewhere in this document. The
finding is that the survivability of a relay buffer loss is governed
by the ratio of the end-to-end RTT to the blackout (inter-contact)
duration:
* When the RTT is much smaller than the blackout (for example an
Earth-Moon relay with an approximately 2.6-second RTT against a
blackout on the order of an hour), the sender's loss probes (PTO)
Blanchet & Eddy Expires 14 March 2027 [Page 15]
Internet-Draft QUIC Profile for Deep Space September 2026
repeatedly refresh the relay's buffer during the blackout, so a
retransmission that entered the relay after the loss is already
buffered downstream when the next contact opens and carries the
data through on the same pass. The loss is masked at negligible
cost in completion time.
* When the RTT approaches the contact cadence (for example an Earth-
Mars relay near closest approach with an approximately 8-minute
RTT), probes are sparse, so a lost buffered request usually has no
surviving retransmission waiting when the pass opens and misses
it, waiting a full orbit. Delivery remains reliable, but each
buffer loss costs on the order of one orbital period, roughly
halving throughput.
* At the longest Earth-Mars delay (an approximately 44-minute RTT, a
large fraction of the orbital period), recovery from a single loss
takes on the order of several orbits, and recurring losses can
prevent the connection from ever being established, because the
handshake itself is buffered across a blackout and is discarded
again before it can complete.
6.4. Intermittence Awareness
Another way to solve the generic problem is to make the transport
aware of the intermittence periods, so that when there is a direct
end-to-end path without any intermittence, the normal QUIC behavior,
such as congestion control, may be used with proper RTT
configuration, and a different behavior and configuration may be used
in the context of intermittence. Such dynamic configuration changes
might be driven by Time-Variant Routing (TVR) schedules, for example
using the YANG data model of [I-D.ietf-tvr-schedule-yang]; the
details are out of scope of this document.
7. TLS
As discussed in section 4.4 of [RFC9001], the certificate chain may
consume a large number of bytes, which may be limited at the time of
authentication. In deep space, this consideration becomes even more
important, given the delays and low bandwidth. Therefore, the
various methods discussed in section 4.4 of [RFC9001] should be
considered.
As discussed in section 4.6 of [RFC9001], TLS imposes a limit of 7
days between the original connection and any attempt to use 0-RTT.
Given that a spacecraft may travel for a long time before
reconnecting, missions should consider this possible limitation on
the use of 0RTT.
Blanchet & Eddy Expires 14 March 2027 [Page 16]
Internet-Draft QUIC Profile for Deep Space September 2026
As discussed in section 6.5 of [RFC9001], a key update initiation
should wait 3 times the PTO. Given that the PTO is calculated based
on the RTT, and that the RTT may vary significantly in deep space
because of intermittence, key updates should be carefully planned.
TLS keys shall be updated depending on the security policy of the
mission or the application. QUIC TLS [RFC9001] enables the update of
keys from each peer. [I-D.ietf-quic-extended-key-update] enables
"frequent key updates without requiring a full handshake
renegotiation. This approach allows applications to refresh their
encryption keys more often using ephemeral keys, improving forward
secrecy and reducing the risk of key compromise over long-lived
connections". Therefore, this mechanism is recommended for deep
space applications.
Simulations [deepspace_simulations] of the Extended Key Update
mechanism over deep space paths confirm that it operates correctly
under deep space delay and intermittent connectivity. On a
continuous Earth-Mars path (8 minutes round-trip time), a long-lived
connection of one thousand requests performed nineteen forward-secret
key updates with no disruption; on an intermittent Mars orbiter
store-and-forward relay, the same mechanism performed thirteen
updates and completed in the same time as the equivalent run without
key updates, adding only about three packets per update.
Unlike the RFC 9001 key update, which ratchets the existing secret
using only locally available material, an Extended Key Update
requires a full round-trip exchange of ExtendedKeyUpdate messages (a
request and a response carrying fresh key shares) before the Key
Phase bit is changed. The cost of one update is therefore
approximately two round-trip times. In deep space, the frequency of
key updates SHOULD be expressed in units of round-trip time or
contact cadence (for example, every N requests, or once per contact
window) rather than as a fixed wall-clock period, so that an update
can complete within the time and connectivity available. The header
protection keys are not changed by a key update.
Blanchet & Eddy Expires 14 March 2027 [Page 17]
Internet-Draft QUIC Profile for Deep Space September 2026
Across intermittent connectivity, an Extended Key Update initiated
during a loss of contact is carried by the relay's store-and-forward
buffer in the same way as application data, and completes once
contact is restored. No special handling is required across
blackouts: the same idle timeout and congestion control configuration
(see Section 4.1 and Section 5.1) that allow data to traverse
intermittent contact also allow the key update exchange to traverse
it. When both peers schedule key updates and their requests cross in
flight, the clash is resolved by the tie-break defined in
[I-D.ietf-quic-extended-key-update] so that the keys still advance by
a single generation; scheduling updates from a single peer avoids
redundant updates.
8. Applicability of the QUIC Profile for Some Example Scenarios
This section provides guidance for a possible QUIC profile for the
connectivity scenarios described in [I-D.ietf-tiptop-usecase],
identified by their two-letter acronyms. This list is not intended
to be exhaustive or normative. Moreover, not all parameters are
discussed, just the most relevant ones for each scenario. The reader
should refer to the sections above for a complete discussion and
references.
8.1. Earth to Cruising Spacecraft (CS)
As discussed in Section 3.1, if the one-way delay is 15 seconds or
more and a new QUIC connection is started, the establishment will not
succeed without setting the initial_rtt based on the delay. If the
one-way delay is lower than 15 seconds, a non-profiled QUIC
connection should be established, but at the cost of multiple
retransmissions of the initial packet. The max_idle_timeout should
be set depending on the one-way delay and the application traffic
pattern.
8.2. Earth-Moon with Full Connectivity (LF)
Given the relatively low one-way delay of around 1.5 seconds, a QUIC
connection with no specific configuration will be successful, but
there will be unnecessary retransmissions of initial packets by the
source, as discussed in Section 3.1. Given full connectivity and the
relatively low one-way delay, if a connection is closed, the cost, in
time or bandwidth, of re-establishing it is quite low. Therefore,
complicated configurations to avoid connection timeouts may be
avoided in favor of simplicity. Moreover, 0RTT may be disabled at
little cost, for better security. As discussed in [johannes_frisch]
and [natia_piotrowski], the Bottleneck Bandwidth and Round-trip
propagation time (BBR) congestion controller [I-D.ietf-ccwg-bbr] may
be used and will perform better than others.
Blanchet & Eddy Expires 14 March 2027 [Page 18]
Internet-Draft QUIC Profile for Deep Space September 2026
8.3. Earth-Moon with Intermittent Connectivity (LI)
If the periods of reachability are "long enough", then the cost of
establishing a new QUIC connection at the start of a new reachability
period may not be too high. Given that the schedule of intermittence
is known, the QUIC connection can also be closed gracefully with
explicit close signaling at the end of the reachability period. This
scenario does not require long-term buffering of packets in
satellites, as no packets shall be sent during the blackout periods.
During the reachability periods, the scenario is identical to
Section 8.2.
The paragraph above assumes that the applications or some application
orchestrator know the schedule of intermittence. If the schedule is
unknown to at least one of the peers, then packets may be sent during
the blackout periods, which means that the packets will be stored
somewhere in the network until reachability is back. This makes the
RTT highly variable, depending on when those events happen. As
discussed in Section 5.1, typical closed-loop congestion controllers
still deliver reliably in this context, but they perform poorly, as
they misinterpret the storage delays as congestion. Therefore, a
rate-based open-loop congestion control algorithm is preferred.
At the short Earth-Moon delay, the relay's store-and-forward buffer
is also resilient to loss: simulations [deepspace_simulations] show
that even when the orbiter buffer is cleared while it holds data, the
connection recovers at negligible cost, because the RTT is small
relative to the blackout and the sender's loss probes quickly refill
the buffer before the next pass. This is in contrast to the Earth-
Mars relay case and is discussed further in Section 6.3.
8.4. Earth-Mars with Full Connectivity (MF)
Compared to the Earth-Moon full connectivity scenario, the one-way
delay is large enough that a QUIC connection without specific
configuration will not be established, as demonstrated in
[deepspace_simulations]. Therefore, the very minimum is to set the
initial_rtt to an appropriate value as discussed in Section 3.1, such
as the maximum one-way delay times 2 plus some margin. Moreover, the
max_idle_timeout should be set to an appropriate value as discussed
in Section 4.1, such as a multiple of the largest RTT; it may even be
set to a larger value depending on the application traffic pattern,
or keep-alives may be used with a period smaller than the configured
max_idle_timeout.
Blanchet & Eddy Expires 14 March 2027 [Page 19]
Internet-Draft QUIC Profile for Deep Space September 2026
8.5. Earth-Mars with Intermittent Connectivity (MI)
As discussed in Section 8.4, the initial_rtt and max_idle_timeout
must be set large enough, but in this case they must also include the
maximum RTT based on the expected contact gap plus the maximum one-
way delay times 2.
Compared to Section 8.3, the long delay typically makes it infeasible
to open a new connection at the beginning of the reachability window
and then close it at the end of that window. In many cases, the
distance RTT is larger than the satellite overpass over the Mars
asset, which means the reachability window is far too small. In this
context, the QUIC connection has to be opened once and kept open over
multiple orbit periods. Similarly, the congestion controller should
be of the rate-based open-loop type.
Packets should be buffered in intermediate nodes of the network, in
order to minimize retransmissions and to maximize the use of the
limited bandwidth.
Simulations [deepspace_simulations] of a low Mars orbit relay, with
an approximately 118-minute orbital period and a 10-minute surface
pass, confirm this behavior. At a 22-minute one-way delay the
connection effectively delivers a single request/response exchange
per orbit, because each request's 22-minute uplink reaches the
orbiter after the current pass has closed and must be stored until
the next pass; the achievable throughput is then bounded by the
contact cadence rather than by the transport or the link RTT.
Notably, even a request issued during a pass can miss that pass when
the one-way delay is a large fraction of the pass duration. Across
these runs, with the intermediate buffers never cleared, no packet
was lost, which confirms that IP-layer store-and-forward, combined
with the initial_rtt and max_idle_timeout settings discussed above,
is sufficient for reliable delivery over scheduled intermittent
paths.
8.6. Solar Conjunction (SC)
In this scenario, described in [I-D.ietf-tiptop-usecase],
communications between Earth and the assets at a celestial body are
completely interrupted for a long period: around two weeks
approximately every 26 months in the case of Mars. Unlike the
intermittent connectivity scenarios, the interruption is long, total,
and precisely predictable years in advance. As the body approaches
the Sun in the sky, the link also degrades progressively, with
increasing error rates, before the complete blackout.
Blanchet & Eddy Expires 14 March 2027 [Page 20]
Internet-Draft QUIC Profile for Deep Space September 2026
A first approach is to close connections gracefully before the
conjunction and re-establish them after it ends, following the known
schedule. This releases the connection resources on both peers and
avoids sending any packets, such as retransmissions or keep-alives,
that cannot traverse the path. Note that the TLS limit of 7 days
between the original connection and any use of 0-RTT, discussed in
Section 7, is shorter than a typical conjunction; therefore, the
connection re-established after the conjunction cannot benefit from
0-RTT and requires a full handshake. The careful resume mechanism
(see Section 3.2) may still be used to prime the new connection with
the parameters of the previous one, as the path characteristics are
mostly unchanged across the conjunction.
A second approach is to keep the connection open across the
conjunction. In this case, the max_idle_timeout of both peers must
exceed the conjunction duration plus a margin, and all traffic,
including keep-alives, should be suspended during the blackout using
the schedule-driven, rate-based open-loop congestion control
discussed in Section 5.1, so that no bandwidth is wasted on packets
that cannot be delivered. Key updates should not be scheduled close
to or during the conjunction, as discussed in Section 7.
Communications local to the celestial body, such as between surface
assets and orbiters, are not affected by the conjunction and can
continue to operate normally, whether on separate connections or
through local proxies; only the connections crossing near the Sun are
interrupted.
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
The use of 0-RTT is subject to replay attacks [RFC9001] and therefore
may be disabled depending on the security policy of the mission.
Certificates and keys need to be renewed before their expiration,
taking into account the delay to send, receive, and confirm.
Protocols such as OCSP [RFC6960], which provide online real-time
validation and revocation checking, will likely not work given the
long delays; therefore, certificates need to be validated using local
trust anchors.
The use of long-term keys, such as ones set prior to launch, may
create exposure; therefore, keys should be renewed at an appropriate
frequency.
Blanchet & Eddy Expires 14 March 2027 [Page 21]
Internet-Draft QUIC Profile for Deep Space September 2026
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
Blanchet & Eddy Expires 14 March 2027 [Page 22]
Internet-Draft QUIC Profile for Deep Space September 2026
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[RFC9308] Kühlewind, M. and B. Trammell, "Applicability of the QUIC
Transport Protocol", RFC 9308, DOI 10.17487/RFC9308,
September 2022, <https://www.rfc-editor.org/info/rfc9308>.
[RFC9959] Kuhn, N., Stephan, E., Fairhurst, G., Secchi, R., and C.
Huitema, "Careful Resume: Convergence of Congestion
Control from Retained State", RFC 9959,
DOI 10.17487/RFC9959, May 2026,
<https://www.rfc-editor.org/info/rfc9959>.
[I-D.michel-quic-fec]
Michel, F. and O. Bonaventure, "Forward Erasure Correction
for QUIC loss recovery", Work in Progress, Internet-Draft,
draft-michel-quic-fec-01, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-michel-quic-
fec-01>.
[I-D.ietf-quic-ack-frequency]
Iyengar, J., Swett, I., and M. Kühlewind, "QUIC
Acknowledgment Frequency", Work in Progress, Internet-
Draft, draft-ietf-quic-ack-frequency-14, 5 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
ack-frequency-14>.
[I-D.ietf-tiptop-usecase]
Blanchet, M., Eddy, W., and M. Eubanks, "IP in Deep Space:
Key Characteristics, Use Cases and Requirements", Work in
Progress, Internet-Draft, draft-ietf-tiptop-usecase-02, 6
July 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-tiptop-usecase-02>.
[I-D.ietf-tiptop-ip-architecture]
Blanchet, M., Eddy, W., and T. Li, "An Architecture for IP
in Deep Space", Work in Progress, Internet-Draft, draft-
ietf-tiptop-ip-architecture-01, 5 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tiptop-
ip-architecture-01>.
Blanchet & Eddy Expires 14 March 2027 [Page 23]
Internet-Draft QUIC Profile for Deep Space September 2026
[I-D.ietf-quic-extended-key-update]
Rosomakho, Y., Tschofenig, H., and T. Reddy.K, "Extended
Key Update for QUIC", Work in Progress, Internet-Draft,
draft-ietf-quic-extended-key-update-03, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
extended-key-update-03>.
[I-D.ietf-tvr-schedule-yang]
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
Blanchet, "A YANG Data Model for Scheduled Attributes",
Work in Progress, Internet-Draft, draft-ietf-tvr-schedule-
yang-12, 10 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr-
schedule-yang-12>.
[I-D.ietf-ccwg-bbr]
Cardwell, N., Swett, I., and J. Beshay, "BBR Congestion
Control", Work in Progress, Internet-Draft, draft-ietf-
ccwg-bbr-06, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccwg-
bbr-06>.
[iana_quic_transport]
Internet Assigned Numbers Authority(IANA), "QUIC Transport
Parameters", September 2025,
<https://www.iana.org/assignments/quic/quic.xhtml#quic-
transport>.
[CCSDS_TM_CC]
Consultative Committee on Space Data Systems (CCSDS), "TM
Synchronization and Channel Coding, Blue Book 131.0-B-5",
September 2023, <https://ccsds.org/Pubs/131x0b5.pdf>.
[CCSDS_TC_CC]
Consultative Committee on Space Data Systems (CCSDS), "TC
Synchronization and Channel Coding, Blue Book 231.0-B-4",
July 2021, <https://ccsds.org/Pubs/231x0b4e1.pdf>.
[deepspace_simulations]
Marc Blanchet, "Deepspace Simulations of QUIC Transport
Parameters", July 2026,
<https://github.com/deepspaceip/deepspace-ip-simulations>.
[natia_piotrowski]
Natia Piotrowski, "QUIC to the Moon Measurements",
November 2025,
<https://datatracker.ietf.org/meeting/124/materials/
slides-124-tiptop-quic-to-the-moon-measurements-00>.
Blanchet & Eddy Expires 14 March 2027 [Page 24]
Internet-Draft QUIC Profile for Deep Space September 2026
[johannes_frisch]
Johannes Frisch, "Evaluation of QUIC in Interplanetary
Networks", April 2026,
<https://datatracker.ietf.org/meeting/126/materials/
slides-126-tiptop-TBD>.
[quinn_keepalive]
Quinn, "Struct TransportConfig", 2026,
<https://docs.rs/quinn/latest/quinn/
struct.TransportConfig.html#method.keep_alive_interval>.
Acknowledgements
This document and its underlying work have been reviewed and
discussed by many, who have provided valuable feedback and comments,
including disagreements, making the document more solid overall.
These people are, in no specific order: Lars Eggert, Christian
Huitema, Adolfo Ochagavia, Mirja Kuehlewind, Michael Richardson.
The Quinn QUIC stack was used for testing. We would like to
acknowledge the help of Benjamin Saunders and Adolfo Ochagavia in
using Quinn.
Authors' Addresses
Marc Blanchet
Viagenie
Canada
Email: marc.blanchet@viagenie.ca
Wesley M. Eddy
Aalyria Technologies
United States of America
Email: wes@aalyria.com
Blanchet & Eddy Expires 14 March 2027 [Page 25]