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

Makefile

@@ -9,14 +9,15 @@ else
 endif
 
 latest::
-	@if grep -l ' $$' *.md; then ! echo "Trailing whitespace found"; fi
 	@err=0; for f in draft-*.md ; do \
-	  line=$$(cat "$$f" | sed -e 's/[|].*[|]//' | 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 grep -n '^.\{81\}' "$$f"; 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' | 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

@@ -199,7 +199,10 @@ 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.
+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
@@ -755,6 +758,7 @@ HTTP_MULTIPLE_SETTINGS (0x10):
 HTTP_RST_CONTROL_STREAM (0x11):
 : A message control stream closed abruptly.
 
+<<<<<<< HEAD
 
 # Considerations for Transitioning from HTTP/2
 
@@ -835,6 +839,9 @@ to the IANA registry in {{iana-settings}}.
 QUIC has the same concepts of "stream" and "connection" errors that HTTP/2
 provides. However, because the error code space is shared between multiple
 components, there is no direct portability of HTTP/2 error codes.
+=======
+## Mapping HTTP/2 Error Codes
+>>>>>>> origin/master
 
 The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to QUIC error
 codes as follows:

draft-ietf-quic-recovery.md

@@ -59,10 +59,6 @@ normative:
 
 informative:
 
-  RFC3782:
-  RFC6582:
-  RFC5682:
-  RFC6937:
   I-D.dukkipati-tcpm-tcp-loss-probe:
 
 --- abstract
@@ -267,7 +263,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
 
@@ -306,7 +304,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
@@ -398,7 +395,11 @@ 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 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.
 
 ### Pseudocode
 
@@ -418,7 +419,6 @@ 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 {{!RFC5827}}
       // with an alarm to reduce spurious retransmits.
@@ -430,15 +430,13 @@ Pseudocode for SetLossDetectionAlarm follows:
       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)
 ~~~
@@ -447,14 +445,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()
 ~~~
 
@@ -494,11 +510,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

draft-ietf-quic-tls.md

@@ -529,6 +529,29 @@ version of TLS.  An endpoint MUST terminate the connection if a version of TLS
 older than 1.3 is negotiated.
 
 
+## ClientHello Size
+
+QUIC requires that the initial handshake packet from a client fit within a
+single packet of at least 1280 octets.  With framing and packet overheads this
+value could be reduced.
+
+A TLS ClientHello can fit within this limit with ample space remaining.
+However, there are several variables that could cause this limit to be exceeded.
+Implementations are reminded that large session tickets or HelloRetryRequest
+cookies, multiple or large key shares, and long lists of supported ciphers,
+signature algorithms, versions, QUIC transport parameters, and other negotiable
+parameters and extensions could cause this message to grow.
+
+For servers, the size of the session tickets and HelloRetryRequest cookie
+extension can have an effect on a client's ability to connect.  Choosing a small
+value increases the probability that these values can be successfully used by a
+client.
+
+A TLS implementation does not need to enforce this size constraint.  QUIC
+padding can be used to reach this size, meaning that a TLS server is unlikely to
+receive a large ClientHello message.
+
+
 ## Peer Authentication
 
 The requirements for authentication depend on the application protocol that is
@@ -1344,11 +1367,12 @@ by an attacker.
 Certificate caching {{?RFC7924}} can reduce the size of the server's handshake
 messages significantly.
 
-A client SHOULD also pad {{!RFC7685}} its ClientHello to at least 1024 octets.
-A server is less likely to generate a packet reflection attack if the data it
-sends is a small multiple of the data it receives.  A server SHOULD use a
-HelloRetryRequest if the size of the handshake messages it sends is likely to
-exceed the size of the ClientHello.
+QUIC requires that the packet containing a ClientHello be padded to the size of
+the maximum transmission unit (MTU).  A server is less likely to generate a
+packet reflection attack if the data it sends is a small multiple of this size.
+A server SHOULD use a HelloRetryRequest if the size of the handshake messages it
+sends is likely to significantly exceed the size of the packet containing the
+ClientHello.
 
 
 ## Peer Denial of Service {#useless}