draft-ietf-quic-recovery-34.txt   draft-ietf-quic-recovery-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track I. Swett, Ed. Intended status: Standards Track I. Swett, Ed.
Expires: July 19, 2021 Google Expires: October 24, 2021 Google
January 15, 2021 April 22, 2021
QUIC Loss Detection and Congestion Control QUIC Loss Detection and Congestion Control
draft-ietf-quic-recovery-14 draft-ietf-quic-recovery-latest
Abstract Abstract
This document describes loss detection and congestion control This document describes loss detection and congestion control
mechanisms for QUIC. mechanisms for QUIC.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org [1]), which is archived at mailing list (quic@ietf.org [1]), which is archived at
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2021. This Internet-Draft will expire on October 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5.2. Estimating min_rtt . . . . . . . . . . . . . . . . . . . 9 5.2. Estimating min_rtt . . . . . . . . . . . . . . . . . . . 9
5.3. Estimating smoothed_rtt and rttvar . . . . . . . . . . . 10 5.3. Estimating smoothed_rtt and rttvar . . . . . . . . . . . 10
6. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 12 6. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Acknowledgment-Based Detection . . . . . . . . . . . . . 12 6.1. Acknowledgment-Based Detection . . . . . . . . . . . . . 12
6.1.1. Packet Threshold . . . . . . . . . . . . . . . . . . 13 6.1.1. Packet Threshold . . . . . . . . . . . . . . . . . . 13
6.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 13 6.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 13
6.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 14
6.2.2. Handshakes and New Paths . . . . . . . . . . . . . . 16 6.2.2. Handshakes and New Paths . . . . . . . . . . . . . . 16
6.2.3. Speeding Up Handshake Completion . . . . . . . . . . 17 6.2.3. Speeding Up Handshake Completion . . . . . . . . . . 17
6.2.4. Sending Probe Packets . . . . . . . . . . . . . . . . 17 6.2.4. Sending Probe Packets . . . . . . . . . . . . . . . . 18
6.3. Handling Retry Packets . . . . . . . . . . . . . . . . . 18 6.3. Handling Retry Packets . . . . . . . . . . . . . . . . . 19
6.4. Discarding Keys and Packet State . . . . . . . . . . . . 19 6.4. Discarding Keys and Packet State . . . . . . . . . . . . 19
7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 19 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 20
7.1. Explicit Congestion Notification . . . . . . . . . . . . 20 7.1. Explicit Congestion Notification . . . . . . . . . . . . 20
7.2. Initial and Minimum Congestion Window . . . . . . . . . . 20 7.2. Initial and Minimum Congestion Window . . . . . . . . . . 21
7.3. Congestion Control States . . . . . . . . . . . . . . . . 21 7.3. Congestion Control States . . . . . . . . . . . . . . . . 21
7.3.1. Slow Start . . . . . . . . . . . . . . . . . . . . . 21 7.3.1. Slow Start . . . . . . . . . . . . . . . . . . . . . 22
7.3.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 22 7.3.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 22
7.3.3. Congestion Avoidance . . . . . . . . . . . . . . . . 22 7.3.3. Congestion Avoidance . . . . . . . . . . . . . . . . 23
7.4. Ignoring Loss of Undecryptable Packets . . . . . . . . . 23 7.4. Ignoring Loss of Undecryptable Packets . . . . . . . . . 23
7.5. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 23 7.5. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 24
7.6. Persistent Congestion . . . . . . . . . . . . . . . . . . 23 7.6. Persistent Congestion . . . . . . . . . . . . . . . . . . 24
7.6.1. Duration . . . . . . . . . . . . . . . . . . . . . . 23 7.6.1. Duration . . . . . . . . . . . . . . . . . . . . . . 24
7.6.2. Establishing Persistent Congestion . . . . . . . . . 24 7.6.2. Establishing Persistent Congestion . . . . . . . . . 25
7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25 7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26
7.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.8. Under-utilizing the Congestion Window . . . . . . . . . . 27 7.8. Under-utilizing the Congestion Window . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8.1. Loss and Congestion Signals . . . . . . . . . . . . . . . 28 8.1. Loss and Congestion Signals . . . . . . . . . . . . . . . 28
8.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 28 8.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 28
8.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 28 8.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 30
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 31 Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 32
A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 32 A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 32
A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 32 A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 32
A.2. Constants of Interest . . . . . . . . . . . . . . . . . . 32 A.2. Constants of Interest . . . . . . . . . . . . . . . . . . 32
A.3. Variables of interest . . . . . . . . . . . . . . . . . . 33 A.3. Variables of interest . . . . . . . . . . . . . . . . . . 33
A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 34 A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 34
A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 34 A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 34
A.6. On Receiving a Datagram . . . . . . . . . . . . . . . . . 35 A.6. On Receiving a Datagram . . . . . . . . . . . . . . . . . 35
A.7. On Receiving an Acknowledgment . . . . . . . . . . . . . 35 A.7. On Receiving an Acknowledgment . . . . . . . . . . . . . 35
A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 36 A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 37
A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 38 A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 39
A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 39 A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 39
A.11. Upon Dropping Initial or Handshake Keys . . . . . . . . . 40 A.11. Upon Dropping Initial or Handshake Keys . . . . . . . . . 40
Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 41 Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 41
B.1. Constants of interest . . . . . . . . . . . . . . . . . . 41 B.1. Constants of interest . . . . . . . . . . . . . . . . . . 41
B.2. Variables of interest . . . . . . . . . . . . . . . . . . 41 B.2. Variables of interest . . . . . . . . . . . . . . . . . . 41
B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 42 B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 42
B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 42 B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 42
B.5. On Packet Acknowledgment . . . . . . . . . . . . . . . . 42 B.5. On Packet Acknowledgment . . . . . . . . . . . . . . . . 42
B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 43 B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 43
B.7. Process ECN Information . . . . . . . . . . . . . . . . . 44 B.7. Process ECN Information . . . . . . . . . . . . . . . . . 44
skipping to change at page 5, line 19 skipping to change at page 5, line 19
In-flight packets: Packets are considered in-flight when they are In-flight packets: Packets are considered in-flight when they are
ack-eliciting or contain a PADDING frame, and they have been sent ack-eliciting or contain a PADDING frame, and they have been sent
but are not acknowledged, declared lost, or discarded along with but are not acknowledged, declared lost, or discarded along with
old keys. old keys.
3. Design of the QUIC Transmission Machinery 3. Design of the QUIC Transmission Machinery
All transmissions in QUIC are sent with a packet-level header, which All transmissions in QUIC are sent with a packet-level header, which
indicates the encryption level and includes a packet sequence number indicates the encryption level and includes a packet sequence number
(referred to below as a packet number). The encryption level (referred to below as a packet number). The encryption level
indicates the packet number space, as described in Section 12.3 in indicates the packet number space, as described in Section 12.3 of
[QUIC-TRANSPORT]. Packet numbers never repeat within a packet number [QUIC-TRANSPORT]. Packet numbers never repeat within a packet number
space for the lifetime of a connection. Packet numbers are sent in space for the lifetime of a connection. Packet numbers are sent in
monotonically increasing order within a space, preventing ambiguity. monotonically increasing order within a space, preventing ambiguity.
It is permitted for some packet numbers to never be used, leaving It is permitted for some packet numbers to never be used, leaving
intentional gaps. intentional gaps.
This design obviates the need for disambiguating between This design obviates the need for disambiguating between
transmissions and retransmissions; this eliminates significant transmissions and retransmissions; this eliminates significant
complexity from QUIC's interpretation of TCP loss detection complexity from QUIC's interpretation of TCP loss detection
mechanisms. mechanisms.
skipping to change at page 11, line 46 skipping to change at page 11, line 46
smoothed_rtt and rttvar are initialized as follows, where kInitialRtt smoothed_rtt and rttvar are initialized as follows, where kInitialRtt
contains the initial RTT value: contains the initial RTT value:
smoothed_rtt = kInitialRtt smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2 rttvar = kInitialRtt / 2
RTT samples for the network path are recorded in latest_rtt; see RTT samples for the network path are recorded in latest_rtt; see
Section 5.1. On the first RTT sample after initialization, the Section 5.1. On the first RTT sample after initialization, the
estimator is reset using that sample. This ensures that the estimator is reset using that sample. This ensures that the
estimator retains no history of past samples. estimator retains no history of past samples. Packets sent on other
paths do not contribute RTT samples to the current path, as described
in Section 9.4 of [QUIC-TRANSPORT].
On the first RTT sample after initialization, smoothed_rtt and rttvar On the first RTT sample after initialization, smoothed_rtt and rttvar
are set as follows: are set as follows:
smoothed_rtt = latest_rtt smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2 rttvar = latest_rtt / 2
On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:
ack_delay = decoded acknowledgment delay from ACK frame ack_delay = decoded acknowledgment delay from ACK frame
if (handshake confirmed): if (handshake confirmed):
ack_delay = min(ack_delay, max_ack_delay) ack_delay = min(ack_delay, max_ack_delay)
adjusted_rtt = latest_rtt adjusted_rtt = latest_rtt
if (min_rtt + ack_delay < latest_rtt): if (min_rtt + ack_delay < latest_rtt):
adjusted_rtt = latest_rtt - ack_delay adjusted_rtt = latest_rtt - ack_delay
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
rttvar_sample = abs(smoothed_rtt - adjusted_rtt) rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
skipping to change at page 16, line 48 skipping to change at page 16, line 51
forward progress and the loss detection timer might have been set for forward progress and the loss detection timer might have been set for
a now discarded packet number space. a now discarded packet number space.
6.2.2.1. Before Address Validation 6.2.2.1. Before Address Validation
Until the server has validated the client's address on the path, the Until the server has validated the client's address on the path, the
amount of data it can send is limited to three times the amount of amount of data it can send is limited to three times the amount of
data received, as specified in Section 8.1 of [QUIC-TRANSPORT]. If data received, as specified in Section 8.1 of [QUIC-TRANSPORT]. If
no additional data can be sent, the server's PTO timer MUST NOT be no additional data can be sent, the server's PTO timer MUST NOT be
armed until datagrams have been received from the client, because armed until datagrams have been received from the client, because
packets sent on PTO count against the anti-amplification limit. Note packets sent on PTO count against the anti-amplification limit.
that the server could fail to validate the client's address even if
0-RTT is accepted. When the server receives a datagram from the client, the
amplification limit is increased and the server resets the PTO timer.
If the PTO timer is then set to a time in the past, it is executed
immediately. Doing so avoids sending new 1-RTT packets prior to
packets critical to the completion of the handshake. In particular,
this can happen when 0-RTT is accepted but the server fails to
validate the client's address.
Since the server could be blocked until more datagrams are received Since the server could be blocked until more datagrams are received
from the client, it is the client's responsibility to send packets to from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished unblock the server until it is certain that the server has finished
its address validation (see Section 8 of [QUIC-TRANSPORT]). That is, its address validation (see Section 8 of [QUIC-TRANSPORT]). That is,
the client MUST set the probe timer if the client has not received an the client MUST set the probe timer if the client has not received an
acknowledgment for any of its Handshake packets and the handshake is acknowledgment for any of its Handshake packets and the handshake is
not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no
packets in flight. When the PTO fires, the client MUST send a packets in flight. When the PTO fires, the client MUST send a
Handshake packet if it has Handshake keys, otherwise it MUST send an Handshake packet if it has Handshake keys, otherwise it MUST send an
skipping to change at page 20, line 18 skipping to change at page 20, line 28
document, the chosen controller MUST conform to the congestion document, the chosen controller MUST conform to the congestion
control guidelines specified in Section 3.1 of [RFC8085]. control guidelines specified in Section 3.1 of [RFC8085].
Similar to TCP, packets containing only ACK frames do not count Similar to TCP, packets containing only ACK frames do not count
towards bytes in flight and are not congestion controlled. Unlike towards bytes in flight and are not congestion controlled. Unlike
TCP, QUIC can detect the loss of these packets and MAY use that TCP, QUIC can detect the loss of these packets and MAY use that
information to adjust the congestion controller or the rate of ACK- information to adjust the congestion controller or the rate of ACK-
only packets being sent, but this document does not describe a only packets being sent, but this document does not describe a
mechanism for doing so. mechanism for doing so.
The congestion controller is per path, so packets sent on other paths
do not alter the current path's congestion controller, as described
in Section 9.4 of [QUIC-TRANSPORT].
The algorithm in this document specifies and uses the controller's The algorithm in this document specifies and uses the controller's
congestion window in bytes. congestion window in bytes.
An endpoint MUST NOT send a packet if it would cause bytes_in_flight An endpoint MUST NOT send a packet if it would cause bytes_in_flight
(see Appendix B.2) to be larger than the congestion window, unless (see Appendix B.2) to be larger than the congestion window, unless
the packet is sent on a PTO timer expiration (see Section 6.2) or the packet is sent on a PTO timer expiration (see Section 6.2) or
when entering recovery (see Section 7.3.2). when entering recovery (see Section 7.3.2).
7.1. Explicit Congestion Notification 7.1. Explicit Congestion Notification
skipping to change at page 29, line 21 skipping to change at page 29, line 28
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", draft-ietf-quic-tls-34 (work in progress), January QUIC", draft-ietf-quic-tls-latest (work in progress).
2021.
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-34 (work in progress), January 2021. transport-latest (work in progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 30, line 10 skipping to change at page 30, line 16
[FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement: [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement:
Refining TCP Congestion Control", ACM SIGCOMM , August Refining TCP Congestion Control", ACM SIGCOMM , August
1996. 1996.
[PRR] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional [PRR] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional
Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937, Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937,
May 2013, <https://www.rfc-editor.org/info/rfc6937>. May 2013, <https://www.rfc-editor.org/info/rfc6937>.
[RACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The [RACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
RACK-TLP loss detection algorithm for TCP", draft-ietf- RACK-TLP Loss Detection Algorithm for TCP", draft-ietf-
tcpm-rack-15 (work in progress), December 2020. tcpm-rack-15 (work in progress), December 2020.
[RETRANSMISSION] [RETRANSMISSION]
Karn, P. and C. Partridge, "Improving Round-Trip Time Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", ACM SIGCOMM Estimates in Reliable Transport Protocols", ACM SIGCOMM
CCR , January 1995. CCR , January 1995.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
skipping to change at page 35, line 19 skipping to change at page 35, line 34
successfully processed. In such a case, the PTO timer will need to successfully processed. In such a case, the PTO timer will need to
be re-armed. be re-armed.
Pseudocode for OnDatagramReceived follows: Pseudocode for OnDatagramReceived follows:
OnDatagramReceived(datagram): OnDatagramReceived(datagram):
// If this datagram unblocks the server, arm the // If this datagram unblocks the server, arm the
// PTO timer to avoid deadlock. // PTO timer to avoid deadlock.
if (server was at anti-amplification limit): if (server was at anti-amplification limit):
SetLossDetectionTimer() SetLossDetectionTimer()
if loss_detection_timer.timeout < now():
// Execute PTO if it would have expired
// while the amplification limit applied.
OnLossDetectionTimeout()
A.7. On Receiving an Acknowledgment A.7. On Receiving an Acknowledgment
When an ACK frame is received, it may newly acknowledge any number of When an ACK frame is received, it may newly acknowledge any number of
packets. packets.
Pseudocode for OnAckReceived and UpdateRtt follow: Pseudocode for OnAckReceived and UpdateRtt follow:
IncludesAckEliciting(packets): IncludesAckEliciting(packets):
for packet in packets: for packet in packets:
skipping to change at page 37, line 26 skipping to change at page 37, line 46
space = Initial space = Initial
for pn_space in [ Handshake, ApplicationData ]: for pn_space in [ Handshake, ApplicationData ]:
if (time == 0 || loss_time[pn_space] < time): if (time == 0 || loss_time[pn_space] < time):
time = loss_time[pn_space]; time = loss_time[pn_space];
space = pn_space space = pn_space
return time, space return time, space
GetPtoTimeAndSpace(): GetPtoTimeAndSpace():
duration = (smoothed_rtt + max(4 * rttvar, kGranularity)) duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
* (2 ^ pto_count) * (2 ^ pto_count)
// Arm PTO from now when there are no inflight packets. // Anti-deadlock PTO starts from the current time
if (no in-flight packets): if (no ack-eliciting packets in flight):
assert(!PeerCompletedAddressValidation()) assert(!PeerCompletedAddressValidation())
if (has handshake keys): if (has handshake keys):
return (now() + duration), Handshake return (now() + duration), Handshake
else: else:
return (now() + duration), Initial return (now() + duration), Initial
pto_timeout = infinite pto_timeout = infinite
pto_space = Initial pto_space = Initial
for space in [ Initial, Handshake, ApplicationData ]: for space in [ Initial, Handshake, ApplicationData ]:
if (no in-flight packets in space): if (no ack-eliciting packets in flight in space):
continue; continue;
if (space == ApplicationData): if (space == ApplicationData):
// Skip Application Data until handshake confirmed. // Skip Application Data until handshake confirmed.
if (handshake is not confirmed): if (handshake is not confirmed):
return pto_timeout, pto_space return pto_timeout, pto_space
// Include max_ack_delay and backoff for Application Data. // Include max_ack_delay and backoff for Application Data.
duration += max_ack_delay * (2 ^ pto_count) duration += max_ack_delay * (2 ^ pto_count)
t = time_of_last_ack_eliciting_packet[space] + duration t = time_of_last_ack_eliciting_packet[space] + duration
if (t < pto_timeout): if (t < pto_timeout):
skipping to change at page 39, line 15 skipping to change at page 39, line 23
OnLossDetectionTimeout(): OnLossDetectionTimeout():
earliest_loss_time, pn_space = GetLossTimeAndSpace() earliest_loss_time, pn_space = GetLossTimeAndSpace()
if (earliest_loss_time != 0): if (earliest_loss_time != 0):
// Time threshold loss Detection // Time threshold loss Detection
lost_packets = DetectAndRemoveLostPackets(pn_space) lost_packets = DetectAndRemoveLostPackets(pn_space)
assert(!lost_packets.empty()) assert(!lost_packets.empty())
OnPacketsLost(lost_packets) OnPacketsLost(lost_packets)
SetLossDetectionTimer() SetLossDetectionTimer()
return return
if (bytes_in_flight > 0): if (no ack-eliciting packets in flight):
// PTO. Send new data if available, else retransmit old data.
// If neither is available, send a single PING frame.
_, pn_space = GetPtoTimeAndSpace()
SendOneOrTwoAckElicitingPackets(pn_space)
else:
assert(!PeerCompletedAddressValidation()) assert(!PeerCompletedAddressValidation())
// Client sends an anti-deadlock packet: Initial is padded // Client sends an anti-deadlock packet: Initial is padded
// to earn more anti-amplification credit, // to earn more anti-amplification credit,
// a Handshake packet proves address ownership. // a Handshake packet proves address ownership.
if (has Handshake keys): if (has Handshake keys):
SendOneAckElicitingHandshakePacket() SendOneAckElicitingHandshakePacket()
else: else:
SendOneAckElicitingPaddedInitialPacket() SendOneAckElicitingPaddedInitialPacket()
else:
// PTO. Send new data if available, else retransmit old data.
// If neither is available, send a single PING frame.
_, pn_space = GetPtoTimeAndSpace()
SendOneOrTwoAckElicitingPackets(pn_space)
pto_count++ pto_count++
SetLossDetectionTimer() SetLossDetectionTimer()
A.10. Detecting Lost Packets A.10. Detecting Lost Packets
DetectAndRemoveLostPackets is called every time an ACK is received or DetectAndRemoveLostPackets is called every time an ACK is received or
the time threshold loss detection timer expires. This function the time threshold loss detection timer expires. This function
operates on the sent_packets for that packet number space and returns operates on the sent_packets for that packet number space and returns
a list of packets newly detected as lost. a list of packets newly detected as lost.
 End of changes. 26 change blocks. 
39 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/