Merge remote-tracking branch 'origin/master' into request_rst

Makefile

@@ -20,7 +20,8 @@ latest::
 	    echo "$$f contains a line with >80 characters"; err=1; \
 	  fi; \
 	  if cat "$$f" | (l=0; while read -r a; do l=$$(($$l + 1)); echo -E "$$l:$$a"; done) | \
-	     sed -e '/^[0-9]*:~~~/,/^[0-9]*:~~~/p;d' | tr -d '\r' | grep '^[0-9]*:.\{70\}'; then \
+	     sed -e '/^[0-9]*:~~~/,/^[0-9]*:~~~/p;/^[0-9]*:```/,/^[0-9]*:```/p;d' | \
+	     tr -d '\r' | grep '^[0-9]*:.\{70\}'; then \
 	    echo "$$f contains a figure with >69 characters"; err=1; \
 	  fi; \
 	done; [ "$$err" -eq 0 ]

draft-ietf-quic-http.md

@@ -90,11 +90,11 @@ via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC frame ({{!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/QUIC was available on UDP port 443 at the same hostname by including the
+HTTP/QUIC was available on UDP port 50781 at the same hostname by including the
 following header in any response:
 
 ~~~ example
-Alt-Svc: hq=":443"
+Alt-Svc: hq=":50781"
 ~~~
 
 On receipt of an Alt-Svc header indicating HTTP/QUIC support, a client MAY
@@ -105,6 +105,10 @@ Connectivity problems (e.g. firewall blocking UDP) can result in QUIC connection
 establishment failure, in which case the client SHOULD continue using the
 existing connection or try another alternative endpoint offered by the origin.
 
+Servers MAY serve HTTP/QUIC on any UDP port.  Servers MUST use the same port
+across all IP addresses that serve a single domain, and SHOULD NOT change this
+port.
+
 ## QUIC Version Hints {#alt-svc-version-hint}
 
 This document defines the "quic" parameter for Alt-Svc, which MAY be used to
@@ -122,7 +126,7 @@ Alt-Svc entry.  For example, if a server supported both version 0x00000001 and
 the version rendered in ASCII as "Q034", it could specify the following header:
 
 ~~~ example
-Alt-Svc: hq=":443";quic=1;quic=51303334
+Alt-Svc: hq=":49288";quic=1;quic=51303334
 ~~~
 
 Where multiple versions are listed, the order of the values reflects the
@@ -141,7 +145,7 @@ While connection-level options pertaining to the core QUIC protocol are set in
 the initial crypto handshake, HTTP-specific settings are conveyed
 in the SETTINGS frame. After the QUIC connection is established, a SETTINGS
 frame ({{frame-settings}}) MUST be sent as the initial frame of the HTTP control
-stream (Stream ID 3, see {{stream-mapping}}).  The server MUST NOT send data on
+stream (Stream ID 1, see {{stream-mapping}}).  The server MUST NOT send data on
 any other stream until the client's SETTINGS frame has been received.
 
 ## Draft Version Identification
@@ -175,17 +179,17 @@ the HTTP framing layer. A QUIC receiver buffers and orders received STREAM
 frames, exposing the data contained within as a reliable byte stream to the
 application.
 
-QUIC reserves Stream 1 for crypto operations (the handshake, crypto config
-updates). Stream 3 is reserved for sending and receiving HTTP control frames,
+QUIC reserves Stream 0 for crypto operations (the handshake, crypto config
+updates). Stream 1 is reserved for sending and receiving HTTP control frames,
 and is analogous to HTTP/2's Stream 0.  This connection control stream is
 considered critical to the HTTP connection.  If the connection control stream is
 closed for any reason, this MUST be treated as a connection error of type
 QUIC_CLOSED_CRITICAL_STREAM.
 
 When HTTP headers and data are sent over QUIC, the QUIC layer handles most of
 the stream management. An HTTP request/response consumes a pair of streams: This
-means that the client's first request occurs on QUIC streams 5 and 7, the second
-on stream 9 and 11, and so on. The server's first push consumes streams 2 and 4.
+means that the client's first request occurs on QUIC streams 3 and 5, the second
+on stream 7 and 9, and so on. The server's first push consumes streams 2 and 4.
 This amounts to the second least-significant bit differentiating the two streams
 in a request.
 
@@ -222,10 +226,10 @@ responses are considered complete when the corresponding QUIC streams are closed
 in the appropriate direction.
 
 
-##  Stream 3: Connection Control Stream
+##  Stream 1: Connection Control Stream
 
 Since most connection-level concerns will be managed by QUIC, the primary use of
-Stream 3 will be for the SETTINGS frame when the connection opens and for
+Stream 1 will be for the SETTINGS frame when the connection opens and for
 PRIORITY frames subsequently.
 
 ## HTTP Message Exchanges
@@ -379,7 +383,7 @@ receipt.
 
 # HTTP Framing Layer
 
-Frames are used only on the connection (stream 3) and message (streams 5, 9,
+Frames are used only on the connection (stream 1) and message (streams 3, 7,
 etc.) control streams. Other streams carry data payload and are not framed at
 the HTTP layer.
 
@@ -755,7 +759,7 @@ PRIORITY frames are sent on the connection control stream and the PRIORITY
 section is removed from the HEADERS frame.
 
 Other than this issue, frame type HTTP/2 extensions are typically portable to
-QUIC simply by replacing Stream 0 in HTTP/2 with Stream 3 in HTTP/QUIC.
+QUIC simply by replacing Stream 0 in HTTP/2 with Stream 1 in HTTP/QUIC.
 
 Below is a listing of how each HTTP/2 frame type is mapped:
 
@@ -1074,47 +1078,42 @@ The original authors of this specification were Robbie Shade and Mike Warres.
 > **RFC Editor's Note:**  Please remove this section prior to publication of a
 > final version of this document.
 
-## Since draft-ietf-quic-http-01:
+## Since draft-ietf-quic-http-02
 
-- SETTINGS changes (#181):
+- Track changes in transport draft
+
+
+## Since draft-ietf-quic-http-01
 
+- SETTINGS changes (#181):
     - SETTINGS can be sent only once at the start of a connection;
       no changes thereafter
     - SETTINGS_ACK removed
     - Settings can only occur in the SETTINGS frame a single time
     - Boolean format updated
 
 - Alt-Svc parameter changed from "v" to "quic"; format updated (#229)
-
 - Closing the connection control stream or any message control stream is a
   fatal error (#176)
-
 - HPACK Sequence counter can wrap (#173)
-
 - 0-RTT guidance added
-
 - Guide to differences from HTTP/2 and porting HTTP/2 extensions added
   (#127,#242)
 
-## Since draft-ietf-quic-http-00:
 
-- Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
+## Since draft-ietf-quic-http-00
 
+- Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
 - Changed from using HTTP/2 framing within Stream 3 to new framing format and
   two-stream-per-request model (#71,#72,#73)
-
 - Adopted SETTINGS format from draft-bishop-httpbis-extended-settings-01
-
 - Reworked SETTINGS_ACK to account for indeterminate inter-stream order (#75)
-
 - Described CONNECT pseudo-method (#95)
-
 - Updated ALPN token and Alt-Svc guidance (#13,#87)
-
 - Application-layer-defined error codes (#19,#74)
 
-## Since draft-shade-quic-http2-mapping-00:
 
-- Adopted as base for draft-ietf-quic-http.
+## Since draft-shade-quic-http2-mapping-00
 
-- Updated authors/editors list.
+- Adopted as base for draft-ietf-quic-http
+- Updated authors/editors list

draft-ietf-quic-recovery.md

@@ -98,7 +98,7 @@ important to the loss detection and congestion control machinery below.
 * Retransmittable frames are frames requiring reliable delivery.  The most
   common are STREAM frames, which typically contain application data.
 
-* Crypto handshake data is also sent as STREAM data, and uses the reliability
+* Crypto handshake data is sent on stream 0, and uses the reliability
   machinery of QUIC underneath.
 
 * ACK frames contain acknowledgment information.  QUIC uses a SACK-based
@@ -196,7 +196,8 @@ An unacknowledged QUIC packet is marked as lost in one of the following ways:
     lost when a packet larger than it is acknowledged and a threshold amount of
     time has passed since the packet was sent.
 
-  * Handshake packets are special in a number of ways, and a separate alarm
+  * Handshake packets, which contain STREAM frames for stream 0, are
+    critical to QUIC transport and crypto negotiation, so a separate alarm
     period is used for them.
 
 
@@ -254,16 +255,20 @@ largest_sent_before_rto:
 : The last packet number sent prior to the first retransmission
   timeout.
 
+time_of_last_sent_packet:
+: The time the most recent packet was sent.
+
+latest_rtt:
+: The most recent RTT measurement made when receiving an ack for
+  a previously unacked packet.
+
 smoothed_rtt:
 : The smoothed RTT of the connection, computed as described in
   {{?RFC6298}}
 
 rttvar:
 : The RTT variance, computed as described in {{?RFC6298}}
 
-initial_rtt:
-: The initial RTT used before any RTT measurements have been made.
-
 reordering_threshold:
 : The largest delta between the largest acked
   retransmittable packet and a packet containing retransmittable frames before
@@ -302,8 +307,8 @@ follows:
    loss_time = 0
    smoothed_rtt = 0
    rttvar = 0
-   initial_rtt = kDefaultInitialRtt
    largest_sent_before_rto = 0
+   time_of_last_sent_packet = 0
 ~~~
 
 ### On Sending a Packet
@@ -326,6 +331,7 @@ Pseudocode for OnPacketSent follows:
 
 ~~~
  OnPacketSent(packet_number, is_retransmittable, sent_bytes):
+   time_of_last_sent_packet = now;
    sent_packets[packet_number].packet_number = packet_number
    sent_packets[packet_number].time = now
    if is_retransmittable:
@@ -337,22 +343,16 @@ Pseudocode for OnPacketSent follows:
 
 When an ack is received, it may acknowledge 0 or more packets.
 
-The sender MUST abort the connection if it receives an ACK for a packet it
-never sent, see {{QUIC-TRANSPORT}}.
-
 Pseudocode for OnAckReceived and UpdateRtt follow:
 
 ~~~
    OnAckReceived(ack):
      // If the largest acked is newly acked, update the RTT.
      if (sent_packets[ack.largest_acked]):
-       rtt_sample = now - sent_packets[ack.largest_acked].time
-       if (rtt_sample > ack.ack_delay):
-         rtt_sample -= ack.delay
-       UpdateRtt(rtt_sample)
-     // The sender may skip packets for detecting optimistic ACKs
-     if (packets acked that the sender skipped):
-       abortConnection()
+       latest_rtt = now - sent_packets[ack.largest_acked].time
+       if (latest_rtt > ack.ack_delay):
+         latest_rtt -= ack.delay
+       UpdateRtt(latest_rtt)
      // Find all newly acked packets.
      for acked_packet in DetermineNewlyAckedPackets():
        OnPacketAcked(acked_packet.packet_number)
@@ -361,14 +361,14 @@ Pseudocode for OnAckReceived and UpdateRtt follow:
      SetLossDetectionAlarm()
 
 
-   UpdateRtt(rtt_sample):
+   UpdateRtt(latest_rtt):
      // Based on {{?RFC6298}}.
      if (smoothed_rtt == 0):
-       smoothed_rtt = rtt_sample
-       rttvar = rtt_sample / 2
+       smoothed_rtt = latest_rtt
+       rttvar = latest_rtt / 2
      else:
-       rttvar = 3/4 * rttvar + 1/4 * (smoothed_rtt - rtt_sample)
-       smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * rtt_sample
+       rttvar = 3/4 * rttvar + 1/4 * (smoothed_rtt - latest_rtt)
+       smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * latest_rtt
 ~~~
 
 ### On Packet Acknowledgment
@@ -412,7 +412,7 @@ below shows how the single timer is set based on the alarm mode.
 The initial flight has no prior RTT sample.  A client SHOULD remember
 the previous RTT it observed when resumption is attempted and use that for an
 initial RTT value.  If no previous RTT is available, the initial RTT defaults
-to 200ms.  Once an RTT measurement is taken, it MUST replace initial_rtt.
+to 200ms.
 
 Endpoints MUST retransmit handshake frames if not acknowledged within a
 time limit. This time limit will start as the largest of twice the rtt value
@@ -456,11 +456,11 @@ Pseudocode for SetLossDetectionAlarm follows:
     if (handshake packets are outstanding):
       // Handshake retransmission alarm.
       if (smoothed_rtt == 0):
-        alarm_duration = 2 * initial_rtt
+        alarm_duration = 2 * kDefaultInitialRtt
       else:
         alarm_duration = 2 * smoothed_rtt
       alarm_duration = max(alarm_duration, kMinTLPTimeout)
-      alarm_duration = alarm_duration << handshake_count
+      alarm_duration = alarm_duration * (2 ^ handshake_count)
     else if (loss_time != 0):
       // Early retransmit timer or time loss detection.
       alarm_duration = loss_time - now
@@ -475,7 +475,7 @@ Pseudocode for SetLossDetectionAlarm follows:
       // RTO alarm
       alarm_duration = smoothed_rtt + 4 * rttvar
       alarm_duration = max(alarm_duration, kMinRTOTimeout)
-      alarm_duration = alarm_duration << rto_count
+      alarm_duration = alarm_duration * (2 ^ rto_count)
 
     loss_detection_alarm.set(now + alarm_duration)
 ~~~
@@ -721,26 +721,30 @@ This document has no IANA actions.  Yet.
 > **RFC Editor's Note:**  Please remove this section prior to
 > publication of a final version of this document.
 
+## Since draft-ietf-quic-recovery-02
+
+- Integrate F-RTO (#544, #409)
+- Add congestion control (#545, #395)
+- Require connection abort if a skipped packet was acknowledged (#415)
+- Simplify RTO calculations (#142, #417)
+
+
 ## Since draft-ietf-quic-recovery-01
 
 - Overview added to loss detection
-
 - Changes initial default RTT to 100ms
-
 - Added time-based loss detection and fixes early retransmit
-
 - Clarified loss recovery for handshake packets
-
 - Fixed references and made TCP references informative
 
-## Since draft-ietf-quic-recovery-00:
 
-- Improved description of constants and ACK behavior
+## Since draft-ietf-quic-recovery-00
 
-## Since draft-iyengar-quic-loss-recovery-01:
+- Improved description of constants and ACK behavior
 
-- Adopted as base for draft-ietf-quic-recovery.
 
-- Updated authors/editors list.
+## Since draft-iyengar-quic-loss-recovery-01
 
-- Added table of contents.
+- Adopted as base for draft-ietf-quic-recovery
+- Updated authors/editors list
+- Added table of contents