Careful Convergence of Congestion Control from Retained State

Internet-Draft	Careful Congestion Control Convergence	September 2023
Kuhn, et al.	Expires 16 March 2024	[Page]

Abstract

This document specifies a cautious method for IETF transports that enables fast startup of congestion control for a wide range of connections or reconnections.¶

The method reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are stored, allowing them to be later used to modify the congestion control behavior of a subsequent connection.¶

It discusses assumptions and defines requirements for how a sender utilizes these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilize available capacity. It discusses how the method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate.¶

1. Introduction

All Internet transports are required to either use a Congestion Control (CC) method, or to constrain their rate of transmission [RFC8085]. In 2010, a survey of alternative CC methods [RFC5783], noted that there are challenges when a CC method operates across an Internet path with a high and/or variable bandwidth-delay product. This mechanism targets a solution for these challenges.¶

A CC method typically takes time to ramp-up the sending rate, called the "slow-start phase", informally known as the time to "Get up to speed". This slow-start phase defines a time in which a sender intentionally uses less capacity than might be available, with the intention to avoid or limit overshooting the available capacity for the path. The slow-start design can increase queuing (latency/jitter) and/or congestion packet loss to the flow. Any overshoot can have a detrimental effect on other flows sharing a common bottleneck. In the extreme case, persistent congestion could result in unwanted starvation of other flows [RFC8867] (i.e., preventing other flows from successfully sharing capacity at a common bottleneck).¶

This document proposes a method that is expected to reduce the time to complete a transfer when the transfer sends significantly more data than allowed by the Initial congestion window (IW), and where the Bandwidth Delay Product (BDP) is also significantly more than the product of the IW and the Round Trip Rime (RTT).¶

It introduces an alternative method to select initial CC parameters, that seek to more rapidly and safely grow the sending rate (or congestion window, CWND). This method is based on temporal sharing (sometimes known as caching) of a saved set of CC parameters that relate to previous observations of the same path. The saved CC parameters include: the available capacity found on the path and the RTT. These parameters are stored and used to modify the CC behavior of a subsequent connection between the same endpoints.¶

When used with the QUIC transport, this provides transport services that resemble those currently available in TCP, using methods such as TCP Control Block (TCB) [RFC9040] caching.¶

1.1. Use of saved CC parameters by a Sender

CC parameters are used by this method for two functions:¶

Information about the utilised path capacity. This allows a later sender to determine an appropriate set of CC parameters for re-using the path.¶
Information to characterize the saved path. This allows a sender to confirm whether the current path is consistent with a saved path.¶

"Generally, implementations are advised to be cautious when using previous values on a new path", as stated in [RFC9000]. While this statement has been proposed in the context of QUIC standardization, this advice is appropriate for any IETF transport protocol. Care is therefore needed to assure safe use and to be robust to changes in traffic patterns, network routing and link/node conditions. There are also cases where using the saved parameters of a previous connection is not appropriate.¶

1.2. Receiver Preference

Whilst a sender could take optimization decisions without considering the receiver's preference, there are cases where a receiver could have information that is not available at the sender, or might benefit from understanding that careful resume might be used. In these cases, a receiver could explicitly ask to enable or inhibit tuning of the CC when an application initiate a new session or resume an existing one.¶

An indication from the sender that the method is available, could also allow a receiver to tune policies for using the connection (e.g., managing the receiver window or flow credit).¶

Examples where a receiver could request not to use the method include:¶

a receiver that can predict the pattern of traffic (e.g., insight into the volume of data to be sent, the expected length of a session, or the maximum transfer rate required);¶
a receiver with a local indication that a path/local interface has changed since the CC parameters were stored;¶
knowledge of the current hardware limitations at a receiver;¶
a receiver that can predit additional capacity will be needed for other concurrent/later flows (i.e., prefers to use the method for the other flows).¶

QUIC introduces the concept of transport parameters (Section 4 of [RFC9000]). A related document proposes an exchange for QUIC that requests the sender-generated CC parameters to be stored at the receiver [I-D.kuhn-quic-bdpframe-extension]. Transferring the information to a receiver releases the need for a sender to retain transport state for each receiver. This document also evaluates the potential for malicious use of this exchange.¶

1.3. Examples of Scenarios of Interest

This section provides a set of examples where the method is expected to improve performance.¶

Either endpoint can assume the role of a sender or a receiver. The method also supports a bidirectional data transfer, where both endpoints simultaneously send data (e.g., remote execution of an application, or a bidirectional video conference call).¶

