Internet-Draft Careful Congestion Control Convergence July 2023
Kuhn, et al. Expires 6 January 2024 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-ietf-tsvwg-careful-resume-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
N. Kuhn
Thales Alenia Space
E. Stephan
Orange
G. Fairhurst
University of Aberdeen
C. Huitema
Private Octopus Inc.

Careful Convergence of Congestion Control from Retained State

Abstract

This document specifies careful convergence of Congestion Control (CC), providing a cautious method that enables fast startup for a wide range of connections or reconnections.

The method reuses a set of computed CC parameters that are based on the previously observed path characteristics between the same pair of transport endpoints, such as the bottleneck bandwidth, available capacity, or the Round Trip Time (RTT). These parameters are stored, allowing them to be later used to modify the CC behavior of a subsequent connection. The document also discusses assumptions and defines requirements around how a sender utilizes these parameters to provide opportunities for a connection to more quickly get up to speed (i.e. utilize the available capacity). It discusses how these changes impact the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. The method is expected to be appropriate to IETF transports.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 January 2024.

▲

Table of Contents

1. Introduction

All Internet transports are required to either use a 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 operates across an Internet path with a high and/or variable bandwidth-delay product (BDP). This mechanism targets these challenges.

A CC method typically takes time to ramp-up the packet rate, called the "slow-start phase", informally known as the time to "Get up to speed". This slow start phase is a period in which a sender intentionally uses less capacity than might be available, with the intention to avoid or limit overshooting the actual capacity at a bottleneck. This can increase queuing (latency/jitter) and/or congestion packet loss to the flow. Any overshoot in the capacity can also 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 a common bottleneck).

The method can improve performance by reducing the time to get up to speed, and hence can reduce the total duration of a transfer. It introduces an alternative method to select initial CC parameters, including a way to more rapidly and safely grow the congestion window (cwnd). This method is based on temporal sharing (sometimes known as caching) of a set of computed CC parameters that relate to a previously observed path, such as the bottleneck bandwidth, available capacity, and RTT. These parameters are stored and used to modify the CC behavior of a subsequent connection between the same local and remote endpoints.

When used with the QUIC transport, it provides transport services that resemble those currently available in TCP, such as TCP Control Block (TCB) [RFC9040] caching or updates to support application-limited traffic.

1.1. Using the Information with Care

"Generally, implementations are advised to be cautious when using previous values on a new path", as stated in [RFC9000]. This advice is appropriate for any IETF transport protocol.

Care is therefore needed in the use of any temporal information to assure safe use of the Internet and to be robust to changes in traffic patterns, network routing and link/node failures. There are also cases where using the parameters of a previous connection are not appropriate, and a need to evaluate the potential for malicious use of the method.

1.2. Receiver Preference

Whilst a sender could take optimization decisions without considering the receiver's preference, there are cases where a client at the receiver could have information that is not available at the sender. In these cases, a client could explicitly ask for tuning the slow start when the application continues transmission, or to to inhibit tuning. Examples where this could have benefit include:

  1. when a receiver understands that the pattern of traffic that a connection will use is different (e.g., the volume of data to be sent, the length of the session, or the maximum transfer rate required);
  2. when a receiver has a local indication that the path/local interface has changed since CC parameters were stored;
  3. when there is information related to the current hardware limitations at the receiver;
  4. where the receiver understands the capacity that will be needed for other concurrent flows that might be expected to share the capacity of the path.

A related document complements this CC method by allowing the sender-generated transport information to be stored at the receiver [I-D.kuhn-quic-bdpframe-extension]. This enables a receiver to implement a policy that informs a sender whether the receiver desires the sender to reuse the CC parameters. By transferring the information to a receiver, it also releases the sender from needing to retain CC parameter state for each receiver.

1.3. Examples of Scenarios of Interest

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

The method is expected to reduce the time to complete a transfer when the transfer sends significantly more data than allowed by the IW, and the BDP is also significantly more than the IW.

An application could use a series of connections over the same path (i.e. resumes a connection to the same endpoint). This can be used by a sender that performs a unidirectional data transfer towards the receiver, (e.g., a receiver downloading a file or a web page). Without the method, each connection would otherwise need to individually discover the CC parameters.

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

