]> Viagenie

Canada marc.blanchet@viagenie.ca

Aalyria Technologies

USA wes@aalyria.com

Internet Internet Engineering Task Force quic space ip dtn deep space delay disruption 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 configuration of QUIC stacks, tuned for the terrestrial Internet, is 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 and local implementation settings, 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 exposing the required controls in their API.

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 configuration of typical QUIC stacks, tuned for the terrestrial Internet, assumes low latency, such as 100-200 ms, and relatively continuous connectivity. Therefore, settings such as the local initial RTT estimate and the max_idle_timeout transport parameter typically have default values that are 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 . As described in , 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 QUIC settings and mechanisms, this document refers to the connectivity scenarios described in , 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 QUIC transport parameters, local implementation settings, and extension mechanisms. Names used for transport parameters exchanged by endpoints are from the IANA registry . Other settings, such as the initial RTT estimate, are local implementation controls and are not QUIC transport parameters.

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 when, and only when, they appear in all capitals, as shown here.

Path Characteristics Calculations This section summarizes the path characteristics of a mission, which are then used to configure the transport parameters and local implementation settings discussed in the following sections. The calculation of the minimum and maximum RTT (minRTT, maxRTT) and of the minimum and maximum bandwidth-delay product (minBDP, maxBDP) of a path is described in , together with examples for the connectivity scenarios used in this document.

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 : 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 , 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 (maxRTT) and the minimum RTT (minRTT) for its mission, as described in . Using the MI scenario, the maxRTT is 6 hours 48 minutes and the minRTT is 8 minutes.

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 minimum and maximum bandwidth-delay product (minBDP, maxBDP) of the whole path for its mission, as described in .

Connection Establishment This section discusses the parameters and mechanisms related to establishing a QUIC connection in deep space.

Initial RTT To prime the QUIC stack with the expected RTT of the mission, an application should configure the local initial RTT estimate on connection establishment to the maximum RTT as calculated in . If the configured initial RTT is too low, then probes 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 probes be sent, but an implementation with an insufficient idle timeout might close the connection before the acknowledgement is received. Long-delay deployments therefore need to configure the initial RTT estimate and idle timeout consistently. Simulations show that, with the tested stack's default initial RTT of 333 ms and default max_idle_timeout of 30 seconds, a connection with a one-way delay of 15 seconds or more times out unless one or both settings are changed. This 15-second threshold is not a QUIC protocol limit; it follows from the tested 30-second idle-timeout default: with a one-way delay of 15 seconds or more, the RTT reaches or exceeds 30 seconds, so the connection is torn down before the peer's first response can arrive (see ). These simulations further show that an Earth to Mars direct connection with a 4-minute one-way delay (8-minute RTT) and default settings never completes its handshake: the client sends probe packets and then closes the connection long before the first response arrives. Once the initial RTT estimate is set above the real RTT, the handshake completes in a single round-trip, and a properly configured initial RTT estimate also enables operation over an Earth to Voyager link with an approximately two-day RTT. For intermittent relayed paths, the initial RTT estimate should be primed with the maximum RTT that includes the store-and-forward contact gap, as computed in , and not merely the propagation delay. 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 estimate is most costly. Before the first acknowledgement is received there is no measured RTT sample, so QUIC's probe timeout (PTO, ) is derived entirely from the initial RTT estimate and evaluates to three times that estimate. Loss of a handshake packet therefore delays the entire connection by one such PTO, a cost that is linear in the initial RTT estimate and cannot be replaced by a measured sample because none exists yet. 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 the initial RTT estimate 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 estimate. Had the estimate been primed at the real RTT, the same loss would have cost roughly 2.2 hours. Operators should therefore set the initial RTT estimate 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 estimate is a local loss-recovery setting described in section 6.2.2 of ; it is not a QUIC transport parameter exchanged between endpoints.

Connection Establishment with a Known Peer When establishing a new connection to the same remote endpoint, a sender can use the careful resume mechanism to retain locally observed congestion-control parameters from a previous connection and cautiously reuse them. Simulations have shown its usefulness for Moon scenarios .

Connection Migration and 0-RTT QUIC connection migration enables an existing connection to survive a change in the client's IP address or port, as seen by the server. A client can send application data from its new address immediately while path validation proceeds; path validation usually requires one RTT but does not re-establish the connection. By contrast, 0-RTT applies when establishing a new connection using previously exchanged security credentials. It allows a client to send application data in 0-RTT packets before the handshake completes. 0-RTT is subject to replay attacks , which means that if it is used, the application should be careful about what it sends, following the guidance provided in section 9.2 of . A maximum time is also set for using 0-RTT, as discussed in . An application or mission may also decide to disable the use of 0-RTT given the security risks.

Connection Maintenance This section discusses keeping a QUIC connection alive over long delays and intermittence.

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 . 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. QUIC does not provide reliability across connections. An application that requires delivery therefore needs to detect the failure, establish a new connection, possibly using 0-RTT, and safely retry data whose delivery was not confirmed. This recovery costs additional time and bandwidth and requires application-level retry and duplicate-handling semantics. 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 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 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 18.2 of , and the idle-timeout mechanism is specified in section 10.1.

Keep Alive and Middleboxes As discussed in section 10.1 of , 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 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 . 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.

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.

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.

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) 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. 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. 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 congestion 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 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 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.