In one example, an application uses a series of connections over a path (i.e., resumes a connection to the same endpoint). Without this method, each connection would need to individually discover appropriate CC parameters, whereas the method allows the flow to continue at a rate that resembles the previous rate.¶

In another example, an application reconnects after a disruption had temporarily reduced the path capacity (e.g., after a link propagation impairment, or where a user on a train journey travels through different areas of connectivity). When the endpoint returns to use a path with the original characteristics, it can resume a transmssion rate based on the previous used capacity.¶

There is particular benefit for any path with an RTT that is much larger than for typical Internet paths. In a specific example, an application connected via a satellite access network [IJSCN] could require 9 seconds to complete a 5.3 MB transfer using standard CC, whereas using the method this transfer time could reduce to 4 seconds. The time to complete a 1 MB transfer could dimilarly reduce by 62 % [MAPRG111]. This benefit is also expected for other sizes of transfer and for different path characteristics when a path has a large BDP.¶

{XXX-Editor note: A future revision would helpfully provide further Path Examples here.}¶

3. The Phases of CC using Careful Resume

This section defines a series of phases that the CC algorithm moves through as a connection uses the Careful Resume method, as shown in Figure 1.¶


Connect -> Reconaissance --------------------> Normal
             |                                   ^
           Unvalidated --> Validating -----------+
             |               |                   |
             +---------------+-> Safe Retreat ---+

Figure 1: The CC phases when starting to use up a connection using the Careful Resume method. An established connection later performs the Observe Phase (not shown).¶

3.1. Observe Phase

During a previous connection, information about the specific path to an endpoint is saved. This is used to characterize the path and to measure the capacity that was used. This includes the minimum RTT (saved_rtt), the path capacity (saved_capacity) and the receiver Endpoint Token (saved_endpoint_token). An implementation can store this information at the server (or could exchange this information with a receiver, as detailed in [I-D.kuhn-quic-bdpframe-extension]).¶

Observe Phase: If the measured CWND is less than four times the Initial Windown (IW) (or the rate is less than would be permitted by IW*4/RTT), a sender SHOULD NOT store and/or send CC parameter information.¶

3.2. Reconnaissance Phase

When a sender resumes transmission between the same pair of endpoints, (a.k.a. thinks it uses the same path) it enters the Reconnaissance Phase. The sender only enters this phase when there are saved CC parameters for the same pair of endpoints and this information is currently valid (i.e., the saved parameters have not expired.) When a method is used (such as the BDP_Frame), a receiver can request the sender to not enter this phase.¶

In this phase, the sender transmits initial data, limited by the IW, and monitors its reception. This phase measures the current path characteristics to confirm these are consistent with the previously characterized path.¶

Reconnaissance Phase (Endpoint change): If the current endpoint is not the same, the sender MUST revert to using the standard CC, and enters the Normal Phase. If the Endpoint Token changes (i.e., the saved_endpoint_token is different from the current_endpoint_token), it is assumed to represent a different network path.¶
Reconnaissance Phase (Confirming RTT): Since the CC information is directly impacted by the RTT, a significant change in the RTT is a strong indication that the previously estimated BDP parameters are not valid for the current path. An RTT measurement is confirmed when current_rtt ≥ (saved_rtt / 2) and the current_rtt ≤ (saved_rtt x 10 (TBC)).¶
Reconnaissance Phase (Lifetime of saved information): The CC information is temporal. Frequent connections to the same endpoint are likely to track changes, but long-term use of previous values is not appropriate.¶

When a sender confirms the path and it receives an acknowledgement for the initial data without reported congestion, it MAY then enter the Unvalidated Phase. This transition occurs when a sender has more data than permitted by the current CWND.¶

Implementation requirements are provided in Section 4.2.¶

When the path is not confirmed, the method is not used and the sender enters the Normal Phase.¶

3.3. Unvalidated Phase

The Unvalidated Phase is designed to enable the rate or CWND to more rapidly get up to speed. The method therefore remains in the Reconnaissance Phase and does not transition to the Unvalidated Phase until the sender has more data ready to send in the transmission buffer than is permitted by the current CWND. (If an application is data-limited, the sender sends insufficient data to be able to validate the tentative higher rate.) In some implementations, the decision to enter the Unvalidated Phase could require coordination with the management of buffers in the interface to the higher layers.¶

This phase paces transmission using an increased rate or CWND (jump_CWND) that is calculated based on the saved CC parameters and current_RTT.¶

