Skip to content

Commit

Permalink
Script updating gh-pages from e60e0ea. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Dec 9, 2019
1 parent 50cd87a commit 554e686
Show file tree
Hide file tree
Showing 3 changed files with 1,857 additions and 1,856 deletions.
3 changes: 2 additions & 1 deletion draft-ietf-quic-recovery.html
View file
Expand Up @@ -1580,7 +1580,8 @@ <h4 id="name-packet-threshold">
</h4>
<p id="section-5.1.1-1">The RECOMMENDED initial value for the packet reordering threshold
(kPacketThreshold) is 3, based on best practices for TCP loss detection
<span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>.<a href="#section-5.1.1-1" class="pilcrow"></a></p>
<span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>. Implementations SHOULD NOT use a packet threshold
less than 3, to keep in line with TCP <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>.<a href="#section-5.1.1-1" class="pilcrow"></a></p>
<p id="section-5.1.1-2">Some networks may exhibit higher degrees of reordering, causing a sender to
detect spurious losses. Implementers MAY use algorithms developed for TCP, such
as TCP-NCR <span>[<a href="#RFC4653" class="xref">RFC4653</a>]</span>, to improve QUIC's reordering resilience.<a href="#section-5.1.1-2" class="pilcrow"></a></p>
Expand Down
96 changes: 48 additions & 48 deletions draft-ietf-quic-recovery.txt
View file
Expand Up @@ -86,10 +86,10 @@ Table of Contents
5. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Acknowledgement-based Detection . . . . . . . . . . . . . 10
5.1.1. Packet Threshold . . . . . . . . . . . . . . . . . . 10
5.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 10
5.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 11
5.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 11
5.3. Handshakes and New Paths . . . . . . . . . . . . . . . . 12
5.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 12
5.3. Handshakes and New Paths . . . . . . . . . . . . . . . . 13
5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 13
5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 14
5.4. Handling Retry Packets . . . . . . . . . . . . . . . . . 15
Expand Down Expand Up @@ -540,20 +540,20 @@ Internet-Draft QUIC Loss Detection December 2019

The RECOMMENDED initial value for the packet reordering threshold
(kPacketThreshold) is 3, based on best practices for TCP loss
detection [RFC5681] [RFC6675].
detection [RFC5681] [RFC6675]. Implementations SHOULD NOT use a
packet threshold less than 3, to keep in line with TCP [RFC5681].

Some networks may exhibit higher degrees of reordering, causing a
sender to detect spurious losses. Implementers MAY use algorithms
developed for TCP, such as TCP-NCR [RFC4653], to improve QUIC's
reordering resilience.

5.1.2. Time Threshold

Once a later packet within the same packet number space has been
acknowledged, an endpoint SHOULD declare an earlier packet lost if it
was sent a threshold amount of time in the past. To avoid declaring
packets as lost too early, this time threshold MUST be set to at
least kGranularity. The time threshold is:








Expand All @@ -562,6 +562,14 @@ Iyengar & Swett Expires 11 June 2020 [Page 10]
Internet-Draft QUIC Loss Detection December 2019


5.1.2. Time Threshold

Once a later packet within the same packet number space has been
acknowledged, an endpoint SHOULD declare an earlier packet lost if it
was sent a threshold amount of time in the past. To avoid declaring
packets as lost too early, this time threshold MUST be set to at
least kGranularity. The time threshold is:

max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)

If packets sent prior to the largest acknowledged packet cannot yet
Expand Down Expand Up @@ -601,6 +609,15 @@ Internet-Draft QUIC Loss Detection December 2019
TCP [RFC5682]. The timeout computation is based on TCP's
retransmission timeout period [RFC6298].





Iyengar & Swett Expires 11 June 2020 [Page 11]

Internet-Draft QUIC Loss Detection December 2019


5.2.1. Computing PTO

When an ack-eliciting packet is transmitted, the sender schedules a
Expand All @@ -611,13 +628,6 @@ Internet-Draft QUIC Loss Detection December 2019
kGranularity, smoothed_rtt, rttvar, and max_ack_delay are defined in
Appendix A.2 and Appendix A.3.



Iyengar & Swett Expires 11 June 2020 [Page 11]

Internet-Draft QUIC Loss Detection December 2019


The PTO period is the amount of time that a sender ought to wait for
an acknowledgement of a sent packet. This time period includes the
estimated network roundtrip-time (smoothed_rtt), the variance in the
Expand Down Expand Up @@ -657,6 +667,13 @@ Internet-Draft QUIC Loss Detection December 2019
expected to both expire earlier than the PTO and be less likely to
spuriously retransmit data.



Iyengar & Swett Expires 11 June 2020 [Page 12]

Internet-Draft QUIC Loss Detection December 2019


5.3. Handshakes and New Paths

The initial probe timeout for a new connection or new path SHOULD be
Expand All @@ -666,14 +683,6 @@ Internet-Draft QUIC Loss Detection December 2019
available, the initial RTT SHOULD be set to 500ms, resulting in a 1
second initial timeout as recommended in [RFC6298].




Iyengar & Swett Expires 11 June 2020 [Page 12]

Internet-Draft QUIC Loss Detection December 2019


A connection MAY use the delay between sending a PATH_CHALLENGE and
receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in
Appendix A.2) for a new path, but the delay SHOULD NOT be considered
Expand Down Expand Up @@ -713,15 +722,6 @@ Internet-Draft QUIC Loss Detection December 2019
expensive consecutive PTO expiration due to a single lost datagram or
transmit data from multiple packet number spaces.

In addition to sending data in the packet number space for which the
timer expired, the sender SHOULD send ack-eliciting packets from
other packet number spaces with in-flight data, coalescing packets if
possible.

When the PTO timer expires, and there is new or previously sent
unacknowledged data, it MUST be sent.





Expand All @@ -730,6 +730,14 @@ Iyengar & Swett Expires 11 June 2020 [Page 13]
Internet-Draft QUIC Loss Detection December 2019


In addition to sending data in the packet number space for which the
timer expired, the sender SHOULD send ack-eliciting packets from
other packet number spaces with in-flight data, coalescing packets if
possible.

When the PTO timer expires, and there is new or previously sent
unacknowledged data, it MUST be sent.

It is possible the sender has no new or previously-sent data to send.
As an example, consider the following sequence of events: new
application data is sent in a STREAM frame, deemed lost, then
Expand Down Expand Up @@ -771,21 +779,19 @@ Internet-Draft QUIC Loss Detection December 2019
Delivery or loss of packets in flight is established when an ACK
frame is received that newly acknowledges one or more packets.

A PTO timer expiration event does not indicate packet loss and MUST
NOT cause prior unacknowledged packets to be marked as lost. When an
acknowledgement is received that newly acknowledges packets, loss
detection proceeds as dictated by packet and time threshold
mechanisms; see Section 5.1.





Iyengar & Swett Expires 11 June 2020 [Page 14]

Internet-Draft QUIC Loss Detection December 2019


A PTO timer expiration event does not indicate packet loss and MUST
NOT cause prior unacknowledged packets to be marked as lost. When an
acknowledgement is received that newly acknowledges packets, loss
detection proceeds as dictated by packet and time threshold
mechanisms; see Section 5.1.

5.4. Handling Retry Packets

A Retry packet causes a client to send another Initial packet,
Expand Down Expand Up @@ -831,12 +837,6 @@ Internet-Draft QUIC Loss Detection December 2019









Iyengar & Swett Expires 11 June 2020 [Page 15]

Internet-Draft QUIC Loss Detection December 2019
Expand Down

0 comments on commit 554e686

Please sign in to comment.