Congestion Window Configuration A QUIC sender's congestion controller maintains a congestion window that limits the amount of data in flight. This is sender-side congestion-control state and is distinct from the receiver-advertised flow-control limits discussed below. recommends initial and minimum congestion-window values for its congestion controller, but the window normally evolves as the controller processes congestion signals. Depending on the congestion controller and QUIC implementation, local configuration can expose an initial congestion window, a minimum or maximum congestion window, a fixed or target congestion window, or equivalent controller-specific controls. These settings are not QUIC transport parameters. Each control has different consequences: an initial value, cap, or target that is too small can prevent the sender from fully using its allocated capacity, while an overly large initial value or target can create bursts, queues, or loss. Raising the minimum can also prevent the controller from reducing its rate sufficiently in response to congestion. When such controls are available, space operations should tune them using the minimum and maximum BDP calculated in , the allocated path capacity, and the storage available at intermediate nodes. Since these characteristics are known in advance for a mission, they can be configured locally when the QUIC implementation exposes the required congestion-control settings. 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 congestion window, or an explicit outbound rate limit, SHOULD be set to the rate of the slowest downstream link. 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.

Flow Control A receiver can tell the sender how much data it is willing to accept using initial flow-control transport parameters and MAX_DATA frames. Insufficient flow-control credit can prevent the sender from fully using the available bandwidth even when the congestion controller permits additional data in flight.

Max Data initial_max_data limits the aggregate amount of stream data that the peer can send on the connection before receiving additional credit . The initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni transport parameters provide corresponding initial per-stream limits. Given the BDP of a typical deep space connection, applications should set these parameters to sufficiently large values so that the sender is capable of sending data while bandwidth is available. The initial flow-control transport parameters are specified in section 18.2 of .

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 amount of information that might need to be sent again is smaller than with larger packets, an important consideration in space where loss recovery is 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. QUIC does not retransmit lost packets whole; it sends the information carried in lost frames again in new frames as needed, as specified in section 13.3 of .

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 for more information.

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 . 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.

Path MTU Discovery To find the optimum MTU, some QUIC stacks implement Path MTU discovery by sending increasingly larger packets until the maximum MTU is found, which can involve loss of probe packets. 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, an implementation may expose controls to disable path MTU discovery and locally set its outgoing maximum datagram size to the known path MTU minus the IP and UDP header sizes. This local setting is distinct from the max_udp_payload_size transport parameter specified in section 18.2 of . That transport parameter advertises the largest UDP payload that an endpoint is willing to receive; it can constrain the peer's datagram size, but it does not configure the sender's local path MTU or disable path MTU discovery. 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 local path MTU can also be exposed by an implementation as a dynamically managed per-path setting. The max_udp_payload_size transport parameter cannot be changed after connection establishment.

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.

Acknowledgement Frequency QUIC stacks have various mechanisms to trigger acknowledgements (ACKs), as described in and . 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 . 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. Support is advertised during connection establishment using the extension's min_ack_delay transport parameter, 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 18.2 of , 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 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.

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 , 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 , it remains to be seen whether it is really needed for deep space. 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.

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 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) 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.

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 ; the details are out of scope of this document.

TLS As discussed in section 4.4 of , 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 should be considered. As discussed in section 4.6 of , 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 0-RTT. As discussed in section 6.5 of , 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 enables the update of keys from each peer. 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 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. 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 and ) 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 so that the keys still advance by a single generation; scheduling updates from a single peer avoids redundant updates.

Applicability of the QUIC Profile for Some Example Scenarios This section provides guidance for a possible QUIC profile for the connectivity scenarios described in , 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.

Earth to Cruising Spacecraft (CS) As discussed in , with the tested stack's default 30-second idle timeout, a new QUIC connection with a one-way delay of 15 seconds or more will not be established unless the initial RTT estimate or idle timeout is changed. This threshold is implementation-specific rather than a QUIC protocol limit. If the one-way delay is lower than 15 seconds, a connection using the tested default settings should be established, but unnecessary probe packets can consume additional bandwidth. The max_idle_timeout should be set depending on the one-way delay and the application traffic pattern.

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 unnecessary probe packets can consume additional bandwidth, as discussed in . 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, 0-RTT may be disabled at little cost, for better security. As discussed in and , the Bottleneck Bandwidth and Round-trip propagation time (BBR) congestion controller may be used and will perform better than others.

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 . 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 , 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 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 .

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 using the tested implementation's default configuration will not be established, as demonstrated in . Therefore, the local initial RTT estimate should be set to an appropriate value as discussed in , 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 , 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.

Earth-Mars with Intermittent Connectivity (MI) As discussed in , the local initial RTT estimate 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 , 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 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 estimate and max_idle_timeout settings discussed above, is sufficient for reliable delivery over scheduled intermittent paths.

Solar Conjunction (SC) In this scenario, described in , 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. 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 , 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 ) may still be used to cautiously reuse retained congestion-control parameters, provided that the path is not known to have changed. 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 , 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 . 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.

IANA Considerations This memo includes no request to IANA.

Security Considerations The use of 0-RTT is subject to replay attacks 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 , 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.

References Normative References Informative References Internet Assigned Numbers Authority(IANA) Consultative Committee on Space Data Systems (CCSDS) Consultative Committee on Space Data Systems (CCSDS) Marc Blanchet Natia Piotrowski Johannes Frisch Quinn

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.