Unvalidated Phase (jump_size): To avoid starving other (potential) flows that could have started or increased their capacity after the Observation Phase, the jump_CWND MUST be no more than half of the previous saved_capacity. Hence, jump_CWND ≤ saved_capacity/2.¶
Unvalidated Phase (Pacing): Transmission using an unvalidated rate or CWND MUST use pacing.¶
Unvalidated Phase (Confirming the path): If a sender determines that the previous parameters are not valid (due to a detected change in the path) (e.g. packet delay has changed), the method enters the Safe Retreat Phase.¶
The sender enters the Validating Phase when an acknowledgement is received for the first packet number (or higher) sent in the Unvalidated Phase.¶

Implementation requirements are provided in Section 4.3.¶

3.4. Validating Phase

The Validating Phase is designed to verify that the packets sent in the Unvalidated Phase were received without inducing congestion. The sender typically remains in this phase for 1 RTT. The CWND remains unvalidated in this phase. (Note: When the full jump_CWND is not fully utilised, this results in s smaller capacity being validated.)¶

Validating Phase (Updating CWND): The CWND is updated using the normal rules for the current congestion controller. The default rule is that of Reno.¶
Validating Phase (Validating capacity): A sender monitors the correct reception of the packets that were sent using the unvalidated jump. If a sender determines that congestion was experienced (e.g., packet loss or ECN-CE marking), the method enters the Safe Retreat Phase.¶
The sender enters the Normal Phase when an acknowledgement is received for the last packet number (or higher) that was sent in one RTT after entering the Unvalidated Phase.¶

3.5. Safe Retreat Phase

This phase is entered when a jump in the Unvalidated Phase has overshot the currently available capacity. The phase starts when the first loss/ECN-CE marking is detected. This trigger is the same as used by QUIC sender to transition from Slow Start to Recovery [RFC9002].¶

Safe Retreat Phase (Saved information): Any saved CC parameters for this path are removed from any cache, to prevent these parameters being used again with other flows.¶
Safe Retreat Phase (Re-initializing CC): On entry, the CWND MUST be reduced to no more than the IW. This avoids persistent starvation by helping other flows to regain their share of the available capacity.¶
Safe Retreat Phase (QUIC recovery): When the CWND is reduced, a QUIC sender can immediately send a single packet prior to reduction [RFC9002]. This speeds up loss recovery if the data in the lost packet is retransmitted and is similar to TCP as described in Section 5 of [RFC6675].¶
Safe Retreat Phase (Increasing CWND): The CWND MAY be increased for each acknowledgment that acknowledges a previously unacknowleded packet that was sent in the Unvalidated Phase, since this indicates a packet has been successfully sent across the path.¶
The sender enters Normal Phase when the last packet (or later) sent during the Unvalidated Phase has been acknowledged.¶

Implementation requirements are provided in Section 4.5.¶

3.5.1. Loss Recovery after entering Safe Retreat

Unacknowledged packets that were sent in the Unvalidated Phase can be lost when there is congestion. Loss recovery commences using the reduced CWND that was set on entry to the Safe Retreat Phase.¶

NOTE: A TCP or SCTP sender is always required to retransmit all lost data. For QUIC and DCCP, the need for loss recovery depends on the sender policy for retransmission.¶
NOTE: During loss recovery, a receiver can cumulatively acknowledge data that was previously sent in the Unvalidated Phase in addition to acknowledging successful retransmission of data. [RFC3465] describes how to appropriately account for such acknowledgments.¶
NOTE: On entry to the Safe Retreat Phase, the rate or CWND can be significantly reduced, when there was multiple loss, recovery of all lost data could require multiple RTTs to complete.¶

The sender leaves the Safe Retreat Phase when an acknowledgement is received for the last packet number (or higher) sent in the Unvalidated Phase. If the last packet number is not cumulatively acknowledged, then additional packets might need to be retransmitted.¶

Methods using a slowstart threshold need to update this using the CWND (i.e., ssthresh = CWND).¶

The Normal Phase is then entered.¶

3.6. Normal Phase

In the Normal Phase, the sender transitions to using the normal CC method (e.g., in congestion avoidance).¶

Normal Phase (Updating CC): The sender MUST reset the rate or CWND on entry to the Normal Phase to reflect the volume of acknowledged data that was received during the Unvalidated Phase. (When the sender has used the entire jump_CWND and this was acknowledged in full, no adjustment is needed.)¶

Implementation requirements are provided in Section 4.6.¶