1.3.1. An Example of a Moving Endpoint

In this example, an application resumes using capacity after a pause in transmission. Without the method, the application that pauses would otherwise need to discover new CC parameters each time it connects to the same endpoint.

A variant of this example is when the application reconnects after a disruption that 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) before the endpoint returns to use a path with the original characteristics.

1.3.2. A Satellite Access Network Example using QUIC

QUIC introduces the concept of transport parameters (Section 4 of [RFC9000]). The present document adds to this by noting that a new connection can utilize a set of key transport parameters from a previous connection to reduce the completion time for a transfer.

This benefit is particularly evident for a path where the RTT is much larger than for typical Internet paths. In a specific example of high BDP path, a satellite access network, takes up to 9 seconds to complete a 5.3 MB transfer using standard CC, whereas using the specified method the transfer time could reduce to 4 seconds [IJSCN]; and the time to complete a 1 MB transfer could be reduced by 62 % [MAPRG111]. Benefit is also expected for other sizes of transfer and for different path characteristics that also result in a path with high BDP.

1.3.3. Another Network Example

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

2. Language, notations and terms

This section provides a brief summary of key terms and the requirements language that is used.

2.1. Requirements Language

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2.2. Use of CC Information collected by the Sender

Sender-generated information is used in this document for two functions:

  • Information to characterize the saved path, to allow a sender to establish if the saved information indicates the saved path is consistent with the current path.
  • Information about the capacity that was available on a saved path, to allow a later sender to determine an appropriate set of CC parameters for its current path.

2.3. Notations and Terms

The document uses language drawn from a range of IETF RFCs. It defines current, and saved values for a set of CC parameters:

  • current_bb : The current estimated bottleneck bandwidth;
  • saved_bb: The estimated bottleneck bandwidth preserved from a previous connection;
  • current_rtt: The current RTT;
  • saved_rtt: The measured RTT, preserved from a previous connection;
  • endpoint_token: The Endpoint Token of the receiver;
  • current_endpoint_token: The current Endpoint Token of the receiver;
  • saved_endpoint_token: The Endpoint Token of a previous connection by the receiver;
  • remembered BDP parameters: A combination of the saved_rtt and saved_bb;
  • jump_cwnd: The resumed congestion window,used in the Unvalidated Phase.

The Endpoint Token is described in Appendix A.

3. The Phases of CC using Careful Resume

This section defines a series of phases that the CC algorithm moves through as a connection gets up to speed when it uses the Careful Resume method.

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 indicate the capacity that was available. It includes the current RTT (current_rtt), bottleneck bandwidth (current_bb) and current receiver Endpoint Token (current_endpoint_token) stored as saved_rtt, saved_bb and saved_endpoint_token Section 4.1. One implementation solution could be to store the information at the server. Different implementation solutions are detailed in [I-D.kuhn-quic-bdpframe-extension].

3.2. Reconnaissance Phase

When a sender resumes between the same pair of endpoints, (aka 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 parameters have not expired.) When a method is provided (such as the BDP_Frame), a receiver can request the sender to not enter this phase.

In the Reconnaissance Phase, the sender sends initial data, limited by the Initial Window, and monitors its reception in the acknowledgements from the receiver. This phase checks whether the current path is consistent with the saved path information. The sender measures the path characteristics of the present path to confirm that the path is consistent with the previously characterized path (including a similar RTT) Section 4.2.

  • If the sender determines that the path RTT or the other saved path information are not consistent with the current path, then the sender continues using the standard CC, and enters the Normal Phase.
  • To ensure a sender avoids resuming under severely congested conditions, if any sent initial data was not correctly acknowledged or congestion was detected, then the sender continues using the standard CC, and enters the Normal Phase.
  • If the sender confirms both that the saved and current path information are consistent and that the sent initial data was correctly received, the sender enters the Unvalidated Phase.

The Reconnaissance Phase calculates a jump_cwnd based on the saved CC parameters. The correct reception of packets sent using the jump_cwnd is monitored during the Unvalidated Phase.

To avoid starving other flows that started or increased their capacity after the Observation Phase, the sender MUST NOT set a jump_cwnd that corresponds to all the capacity that it previously used.

