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

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 . 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 transport parameters, 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 a number of QUIC transport parameters. The parameter names are from the IANA registry .

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 describes how to calculate the path characteristics of a mission, which are then used to set the transport parameters discussed in the following sections.

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

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.

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 set the Initial RTT on connection establishment to the maximum RTT as calculated in . 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 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 ). These 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 , 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 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 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 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 .

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 . Simulations have shown its usefulness for Moon scenarios .

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 , 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 . A maximum time is also set for using 0RTT, as discussed in . An application or mission may also decide to disable the use of 0RTT 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. 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 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 8.2 of .

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

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

Max Data initial_max_data is the maximum number of bytes that can be sent on a connection . 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 .

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.

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

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

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 . 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 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 without specific configuration will not be established, as demonstrated in . Therefore, the very minimum is to set the initial_rtt 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 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 , 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 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 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 , 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.