3.7. RTO Expiry while using Careful Resume

A sender that experiences a Retransmission Time Out (RTO) expiry while using Careful Resume, ceases to use the method. The sender continues using normal CC.¶

NOTE: As in loss recovery, data sent in the Unvalidated Phase could be later acknowledged after an RTO event (see Section 3.5.1).¶

4. Congestion Control Guidelines and Requirements

This section provides requirements for implementation and guidance on use.¶

4.1. Determining the Current Path Capacity in the Observe Phase

There are various approaches to measuring the capacity that has been used by a connection. Congestion controllers, such as CUBIC or RENO, can estimate the capacity by utilizing a combination of the CWND/flight_size and the minimum RTT. A different approach could estimate the same values for a rate-based congestion controller, such as BBR [I-D.cardwell-iccrg-bbr-congestion-control].¶

Observe Phase: The sender should update the stored CC parameters and/or send updated CC parameter information related to an estimated path capacity (saved_capacity) after each observation.¶
Observe Phase: The stored CC parameters should be updated if there are significant changes in the saved CC parameters. The rate of update MUST be less than one update for several RTTs of time.¶
Observe Phase: There are cases where the current rate or CWND does not reflect the path capacity. At the End of the CC slow start phase, the value can be significantly larger than needed to fully utilize the path (i.e., a CWND overshoot). It is inappropriate to use an overshoot in the rate or CWND as a basis for estimating the capacity. In most case, the rate or CWND will converge to a stable value after several more RTTs. One mitigation could be to calculate the capacity based on the flight_size or an averaged rate or CWND. Also when the sender is application-limited or in an RTT following a burst of transmission, a sender typically transmits much less data than allowed. This case also ought to be discounted when estimating the capacity.¶

4.2. Confirming the Path in the Reconaisance Phase

In the Reconaisance Phase a sender initates a connection and starts sending initial data. It measures the RTT to confirm the path it wishes to use.¶

A sender must limit the initial data, sent in the first RTT of transmitted data, to not more than the IW [RFC9000]. This transmission using the IW is assumed to be a safe starting point for any path to avoid adding excessive load to a potentially congested path. any initial data. (When used in a controlled network, additional information about local path characteristics could be known, which might be used to configure a non-standard IW.)¶

4.2.1. Confirming the Path

Paths can change with respect to time for many reasons. This could result in previously measured CC parameters becoming irrelevant. The sender confirms the RTT by comparing each of a series of measured RTT samples against the previously saved_RTT.¶

A current RTT sample that is less than a half of the saved_RTT is regarded as too small, such a low RTT is indicative of a path change. (This factor of two arises, since the rate should not exceed the previous rate when the capacity was measured, because the jump_CWND is calculated as 1/2 x saved_capacity.) An RTT sample more than ten times the saved_RTT is regarded as too large, such a high RTT is indicative of a path change. (The factor of ten accommodates both increases in latency from buffering on a path, and any variation between samples).¶

NOTE: Some transport protocols implement methods that detect potential congestion by inferring congestion from an increase in the RTT. In the Reconnaissance Phase, this indication occurs earlier than congestion which is reported by loss or by ECN marking. Designs need to consider if this is a suitable trigger for changing the phase.¶

4.3. Safety Requirements for the Unvalidated Phase

This section defines the safety requirements for using saved CC parameters to tentatively update the rate or CWND. These safety guidelines mitigate the risk that a sender adds excessive congestion to an already congested path.¶

{XXX-Editor NOTE: A future revision of this document needs to specify how long CC Parameters can be cached, possibly based on TCP-new-CWV or TCB, RFC9040.}¶

Unvalidated Phase (Jxump): A connection MUST NOT directly use the previously measured saved_rtt and saved_capacity to simply initialize a new flow to resume sending at the same rate. The jump_CWND must be no more than 1/2 the previous saved capacity based on the current RTT (saved_BDP / current_RTT). Using the current_rtt rather than a saved RTT value helps to ensure appropriate pacing, but places a limitation on the minimum acceptable RTT for using the method to avoid sending at a rate higher than previously observed.¶

4.3.1. Exit for the Unvalidated Phase because of Variable Network Conditions

Unvalidated and Reconnaissance Phases: The method MUST be robust to network conditions that are different due to variations in the forwarding path, reconfiguration of equipment, or changes in the link conditions.¶