{XXX-Editor note: What safety factor is appropriate for the resuming sender? If using slow-start it would anyway double the rate on the next RTT, so is capacity*2/3 or 1/2 appropriate? Could this be a MUST NOT for the part about not using the values without somehow curbing them, with maybe a SHOULD for a specific value? Do we need to factor-in the degree of the indication? This could be nice, but then it makes it even harder to pick something useful? }

{XXX-Editor Note: It is possible that an implementation can start sending data using the jump_cwnd while still in the Reconnaissance Phase, before the all initial data is acknowledged. In this method, the cwnd is increased for each new ACK received, in proportion to the acknowledged volume of initial data, i.e. cwnd+=(jump_cwnd*(acknowledged_bytes/Initial_Window)). Transmission of this unvalidated data still requires pacing (see section XXX), and is tentative based on the rules for the Reconnaisance Phase. This proprtional method reduces the impact of delayed acknowledgements, which could otherwise delay the start of transmisison using the jump_cwnd, it also reduces additional delay when the IW was paced.}

3.3. Unvalidated Phase:

In the Unvalidated Phase, a sender monitors the tentaive use of the updated CC parameters. (These CC parameters are based on saved path information and allow a rate higher than allowed by a traditional slow-start mechanism.) The convergence towards the previous rate is expected to be faster, but should not be instantaneous, to avoid adding congestion to an already congested bottleneck. In this phase, the sender continues to check the saved and current path information are consistent Section 4.3.

  • If a sender determines either that previous parameters are not valid (due to a detected change in the path) or congestion was experienced, then the sender needs to enter the Safe Retreat Phase (see below).
  • If acknowledgments show that the data sent at the unvalidated rate was successful without inducing significant congestion to the path, then the sender is permitted to continue at the rate in the Unvalidated Phase when it enters the Normal Phase.

3.4. Safe Retreat Phase

In the Safe Retreat Phase, the sender stops using the saved CC parameters. This phase is designed to mitigate the impact on other flows that might have been sharing a congested bottleneck when in the Unvalidated Phase. The sender needs to re-initialize CC parameters to drain any queue that has built at the bottleneck during the Unvalidated Phase and allow other flows to then regain their share of the available capacity. This reaction differs to a traditional CC reaction to congestion, because in this case the capacity estimate was unvalidated Section 4.4. Saved CC parameters for this path need be removed from any cache, to prevent the parameters being used again with other flows.

When the sender transitions to the Safe Retreat Phase, there could still be packets that were sent in the Unvalidated Phase that have not yet been acknowledged. If these packets from the Unvalidated Phase are declared lost, they do not trigger an additional CC reaction.

If the data in the packets that are lost in the Unvalidated Phase needs to be recovered, this recovery commences using the reduced window set on entry to the Safe Retreat Phase. In the case of multiple loss, this could require multiple RTTs to complete successful resending of data that lost in the Unvalidated Phase. The loss of the packets used to resend data is considered a separate congestion event, and this does also trigger another CC reaction.

The sender then enters the Normal phase with re-initialized CC parameters.

3.5. Normal Phase

The sender continues transmisison using the normal CC method.

If the sender experiences a Retransmission Time Out (RTO) expiry, the sender returns to the normal CC phase and processes the RTO expiry.

4. Congestion Control Guidelines and Requirements

The sender is limited by any rate-limitation of the transport protocol being used. For QUIC this includes: flow control mechanisms or amplification attack prevention. 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.

As in QUIC, a TCP sender is limited by the receiver window (rwnd). The rwnd may need to be increased for a connection that is started with this method to gain the expected benefit.

4.1. Determining the current Path Capacity in the Observe Phase

