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

CONTRIBUTING.md

@@ -59,33 +59,27 @@ commits will only be responded to with best effort, and may not be seen.
 
 ## Resolving Issues
 
-The `open` issues in the issues list are those that we are currently or plan to discuss. When an issue is `closed`, it implies that the group has consensus and it is reflected in the draft(s). If substantive new information is brought to our attention, issues can be reopened by the Chairs.
-
-Issues will be labeled by the Chairs as either `editorial` or `design`.
+Issues will be labeled by the Chairs as either `editorial` or `design`:
 
 * **Design** issues require discussion and consensus in the Working Group. This discussion can happen both in the issue and on the [Working Group mailing list](https://www.ietf.org/mailman/listinfo/quic), as outlined below.
 
-* **Editorial** issues can be closed by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself.
-
-Consensus for the resolution of a design issue can be established in a few different ways:
-
-* Through discussion on the mailing list. Once a resolution is found, it will be recorded in the issue.
+* **Editorial** issues can be dealt with by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself.
 
-* Through discussion on the issues list. Once a resolution is found, it will be confirmed on the mailing list before consensus is declared.
+The `open` design issues in the issues list are those that we are currently or plan to discuss. When a design issue is `closed`, it implies that the issue has a proposed resolution that is reflected in the drafts; if a `closed` design issue is labeled with `has-consensus`, it means that the incorporated resolution has Working Group consensus.
 
-The editors can also propose resolutions for the group's consideration by incorporating them into the draft(s); when doing so, the issue should not be closed until consensus is declared.
+Design issues can be discussed on the mailing list or the issues list. The editors can also propose resolutions to design issues for the group's consideration by incorporating them into the draft(s).
 
-Issues that have consensus but which aren't yet reflected in text will be labelled as `editor-ready`. After the editors have incorporated a resolution into the specification, the issue can be closed.
+When a new draft is published, the design issues that have been closed since the last draft will be highlighted on the mailing list, to aid reviewers. Once consensus is confirmed, those issues will be labeled with [`has-consensus`](https://github.com/quicwg/base-drafts/issues?utf8=✓&q=label%3Ahas-consensus%20).
 
-When a new draft is published, the design issues that have been closed since the last draft will be highlighted on the mailing list, to aid reviewers.
+Note that whether or not a design issue is closed does **not** reflect consensus of the Working Group; an issue's `open`/`closed` state is only used to organise our discussions. If you have a question or problem with an issue in the `closed` state, please comment on it (either in the issues list or mailing list), and we'll adjust its state accordingly. Note that reopening issues with `has-consensus` requires new information.
 
 ### Discretionary Design Issue Labels
 
 We also use the following labels to help understand the state of our design issues:
 
-* **Needs Discussion**: The issue needs significant Working Group discussion before it can progress.
-* **Confirm Consensus**: There is a resolution that the proponents believe reflects a consensus position, needs to be confirmed with the WG.
-* **Notify Consensus**: The WG has achieved consensus in a meeting, needs to be confirmed on the mailing list.
+* [`needs-discussion`](https://github.com/quicwg/base-drafts/labels/needs-discussion): The issue needs significant Working Group discussion before it can progress.
+* [`has-proposal`](https://github.com/quicwg/base-drafts/labels/has-proposal): The issue has a proposal for resolution.
+* [`editor-ready`](https://github.com/quicwg/base-drafts/labels/editor-ready): The Working Group believes it has a viable resolution, but the editors need to incorporate that into the document so we can see it in situ.
 
 
 ## Pull Requests

Makefile

@@ -9,14 +9,16 @@ else
 endif
 
 latest::
-	@if grep -l ' $$' *.md; then ! echo "Trailing whitespace found"; fi
 	@err=0; for f in draft-*.md ; do \
-	  line=$$(cat "$$f" | wc -L); \
-	  if [ "$$line" -gt 80 ]; then \
-	    echo "$$f contains a line with >80 ($$line) characters"; err=1; \
+	  if grep -n ' $$' "$$f"; then \
+	    echo "$$f contains trailing whitespace"; err=1; \
 	  fi; \
-	  figure=$$(sed -e '/^~~~/,/^~~~/p;d' "$$f" | wc -L); \
-	  if [ "$$figure" -gt 69 ]; then \
-	    echo "$$f contains a figure with >69 ($$figure) characters"; err=1; \
+	  if cat "$$f" | (l=0; while read -r a; do l=$$(($$l + 1)); echo -E "$$l:$$a"; done) | \
+	     grep -v '^[0-9]*: *|' | tr -d '\r' | grep '^[0-9]*:.\{81\}'; then \
+	    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 \
+	    echo "$$f contains a figure with >69 characters"; err=1; \
 	  fi; \
 	done; [ "$$err" -eq 0 ]

draft-ietf-quic-http.md

@@ -170,7 +170,10 @@ application.
 
 QUIC reserves Stream 1 for crypto operations (the handshake, crypto config
 updates). Stream 3 is reserved for sending and receiving HTTP control frames,
-and is analogous to HTTP/2's Stream 0.
+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
@@ -186,6 +189,21 @@ additional framing. Note that a request or response without a body will cause
 this stream to be half-closed in the corresponding direction without
 transferring data.
 
+Because the message control stream contains HPACK data which manipulates
+connection-level state, the message control stream MUST NOT be closed with a
+stream-level error.  If an implementation chooses to reject a request with a
+QUIC error code, it MUST trigger a QUIC RST_STREAM on the data stream only.  An
+implementation MAY close (FIN) a message control stream without completing a
+full HTTP message if the data stream has been abruptly closed.  Data on message
+control streams MUST be fully consumed, or the connection terminated.
+
+All message control streams are considered critical to the HTTP connection.  If
+a message control stream is terminated abruptly for any reason, this MUST be
+treated as a connection error of type HTTP_RST_CONTROL_STREAM.  When a message
+control stream terminates cleanly, if the last frame on the stream was
+truncated, this MUST be treated as a connection error (see HTTP_MALFORMED_* in
+{{http-error-codes}}).
+
 Pairs of streams must be utilized sequentially, with no gaps.  The data stream
 is opened at the same time as the message control stream is opened and is closed
 after transferring the body.  The data stream is closed immediately after
@@ -675,11 +693,6 @@ The payload consists of:
   Payload:
   : HPACK-compressed request headers for the promised response.
 
-TODOs:
-
- - QUIC stream space may be enlarged; would need to redefine Promised Stream
-   field in this case.
- - No CONTINUATION -- HEADERS have EHB; do we need it here?
 
 ### PING
 
@@ -767,10 +780,14 @@ HTTP_SETTINGS_ON_WRONG_STREAM (0x0F):
 HTTP_MULTIPLE_SETTINGS (0x10):
 : More than one SETTINGS frame was received.
 
-HTTP_EARLY_RESPONSE (0x11):
+HTTP_RST_CONTROL_STREAM (0x11):
+: A message control stream closed abruptly.
+
+HTTP_EARLY_RESPONSE (0x12):
 : Server is able to generate a response to the client request without selecting
   the complete request body.
 
+
 ## Mapping HTTP/2 Error Codes
 
 The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to QUIC error

draft-ietf-quic-recovery.md

@@ -27,21 +27,6 @@ author:
 
 normative:
 
-  QUIC-TLS:
-    title: "Using Transport Layer Security (TLS) to Secure QUIC"
-    date: {DATE}
-    author:
-      -
-        ins: M. Thomson
-        name: Martin Thomson
-        org: Mozilla
-        role: editor
-      -
-        ins: S. Turner
-        name: Sean Turner
-        org: sn3rd
-        role: editor
-
   QUIC-TRANSPORT:
     title: "QUIC: A UDP-Based Multiplexed and Secure Transport"
     date: {DATE}
@@ -57,15 +42,6 @@ normative:
         org: Mozilla
         role: editor
 
-informative:
-
-  RFC3782:
-  RFC6582:
-  RFC5827:
-  RFC5682:
-  RFC6937:
-  I-D.dukkipati-tcpm-tcp-loss-probe:
-
 --- abstract
 
 QUIC is a new multiplexed and secure transport atop UDP.  QUIC builds on decades
@@ -221,7 +197,7 @@ kMinRTOTimeout (default 200ms):
 kDelayedAckTimeout (default 25ms):
 : The length of the peer's delayed ack timer.
 
-kDefaultInitialRtt (default 200ms):
+kDefaultInitialRtt (default 100ms):
 : The default RTT used before an RTT sample is taken.
 
 ## Variables of interest
@@ -268,7 +244,9 @@ use_time_loss:
   threshold in time, rather than in packet number gaps.
 
 sent_packets:
-: An association of packet numbers to information about them.
+: An association of packet numbers to information about them, including a time
+  field indicating the time a packet was sent and a bytes field indicating the
+  packet's size.
 
 ## Initialization
 
@@ -287,51 +265,6 @@ follows:
    initial_rtt = kDefaultInitialRtt
 ~~~
 
-## Setting the Loss Detection Alarm
-
-QUIC loss detection uses a single alarm for all timer-based loss 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 function SetLossDetectionAlarm defined
-below shows how the single timer is set based on the alarm mode.
-
-Pseudocode for SetLossDetectionAlarm follows:
-
-~~~
- SetLossDetectionAlarm():
-    if (retransmittable packets are not outstanding):
-      loss_detection_alarm.cancel()
-      return
-
-    if (handshake packets are outstanding):
-      // Handshake retransmission alarm.
-      alarm_duration = max(1.5 * smoothed_rtt, kMinTLPTimeout)
-                         << handshake_count
-      handshake_count++;
-    else if (largest sent packet is acked):
-      // Early retransmit {{!RFC 5827}}
-      // with an alarm to reduce spurious retransmits.
-      alarm_duration = 0.25 * smoothed_rtt
-    else if (tlp_count < kMaxTLPs):
-      // Tail Loss Probe alarm.
-      if (retransmittable_packets_outstanding = 1):
-        alarm_duration = max(
-                           1.5 * smoothed_rtt + kDelayedAckTimeout,
-                           2 * smoothed_rtt)
-      else:
-        alarm_duration = max (kMinTLPTimeout, 2 * smoothed_rtt)
-      tlp_count++;
-    else:
-      // RTO alarm.
-      if (rto_count = 0):
-        alarm_duration = max(kMinRTOTimeout,
-                             smoothed_rtt + 4 * rttvar)
-      else:
-        alarm_duration = loss_detection_alarm.get_delay() << 1
-      rto_count++
-
-    loss_detection_alarm.set(now + alarm_duration)
-~~~
-
 ## On Sending a Packet
 
 After any packet is sent, be it a new transmission or a rebundled transmission,
@@ -352,7 +285,6 @@ Pseudocode for OnPacketSent follows:
 
 ~~~
  OnPacketSent(packet_number, is_retransmittable, sent_bytes):
-   # TODO: Clarify the data in sent_packets.
    sent_packets[packet_number].time = now
    if is_retransmittable:
      sent_packets[packet_number].bytes = sent_bytes
@@ -377,7 +309,8 @@ Pseudocode for OnAckReceived and UpdateRtt follow:
      for acked_packet in DetermineNewlyAckedPackets():
        OnPacketAcked(acked_packet)
 
-     DetectLostPackets(ack.largest_acked_packet)
+     lost_packets = DetectLostPackets(ack.largest_acked_packet)
+     MaybeRetransmit(lost_packets)
      SetLossDetectionAlarm()
 
 
@@ -443,9 +376,14 @@ Version negotiation packets are always stateless, and MUST be sent once per
 per handshake packet that uses an unsupported QUIC version, and MAY be sent
 in response to 0RTT packets.
 
-(Add sections for early retransmit and TLP/RTO here)
+### Tail Loss Probe and Retransmission Timeout
+
+Tail loss probes {{?I-D.dukkipati-tcpm-tcp-loss-probe}} and retransmission
+timeouts{{?RFC6298}} are an alarm based mechanism to recover from cases when
+there are outstanding retransmittable packets, but an acknowledgement has
+not been received in a timely manner.
 
-### Psuedocode
+### Pseudocode
 
 Pseudocode for SetLossDetectionAlarm follows:
 
@@ -463,27 +401,24 @@ Pseudocode for SetLossDetectionAlarm follows:
         alarm_duration = 2 * smoothed_rtt
       alarm_duration = max(alarm_duration, kMinTLPTimeout)
       alarm_duration = alarm_duration << handshake_count
-      handshake_count++;
     else if (largest sent packet is acked):
-      // Early retransmit {{!RFC 5827}}
+      // Early retransmit {{?RFC5827}}
       // with an alarm to reduce spurious retransmits.
       alarm_duration = 0.25 * smoothed_rtt
     else if (tlp_count < kMaxTLPs):
-      // Tail Loss Probe alarm.
+      // Tail Loss Probe {{?I-D.dukkipati-tcpm-tcp-loss-probe}}
       if (retransmittable_packets_outstanding = 1):
         alarm_duration = 1.5 * smoothed_rtt + kDelayedAckTimeout
       else:
         alarm_duration = kMinTLPTimeout
       alarm_duration = max(alarm_duration, 2 * smoothed_rtt)
-      tlp_count++
     else:
       // RTO alarm.
       if (rto_count = 0):
         alarm_duration = smoothed_rtt + 4 * rttvar
         alarm_duration = max(alarm_duration, kMinRTOTimeout)
       else:
         alarm_duration = loss_detection_alarm.get_delay() << 1
-      rto_count++
 
     loss_detection_alarm.set(now + alarm_duration)
 ~~~
@@ -492,14 +427,32 @@ Pseudocode for SetLossDetectionAlarm follows:
 
 QUIC uses one loss recovery alarm, which when set, can be in one of several
 modes.  When the alarm fires, the mode determines the action to be performed.
-OnAlarm returns a list of packet numbers that are detected as lost.
 
-Pseudocode for OnAlarm follows:
+Pseudocode for OnLossDetectionAlarm follows:
 
 ~~~
-   OnAlarm(acked_packet):
-     lost_packets = DetectLostPackets(acked_packet)
-     MaybeRetransmit(lost_packets)
+   OnLossDetectionAlarm():
+     if (handshake packets are outstanding):
+       // Handshake retransmission alarm.
+       RetransmitAllHandshakePackets();
+       handshake_count++;
+     // TODO: Clarify early retransmit and time loss.
+     else if ():
+       // Early retransmit or Time Loss Detection
+       lost_packets = DetectLostPackets(acked_packet)
+       MaybeRetransmit(lost_packets)
+     else if (tlp_count < kMaxTLPs):
+       // Tail Loss Probe alarm.
+       if (HasNewDataToSend()):
+         SendOnePacketOfNewData()
+       else:
+         RetransmitOldestPacket()
+       tlp_count++
+     else:
+       // RTO alarm.
+       RetransmitOldestPacket()
+       rto_count++
+
      SetLossDetectionAlarm()
 ~~~
 
@@ -517,7 +470,7 @@ The receiver MUST trust protected acks for unprotected packets, however.  Aside
 from this, loss detection for handshake packets when an ack is processed is
 identical to other packets.
 
-### Psuedocode
+### Pseudocode
 
 DetectLostPackets takes one parameter, acked, which is the largest acked packet,
 and returns a list of packets detected as lost.
@@ -539,11 +492,12 @@ Pseudocode for DetectLostPackets follows:
 
 # Congestion Control
 
-(describe NewReno-style congestion control for QUIC.)
+(describe NewReno-style congestion control {{?RFC6582}} for QUIC.)
 (describe appropriate byte counting.)
 (define recovery based on packet numbers.)
 (describe min_rtt based hystart.)
-(describe how QUIC's F-RTO delays reducing CWND until an ack is received.)
+(describe how QUIC's F-RTO {{?RFC5682}} delays reducing CWND.)
+(describe PRR {{?RFC6937}})
 
 
 # IANA Considerations