Unvalidated Phase: The method MUST be robust to changes in network traffic, including the arrival of new traffic flows that compete for capacity at a shared bottleneck.¶
Unvalidated Phase: The method MUST prevent unduly suppressing flows that used the capacity since the available capacity was measured.¶
Unvalidated Phase: The sender MUST transition to the Safe Retreat Phase when a packet loss is detected or acknowledgments indicate sent packets were ECN CE-marked. These are an indication of potential congestion.¶

4.3.2. Pacing in the Unvalidated Phase

The sender must avoid sending a burst of packets greater than IW as a result of a step-increase in the congestion window [RFC8085], [RFC9000]. Pacing sent packets as a function of the current RTT provides an additional safety during the Unvalidated Phase. Other sender mitigatuons have also been suggested to avoid line-rate bursts (e.g., [I-D.hughes-restart]).¶

The following example provides a relevant pacing rhythm: The sender estimates a pacing rhythm using the RTT and the saved_capacity. The Inter-packet Transmission Time (ITT) is determined from the ratio between the current Maximum Message Size (MMS) and the ratio between the saved_capacity and the RTT. A safety margin can avoid sending more than a recommended maximum (recom_jump):¶

jump_CWND = min(recom_jump,saved_capacity/2)¶
ITT = MSS/(jump_CWND/saved_rtt)¶

This follows the idea presented in [RFC4782], [I-D.irtf-iccrg-sallantin-initial-spreading] and [CONEXT15].¶

4.4. Safety Requirements for the Validating Phase

When a sender completes the unvalidated phase, either by sending the jump_CWND or after 1 RTT, it then awaits reception of the acknowledgments to validate the use of this capacity.¶

4.5. Safety Requirements for the Safe Retreat Phase

This section defines the safety requirements after congestion has been detected during the Unvalidated Phase.¶

The Safe Retreat reaction MUST differ from a traditional reaction to detected congestion, because the jump_CWND can result in a significantly higher rate than would be allowed by the slow-start mechanism. This could aggressively feed a congested bottleneck, resulting in overshoot where a disproportionate number of packets from existing flows are displaced from the buffer at the congested bottleneck. For this reason, a sender needs to reduce its rate or CWND significantly below the saved_capacity.¶

Note: Proportional Rate Reduction (PRR) assumes that it is safe to reduce the rate gradually when in congestion avoidance. The method specified for PRR [RFC6937] is therefore not appropriate when there might be significant overshoot in the use of the capacity.¶

The CWND is reduced on entry to the Safe Retreat Phase to no more than the IW.¶

This provdies some examples of how to implement the Safe Retreat Phase:¶

A simple conservative approach sets CWND = IW and then resumes using normal slow-start. This method does not require measuring the capacity at congestion. The resulting pattern of CWND growth resembles that which would have occurred had the method not been used.¶
Performance can be improved by tracking the volume of successfully transmitted packets sent using the Unvalidated Phase (e.g., by recording the sequence number of the first packet sent in the phase.). This measured capacity is called the Pipe. The Pipe is not a safe measure of the current available share of the capacity whenever there was also a significant overshoot of the capacity, as indicated by excessive loss. Therefore, any method that increases CWND based on received acknowledgments ought to be scaled, because an overshoot could have resulted in unduly taking capacity from sharing flows.¶

4.6. Returning to Normal Congestion Control

After using the method, the CC controller returns to the Normal Phase.¶

For NewReno and CUBIC, it is recommended to exit slow-start and enter the congestion avoidance phase.¶
For BBR CC, it is recommended to enter the "probe bandwidth" state.¶

{XXX-Editor note: A future revision should discuss updating the saved values, whether used or not, after reaching normal operation for use the next time even if that update is to just refresh the expiration time.}¶

4.7. Limitations from Transport Protocols

A sender is limited by any rate-limitation of the transport protocol that is used.¶

The implementation details for different transports depend on the deisgn of the transport.¶

For QUIC this includes flow control mechanisms or preventing amplification attack. In particular, a QUIC receiver might need to issue proactive MAX_DATA frames to increase the flow control limits of a connection that is started with this method to gain the expected benefit.¶

A TCP sender is limited by the receiver window (rwnd). Unless configured at a receiver, the rwnd constrains the rate of increase for a connection and reduces the benefit of this method.¶

8. References