Congestion controllers, such as CUBIC or RENO, can estimate the saved_bb and current_bb values by utilizing a combination of the cwnd/flight_size and the minimum RTT. A different method could be used to estimate the same values when using a rate-based congestion controller, such as BBR [I-D.cardwell-iccrg-bbr-congestion-control].

  • Observe Phase: The sender SHOULD NOT store and/or send CC parameter information related to an estimated bottleneck bandwidth (saved_bb) (see Section 2.3 for more details on bottleneck bandwidth definition), if the cwnd is not at least four times larger than the IW.
  • Observe Phase: The sender SHOULD update the stored CC parameters and/or send updated CC parameter information related to an estimated bottleneck bandwidth (saved_bb) (see Section 2.3 for more details on bottleneck bandwidth definition), if there are significant changes in the CC parameters that the session has measured. The rate of the updates transmission SHOULD be limited to at most one update for several RTTs of time.
  • Observe Phase: There are cases where the current cwnd does not reflect the bottleneck bandwidth. At the end of the CC slow start phase, the value of cwnd can be significantly larger than the minimum value needed to utilize the path (i.e., a cwnd overshoot). In most case, the cwnd finally converges to a stable value after several more RTTs. It would be inappropriate to use an overshoot in the cwnd as a basis for estimating the bottleneck bandwidth. NOTE: One mitigation could be to further restrict to only a fraction (e.g., 1/2) of the previously used cwnd; another mitigation might be to calculate the bottleneck bandwidth based on the flight_size or an averaged cwnd.

4.2. Confirming the Path in the Reconnaissance Phase

The sender sends initial data limited by the IW - this value is assumed a safe starting point for any path where there is no path information or congestion control information. This limit avoids adding excessive congestion to a potentially congested path.

The sender monitors the reception of the initial data. If the path characteristics resemble those of a previously observed connection (i.e., current_rtt < 1.2*saved_rtt) and all data was acknowledged without reported congestion, the method permits the sender to utilize the saved_bb as an input to adapt current_bb to rapidly determine a new safe rate.

  • Reconnaissance Phase: A sender MUST limit the initial data, sent in the first RTT of transmitted data, to not more than the IW [RFC9000].

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.

  • Endpoint Token change: If the Endpoint Token changes (i.e., the saved_endpoint_token is different from the current_endpoint_token), the different Endpoint Token can be assumed as an indication of a different network path. This new path does not necessarily exhibit the same characteristics as the old one.
  • RTT change: A significant change in RTT is regarded as an indication that the network conditions have changed. 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 likely to not be valid for the current path.
  • Lifetime of the 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.

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

Reconnaissance Phase:

  • The sender in the Reconnaissance Phase MUST compare the measured transport parameters (in particular current_rtt) of the new session with those of the previous session (in particular saved_rtt). The method MUST NOT be used when the path fails to be validated.
  • The sender MUST NOT use the parameters if any packet sent in the IW is detected as lost or acknowledgments indicate these packets were ECN CE-marked. The first indication of potential congestion therefore MUST result in a transition to the Normal Phase.

{XXX-Editor-note: RTT check should be a range rather than an inequality (current_rtt < 1.2*saved_rtt).}

4.3. Safety Requirements for the Unvalidated Phase

This section defines the safety requirements for using saved CC parameters to update the cwnd. These safety guidelines are designed to mitigate the risk that sender adds excessive congestion to an already congested path.

The method needs to be designed to avoid sending excessive data into a congested bottleneck, because this can have a material impact on any flows sharing that bottleneck, and the ability of those flows to control their own sending rate.

  • Unvalidated Phase: A new connection MUST NOT directly use the previously measured saved_rtt and saved_bb to simply initialize a new flow to resume sending at the same rate. The method needs to set cwnd less than or equal to 2/3 the previous value

{NOTE: A later revision needs to define how to decide a significant change.}

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

The network conditions for the same path can also change over time. Bottleneck bandwidth and network traffic can change at any time. An Internet method needs to be robust to network conditions that can differ from one connection to the next, due to variations in the forwarding path, reconfiguration of equipment or changes in the link conditions.

  • Unvalidated Phase: Careful Resume MUST be robust to changes in network traffic, including the arrival of new traffic flows that compete for the bottleneck capacity.
  • Unvalidated Phase: Preventing Starvation of New Flows. It would not be appropriate to fully use a bottleneck bandwidth estimate based on a previous measurement of capacity, because new flows might have started using the available capacity since that measurement was made. The mitigation could be to restrict to only a fraction (e.g., 1/2) of the previously used cwnd.
  • Unvalidated Phase: The sender MUST transition to the Safe Retreat Phase when packets are detected as lost or acknowledgments indicate the packets were ECN CE-marked. These are indication of potential congestion and therefore the method is not used.

4.3.2. Pacing in the Unvalidated Phase

