draft-ietf-quic-recovery-04.txt   draft-ietf-quic-recovery-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft I. Swett, Ed. Internet-Draft I. Swett, Ed.
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: December 15, 2017 June 13, 2017 Expires: January 21, 2018 July 20, 2017
QUIC Loss Detection and Congestion Control QUIC Loss Detection and Congestion Control
draft-ietf-quic-recovery-04 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), which is archived at mailing list (quic@ietf.org), which is archived at
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 15, 2017. This Internet-Draft will expire on January 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 27 skipping to change at page 2, line 27
2.1. Relevant Differences Between QUIC and TCP . . . . . . . . 4 2.1. Relevant Differences Between QUIC and TCP . . . . . . . . 4
2.1.1. Monotonically Increasing Packet Numbers . . . . . . . 4 2.1.1. Monotonically Increasing Packet Numbers . . . . . . . 4
2.1.2. No Reneging . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. No Reneging . . . . . . . . . . . . . . . . . . . . . 4
2.1.3. More ACK Ranges . . . . . . . . . . . . . . . . . . . 5 2.1.3. More ACK Ranges . . . . . . . . . . . . . . . . . . . 5
2.1.4. Explicit Correction For Delayed Acks . . . . . . . . 5 2.1.4. Explicit Correction For Delayed Acks . . . . . . . . 5
3. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 5 3. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Algorithm Details . . . . . . . . . . . . . . . . . . . . 6 3.2. Algorithm Details . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Constants of interest . . . . . . . . . . . . . . . . 6 3.2.1. Constants of interest . . . . . . . . . . . . . . . . 6
3.2.2. Variables of interest . . . . . . . . . . . . . . . . 6 3.2.2. Variables of interest . . . . . . . . . . . . . . . . 6
3.2.3. Initialization . . . . . . . . . . . . . . . . . . . 7 3.2.3. Initialization . . . . . . . . . . . . . . . . . . . 8
3.2.4. On Sending a Packet . . . . . . . . . . . . . . . . . 8 3.2.4. On Sending a Packet . . . . . . . . . . . . . . . . . 8
3.2.5. On Ack Receipt . . . . . . . . . . . . . . . . . . . 8 3.2.5. On Ack Receipt . . . . . . . . . . . . . . . . . . . 9
3.2.6. On Packet Acknowledgment . . . . . . . . . . . . . . 9 3.2.6. On Packet Acknowledgment . . . . . . . . . . . . . . 9
3.2.7. Setting the Loss Detection Alarm . . . . . . . . . . 10 3.2.7. Setting the Loss Detection Alarm . . . . . . . . . . 10
3.2.8. On Alarm Firing . . . . . . . . . . . . . . . . . . . 12 3.2.8. On Alarm Firing . . . . . . . . . . . . . . . . . . . 12
3.2.9. Detecting Lost Packets . . . . . . . . . . . . . . . 12 3.2.9. Detecting Lost Packets . . . . . . . . . . . . . . . 13
3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14
4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 14 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 14
4.1. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Constants of interest . . . . . . . . . . . . . . . . . . 14 4.3. Constants of interest . . . . . . . . . . . . . . . . . . 15
4.4. Variables of interest . . . . . . . . . . . . . . . . . . 14 4.4. Variables of interest . . . . . . . . . . . . . . . . . . 15
4.5. Initialization . . . . . . . . . . . . . . . . . . . . . 15 4.5. Initialization . . . . . . . . . . . . . . . . . . . . . 16
4.6. On Packet Acknowledgement . . . . . . . . . . . . . . . . 15 4.6. On Packet Acknowledgement . . . . . . . . . . . . . . . . 16
4.7. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 15 4.7. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 16
4.8. On Retransmission Timeout Verified . . . . . . . . . . . 16 4.8. On Retransmission Timeout Verified . . . . . . . . . . . 17
4.9. Pacing Packets . . . . . . . . . . . . . . . . . . . . . 16 4.9. Pacing Packets . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
B.1. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 17 B.1. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 18
B.2. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 18 B.2. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 19
B.3. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 18 B.3. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 19
B.4. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 18 B.4. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
QUIC is a new multiplexed and secure transport atop UDP. QUIC builds QUIC is a new multiplexed and secure transport atop UDP. QUIC builds
on decades of transport and security experience, and implements on decades of transport and security experience, and implements
mechanisms that make it attractive as a modern general-purpose mechanisms that make it attractive as a modern general-purpose
transport. The QUIC protocol is described in [QUIC-TRANSPORT]. transport. The QUIC protocol is described in [QUIC-TRANSPORT].
QUIC implements the spirit of known TCP loss recovery mechanisms, QUIC implements the spirit of known TCP loss recovery mechanisms,
described in RFCs, various Internet-drafts, and also those prevalent described in RFCs, various Internet-drafts, and also those prevalent
skipping to change at page 7, line 19 skipping to change at page 7, line 19
without receiving an ack. without receiving an ack.
rto_count: The number of times an rto has been sent without rto_count: The number of times an rto has been sent without
receiving an ack. receiving an ack.
largest_sent_before_rto: The last packet number sent prior to the largest_sent_before_rto: The last packet number sent prior to the
first retransmission timeout. first retransmission timeout.
time_of_last_sent_packet: The time the most recent packet was sent. time_of_last_sent_packet: The time the most recent packet was sent.
largest_sent_packet: The packet number of the most recently sent
packet.
largest_acked_packet: The largest packet number acknowledged in an
ack frame.
latest_rtt: The most recent RTT measurement made when receiving an latest_rtt: The most recent RTT measurement made when receiving an
ack for a previously unacked packet. ack for a previously unacked packet.
smoothed_rtt: The smoothed RTT of the connection, computed as smoothed_rtt: The smoothed RTT of the connection, computed as
described in [RFC6298] described in [RFC6298]
rttvar: The RTT variance, computed as described in [RFC6298] rttvar: The RTT variance, computed as described in [RFC6298]
reordering_threshold: The largest delta between the largest acked reordering_threshold: The largest delta between the largest acked
retransmittable packet and a packet containing retransmittable retransmittable packet and a packet containing retransmittable
skipping to change at page 8, line 20 skipping to change at page 8, line 25
reordering_threshold = infinite reordering_threshold = infinite
time_reordering_fraction = kTimeReorderingFraction time_reordering_fraction = kTimeReorderingFraction
else: else:
reordering_threshold = kReorderingThreshold reordering_threshold = kReorderingThreshold
time_reordering_fraction = infinite time_reordering_fraction = infinite
loss_time = 0 loss_time = 0
smoothed_rtt = 0 smoothed_rtt = 0
rttvar = 0 rttvar = 0
largest_sent_before_rto = 0 largest_sent_before_rto = 0
time_of_last_sent_packet = 0 time_of_last_sent_packet = 0
largest_sent_packet = 0
3.2.4. On Sending a Packet 3.2.4. On Sending a Packet
After any packet is sent, be it a new transmission or a rebundled After any packet is sent, be it a new transmission or a rebundled
transmission, the following OnPacketSent function is called. The transmission, the following OnPacketSent function is called. The
parameters to OnPacketSent are as follows: parameters to OnPacketSent are as follows:
o packet_number: The packet number of the sent packet. o packet_number: The packet number of the sent packet.
o is_retransmittable: A boolean that indicates whether the packet o is_retransmittable: A boolean that indicates whether the packet
skipping to change at page 8, line 41 skipping to change at page 9, line 6
retransmittability of various QUIC frames is described in retransmittability of various QUIC frames is described in
[QUIC-TRANSPORT]. If false, it is still acceptable for an ack to [QUIC-TRANSPORT]. If false, it is still acceptable for an ack to
be received for this packet. However, a caller MUST NOT set be received for this packet. However, a caller MUST NOT set
is_retransmittable to true if an ack is not expected. is_retransmittable to true if an ack is not expected.
o sent_bytes: The number of bytes sent in the packet. o sent_bytes: The number of bytes sent in the packet.
Pseudocode for OnPacketSent follows: Pseudocode for OnPacketSent follows:
OnPacketSent(packet_number, is_retransmittable, sent_bytes): OnPacketSent(packet_number, is_retransmittable, sent_bytes):
time_of_last_sent_packet = now; time_of_last_sent_packet = now
largest_sent_packet = packet_number
sent_packets[packet_number].packet_number = packet_number sent_packets[packet_number].packet_number = packet_number
sent_packets[packet_number].time = now sent_packets[packet_number].time = now
if is_retransmittable: if is_retransmittable:
sent_packets[packet_number].bytes = sent_bytes sent_packets[packet_number].bytes = sent_bytes
SetLossDetectionAlarm() SetLossDetectionAlarm()
3.2.5. On Ack Receipt 3.2.5. On Ack Receipt
When an ack is received, it may acknowledge 0 or more packets. When an ack is received, it may acknowledge 0 or more packets.
Pseudocode for OnAckReceived and UpdateRtt follow: Pseudocode for OnAckReceived and UpdateRtt follow:
OnAckReceived(ack): OnAckReceived(ack):
largest_acked_packet = ack.largest_acked
// If the largest acked is newly acked, update the RTT. // If the largest acked is newly acked, update the RTT.
if (sent_packets[ack.largest_acked]): if (sent_packets[ack.largest_acked]):
latest_rtt = now - sent_packets[ack.largest_acked].time latest_rtt = now - sent_packets[ack.largest_acked].time
if (latest_rtt > ack.ack_delay): if (latest_rtt > ack.ack_delay):
latest_rtt -= ack.delay latest_rtt -= ack.delay
UpdateRtt(latest_rtt) UpdateRtt(latest_rtt)
// Find all newly acked packets. // Find all newly acked packets.
for acked_packet in DetermineNewlyAckedPackets(): for acked_packet in DetermineNewlyAckedPackets():
OnPacketAcked(acked_packet.packet_number) OnPacketAcked(acked_packet.packet_number)
skipping to change at page 10, line 6 skipping to change at page 10, line 17
numbers that are detected as lost. numbers that are detected as lost.
If this is the first acknowledgement following RTO, check if the If this is the first acknowledgement following RTO, check if the
smallest newly acknowledged packet is one sent by the RTO, and if so, smallest newly acknowledged packet is one sent by the RTO, and if so,
inform congestion control of a verified RTO, similar to F-RTO inform congestion control of a verified RTO, similar to F-RTO
[RFC5682] [RFC5682]
Pseudocode for OnPacketAcked follows: Pseudocode for OnPacketAcked follows:
OnPacketAcked(acked_packet_number): OnPacketAcked(acked_packet_number):
OnPacketAckedCC(acked_packet_number)
// If a packet sent prior to RTO was acked, then the RTO // If a packet sent prior to RTO was acked, then the RTO
// was spurious. Otherwise, inform congestion control. // was spurious. Otherwise, inform congestion control.
if (rto_count > 0 && if (rto_count > 0 &&
acked_packet_number > largest_sent_before_rto) acked_packet_number > largest_sent_before_rto)
OnRetransmissionTimeoutVerified() OnRetransmissionTimeoutVerified()
handshake_count = 0 handshake_count = 0
tlp_count = 0 tlp_count = 0
rto_count = 0 rto_count = 0
sent_packets.remove(acked_packet_number) sent_packets.remove(acked_packet_number)
skipping to change at page 10, line 29 skipping to change at page 10, line 41
detection. The duration of the alarm is based on the alarm's mode, detection. The duration of the alarm is based on the alarm's mode,
which is set in the packet and timer events further below. The which is set in the packet and timer events further below. The
function SetLossDetectionAlarm defined below shows how the single function SetLossDetectionAlarm defined below shows how the single
timer is set based on the alarm mode. timer is set based on the alarm mode.
3.2.7.1. Handshake Packets 3.2.7.1. Handshake Packets
The initial flight has no prior RTT sample. A client SHOULD remember The initial flight has no prior RTT sample. A client SHOULD remember
the previous RTT it observed when resumption is attempted and use the previous RTT it observed when resumption is attempted and use
that for an initial RTT value. If no previous RTT is available, the that for an initial RTT value. If no previous RTT is available, the
initial RTT defaults to 200ms. initial RTT defaults to 100ms.
Endpoints MUST retransmit handshake frames if not acknowledged within Endpoints MUST retransmit handshake frames if not acknowledged within
a time limit. This time limit will start as the largest of twice the a time limit. This time limit will start as the largest of twice the
rtt value and MinTLPTimeout. Each consecutive handshake RTT value and MinTLPTimeout. Each consecutive handshake
retransmission doubles the time limit, until an acknowledgement is retransmission doubles the time limit, until an acknowledgement is
received. received.
Handshake frames may be cancelled by handshake state transitions. In Handshake frames may be cancelled by handshake state transitions. In
particular, all non-protected frames SHOULD be no longer be particular, all non-protected frames SHOULD be no longer be
transmitted once packet protection is available. transmitted once packet protection is available.
When stateless rejects are in use, the connection is considered When stateless rejects are in use, the connection is considered
immediately closed once a reject is sent, so no timer is set to immediately closed once a reject is sent, so no timer is set to
retransmit the reject. retransmit the reject.
Version negotiation packets are always stateless, and MUST be sent Version negotiation packets are always stateless, and MUST be sent
once per per handshake packet that uses an unsupported QUIC version, once per handshake packet that uses an unsupported QUIC version, and
and MAY be sent in response to 0RTT packets. MAY be sent in response to 0RTT packets.
3.2.7.2. Tail Loss Probe and Retransmission Timeout 3.2.7.2. Tail Loss Probe and Retransmission Timeout
Tail loss probes [LOSS-PROBE] and retransmission timeouts [RFC6298] Tail loss probes [LOSS-PROBE] and retransmission timeouts [RFC6298]
are an alarm based mechanism to recover from cases when there are are an alarm based mechanism to recover from cases when there are
outstanding retransmittable packets, but an acknowledgement has not outstanding retransmittable packets, but an acknowledgement has not
been received in a timely manner. been received in a timely manner.
3.2.7.3. Early Retransmit 3.2.7.3. Early Retransmit
skipping to change at page 14, line 47 skipping to change at page 15, line 42
kLossReductionFactor (default 0.5): Reduction in congestion window kLossReductionFactor (default 0.5): Reduction in congestion window
when a new loss event is detected. when a new loss event is detected.
4.4. Variables of interest 4.4. Variables of interest
Variables required to implement the congestion control mechanisms are Variables required to implement the congestion control mechanisms are
described in this section. described in this section.
bytes_in_flight: The sum of the size in bytes of all sent packets bytes_in_flight: The sum of the size in bytes of all sent packets
that contain at least one retransmittable frame, and have not been that contain at least one retransmittable or PADDING frame, and
acked or declared lost. have not been acked or declared lost. The size does not include
IP or UDP overhead. Ack only frames do not count towards
byte_in_flight.
congestion_window: Maximum number of bytes in flight that may be congestion_window: Maximum number of bytes in flight that may be
sent. sent.
end_of_recovery: The packet number after which QUIC will no longer end_of_recovery: The packet number after which QUIC will no longer
be in recovery. be in recovery.
ssthresh Slow start threshold in bytes. When the congestion window ssthresh Slow start threshold in bytes. When the congestion window
is below ssthresh, it grows by the number of bytes acknowledged is below ssthresh, it grows by the number of bytes acknowledged
for each ack. for each ack.
skipping to change at page 15, line 24 skipping to change at page 16, line 21
At the beginning of the connection, initialize the loss detection At the beginning of the connection, initialize the loss detection
variables as follows: variables as follows:
congestion_window = kInitialWindow congestion_window = kInitialWindow
bytes_in_flight = 0 bytes_in_flight = 0
end_of_recovery = 0 end_of_recovery = 0
ssthresh = infinite ssthresh = infinite
4.6. On Packet Acknowledgement 4.6. On Packet Acknowledgement
Invoked at the same time loss detection's OnPacketAcked is called and Invoked from loss detection's OnPacketAcked and is supplied with
supplied with the acked_packet from sent_packets. acked_packet from sent_packets.
Pseudocode for OnPacketAcked follows: Pseudocode for OnPacketAckedCC follows:
OnPacketAcked(acked_packet): OnPacketAckedCC(acked_packet):
if (acked_packet.packet_number < end_of_recovery): if (acked_packet.packet_number < end_of_recovery):
return return
if (congestion_window < ssthresh): if (congestion_window < ssthresh):
congestion_window += acket_packets.bytes congestion_window += acket_packets.bytes
else: else:
congestion_window += congestion_window +=
acked_packets.bytes / congestion_window acked_packets.bytes / congestion_window
4.7. On Packets Lost 4.7. On Packets Lost
 End of changes. 19 change blocks. 
38 lines changed or deleted 50 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/