8.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>.
[RFC8085]: Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[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>.
[RFC8801]: Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", RFC 8801, DOI 10.17487/RFC8801, July 2020, <https://www.rfc-editor.org/info/rfc8801>.
[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>.

8.2. Informative References

[CONEXT15]: Li, Q., Dong, M., and P B. Godfrey, "Halfback: Running Short Flows Quickly and Safely", ACM CoNEXT , 2015.
[I-D.cardwell-iccrg-bbr-congestion-control]: Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. Jacobson, "BBR Congestion Control", Work in Progress, Internet-Draft, draft-cardwell-iccrg-bbr-congestion-control-02, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>.
[I-D.hughes-restart]: Hughes, A., "Issues in TCP Slow-Start Restart After Idle", Work in Progress, Internet-Draft, draft-hughes-restart-00, 30 November 2001, <https://datatracker.ietf.org/doc/html/draft-hughes-restart-00>.
[I-D.irtf-iccrg-sallantin-initial-spreading]: Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, E., and A. Beylot, "Safe increase of the TCP's Initial Window Using Initial Spreading", Work in Progress, Internet-Draft, draft-irtf-iccrg-sallantin-initial-spreading-00, 15 January 2014, <https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-sallantin-initial-spreading-00>.
[I-D.kuhn-quic-bdpframe-extension]: Kuhn, N., Emile, S., Fairhurst, G., and C. Huitema, "BDP Frame Extension", Work in Progress, Internet-Draft, draft-kuhn-quic-bdpframe-extension-02, 10 May 2023, <https://datatracker.ietf.org/doc/html/draft-kuhn-quic-bdpframe-extension-02>.
[IJSCN]: Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google QUIC performance over a public SATCOM access", International Journal of Satellite Communications and Networking 10.1002/sat.1301, 2019.
[MAPRG111]: Kuhn, N., Stephan, E., Fairhurst, G., Jones, T., and C. Huitema, "Feedback from using QUIC's 0-RTT-BDP extension over SATCOM public access", IETF 111 - MAPRG meeting , 2022.
[RFC3465]: Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 2003, <https://www.rfc-editor.org/info/rfc3465>.
[RFC4782]: Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, January 2007, <https://www.rfc-editor.org/info/rfc4782>.
[RFC5681]: Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5783]: Welzl, M. and W. Eddy, "Congestion Control in the RFC Series", RFC 5783, DOI 10.17487/RFC5783, February 2010, <https://www.rfc-editor.org/info/rfc5783>.
[RFC6675]: Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP", RFC 6675, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.
[RFC6937]: Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937, May 2013, <https://www.rfc-editor.org/info/rfc6937>.
[RFC8867]: Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating Congestion Control for Interactive Real-Time Media", RFC 8867, DOI 10.17487/RFC8867, January 2021, <https://www.rfc-editor.org/info/rfc8867>.
[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>.
[RFC9040]: Touch, J., Welzl, M., and S. Islam, "TCP Control Block Interdependence", RFC 9040, DOI 10.17487/RFC9040, July 2021, <https://www.rfc-editor.org/info/rfc9040>.

Appendix A. Appendix: An Endpoint Token

This annex proposes an Endpoint Token to allow a sender to identify its own view of the network path that it is using. In [I-D.kuhn-quic-bdpframe-extension] this Endpoint Token could be shared and used as an opaque path identifier to other parties and the sender can verify if this is one of its current paths.¶

A.1. Creating an Endpoint Token

When computing the Endpoint Token, the sender includes information to identify the path on which it sends, for example:¶

it needs to include a unique identifier for itself (e.g., a globally assigned address/prefix; or randomly chosen value).¶
it needs to include an identifier for the destination (e.g., a destination IP address or name).¶
it needs to include an interface identifier (e.g., an index value or a MAC address to associate the endpoint with the interface on which the path starts);¶
it could include other information such as the DSCP, ports, flow label, etc (recognising that this additional information might improve the path differentiation, but that this can can reduce the re-usability of the token);¶
it could include any other information the sender chooses to include, and potentially including PvD information [RFC8801] or information relating to its public-facing IP address;¶
it could include a nonce;¶
it could include a time-dependent value to define the validity period of the token.¶

When creating an Endpoint Token, the sender has to ensure the following:¶

To reduce the likelihood of misuse of the Endpoint Token, the value ought to be encoded in a way that hides the component information from the recipient and any eavesdropper on the path.¶
The sender can recalculate the Endpoint Token if it needs to validate a previously issued token; and that the Endpoint Token itself can be included in the computed integrity check for any path information it provides.¶
The Endpoint Token is designed so that if shared, it prevents another party from deriving private data from the token, or to use the token to perform unwanted likability with other information. This implies that the Endpoint Token MUST necessarily be different when used to identify paths using different interfaces.¶