The sender needs to avoid sending a burst of packets as a result of a step-increase in the congestion window [RFC8085], [RFC9000]. Various modifications to the sender to avoid line-rate bursts have been suggested (e.g., [I-D.hughes-restart]). Pacing the packets as a function of the current_rtt can provide this additional safety during the unvalidated period.

Identifing a relevant pacing rhythm:

  • The sender estimates a pacing rhythm using saved_rtt and saved_bb. The Inter-packet Transmission Time (ITT) is determined from the ratio between the current Maximum Message Size (MMS) and the ratio between the saved_bb and saved_rtt. A tunable safety margin can avoid sending more than a recommended maximum IW (recom_iw):

    • current_iw = min(recom_iw,saved_bb)
    • ITT = MSS/(current_iw/saved_rtt)

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

4.4. Safety Requirements for the Safe Retreat Phase

This section defines the safety requirements after a path change or congestion has been detected during the Unvalidated Phase.

The transport parameters are adjusted in the Unvalidated Phase, resulting in a higher cwnd. If there are indications of congestion, this also indicates that the parameters no longer reflect the current path, and the cwnd needs to be reduced to avoid overshoot of the bottleneck capacity. This can result from changes in traffic at the bottleneck and/or changes in the path capacity.

{XXX-Editor note: A later revision will guide on the mitigation after detected congestion.}

4.5. Returning to Normal Congestion Control

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 later revision will guide on the entering normal CC.}

{XXX-Editor note: It would be good to have a discussing about 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.}

5. Acknowledgments

The authors would like to thank John Border, Gabriel Montenegro, Patrick McManus, Ian Swett, Igor Lubashev, Robin Marx, Roland Bless and Franklin Simo for their fruitful comments on earlier versions of this document.

The authors would like to particularly thank Tom Jones for co-authoring previous versions of this document.

6. IANA Considerations

{XXX-Editor note: Text is required to register any IANA Considerations.

7. Security Considerations

This document does not exhibit specific security considerations since only sender level considerations are proposed. Security considerations for the interactions with the receiver are discussed in [I-D.kuhn-quic-bdpframe-extension].

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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4782]
Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, , <https://www.rfc-editor.org/info/rfc4782>.
[RFC8085]
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc9000>.
[RFC9040]
Touch, J., Welzl, M., and S. Islam, "TCP Control Block Interdependence", RFC 9040, DOI 10.17487/RFC9040, , <https://www.rfc-editor.org/info/rfc9040>.

8.2. Informative References

[CONEXT15]
Li, Q., Dong, M., and P B. Godfrey, "Halfback: Running Short Flows Quickly and Safely", ACM CoNEXT , .
[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, , <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, , <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, , <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, , <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, .
[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 , .
[RFC5783]
Welzl, M. and W. Eddy, "Congestion Control in the RFC Series", RFC 5783, DOI 10.17487/RFC5783, , <https://www.rfc-editor.org/info/rfc5783>.
[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, , <https://www.rfc-editor.org/info/rfc8867>.

Appendix A. Appendix: An Endpoint Token

This 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:

  1. 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.
  2. 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.
  3. 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.

Appendix B. Summary 

+---------+-----------+----------------+---------------+-----------+
|Rationale| Solution  |    Advantage   |    Drawback   |  Comment  |
+---------+-----------+----------------+---------------+-----------+
|#1       |#1         |                |               |           |
|Variable |set        |Ingress optim.  |Risk of adding |MUST NOT   |
|Network  |current_*  |                | congestion    |implement  |
|         |to saved_* |                |               |           |
|         +-----------+----------------+---------------+-----------+
|         |#2         |                |               |           |
|         |Implement  |Reduce risk of  |Negative impact|MUST       |
|         |safety     | adding         | on ingress    |implement  |
|         |check      | congestion     | optim.        |Section 3  |
+---------+-----------+----------------+---------------+-----------+
Figure 1: Comparing Careful Resume solutions

Appendix C. Appendix: Revision details

Previous individual submissions were discussed in TSVWG and QUIC.

Authors' Addresses

Nicolas Kuhn
Thales Alenia Space
Emile Stephan
Orange
Godred Fairhurst
University of Aberdeen
Department of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Christian Huitema
Private Octopus Inc.