Merge remote-tracking branch 'origin/master' into transport/packet-types

draft-ietf-quic-http.md

@@ -159,9 +159,9 @@ the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame
 ({{!ALTSVC=RFC7838}}), using the ALPN token defined in
 {{connection-establishment}}.
 
-For example, an origin could indicate in an HTTP/1.1 or HTTP/2 response that
-HTTP/3 was available on UDP port 50781 at the same hostname by including the
-following header field in any response:
+For example, an origin could indicate in an HTTP response that HTTP/3 was
+available on UDP port 50781 at the same hostname by including the following
+header field:
 
 ~~~ example
 Alt-Svc: h3=":50781"
@@ -225,7 +225,7 @@ some other mechanism.
 
 QUIC connections are established as described in {{QUIC-TRANSPORT}}. During
 connection establishment, HTTP/3 support is indicated by selecting the ALPN
-token "hq" in the TLS handshake.  Support for other application-layer protocols
+token "h3" in the TLS handshake.  Support for other application-layer protocols
 MAY be offered in the same handshake.
 
 While connection-level options pertaining to the core QUIC protocol are set in
@@ -573,8 +573,8 @@ HTTP_UNEXPECTED_FRAME.
 ### CANCEL_PUSH {#frame-cancel-push}
 
 The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a server
-push prior to the push stream being created.  The CANCEL_PUSH frame identifies a
-server push by Push ID (see {{frame-push-promise}}), encoded as a
+push prior to the push stream being received.  The CANCEL_PUSH frame identifies
+a server push by Push ID (see {{frame-push-promise}}), encoded as a
 variable-length integer.
 
 When a server receives this frame, it aborts sending the response for the

draft-ietf-quic-recovery.md

@@ -362,10 +362,10 @@ Using max(SRTT, latest_RTT) protects from the two following cases:
 * the latest RTT sample is higher than the SRTT, perhaps due to a sustained
   increase in the actual RTT, but the smoothed SRTT has not yet caught up.
 
-Implementers MAY experiment with using other reordering thresholds, including
-absolute thresholds, bearing in mind that a lower multiplier reduces reordering
-resilience and increases spurious retransmissions, and a higher multiplier
-increases loss detection delay.
+Implementations MAY experiment with absolute thresholds, thresholds from
+previous connections, adaptive thresholds, or including RTT variance.  Smaller
+thresholds reduce reordering resilience and increase spurious retransmissions,
+and larger thresholds increase loss detection delay.
 
 
 ## Timeout Loss Detection
@@ -496,6 +496,13 @@ MAY use alternate strategies for determining the content of probe packets,
 including sending new or retransmitted data based on the application's
 priorities.
 
+When a PTO timer expires, new or previously-sent data may not be available to
+send and packets may still be in flight.  A sender can be blocked from sending
+new data in the future if packets are left in flight.  Under these conditions, a
+sender SHOULD mark any packets still in flight as lost.  If a sender wishes to
+establish delivery of packets still in flight, it MAY send an ack-eliciting
+packet and re-arm the PTO timer instead.
+
 
 #### Loss Detection {#pto-loss}
 
@@ -671,10 +678,11 @@ Pseudocode for OnPacketSent follows:
    sent_packets[packet_number].time_sent = now
    sent_packets[packet_number].ack_eliciting = ack_eliciting
    sent_packets[packet_number].in_flight = in_flight
-   if (ack_eliciting):
+   if (in_flight):
      if (is_crypto_packet):
        time_of_last_sent_crypto_packet = now
-     time_of_last_sent_ack_eliciting_packet = now
+     if (ack_eliciting):
+       time_of_last_sent_ack_eliciting_packet = now
      OnPacketSentCC(sent_bytes)
      sent_packets[packet_number].size = sent_bytes
      SetLossDetectionTimer()
@@ -711,10 +719,11 @@ Pseudocode for OnAckReceived and UpdateRtt follow:
     for acked_packet in newly_acked_packets:
       OnPacketAcked(acked_packet.packet_number)
 
+    DetectLostPackets()
+
     crypto_count = 0
     pto_count = 0
 
-    DetectLostPackets()
     SetLossDetectionTimer()
 
 
@@ -946,10 +955,15 @@ packets might cause the sender's bytes in flight to exceed the congestion window
 until an acknowledgement is received that establishes loss or delivery of
 packets.
 
-If a threshold number of consecutive PTOs have occurred (pto_count is more than
+When an ACK frame is received that establishes loss of all in-flight packets
+sent prior to a threshold number of consecutive PTOs (pto_count is more than
 kPersistentCongestionThreshold, see {{cc-consts-of-interest}}), the network is
 considered to be experiencing persistent congestion, and the sender's congestion
-window MUST be reduced to the minimum congestion window.
+window MUST be reduced to the minimum congestion window (kMinimumWindow).  This
+response of collapsing the congestion window on persistent congestion is
+functionally similar to a sender's response on a Retransmission Timeout (RTO) in
+TCP {{RFC5681}}.
+
 
 ## Pacing
 
@@ -975,7 +989,7 @@ in Linux (3.11 onwards).
 ## Sending data after an idle period
 
 A sender becomes idle if it ceases to send data and has no bytes in flight.  A
-sender's congestion window MUST not increase while it is idle.
+sender's congestion window MUST NOT increase while it is idle.
 
 When sending data after becoming idle, a sender MUST reset its congestion window
 to the initial congestion window (see Section 4.1 of {{?RFC5681}}), unless it
@@ -1021,15 +1035,13 @@ kLossReductionFactor:
   The RECOMMENDED value is 0.5.
 
 kPersistentCongestionThreshold:
-: Number of consecutive PTOs after which network is considered to be
-  experiencing persistent congestion.  The rationale for this threshold is to
-  enable a sender to use initial PTOs for aggressive probing, similar to Tail
-  Loss Probe (TLP) in TCP {{TLP}} {{RACK}}.  Once the number of consecutive PTOs
-  reaches this threshold - that is, persistent congestion is established - the
-  sender responds by collapsing its congestion window to kMinimumWindow, similar
-  to a Retransmission Timeout (RTO) in TCP {{RFC5681}}.  The RECOMMENDED value
-  for kPersistentCongestionThreshold is 2, which is equivalent to having two
-  TLPs before an RTO in TCP.
+: Number of consecutive PTOs required for persistent congestion to be
+  established.  The rationale for this threshold is to enable a sender to use
+  initial PTOs for aggressive probing, as TCP does with Tail Loss Probe (TLP)
+  {{TLP}} {{RACK}}, before establishing persistent congestion, as TCP does with
+  a Retransmission Timeout (RTO) {{?RFC5681}}.  The RECOMMENDED value for
+  kPersistentCongestionThreshold is 2, which is equivalent to having two TLPs
+  before an RTO in TCP.
 
 ### Variables of interest {#vars-of-interest}