diff --git a/index.html b/index.html
index 5140f65b83..dac9dfdea2 100644
--- a/index.html
+++ b/index.html
@@ -73,659 +73,709 @@ <h1>Editor's drafts for master branch of <a href="https://github.com/quicwg/base
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="invariants">invariants</a></h2>
-    <table id="branch-invariants">
-      <tr>
-        <th>*</th>
-        <td><a href="invariants/*.html"
-           class="html *">html</a></td>
-        <td><a href="invariants/*.txt"
-           class="txt *">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/*.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/*.txt" class="diff *">
-          diff with last submission</a></td>
-      </tr>
-    </table>
-    <h2>Preview for branch <a href="invariants/consistency">invariants/consistency</a></h2>
-    <table id="branch-invariants/consistency">
+    <h2>Preview for branch <a href="dedupe-packets">dedupe-packets</a></h2>
+    <table id="branch-dedupe-packets">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="invariants/consistency/draft-ietf-quic-http.html"
+        <td><a href="dedupe-packets/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="invariants/consistency/draft-ietf-quic-http.txt"
+        <td><a href="dedupe-packets/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="invariants/consistency/draft-ietf-quic-invariants.html"
+        <td><a href="dedupe-packets/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="invariants/consistency/draft-ietf-quic-invariants.txt"
+        <td><a href="dedupe-packets/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="invariants/consistency/draft-ietf-quic-qpack.html"
+        <td><a href="dedupe-packets/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="invariants/consistency/draft-ietf-quic-qpack.txt"
+        <td><a href="dedupe-packets/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="invariants/consistency/draft-ietf-quic-recovery.html"
+        <td><a href="dedupe-packets/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="invariants/consistency/draft-ietf-quic-recovery.txt"
+        <td><a href="dedupe-packets/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="invariants/consistency/draft-ietf-quic-tls.html"
+        <td><a href="dedupe-packets/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="invariants/consistency/draft-ietf-quic-tls.txt"
+        <td><a href="dedupe-packets/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="invariants/consistency/draft-ietf-quic-transport.html"
+        <td><a href="dedupe-packets/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="invariants/consistency/draft-ietf-quic-transport.txt"
+        <td><a href="dedupe-packets/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="qpack-backtick">qpack-backtick</a></h2>
-    <table id="branch-qpack-backtick">
+    <h2>Preview for branch <a href="cite-this">cite-this</a></h2>
+    <table id="branch-cite-this">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack-backtick/draft-ietf-quic-http.html"
+        <td><a href="cite-this/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack-backtick/draft-ietf-quic-http.txt"
+        <td><a href="cite-this/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="qpack-backtick/draft-ietf-quic-invariants.html"
+        <td><a href="cite-this/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack-backtick/draft-ietf-quic-invariants.txt"
+        <td><a href="cite-this/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="qpack-backtick/draft-ietf-quic-qpack.html"
+        <td><a href="cite-this/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack-backtick/draft-ietf-quic-qpack.txt"
+        <td><a href="cite-this/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="qpack-backtick/draft-ietf-quic-recovery.html"
+        <td><a href="cite-this/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack-backtick/draft-ietf-quic-recovery.txt"
+        <td><a href="cite-this/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="qpack-backtick/draft-ietf-quic-tls.html"
+        <td><a href="cite-this/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack-backtick/draft-ietf-quic-tls.txt"
+        <td><a href="cite-this/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="qpack-backtick/draft-ietf-quic-transport.html"
+        <td><a href="cite-this/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack-backtick/draft-ietf-quic-transport.txt"
+        <td><a href="cite-this/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="dplpmtud-merge">dplpmtud-merge</a></h2>
-    <table id="branch-dplpmtud-merge">
+    <h2>Preview for branch <a href="alarm-timer">alarm-timer</a></h2>
+    <table id="branch-alarm-timer">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-http.html"
+        <td><a href="alarm-timer/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-http.txt"
+        <td><a href="alarm-timer/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-invariants.html"
+        <td><a href="alarm-timer/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-invariants.txt"
+        <td><a href="alarm-timer/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-qpack.html"
+        <td><a href="alarm-timer/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-qpack.txt"
+        <td><a href="alarm-timer/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-recovery.html"
+        <td><a href="alarm-timer/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-recovery.txt"
+        <td><a href="alarm-timer/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-tls.html"
+        <td><a href="alarm-timer/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-tls.txt"
+        <td><a href="alarm-timer/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-transport.html"
+        <td><a href="alarm-timer/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="dplpmtud-merge/draft-ietf-quic-transport.txt"
+        <td><a href="alarm-timer/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
-          diff with last submission</a></td>
-      </tr>
-    </table>
-    <h2>Preview for branch <a href="http">http</a></h2>
-    <table id="branch-http">
-      <tr>
-        <th>*</th>
-        <td><a href="http/*.html"
-           class="html *">html</a></td>
-        <td><a href="http/*.txt"
-           class="txt *">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/http/*.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/http/*.txt" class="diff *">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/explicit_failure">http/explicit_failure</a></h2>
-    <table id="branch-http/explicit_failure">
+    <h2>Preview for branch <a href="link-preferred-address">link-preferred-address</a></h2>
+    <table id="branch-link-preferred-address">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/explicit_failure/draft-ietf-quic-http.html"
+        <td><a href="link-preferred-address/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/explicit_failure/draft-ietf-quic-http.txt"
+        <td><a href="link-preferred-address/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/explicit_failure/draft-ietf-quic-invariants.html"
+        <td><a href="link-preferred-address/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/explicit_failure/draft-ietf-quic-invariants.txt"
+        <td><a href="link-preferred-address/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/explicit_failure/draft-ietf-quic-qpack.html"
+        <td><a href="link-preferred-address/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/explicit_failure/draft-ietf-quic-qpack.txt"
+        <td><a href="link-preferred-address/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/explicit_failure/draft-ietf-quic-recovery.html"
+        <td><a href="link-preferred-address/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/explicit_failure/draft-ietf-quic-recovery.txt"
+        <td><a href="link-preferred-address/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/explicit_failure/draft-ietf-quic-tls.html"
+        <td><a href="link-preferred-address/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/explicit_failure/draft-ietf-quic-tls.txt"
+        <td><a href="link-preferred-address/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/explicit_failure/draft-ietf-quic-transport.html"
+        <td><a href="link-preferred-address/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/explicit_failure/draft-ietf-quic-transport.txt"
+        <td><a href="link-preferred-address/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/no_rtt">http/no_rtt</a></h2>
-    <table id="branch-http/no_rtt">
+    <h2>Preview for branch <a href="section-ref-titlecase">section-ref-titlecase</a></h2>
+    <table id="branch-section-ref-titlecase">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/no_rtt/draft-ietf-quic-http.html"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/no_rtt/draft-ietf-quic-http.txt"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/no_rtt/draft-ietf-quic-invariants.html"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/no_rtt/draft-ietf-quic-invariants.txt"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/no_rtt/draft-ietf-quic-qpack.html"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/no_rtt/draft-ietf-quic-qpack.txt"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/no_rtt/draft-ietf-quic-recovery.html"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/no_rtt/draft-ietf-quic-recovery.txt"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/no_rtt/draft-ietf-quic-tls.html"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/no_rtt/draft-ietf-quic-tls.txt"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/no_rtt/draft-ietf-quic-transport.html"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/no_rtt/draft-ietf-quic-transport.txt"
+        <td><a href="section-ref-titlecase/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/one_true_reference_format">http/one_true_reference_format</a></h2>
-    <table id="branch-http/one_true_reference_format">
+    <h2>Preview for branch <a href="varint-fmt-example">varint-fmt-example</a></h2>
+    <table id="branch-varint-fmt-example">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-http.html"
+        <td><a href="varint-fmt-example/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-http.txt"
+        <td><a href="varint-fmt-example/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-invariants.html"
+        <td><a href="varint-fmt-example/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-invariants.txt"
+        <td><a href="varint-fmt-example/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-qpack.html"
+        <td><a href="varint-fmt-example/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-qpack.txt"
+        <td><a href="varint-fmt-example/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-recovery.html"
+        <td><a href="varint-fmt-example/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-recovery.txt"
+        <td><a href="varint-fmt-example/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-tls.html"
+        <td><a href="varint-fmt-example/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-tls.txt"
+        <td><a href="varint-fmt-example/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-transport.html"
+        <td><a href="varint-fmt-example/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/one_true_reference_format/draft-ietf-quic-transport.txt"
+        <td><a href="varint-fmt-example/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/alpn_specificity">http/alpn_specificity</a></h2>
-    <table id="branch-http/alpn_specificity">
+    <h2>Preview for branch <a href="ianswett-recompute-pto">ianswett-recompute-pto</a></h2>
+    <table id="branch-ianswett-recompute-pto">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-http.html"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/alpn_specificity/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-recompute-pto/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/without_authority">http/without_authority</a></h2>
-    <table id="branch-http/without_authority">
+    <h2>Preview for branch <a href="qpack-security">qpack-security</a></h2>
+    <table id="branch-qpack-security">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/without_authority/draft-ietf-quic-http.html"
+        <td><a href="qpack-security/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/without_authority/draft-ietf-quic-http.txt"
+        <td><a href="qpack-security/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/without_authority/draft-ietf-quic-invariants.html"
+        <td><a href="qpack-security/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/without_authority/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack-security/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/without_authority/draft-ietf-quic-qpack.html"
+        <td><a href="qpack-security/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/without_authority/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack-security/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/without_authority/draft-ietf-quic-recovery.html"
+        <td><a href="qpack-security/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/without_authority/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack-security/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/without_authority/draft-ietf-quic-tls.html"
+        <td><a href="qpack-security/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/without_authority/draft-ietf-quic-tls.txt"
+        <td><a href="qpack-security/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/without_authority/draft-ietf-quic-transport.html"
+        <td><a href="qpack-security/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/without_authority/draft-ietf-quic-transport.txt"
+        <td><a href="qpack-security/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/blowing_up_hurts">http/blowing_up_hurts</a></h2>
-    <table id="branch-http/blowing_up_hurts">
+    <h2>Preview for branch <a href="bounded-rcid">bounded-rcid</a></h2>
+    <table id="branch-bounded-rcid">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-http.html"
+        <td><a href="bounded-rcid/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-http.txt"
+        <td><a href="bounded-rcid/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-invariants.html"
+        <td><a href="bounded-rcid/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-invariants.txt"
+        <td><a href="bounded-rcid/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-qpack.html"
+        <td><a href="bounded-rcid/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-qpack.txt"
+        <td><a href="bounded-rcid/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-recovery.html"
+        <td><a href="bounded-rcid/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-recovery.txt"
+        <td><a href="bounded-rcid/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-tls.html"
+        <td><a href="bounded-rcid/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-tls.txt"
+        <td><a href="bounded-rcid/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-transport.html"
+        <td><a href="bounded-rcid/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/blowing_up_hurts/draft-ietf-quic-transport.txt"
+        <td><a href="bounded-rcid/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/acknowledgements">http/acknowledgements</a></h2>
-    <table id="branch-http/acknowledgements">
+    <h2>Preview for branch <a href="tls-compat-mode">tls-compat-mode</a></h2>
+    <table id="branch-tls-compat-mode">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/acknowledgements/draft-ietf-quic-http.html"
+        <td><a href="tls-compat-mode/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/acknowledgements/draft-ietf-quic-http.txt"
+        <td><a href="tls-compat-mode/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/acknowledgements/draft-ietf-quic-invariants.html"
+        <td><a href="tls-compat-mode/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/acknowledgements/draft-ietf-quic-invariants.txt"
+        <td><a href="tls-compat-mode/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/acknowledgements/draft-ietf-quic-qpack.html"
+        <td><a href="tls-compat-mode/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/acknowledgements/draft-ietf-quic-qpack.txt"
+        <td><a href="tls-compat-mode/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/acknowledgements/draft-ietf-quic-recovery.html"
+        <td><a href="tls-compat-mode/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/acknowledgements/draft-ietf-quic-recovery.txt"
+        <td><a href="tls-compat-mode/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/acknowledgements/draft-ietf-quic-tls.html"
+        <td><a href="tls-compat-mode/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/acknowledgements/draft-ietf-quic-tls.txt"
+        <td><a href="tls-compat-mode/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/acknowledgements/draft-ietf-quic-transport.html"
+        <td><a href="tls-compat-mode/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/acknowledgements/draft-ietf-quic-transport.txt"
+        <td><a href="tls-compat-mode/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+          diff with last submission</a></td>
+      </tr>
+    </table>
+    <h2>Preview for branch <a href="http">http</a></h2>
+    <table id="branch-http">
+      <tr>
+        <th>*</th>
+        <td><a href="http/*.html"
+           class="html *">html</a></td>
+        <td><a href="http/*.txt"
+           class="txt *">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/http/*.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/http/*.txt" class="diff *">
+          diff with last submission</a></td>
+      </tr>
+    </table>
+    <h2>Preview for branch <a href="http/alpn_specificity">http/alpn_specificity</a></h2>
+    <table id="branch-http/alpn_specificity">
+      <tr>
+        <th>draft-ietf-quic-http</th>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-http.html"
+           class="html draft-ietf-quic-http">html</a></td>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-http.txt"
+           class="txt draft-ietf-quic-http">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-invariants</th>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-invariants.html"
+           class="html draft-ietf-quic-invariants">html</a></td>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-invariants.txt"
+           class="txt draft-ietf-quic-invariants">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-qpack</th>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-qpack.html"
+           class="html draft-ietf-quic-qpack">html</a></td>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-qpack.txt"
+           class="txt draft-ietf-quic-qpack">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-recovery</th>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-recovery.html"
+           class="html draft-ietf-quic-recovery">html</a></td>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-recovery.txt"
+           class="txt draft-ietf-quic-recovery">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-tls</th>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-tls.html"
+           class="html draft-ietf-quic-tls">html</a></td>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-tls.txt"
+           class="txt draft-ietf-quic-tls">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-transport</th>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-transport.html"
+           class="html draft-ietf-quic-transport">html</a></td>
+        <td><a href="http/alpn_specificity/draft-ietf-quic-transport.txt"
+           class="txt draft-ietf-quic-transport">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/alpn_specificity/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
@@ -792,1326 +842,1263 @@ <h2>Preview for branch <a href="http/what_is_malformed">http/what_is_malformed</
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/sewage_tunnels">http/sewage_tunnels</a></h2>
-    <table id="branch-http/sewage_tunnels">
+    <h2>Preview for branch <a href="http/explicit_failure">http/explicit_failure</a></h2>
+    <table id="branch-http/explicit_failure">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-http.html"
+        <td><a href="http/explicit_failure/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-http.txt"
+        <td><a href="http/explicit_failure/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-invariants.html"
+        <td><a href="http/explicit_failure/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-invariants.txt"
+        <td><a href="http/explicit_failure/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-qpack.html"
+        <td><a href="http/explicit_failure/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-qpack.txt"
+        <td><a href="http/explicit_failure/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-recovery.html"
+        <td><a href="http/explicit_failure/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-recovery.txt"
+        <td><a href="http/explicit_failure/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-tls.html"
+        <td><a href="http/explicit_failure/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-tls.txt"
+        <td><a href="http/explicit_failure/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-transport.html"
+        <td><a href="http/explicit_failure/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/sewage_tunnels/draft-ietf-quic-transport.txt"
+        <td><a href="http/explicit_failure/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/explicit_failure/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/which_connection_close">http/which_connection_close</a></h2>
-    <table id="branch-http/which_connection_close">
+    <h2>Preview for branch <a href="http/auth-reference">http/auth-reference</a></h2>
+    <table id="branch-http/auth-reference">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/which_connection_close/draft-ietf-quic-http.html"
+        <td><a href="http/auth-reference/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/which_connection_close/draft-ietf-quic-http.txt"
+        <td><a href="http/auth-reference/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/which_connection_close/draft-ietf-quic-invariants.html"
+        <td><a href="http/auth-reference/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/which_connection_close/draft-ietf-quic-invariants.txt"
+        <td><a href="http/auth-reference/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/which_connection_close/draft-ietf-quic-qpack.html"
+        <td><a href="http/auth-reference/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/which_connection_close/draft-ietf-quic-qpack.txt"
+        <td><a href="http/auth-reference/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/which_connection_close/draft-ietf-quic-recovery.html"
+        <td><a href="http/auth-reference/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/which_connection_close/draft-ietf-quic-recovery.txt"
+        <td><a href="http/auth-reference/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/which_connection_close/draft-ietf-quic-tls.html"
+        <td><a href="http/auth-reference/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/which_connection_close/draft-ietf-quic-tls.txt"
+        <td><a href="http/auth-reference/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/which_connection_close/draft-ietf-quic-transport.html"
+        <td><a href="http/auth-reference/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/which_connection_close/draft-ietf-quic-transport.txt"
+        <td><a href="http/auth-reference/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/grease_errors">http/grease_errors</a></h2>
-    <table id="branch-http/grease_errors">
+    <h2>Preview for branch <a href="http/core_and_friends">http/core_and_friends</a></h2>
+    <table id="branch-http/core_and_friends">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/grease_errors/draft-ietf-quic-http.html"
+        <td><a href="http/core_and_friends/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/grease_errors/draft-ietf-quic-http.txt"
+        <td><a href="http/core_and_friends/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/grease_errors/draft-ietf-quic-invariants.html"
+        <td><a href="http/core_and_friends/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/grease_errors/draft-ietf-quic-invariants.txt"
+        <td><a href="http/core_and_friends/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/grease_errors/draft-ietf-quic-qpack.html"
+        <td><a href="http/core_and_friends/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/grease_errors/draft-ietf-quic-qpack.txt"
+        <td><a href="http/core_and_friends/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/grease_errors/draft-ietf-quic-recovery.html"
+        <td><a href="http/core_and_friends/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/grease_errors/draft-ietf-quic-recovery.txt"
+        <td><a href="http/core_and_friends/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/grease_errors/draft-ietf-quic-tls.html"
+        <td><a href="http/core_and_friends/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/grease_errors/draft-ietf-quic-tls.txt"
+        <td><a href="http/core_and_friends/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/grease_errors/draft-ietf-quic-transport.html"
+        <td><a href="http/core_and_friends/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/grease_errors/draft-ietf-quic-transport.txt"
+        <td><a href="http/core_and_friends/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/references">http/references</a></h2>
-    <table id="branch-http/references">
+    <h2>Preview for branch <a href="http/without_authority">http/without_authority</a></h2>
+    <table id="branch-http/without_authority">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/references/draft-ietf-quic-http.html"
+        <td><a href="http/without_authority/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/references/draft-ietf-quic-http.txt"
+        <td><a href="http/without_authority/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/references/draft-ietf-quic-invariants.html"
+        <td><a href="http/without_authority/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/references/draft-ietf-quic-invariants.txt"
+        <td><a href="http/without_authority/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/references/draft-ietf-quic-qpack.html"
+        <td><a href="http/without_authority/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/references/draft-ietf-quic-qpack.txt"
+        <td><a href="http/without_authority/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/references/draft-ietf-quic-recovery.html"
+        <td><a href="http/without_authority/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/references/draft-ietf-quic-recovery.txt"
+        <td><a href="http/without_authority/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/references/draft-ietf-quic-tls.html"
+        <td><a href="http/without_authority/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/references/draft-ietf-quic-tls.txt"
+        <td><a href="http/without_authority/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/references/draft-ietf-quic-transport.html"
+        <td><a href="http/without_authority/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/references/draft-ietf-quic-transport.txt"
+        <td><a href="http/without_authority/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/without_authority/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/unknown_is_no-error">http/unknown_is_no-error</a></h2>
-    <table id="branch-http/unknown_is_no-error">
+    <h2>Preview for branch <a href="http/no_rtt">http/no_rtt</a></h2>
+    <table id="branch-http/no_rtt">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-http.html"
+        <td><a href="http/no_rtt/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-http.txt"
+        <td><a href="http/no_rtt/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-invariants.html"
+        <td><a href="http/no_rtt/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-invariants.txt"
+        <td><a href="http/no_rtt/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-qpack.html"
+        <td><a href="http/no_rtt/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-qpack.txt"
+        <td><a href="http/no_rtt/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-recovery.html"
+        <td><a href="http/no_rtt/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-recovery.txt"
+        <td><a href="http/no_rtt/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-tls.html"
+        <td><a href="http/no_rtt/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-tls.txt"
+        <td><a href="http/no_rtt/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-transport.html"
+        <td><a href="http/no_rtt/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/unknown_is_no-error/draft-ietf-quic-transport.txt"
+        <td><a href="http/no_rtt/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/no_rtt/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/security_considerations">http/security_considerations</a></h2>
-    <table id="branch-http/security_considerations">
+    <h2>Preview for branch <a href="http/which_connection_close">http/which_connection_close</a></h2>
+    <table id="branch-http/which_connection_close">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/security_considerations/draft-ietf-quic-http.html"
+        <td><a href="http/which_connection_close/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/security_considerations/draft-ietf-quic-http.txt"
+        <td><a href="http/which_connection_close/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/security_considerations/draft-ietf-quic-invariants.html"
+        <td><a href="http/which_connection_close/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/security_considerations/draft-ietf-quic-invariants.txt"
+        <td><a href="http/which_connection_close/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/security_considerations/draft-ietf-quic-qpack.html"
+        <td><a href="http/which_connection_close/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/security_considerations/draft-ietf-quic-qpack.txt"
+        <td><a href="http/which_connection_close/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/security_considerations/draft-ietf-quic-recovery.html"
+        <td><a href="http/which_connection_close/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/security_considerations/draft-ietf-quic-recovery.txt"
+        <td><a href="http/which_connection_close/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/security_considerations/draft-ietf-quic-tls.html"
+        <td><a href="http/which_connection_close/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/security_considerations/draft-ietf-quic-tls.txt"
+        <td><a href="http/which_connection_close/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/security_considerations/draft-ietf-quic-transport.html"
+        <td><a href="http/which_connection_close/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/security_considerations/draft-ietf-quic-transport.txt"
+        <td><a href="http/which_connection_close/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/which_connection_close/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/push_association">http/push_association</a></h2>
-    <table id="branch-http/push_association">
+    <h2>Preview for branch <a href="http/references">http/references</a></h2>
+    <table id="branch-http/references">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/push_association/draft-ietf-quic-http.html"
+        <td><a href="http/references/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/push_association/draft-ietf-quic-http.txt"
+        <td><a href="http/references/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/push_association/draft-ietf-quic-invariants.html"
+        <td><a href="http/references/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/push_association/draft-ietf-quic-invariants.txt"
+        <td><a href="http/references/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/push_association/draft-ietf-quic-qpack.html"
+        <td><a href="http/references/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/push_association/draft-ietf-quic-qpack.txt"
+        <td><a href="http/references/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/push_association/draft-ietf-quic-recovery.html"
+        <td><a href="http/references/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/push_association/draft-ietf-quic-recovery.txt"
+        <td><a href="http/references/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/push_association/draft-ietf-quic-tls.html"
+        <td><a href="http/references/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/push_association/draft-ietf-quic-tls.txt"
+        <td><a href="http/references/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/push_association/draft-ietf-quic-transport.html"
+        <td><a href="http/references/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/push_association/draft-ietf-quic-transport.txt"
+        <td><a href="http/references/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/references/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/auth-reference">http/auth-reference</a></h2>
-    <table id="branch-http/auth-reference">
+    <h2>Preview for branch <a href="http/grease_errors">http/grease_errors</a></h2>
+    <table id="branch-http/grease_errors">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/auth-reference/draft-ietf-quic-http.html"
+        <td><a href="http/grease_errors/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/auth-reference/draft-ietf-quic-http.txt"
+        <td><a href="http/grease_errors/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/auth-reference/draft-ietf-quic-invariants.html"
+        <td><a href="http/grease_errors/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/auth-reference/draft-ietf-quic-invariants.txt"
+        <td><a href="http/grease_errors/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/auth-reference/draft-ietf-quic-qpack.html"
+        <td><a href="http/grease_errors/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/auth-reference/draft-ietf-quic-qpack.txt"
+        <td><a href="http/grease_errors/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/auth-reference/draft-ietf-quic-recovery.html"
+        <td><a href="http/grease_errors/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/auth-reference/draft-ietf-quic-recovery.txt"
+        <td><a href="http/grease_errors/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/auth-reference/draft-ietf-quic-tls.html"
+        <td><a href="http/grease_errors/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/auth-reference/draft-ietf-quic-tls.txt"
+        <td><a href="http/grease_errors/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/auth-reference/draft-ietf-quic-transport.html"
+        <td><a href="http/grease_errors/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/auth-reference/draft-ietf-quic-transport.txt"
+        <td><a href="http/grease_errors/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/auth-reference/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/grease_errors/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/core_and_friends">http/core_and_friends</a></h2>
-    <table id="branch-http/core_and_friends">
+    <h2>Preview for branch <a href="http/push_association">http/push_association</a></h2>
+    <table id="branch-http/push_association">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/core_and_friends/draft-ietf-quic-http.html"
+        <td><a href="http/push_association/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/core_and_friends/draft-ietf-quic-http.txt"
+        <td><a href="http/push_association/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/core_and_friends/draft-ietf-quic-invariants.html"
+        <td><a href="http/push_association/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/core_and_friends/draft-ietf-quic-invariants.txt"
+        <td><a href="http/push_association/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/core_and_friends/draft-ietf-quic-qpack.html"
+        <td><a href="http/push_association/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/core_and_friends/draft-ietf-quic-qpack.txt"
+        <td><a href="http/push_association/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/core_and_friends/draft-ietf-quic-recovery.html"
+        <td><a href="http/push_association/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/core_and_friends/draft-ietf-quic-recovery.txt"
+        <td><a href="http/push_association/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/core_and_friends/draft-ietf-quic-tls.html"
+        <td><a href="http/push_association/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/core_and_friends/draft-ietf-quic-tls.txt"
+        <td><a href="http/push_association/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/core_and_friends/draft-ietf-quic-transport.html"
+        <td><a href="http/push_association/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/core_and_friends/draft-ietf-quic-transport.txt"
+        <td><a href="http/push_association/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/core_and_friends/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/push_association/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/canceled_push">http/canceled_push</a></h2>
-    <table id="branch-http/canceled_push">
+    <h2>Preview for branch <a href="http/sewage_tunnels">http/sewage_tunnels</a></h2>
+    <table id="branch-http/sewage_tunnels">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/canceled_push/draft-ietf-quic-http.html"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/canceled_push/draft-ietf-quic-http.txt"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/canceled_push/draft-ietf-quic-invariants.html"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/canceled_push/draft-ietf-quic-invariants.txt"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/canceled_push/draft-ietf-quic-qpack.html"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/canceled_push/draft-ietf-quic-qpack.txt"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/canceled_push/draft-ietf-quic-recovery.html"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/canceled_push/draft-ietf-quic-recovery.txt"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/canceled_push/draft-ietf-quic-tls.html"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/canceled_push/draft-ietf-quic-tls.txt"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/canceled_push/draft-ietf-quic-transport.html"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/canceled_push/draft-ietf-quic-transport.txt"
+        <td><a href="http/sewage_tunnels/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/sewage_tunnels/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/authority">http/authority</a></h2>
-    <table id="branch-http/authority">
+    <h2>Preview for branch <a href="http/security_considerations">http/security_considerations</a></h2>
+    <table id="branch-http/security_considerations">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/authority/draft-ietf-quic-http.html"
+        <td><a href="http/security_considerations/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/authority/draft-ietf-quic-http.txt"
+        <td><a href="http/security_considerations/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/authority/draft-ietf-quic-invariants.html"
+        <td><a href="http/security_considerations/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/authority/draft-ietf-quic-invariants.txt"
+        <td><a href="http/security_considerations/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/authority/draft-ietf-quic-qpack.html"
+        <td><a href="http/security_considerations/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/authority/draft-ietf-quic-qpack.txt"
+        <td><a href="http/security_considerations/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/authority/draft-ietf-quic-recovery.html"
+        <td><a href="http/security_considerations/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/authority/draft-ietf-quic-recovery.txt"
+        <td><a href="http/security_considerations/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/authority/draft-ietf-quic-tls.html"
+        <td><a href="http/security_considerations/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/authority/draft-ietf-quic-tls.txt"
+        <td><a href="http/security_considerations/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/authority/draft-ietf-quic-transport.html"
+        <td><a href="http/security_considerations/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/authority/draft-ietf-quic-transport.txt"
+        <td><a href="http/security_considerations/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/security_considerations/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="http/should_cancel_push">http/should_cancel_push</a></h2>
-    <table id="branch-http/should_cancel_push">
+    <h2>Preview for branch <a href="http/acknowledgements">http/acknowledgements</a></h2>
+    <table id="branch-http/acknowledgements">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-http.html"
+        <td><a href="http/acknowledgements/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-http.txt"
+        <td><a href="http/acknowledgements/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-invariants.html"
+        <td><a href="http/acknowledgements/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-invariants.txt"
+        <td><a href="http/acknowledgements/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-qpack.html"
+        <td><a href="http/acknowledgements/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-qpack.txt"
+        <td><a href="http/acknowledgements/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-recovery.html"
+        <td><a href="http/acknowledgements/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-recovery.txt"
+        <td><a href="http/acknowledgements/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-tls.html"
+        <td><a href="http/acknowledgements/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-tls.txt"
+        <td><a href="http/acknowledgements/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-transport.html"
+        <td><a href="http/acknowledgements/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="http/should_cancel_push/draft-ietf-quic-transport.txt"
+        <td><a href="http/acknowledgements/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/acknowledgements/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ianswett-onpacketreceived">ianswett-onpacketreceived</a></h2>
-    <table id="branch-ianswett-onpacketreceived">
+    <h2>Preview for branch <a href="http/canceled_push">http/canceled_push</a></h2>
+    <table id="branch-http/canceled_push">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-http.html"
+        <td><a href="http/canceled_push/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-http.txt"
+        <td><a href="http/canceled_push/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-invariants.html"
+        <td><a href="http/canceled_push/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-invariants.txt"
+        <td><a href="http/canceled_push/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-qpack.html"
+        <td><a href="http/canceled_push/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-qpack.txt"
+        <td><a href="http/canceled_push/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-recovery.html"
+        <td><a href="http/canceled_push/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-recovery.txt"
+        <td><a href="http/canceled_push/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-tls.html"
+        <td><a href="http/canceled_push/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-tls.txt"
+        <td><a href="http/canceled_push/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-transport.html"
+        <td><a href="http/canceled_push/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-transport.txt"
+        <td><a href="http/canceled_push/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/canceled_push/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ianswett-include-ack-delay">ianswett-include-ack-delay</a></h2>
-    <table id="branch-ianswett-include-ack-delay">
+    <h2>Preview for branch <a href="http/unknown_is_no-error">http/unknown_is_no-error</a></h2>
+    <table id="branch-http/unknown_is_no-error">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-http.html"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-http.txt"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-invariants.html"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-invariants.txt"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-qpack.html"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-qpack.txt"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-recovery.html"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-recovery.txt"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-tls.html"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-tls.txt"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-transport.html"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-transport.txt"
+        <td><a href="http/unknown_is_no-error/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/unknown_is_no-error/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ianswett-split-pto-pseudocode">ianswett-split-pto-pseudocode</a></h2>
-    <table id="branch-ianswett-split-pto-pseudocode">
+    <h2>Preview for branch <a href="http/blowing_up_hurts">http/blowing_up_hurts</a></h2>
+    <table id="branch-http/blowing_up_hurts">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-http.html"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-http.txt"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-invariants.html"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-invariants.txt"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-qpack.html"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-qpack.txt"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-recovery.html"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-recovery.txt"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-tls.html"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-tls.txt"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-transport.html"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-transport.txt"
+        <td><a href="http/blowing_up_hurts/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/blowing_up_hurts/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="recovery-quoting">recovery-quoting</a></h2>
-    <table id="branch-recovery-quoting">
+    <h2>Preview for branch <a href="http/one_true_reference_format">http/one_true_reference_format</a></h2>
+    <table id="branch-http/one_true_reference_format">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="recovery-quoting/draft-ietf-quic-http.html"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="recovery-quoting/draft-ietf-quic-http.txt"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="recovery-quoting/draft-ietf-quic-invariants.html"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="recovery-quoting/draft-ietf-quic-invariants.txt"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="recovery-quoting/draft-ietf-quic-qpack.html"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="recovery-quoting/draft-ietf-quic-qpack.txt"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="recovery-quoting/draft-ietf-quic-recovery.html"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="recovery-quoting/draft-ietf-quic-recovery.txt"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="recovery-quoting/draft-ietf-quic-tls.html"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="recovery-quoting/draft-ietf-quic-tls.txt"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="recovery-quoting/draft-ietf-quic-transport.html"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="recovery-quoting/draft-ietf-quic-transport.txt"
+        <td><a href="http/one_true_reference_format/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/one_true_reference_format/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="janaiyengar-patch-1">janaiyengar-patch-1</a></h2>
-    <table id="branch-janaiyengar-patch-1">
+    <h2>Preview for branch <a href="http/should_cancel_push">http/should_cancel_push</a></h2>
+    <table id="branch-http/should_cancel_push">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-http.html"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-http.txt"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-invariants.html"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-invariants.txt"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-qpack.html"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-qpack.txt"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-recovery.html"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-recovery.txt"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-tls.html"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-tls.txt"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-transport.html"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="janaiyengar-patch-1/draft-ietf-quic-transport.txt"
+        <td><a href="http/should_cancel_push/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/should_cancel_push/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="alarm-timer">alarm-timer</a></h2>
-    <table id="branch-alarm-timer">
+    <h2>Preview for branch <a href="http/authority">http/authority</a></h2>
+    <table id="branch-http/authority">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="alarm-timer/draft-ietf-quic-http.html"
+        <td><a href="http/authority/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="alarm-timer/draft-ietf-quic-http.txt"
+        <td><a href="http/authority/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="alarm-timer/draft-ietf-quic-invariants.html"
+        <td><a href="http/authority/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="alarm-timer/draft-ietf-quic-invariants.txt"
+        <td><a href="http/authority/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="alarm-timer/draft-ietf-quic-qpack.html"
+        <td><a href="http/authority/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="alarm-timer/draft-ietf-quic-qpack.txt"
+        <td><a href="http/authority/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="alarm-timer/draft-ietf-quic-recovery.html"
+        <td><a href="http/authority/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="alarm-timer/draft-ietf-quic-recovery.txt"
-           class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
-          diff with last submission</a></td>
-      </tr>
-      <tr>
-        <th>draft-ietf-quic-tls</th>
-        <td><a href="alarm-timer/draft-ietf-quic-tls.html"
-           class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="alarm-timer/draft-ietf-quic-tls.txt"
-           class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
-          diff with last submission</a></td>
-      </tr>
-      <tr>
-        <th>draft-ietf-quic-transport</th>
-        <td><a href="alarm-timer/draft-ietf-quic-transport.html"
-           class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="alarm-timer/draft-ietf-quic-transport.txt"
-           class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/alarm-timer/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
-          diff with last submission</a></td>
-      </tr>
-    </table>
-    <h2>Preview for branch <a href="forgeries-and-updates">forgeries-and-updates</a></h2>
-    <table id="branch-forgeries-and-updates">
-      <tr>
-        <th>draft-ietf-quic-http</th>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-http.html"
-           class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-http.txt"
-           class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
-          diff with last submission</a></td>
-      </tr>
-      <tr>
-        <th>draft-ietf-quic-invariants</th>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-invariants.html"
-           class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-invariants.txt"
-           class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
-          diff with last submission</a></td>
-      </tr>
-      <tr>
-        <th>draft-ietf-quic-qpack</th>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-qpack.html"
-           class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-qpack.txt"
-           class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
-          diff with last submission</a></td>
-      </tr>
-      <tr>
-        <th>draft-ietf-quic-recovery</th>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-recovery.html"
-           class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-recovery.txt"
+        <td><a href="http/authority/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-tls.html"
+        <td><a href="http/authority/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-tls.txt"
+        <td><a href="http/authority/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-transport.html"
+        <td><a href="http/authority/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="forgeries-and-updates/draft-ietf-quic-transport.txt"
+        <td><a href="http/authority/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/http/authority/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="lint-args">lint-args</a></h2>
-    <table id="branch-lint-args">
+    <h2>Preview for branch <a href="active-cid-limit-rpt">active-cid-limit-rpt</a></h2>
+    <table id="branch-active-cid-limit-rpt">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="lint-args/draft-ietf-quic-http.html"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="lint-args/draft-ietf-quic-http.txt"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="lint-args/draft-ietf-quic-invariants.html"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="lint-args/draft-ietf-quic-invariants.txt"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="lint-args/draft-ietf-quic-qpack.html"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="lint-args/draft-ietf-quic-qpack.txt"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="lint-args/draft-ietf-quic-recovery.html"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="lint-args/draft-ietf-quic-recovery.txt"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="lint-args/draft-ietf-quic-tls.html"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="lint-args/draft-ietf-quic-tls.txt"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="lint-args/draft-ietf-quic-transport.html"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="lint-args/draft-ietf-quic-transport.txt"
+        <td><a href="active-cid-limit-rpt/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="pacing-dfn">pacing-dfn</a></h2>
-    <table id="branch-pacing-dfn">
+    <h2>Preview for branch <a href="chacha20-sample">chacha20-sample</a></h2>
+    <table id="branch-chacha20-sample">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="pacing-dfn/draft-ietf-quic-http.html"
+        <td><a href="chacha20-sample/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="pacing-dfn/draft-ietf-quic-http.txt"
+        <td><a href="chacha20-sample/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="pacing-dfn/draft-ietf-quic-invariants.html"
+        <td><a href="chacha20-sample/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="pacing-dfn/draft-ietf-quic-invariants.txt"
+        <td><a href="chacha20-sample/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="pacing-dfn/draft-ietf-quic-qpack.html"
+        <td><a href="chacha20-sample/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="pacing-dfn/draft-ietf-quic-qpack.txt"
+        <td><a href="chacha20-sample/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="pacing-dfn/draft-ietf-quic-recovery.html"
+        <td><a href="chacha20-sample/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="pacing-dfn/draft-ietf-quic-recovery.txt"
+        <td><a href="chacha20-sample/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="pacing-dfn/draft-ietf-quic-tls.html"
+        <td><a href="chacha20-sample/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="pacing-dfn/draft-ietf-quic-tls.txt"
+        <td><a href="chacha20-sample/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="pacing-dfn/draft-ietf-quic-transport.html"
+        <td><a href="chacha20-sample/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="pacing-dfn/draft-ietf-quic-transport.txt"
+        <td><a href="chacha20-sample/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
@@ -2178,2638 +2165,2714 @@ <h2>Preview for branch <a href="ianswett-pacing-must">ianswett-pacing-must</a></
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="qpack">qpack</a></h2>
-    <table id="branch-qpack">
-      <tr>
-        <th>*</th>
-        <td><a href="qpack/*.html"
-           class="html *">html</a></td>
-        <td><a href="qpack/*.txt"
-           class="txt *">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/*.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/*.txt" class="diff *">
-          diff with last submission</a></td>
-      </tr>
-    </table>
-    <h2>Preview for branch <a href="qpack/core_terminology">qpack/core_terminology</a></h2>
-    <table id="branch-qpack/core_terminology">
+    <h2>Preview for branch <a href="recovery-quoting">recovery-quoting</a></h2>
+    <table id="branch-recovery-quoting">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-http.html"
+        <td><a href="recovery-quoting/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-http.txt"
+        <td><a href="recovery-quoting/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-invariants.html"
+        <td><a href="recovery-quoting/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-invariants.txt"
+        <td><a href="recovery-quoting/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-qpack.html"
+        <td><a href="recovery-quoting/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-qpack.txt"
+        <td><a href="recovery-quoting/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-recovery.html"
+        <td><a href="recovery-quoting/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-recovery.txt"
+        <td><a href="recovery-quoting/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-tls.html"
+        <td><a href="recovery-quoting/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-tls.txt"
+        <td><a href="recovery-quoting/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-transport.html"
+        <td><a href="recovery-quoting/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack/core_terminology/draft-ietf-quic-transport.txt"
+        <td><a href="recovery-quoting/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/recovery-quoting/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="example-28">example-28</a></h2>
-    <table id="branch-example-28">
+    <h2>Preview for branch <a href="max-udp-pmtud">max-udp-pmtud</a></h2>
+    <table id="branch-max-udp-pmtud">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="example-28/draft-ietf-quic-http.html"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="example-28/draft-ietf-quic-http.txt"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="example-28/draft-ietf-quic-invariants.html"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="example-28/draft-ietf-quic-invariants.txt"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="example-28/draft-ietf-quic-qpack.html"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="example-28/draft-ietf-quic-qpack.txt"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="example-28/draft-ietf-quic-recovery.html"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="example-28/draft-ietf-quic-recovery.txt"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="example-28/draft-ietf-quic-tls.html"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="example-28/draft-ietf-quic-tls.txt"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="example-28/draft-ietf-quic-transport.html"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="example-28/draft-ietf-quic-transport.txt"
+        <td><a href="max-udp-pmtud/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="only-ecn">only-ecn</a></h2>
-    <table id="branch-only-ecn">
+    <h2>Preview for branch <a href="ianswett-split-pto-pseudocode">ianswett-split-pto-pseudocode</a></h2>
+    <table id="branch-ianswett-split-pto-pseudocode">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="only-ecn/draft-ietf-quic-http.html"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="only-ecn/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="only-ecn/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="only-ecn/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="only-ecn/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="only-ecn/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="only-ecn/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="only-ecn/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="only-ecn/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="only-ecn/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="only-ecn/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="only-ecn/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-split-pto-pseudocode/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-split-pto-pseudocode/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="more-semicolon">more-semicolon</a></h2>
-    <table id="branch-more-semicolon">
+    <h2>Preview for branch <a href="ianswett-anti-amplification">ianswett-anti-amplification</a></h2>
+    <table id="branch-ianswett-anti-amplification">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="more-semicolon/draft-ietf-quic-http.html"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="more-semicolon/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="more-semicolon/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="more-semicolon/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="more-semicolon/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="more-semicolon/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="more-semicolon/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="more-semicolon/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="more-semicolon/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="more-semicolon/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="more-semicolon/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="more-semicolon/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-anti-amplification/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="link-preferred-address">link-preferred-address</a></h2>
-    <table id="branch-link-preferred-address">
+    <h2>Preview for branch <a href="authenticate-hs-cid">authenticate-hs-cid</a></h2>
+    <table id="branch-authenticate-hs-cid">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="link-preferred-address/draft-ietf-quic-http.html"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="link-preferred-address/draft-ietf-quic-http.txt"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="link-preferred-address/draft-ietf-quic-invariants.html"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="link-preferred-address/draft-ietf-quic-invariants.txt"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="link-preferred-address/draft-ietf-quic-qpack.html"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="link-preferred-address/draft-ietf-quic-qpack.txt"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="link-preferred-address/draft-ietf-quic-recovery.html"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="link-preferred-address/draft-ietf-quic-recovery.txt"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="link-preferred-address/draft-ietf-quic-tls.html"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="link-preferred-address/draft-ietf-quic-tls.txt"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="link-preferred-address/draft-ietf-quic-transport.html"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="link-preferred-address/draft-ietf-quic-transport.txt"
+        <td><a href="authenticate-hs-cid/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/link-preferred-address/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="invariant-independent">invariant-independent</a></h2>
-    <table id="branch-invariant-independent">
+    <h2>Preview for branch <a href="ianswett-onpacketreceived">ianswett-onpacketreceived</a></h2>
+    <table id="branch-ianswett-onpacketreceived">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="invariant-independent/draft-ietf-quic-http.html"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="invariant-independent/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="invariant-independent/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="invariant-independent/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="invariant-independent/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="invariant-independent/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="invariant-independent/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="invariant-independent/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="invariant-independent/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="invariant-independent/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="invariant-independent/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="invariant-independent/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-onpacketreceived/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-onpacketreceived/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="qpack-table-flip">qpack-table-flip</a></h2>
-    <table id="branch-qpack-table-flip">
+    <h2>Preview for branch <a href="janaiyengar-patch-1">janaiyengar-patch-1</a></h2>
+    <table id="branch-janaiyengar-patch-1">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack-table-flip/draft-ietf-quic-http.html"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack-table-flip/draft-ietf-quic-http.txt"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="qpack-table-flip/draft-ietf-quic-invariants.html"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack-table-flip/draft-ietf-quic-invariants.txt"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="qpack-table-flip/draft-ietf-quic-qpack.html"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack-table-flip/draft-ietf-quic-qpack.txt"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="qpack-table-flip/draft-ietf-quic-recovery.html"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack-table-flip/draft-ietf-quic-recovery.txt"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="qpack-table-flip/draft-ietf-quic-tls.html"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack-table-flip/draft-ietf-quic-tls.txt"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="qpack-table-flip/draft-ietf-quic-transport.html"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack-table-flip/draft-ietf-quic-transport.txt"
+        <td><a href="janaiyengar-patch-1/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
-          diff with last submission</a></td>
-      </tr>
-    </table>
-    <h2>Preview for branch <a href="jri">jri</a></h2>
-    <table id="branch-jri">
-      <tr>
-        <th>*</th>
-        <td><a href="jri/*.html"
-           class="html *">html</a></td>
-        <td><a href="jri/*.txt"
-           class="txt *">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/*.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/*.txt" class="diff *">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/janaiyengar-patch-1/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="jri/sec3.1">jri/sec3.1</a></h2>
-    <table id="branch-jri/sec3.1">
+    <h2>Preview for branch <a href="more-semicolon">more-semicolon</a></h2>
+    <table id="branch-more-semicolon">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="jri/sec3.1/draft-ietf-quic-http.html"
+        <td><a href="more-semicolon/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="jri/sec3.1/draft-ietf-quic-http.txt"
+        <td><a href="more-semicolon/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="jri/sec3.1/draft-ietf-quic-invariants.html"
+        <td><a href="more-semicolon/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="jri/sec3.1/draft-ietf-quic-invariants.txt"
+        <td><a href="more-semicolon/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="jri/sec3.1/draft-ietf-quic-qpack.html"
+        <td><a href="more-semicolon/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="jri/sec3.1/draft-ietf-quic-qpack.txt"
+        <td><a href="more-semicolon/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="jri/sec3.1/draft-ietf-quic-recovery.html"
+        <td><a href="more-semicolon/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="jri/sec3.1/draft-ietf-quic-recovery.txt"
+        <td><a href="more-semicolon/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="jri/sec3.1/draft-ietf-quic-tls.html"
+        <td><a href="more-semicolon/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="jri/sec3.1/draft-ietf-quic-tls.txt"
+        <td><a href="more-semicolon/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="jri/sec3.1/draft-ietf-quic-transport.html"
+        <td><a href="more-semicolon/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="jri/sec3.1/draft-ietf-quic-transport.txt"
+        <td><a href="more-semicolon/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/more-semicolon/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="jri/ackf">jri/ackf</a></h2>
-    <table id="branch-jri/ackf">
+    <h2>Preview for branch <a href="qpack-backtick">qpack-backtick</a></h2>
+    <table id="branch-qpack-backtick">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="jri/ackf/draft-ietf-quic-http.html"
+        <td><a href="qpack-backtick/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="jri/ackf/draft-ietf-quic-http.txt"
+        <td><a href="qpack-backtick/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="jri/ackf/draft-ietf-quic-invariants.html"
+        <td><a href="qpack-backtick/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="jri/ackf/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack-backtick/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="jri/ackf/draft-ietf-quic-qpack.html"
+        <td><a href="qpack-backtick/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="jri/ackf/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack-backtick/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="jri/ackf/draft-ietf-quic-recovery.html"
+        <td><a href="qpack-backtick/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="jri/ackf/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack-backtick/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="jri/ackf/draft-ietf-quic-tls.html"
+        <td><a href="qpack-backtick/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="jri/ackf/draft-ietf-quic-tls.txt"
+        <td><a href="qpack-backtick/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="jri/ackf/draft-ietf-quic-transport.html"
+        <td><a href="qpack-backtick/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="jri/ackf/draft-ietf-quic-transport.txt"
+        <td><a href="qpack-backtick/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-backtick/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="jri/fix-n">jri/fix-n</a></h2>
-    <table id="branch-jri/fix-n">
+    <h2>Preview for branch <a href="pacing-dfn">pacing-dfn</a></h2>
+    <table id="branch-pacing-dfn">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="jri/fix-n/draft-ietf-quic-http.html"
+        <td><a href="pacing-dfn/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="jri/fix-n/draft-ietf-quic-http.txt"
+        <td><a href="pacing-dfn/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="jri/fix-n/draft-ietf-quic-invariants.html"
+        <td><a href="pacing-dfn/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="jri/fix-n/draft-ietf-quic-invariants.txt"
+        <td><a href="pacing-dfn/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="jri/fix-n/draft-ietf-quic-qpack.html"
+        <td><a href="pacing-dfn/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="jri/fix-n/draft-ietf-quic-qpack.txt"
+        <td><a href="pacing-dfn/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="jri/fix-n/draft-ietf-quic-recovery.html"
+        <td><a href="pacing-dfn/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="jri/fix-n/draft-ietf-quic-recovery.txt"
+        <td><a href="pacing-dfn/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="jri/fix-n/draft-ietf-quic-tls.html"
+        <td><a href="pacing-dfn/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="jri/fix-n/draft-ietf-quic-tls.txt"
+        <td><a href="pacing-dfn/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="jri/fix-n/draft-ietf-quic-transport.html"
+        <td><a href="pacing-dfn/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="jri/fix-n/draft-ietf-quic-transport.txt"
+        <td><a href="pacing-dfn/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/pacing-dfn/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="vn-consistency">vn-consistency</a></h2>
-    <table id="branch-vn-consistency">
+    <h2>Preview for branch <a href="period-rttvar">period-rttvar</a></h2>
+    <table id="branch-period-rttvar">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="vn-consistency/draft-ietf-quic-http.html"
+        <td><a href="period-rttvar/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="vn-consistency/draft-ietf-quic-http.txt"
+        <td><a href="period-rttvar/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="vn-consistency/draft-ietf-quic-invariants.html"
+        <td><a href="period-rttvar/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="vn-consistency/draft-ietf-quic-invariants.txt"
+        <td><a href="period-rttvar/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="vn-consistency/draft-ietf-quic-qpack.html"
+        <td><a href="period-rttvar/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="vn-consistency/draft-ietf-quic-qpack.txt"
+        <td><a href="period-rttvar/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="vn-consistency/draft-ietf-quic-recovery.html"
+        <td><a href="period-rttvar/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="vn-consistency/draft-ietf-quic-recovery.txt"
+        <td><a href="period-rttvar/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="vn-consistency/draft-ietf-quic-tls.html"
+        <td><a href="period-rttvar/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="vn-consistency/draft-ietf-quic-tls.txt"
+        <td><a href="period-rttvar/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="vn-consistency/draft-ietf-quic-transport.html"
+        <td><a href="period-rttvar/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="vn-consistency/draft-ietf-quic-transport.txt"
+        <td><a href="period-rttvar/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="tls-compat-mode">tls-compat-mode</a></h2>
-    <table id="branch-tls-compat-mode">
+    <h2>Preview for branch <a href="ianswett-stateless-reset-nits">ianswett-stateless-reset-nits</a></h2>
+    <table id="branch-ianswett-stateless-reset-nits">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="tls-compat-mode/draft-ietf-quic-http.html"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="tls-compat-mode/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="tls-compat-mode/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="tls-compat-mode/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="tls-compat-mode/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="tls-compat-mode/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="tls-compat-mode/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="tls-compat-mode/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="tls-compat-mode/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="tls-compat-mode/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="tls-compat-mode/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="tls-compat-mode/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/tls-compat-mode/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="dedupe-packets">dedupe-packets</a></h2>
-    <table id="branch-dedupe-packets">
+    <h2>Preview for branch <a href="only-transport-close">only-transport-close</a></h2>
+    <table id="branch-only-transport-close">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="dedupe-packets/draft-ietf-quic-http.html"
+        <td><a href="only-transport-close/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="dedupe-packets/draft-ietf-quic-http.txt"
+        <td><a href="only-transport-close/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="dedupe-packets/draft-ietf-quic-invariants.html"
+        <td><a href="only-transport-close/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="dedupe-packets/draft-ietf-quic-invariants.txt"
+        <td><a href="only-transport-close/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="dedupe-packets/draft-ietf-quic-qpack.html"
+        <td><a href="only-transport-close/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="dedupe-packets/draft-ietf-quic-qpack.txt"
+        <td><a href="only-transport-close/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="dedupe-packets/draft-ietf-quic-recovery.html"
+        <td><a href="only-transport-close/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="dedupe-packets/draft-ietf-quic-recovery.txt"
+        <td><a href="only-transport-close/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="dedupe-packets/draft-ietf-quic-tls.html"
+        <td><a href="only-transport-close/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="dedupe-packets/draft-ietf-quic-tls.txt"
+        <td><a href="only-transport-close/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="dedupe-packets/draft-ietf-quic-transport.html"
+        <td><a href="only-transport-close/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="dedupe-packets/draft-ietf-quic-transport.txt"
+        <td><a href="only-transport-close/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/dedupe-packets/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="changelog-28">changelog-28</a></h2>
-    <table id="branch-changelog-28">
+    <h2>Preview for branch <a href="qpack-pseudocode">qpack-pseudocode</a></h2>
+    <table id="branch-qpack-pseudocode">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="changelog-28/draft-ietf-quic-http.html"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="changelog-28/draft-ietf-quic-http.txt"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="changelog-28/draft-ietf-quic-invariants.html"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="changelog-28/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="changelog-28/draft-ietf-quic-qpack.html"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="changelog-28/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="changelog-28/draft-ietf-quic-recovery.html"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="changelog-28/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="changelog-28/draft-ietf-quic-tls.html"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="changelog-28/draft-ietf-quic-tls.txt"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="changelog-28/draft-ietf-quic-transport.html"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="changelog-28/draft-ietf-quic-transport.txt"
+        <td><a href="qpack-pseudocode/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="3691-prose">3691-prose</a></h2>
-    <table id="branch-3691-prose">
+    <h2>Preview for branch <a href="ianswett-min-cwnd">ianswett-min-cwnd</a></h2>
+    <table id="branch-ianswett-min-cwnd">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="3691-prose/draft-ietf-quic-http.html"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="3691-prose/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="3691-prose/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="3691-prose/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="3691-prose/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="3691-prose/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="3691-prose/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="3691-prose/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="3691-prose/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="3691-prose/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="3691-prose/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="3691-prose/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-min-cwnd/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ianswett-pto-loss-reorg">ianswett-pto-loss-reorg</a></h2>
-    <table id="branch-ianswett-pto-loss-reorg">
+    <h2>Preview for branch <a href="ianswett-include-ack-delay">ianswett-include-ack-delay</a></h2>
+    <table id="branch-ianswett-include-ack-delay">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-http.html"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-include-ack-delay/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-include-ack-delay/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="forgery-limit">forgery-limit</a></h2>
-    <table id="branch-forgery-limit">
+    <h2>Preview for branch <a href="invariant-independent">invariant-independent</a></h2>
+    <table id="branch-invariant-independent">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="forgery-limit/draft-ietf-quic-http.html"
+        <td><a href="invariant-independent/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="forgery-limit/draft-ietf-quic-http.txt"
+        <td><a href="invariant-independent/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="forgery-limit/draft-ietf-quic-invariants.html"
+        <td><a href="invariant-independent/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="forgery-limit/draft-ietf-quic-invariants.txt"
+        <td><a href="invariant-independent/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="forgery-limit/draft-ietf-quic-qpack.html"
+        <td><a href="invariant-independent/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="forgery-limit/draft-ietf-quic-qpack.txt"
+        <td><a href="invariant-independent/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="forgery-limit/draft-ietf-quic-recovery.html"
+        <td><a href="invariant-independent/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="forgery-limit/draft-ietf-quic-recovery.txt"
+        <td><a href="invariant-independent/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="forgery-limit/draft-ietf-quic-tls.html"
+        <td><a href="invariant-independent/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="forgery-limit/draft-ietf-quic-tls.txt"
+        <td><a href="invariant-independent/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="forgery-limit/draft-ietf-quic-transport.html"
+        <td><a href="invariant-independent/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="forgery-limit/draft-ietf-quic-transport.txt"
+        <td><a href="invariant-independent/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/invariant-independent/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="chacha20-sample">chacha20-sample</a></h2>
-    <table id="branch-chacha20-sample">
+    <h2>Preview for branch <a href="qpack">qpack</a></h2>
+    <table id="branch-qpack">
+      <tr>
+        <th>*</th>
+        <td><a href="qpack/*.html"
+           class="html *">html</a></td>
+        <td><a href="qpack/*.txt"
+           class="txt *">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/*.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/*.txt" class="diff *">
+          diff with last submission</a></td>
+      </tr>
+    </table>
+    <h2>Preview for branch <a href="qpack/core_terminology">qpack/core_terminology</a></h2>
+    <table id="branch-qpack/core_terminology">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="chacha20-sample/draft-ietf-quic-http.html"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="chacha20-sample/draft-ietf-quic-http.txt"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="chacha20-sample/draft-ietf-quic-invariants.html"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="chacha20-sample/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="chacha20-sample/draft-ietf-quic-qpack.html"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="chacha20-sample/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="chacha20-sample/draft-ietf-quic-recovery.html"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="chacha20-sample/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="chacha20-sample/draft-ietf-quic-tls.html"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="chacha20-sample/draft-ietf-quic-tls.txt"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="chacha20-sample/draft-ietf-quic-transport.html"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="chacha20-sample/draft-ietf-quic-transport.txt"
+        <td><a href="qpack/core_terminology/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/chacha20-sample/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack/core_terminology/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="qpack-thanks">qpack-thanks</a></h2>
-    <table id="branch-qpack-thanks">
+    <h2>Preview for branch <a href="jri">jri</a></h2>
+    <table id="branch-jri">
+      <tr>
+        <th>*</th>
+        <td><a href="jri/*.html"
+           class="html *">html</a></td>
+        <td><a href="jri/*.txt"
+           class="txt *">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/*.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/*.txt" class="diff *">
+          diff with last submission</a></td>
+      </tr>
+    </table>
+    <h2>Preview for branch <a href="jri/mustnot">jri/mustnot</a></h2>
+    <table id="branch-jri/mustnot">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack-thanks/draft-ietf-quic-http.html"
+        <td><a href="jri/mustnot/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack-thanks/draft-ietf-quic-http.txt"
+        <td><a href="jri/mustnot/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="qpack-thanks/draft-ietf-quic-invariants.html"
+        <td><a href="jri/mustnot/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack-thanks/draft-ietf-quic-invariants.txt"
+        <td><a href="jri/mustnot/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="qpack-thanks/draft-ietf-quic-qpack.html"
+        <td><a href="jri/mustnot/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack-thanks/draft-ietf-quic-qpack.txt"
+        <td><a href="jri/mustnot/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="qpack-thanks/draft-ietf-quic-recovery.html"
+        <td><a href="jri/mustnot/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack-thanks/draft-ietf-quic-recovery.txt"
+        <td><a href="jri/mustnot/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="qpack-thanks/draft-ietf-quic-tls.html"
+        <td><a href="jri/mustnot/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack-thanks/draft-ietf-quic-tls.txt"
+        <td><a href="jri/mustnot/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="qpack-thanks/draft-ietf-quic-transport.html"
+        <td><a href="jri/mustnot/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack-thanks/draft-ietf-quic-transport.txt"
+        <td><a href="jri/mustnot/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ianswett-min-cwnd">ianswett-min-cwnd</a></h2>
-    <table id="branch-ianswett-min-cwnd">
+    <h2>Preview for branch <a href="jri/sec3.1">jri/sec3.1</a></h2>
+    <table id="branch-jri/sec3.1">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-http.html"
+        <td><a href="jri/sec3.1/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-http.txt"
+        <td><a href="jri/sec3.1/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-invariants.html"
+        <td><a href="jri/sec3.1/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-invariants.txt"
+        <td><a href="jri/sec3.1/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-qpack.html"
+        <td><a href="jri/sec3.1/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-qpack.txt"
+        <td><a href="jri/sec3.1/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-recovery.html"
+        <td><a href="jri/sec3.1/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-recovery.txt"
+        <td><a href="jri/sec3.1/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-tls.html"
+        <td><a href="jri/sec3.1/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-tls.txt"
+        <td><a href="jri/sec3.1/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-transport.html"
+        <td><a href="jri/sec3.1/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-min-cwnd/draft-ietf-quic-transport.txt"
+        <td><a href="jri/sec3.1/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-min-cwnd/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/sec3.1/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="section-ref-titlecase">section-ref-titlecase</a></h2>
-    <table id="branch-section-ref-titlecase">
+    <h2>Preview for branch <a href="jri/fix-n">jri/fix-n</a></h2>
+    <table id="branch-jri/fix-n">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-http.html"
+        <td><a href="jri/fix-n/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-http.txt"
+        <td><a href="jri/fix-n/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-invariants.html"
+        <td><a href="jri/fix-n/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-invariants.txt"
+        <td><a href="jri/fix-n/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-qpack.html"
+        <td><a href="jri/fix-n/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-qpack.txt"
+        <td><a href="jri/fix-n/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-recovery.html"
+        <td><a href="jri/fix-n/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-recovery.txt"
+        <td><a href="jri/fix-n/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-tls.html"
+        <td><a href="jri/fix-n/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-tls.txt"
+        <td><a href="jri/fix-n/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-transport.html"
+        <td><a href="jri/fix-n/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="section-ref-titlecase/draft-ietf-quic-transport.txt"
+        <td><a href="jri/fix-n/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/section-ref-titlecase/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/fix-n/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ianswett-anti-amplification">ianswett-anti-amplification</a></h2>
-    <table id="branch-ianswett-anti-amplification">
+    <h2>Preview for branch <a href="jri/ackf">jri/ackf</a></h2>
+    <table id="branch-jri/ackf">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-http.html"
+        <td><a href="jri/ackf/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-http.txt"
+        <td><a href="jri/ackf/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-invariants.html"
+        <td><a href="jri/ackf/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-invariants.txt"
+        <td><a href="jri/ackf/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-qpack.html"
+        <td><a href="jri/ackf/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-qpack.txt"
+        <td><a href="jri/ackf/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-recovery.html"
+        <td><a href="jri/ackf/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-recovery.txt"
+        <td><a href="jri/ackf/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-tls.html"
+        <td><a href="jri/ackf/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-tls.txt"
+        <td><a href="jri/ackf/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-transport.html"
+        <td><a href="jri/ackf/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-anti-amplification/draft-ietf-quic-transport.txt"
+        <td><a href="jri/ackf/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-anti-amplification/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/ackf/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="varint-fmt-example">varint-fmt-example</a></h2>
-    <table id="branch-varint-fmt-example">
+    <h2>Preview for branch <a href="forgery-limit">forgery-limit</a></h2>
+    <table id="branch-forgery-limit">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="varint-fmt-example/draft-ietf-quic-http.html"
+        <td><a href="forgery-limit/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="varint-fmt-example/draft-ietf-quic-http.txt"
+        <td><a href="forgery-limit/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="varint-fmt-example/draft-ietf-quic-invariants.html"
+        <td><a href="forgery-limit/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="varint-fmt-example/draft-ietf-quic-invariants.txt"
+        <td><a href="forgery-limit/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="varint-fmt-example/draft-ietf-quic-qpack.html"
+        <td><a href="forgery-limit/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="varint-fmt-example/draft-ietf-quic-qpack.txt"
+        <td><a href="forgery-limit/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="varint-fmt-example/draft-ietf-quic-recovery.html"
+        <td><a href="forgery-limit/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="varint-fmt-example/draft-ietf-quic-recovery.txt"
+        <td><a href="forgery-limit/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="varint-fmt-example/draft-ietf-quic-tls.html"
+        <td><a href="forgery-limit/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="varint-fmt-example/draft-ietf-quic-tls.txt"
+        <td><a href="forgery-limit/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="varint-fmt-example/draft-ietf-quic-transport.html"
+        <td><a href="forgery-limit/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="varint-fmt-example/draft-ietf-quic-transport.txt"
+        <td><a href="forgery-limit/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/varint-fmt-example/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/forgery-limit/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="transport">transport</a></h2>
-    <table id="branch-transport">
+    <h2>Preview for branch <a href="captions">captions</a></h2>
+    <table id="branch-captions">
       <tr>
-        <th>*</th>
-        <td><a href="transport/*.html"
-           class="html *">html</a></td>
-        <td><a href="transport/*.txt"
-           class="txt *">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/*.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/*.txt" class="diff *">
+        <th>draft-ietf-quic-http</th>
+        <td><a href="captions/draft-ietf-quic-http.html"
+           class="html draft-ietf-quic-http">html</a></td>
+        <td><a href="captions/draft-ietf-quic-http.txt"
+           class="txt draft-ietf-quic-http">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-invariants</th>
+        <td><a href="captions/draft-ietf-quic-invariants.html"
+           class="html draft-ietf-quic-invariants">html</a></td>
+        <td><a href="captions/draft-ietf-quic-invariants.txt"
+           class="txt draft-ietf-quic-invariants">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-qpack</th>
+        <td><a href="captions/draft-ietf-quic-qpack.html"
+           class="html draft-ietf-quic-qpack">html</a></td>
+        <td><a href="captions/draft-ietf-quic-qpack.txt"
+           class="txt draft-ietf-quic-qpack">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-recovery</th>
+        <td><a href="captions/draft-ietf-quic-recovery.html"
+           class="html draft-ietf-quic-recovery">html</a></td>
+        <td><a href="captions/draft-ietf-quic-recovery.txt"
+           class="txt draft-ietf-quic-recovery">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-tls</th>
+        <td><a href="captions/draft-ietf-quic-tls.html"
+           class="html draft-ietf-quic-tls">html</a></td>
+        <td><a href="captions/draft-ietf-quic-tls.txt"
+           class="txt draft-ietf-quic-tls">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-transport</th>
+        <td><a href="captions/draft-ietf-quic-transport.html"
+           class="html draft-ietf-quic-transport">html</a></td>
+        <td><a href="captions/draft-ietf-quic-transport.txt"
+           class="txt draft-ietf-quic-transport">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="transport/handshake-tokens">transport/handshake-tokens</a></h2>
-    <table id="branch-transport/handshake-tokens">
+    <h2>Preview for branch <a href="example-28">example-28</a></h2>
+    <table id="branch-example-28">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-http.html"
+        <td><a href="example-28/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-http.txt"
+        <td><a href="example-28/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-invariants.html"
+        <td><a href="example-28/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-invariants.txt"
+        <td><a href="example-28/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-qpack.html"
+        <td><a href="example-28/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-qpack.txt"
+        <td><a href="example-28/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-recovery.html"
+        <td><a href="example-28/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-recovery.txt"
+        <td><a href="example-28/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-tls.html"
+        <td><a href="example-28/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-tls.txt"
+        <td><a href="example-28/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-transport.html"
+        <td><a href="example-28/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/handshake-tokens/draft-ietf-quic-transport.txt"
+        <td><a href="example-28/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/example-28/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="transport/contributor_bullets">transport/contributor_bullets</a></h2>
-    <table id="branch-transport/contributor_bullets">
+    <h2>Preview for branch <a href="vn-consistency">vn-consistency</a></h2>
+    <table id="branch-vn-consistency">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-http.html"
+        <td><a href="vn-consistency/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-http.txt"
+        <td><a href="vn-consistency/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-invariants.html"
+        <td><a href="vn-consistency/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-invariants.txt"
+        <td><a href="vn-consistency/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-qpack.html"
+        <td><a href="vn-consistency/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-qpack.txt"
+        <td><a href="vn-consistency/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-recovery.html"
+        <td><a href="vn-consistency/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-recovery.txt"
+        <td><a href="vn-consistency/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-tls.html"
+        <td><a href="vn-consistency/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-tls.txt"
+        <td><a href="vn-consistency/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-transport.html"
+        <td><a href="vn-consistency/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/contributor_bullets/draft-ietf-quic-transport.txt"
+        <td><a href="vn-consistency/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/vn-consistency/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="transport/scope_disable">transport/scope_disable</a></h2>
-    <table id="branch-transport/scope_disable">
+    <h2>Preview for branch <a href="revert-3694-kazuho">revert-3694-kazuho</a></h2>
+    <table id="branch-revert-3694-kazuho">
+      <tr>
+        <th>*</th>
+        <td><a href="revert-3694-kazuho/*.html"
+           class="html *">html</a></td>
+        <td><a href="revert-3694-kazuho/*.txt"
+           class="txt *">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/*.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/*.txt" class="diff *">
+          diff with last submission</a></td>
+      </tr>
+    </table>
+    <h2>Preview for branch <a href="revert-3694-kazuho/connection-refused-error">revert-3694-kazuho/connection-refused-error</a></h2>
+    <table id="branch-revert-3694-kazuho/connection-refused-error">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/scope_disable/draft-ietf-quic-http.html"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/scope_disable/draft-ietf-quic-http.txt"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="transport/scope_disable/draft-ietf-quic-invariants.html"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/scope_disable/draft-ietf-quic-invariants.txt"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="transport/scope_disable/draft-ietf-quic-qpack.html"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/scope_disable/draft-ietf-quic-qpack.txt"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="transport/scope_disable/draft-ietf-quic-recovery.html"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/scope_disable/draft-ietf-quic-recovery.txt"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="transport/scope_disable/draft-ietf-quic-tls.html"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/scope_disable/draft-ietf-quic-tls.txt"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="transport/scope_disable/draft-ietf-quic-transport.html"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/scope_disable/draft-ietf-quic-transport.txt"
+        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="transport/another-one">transport/another-one</a></h2>
-    <table id="branch-transport/another-one">
+    <h2>Preview for branch <a href="transport">transport</a></h2>
+    <table id="branch-transport">
+      <tr>
+        <th>*</th>
+        <td><a href="transport/*.html"
+           class="html *">html</a></td>
+        <td><a href="transport/*.txt"
+           class="txt *">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/*.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/*.txt" class="diff *">
+          diff with last submission</a></td>
+      </tr>
+    </table>
+    <h2>Preview for branch <a href="transport/contributor_bullets">transport/contributor_bullets</a></h2>
+    <table id="branch-transport/contributor_bullets">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="transport/another-one/draft-ietf-quic-http.html"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="transport/another-one/draft-ietf-quic-http.txt"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="transport/another-one/draft-ietf-quic-invariants.html"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="transport/another-one/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="transport/another-one/draft-ietf-quic-qpack.html"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="transport/another-one/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="transport/another-one/draft-ietf-quic-recovery.html"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="transport/another-one/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="transport/another-one/draft-ietf-quic-tls.html"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="transport/another-one/draft-ietf-quic-tls.txt"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="transport/another-one/draft-ietf-quic-transport.html"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="transport/another-one/draft-ietf-quic-transport.txt"
+        <td><a href="transport/contributor_bullets/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/contributor_bullets/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="qpack-security">qpack-security</a></h2>
-    <table id="branch-qpack-security">
+    <h2>Preview for branch <a href="transport/handshake-tokens">transport/handshake-tokens</a></h2>
+    <table id="branch-transport/handshake-tokens">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack-security/draft-ietf-quic-http.html"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack-security/draft-ietf-quic-http.txt"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="qpack-security/draft-ietf-quic-invariants.html"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack-security/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="qpack-security/draft-ietf-quic-qpack.html"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack-security/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="qpack-security/draft-ietf-quic-recovery.html"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack-security/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="qpack-security/draft-ietf-quic-tls.html"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack-security/draft-ietf-quic-tls.txt"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="qpack-security/draft-ietf-quic-transport.html"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack-security/draft-ietf-quic-transport.txt"
+        <td><a href="transport/handshake-tokens/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-security/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/handshake-tokens/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="bounded-rcid">bounded-rcid</a></h2>
-    <table id="branch-bounded-rcid">
+    <h2>Preview for branch <a href="transport/another-one">transport/another-one</a></h2>
+    <table id="branch-transport/another-one">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="bounded-rcid/draft-ietf-quic-http.html"
+        <td><a href="transport/another-one/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="bounded-rcid/draft-ietf-quic-http.txt"
+        <td><a href="transport/another-one/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="bounded-rcid/draft-ietf-quic-invariants.html"
+        <td><a href="transport/another-one/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="bounded-rcid/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/another-one/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="bounded-rcid/draft-ietf-quic-qpack.html"
+        <td><a href="transport/another-one/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="bounded-rcid/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/another-one/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="bounded-rcid/draft-ietf-quic-recovery.html"
+        <td><a href="transport/another-one/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="bounded-rcid/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/another-one/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="bounded-rcid/draft-ietf-quic-tls.html"
+        <td><a href="transport/another-one/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="bounded-rcid/draft-ietf-quic-tls.txt"
+        <td><a href="transport/another-one/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="bounded-rcid/draft-ietf-quic-transport.html"
+        <td><a href="transport/another-one/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="bounded-rcid/draft-ietf-quic-transport.txt"
+        <td><a href="transport/another-one/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/bounded-rcid/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
-          diff with last submission</a></td>
-      </tr>
-    </table>
-    <h2>Preview for branch <a href="revert-3694-kazuho">revert-3694-kazuho</a></h2>
-    <table id="branch-revert-3694-kazuho">
-      <tr>
-        <th>*</th>
-        <td><a href="revert-3694-kazuho/*.html"
-           class="html *">html</a></td>
-        <td><a href="revert-3694-kazuho/*.txt"
-           class="txt *">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/*.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/*.txt" class="diff *">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/another-one/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="revert-3694-kazuho/connection-refused-error">revert-3694-kazuho/connection-refused-error</a></h2>
-    <table id="branch-revert-3694-kazuho/connection-refused-error">
+    <h2>Preview for branch <a href="transport/scope_disable">transport/scope_disable</a></h2>
+    <table id="branch-transport/scope_disable">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-http.html"
+        <td><a href="transport/scope_disable/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-http.txt"
+        <td><a href="transport/scope_disable/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-invariants.html"
+        <td><a href="transport/scope_disable/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-invariants.txt"
+        <td><a href="transport/scope_disable/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-qpack.html"
+        <td><a href="transport/scope_disable/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-qpack.txt"
+        <td><a href="transport/scope_disable/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-recovery.html"
+        <td><a href="transport/scope_disable/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-recovery.txt"
+        <td><a href="transport/scope_disable/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-tls.html"
+        <td><a href="transport/scope_disable/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-tls.txt"
+        <td><a href="transport/scope_disable/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-transport.html"
+        <td><a href="transport/scope_disable/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="revert-3694-kazuho/connection-refused-error/draft-ietf-quic-transport.txt"
+        <td><a href="transport/scope_disable/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/revert-3694-kazuho/connection-refused-error/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/transport/scope_disable/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="authenticate-hs-cid">authenticate-hs-cid</a></h2>
-    <table id="branch-authenticate-hs-cid">
+    <h2>Preview for branch <a href="forgeries-and-updates">forgeries-and-updates</a></h2>
+    <table id="branch-forgeries-and-updates">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-http.html"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-http.txt"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-invariants.html"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-invariants.txt"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-qpack.html"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-qpack.txt"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-recovery.html"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-recovery.txt"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-tls.html"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-tls.txt"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-transport.html"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="authenticate-hs-cid/draft-ietf-quic-transport.txt"
+        <td><a href="forgeries-and-updates/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/authenticate-hs-cid/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/forgeries-and-updates/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="active-cid-limit-rpt">active-cid-limit-rpt</a></h2>
-    <table id="branch-active-cid-limit-rpt">
+    <h2>Preview for branch <a href="qpack-table-flip">qpack-table-flip</a></h2>
+    <table id="branch-qpack-table-flip">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-http.html"
+        <td><a href="qpack-table-flip/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-http.txt"
+        <td><a href="qpack-table-flip/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-invariants.html"
+        <td><a href="qpack-table-flip/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack-table-flip/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-qpack.html"
+        <td><a href="qpack-table-flip/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack-table-flip/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-recovery.html"
+        <td><a href="qpack-table-flip/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack-table-flip/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-tls.html"
+        <td><a href="qpack-table-flip/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-tls.txt"
+        <td><a href="qpack-table-flip/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-transport.html"
+        <td><a href="qpack-table-flip/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="active-cid-limit-rpt/draft-ietf-quic-transport.txt"
+        <td><a href="qpack-table-flip/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/active-cid-limit-rpt/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-table-flip/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="samples-29">samples-29</a></h2>
-    <table id="branch-samples-29">
+    <h2>Preview for branch <a href="invariants">invariants</a></h2>
+    <table id="branch-invariants">
+      <tr>
+        <th>*</th>
+        <td><a href="invariants/*.html"
+           class="html *">html</a></td>
+        <td><a href="invariants/*.txt"
+           class="txt *">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/*.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/*.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/*.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/*.txt" class="diff *">
+          diff with last submission</a></td>
+      </tr>
+    </table>
+    <h2>Preview for branch <a href="invariants/consistency">invariants/consistency</a></h2>
+    <table id="branch-invariants/consistency">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="samples-29/draft-ietf-quic-http.html"
+        <td><a href="invariants/consistency/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="samples-29/draft-ietf-quic-http.txt"
+        <td><a href="invariants/consistency/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="samples-29/draft-ietf-quic-invariants.html"
+        <td><a href="invariants/consistency/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="samples-29/draft-ietf-quic-invariants.txt"
+        <td><a href="invariants/consistency/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="samples-29/draft-ietf-quic-qpack.html"
+        <td><a href="invariants/consistency/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="samples-29/draft-ietf-quic-qpack.txt"
+        <td><a href="invariants/consistency/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="samples-29/draft-ietf-quic-recovery.html"
+        <td><a href="invariants/consistency/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="samples-29/draft-ietf-quic-recovery.txt"
+        <td><a href="invariants/consistency/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="samples-29/draft-ietf-quic-tls.html"
+        <td><a href="invariants/consistency/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="samples-29/draft-ietf-quic-tls.txt"
+        <td><a href="invariants/consistency/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="samples-29/draft-ietf-quic-transport.html"
+        <td><a href="invariants/consistency/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="samples-29/draft-ietf-quic-transport.txt"
+        <td><a href="invariants/consistency/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/invariants/consistency/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ianswett-recompute-pto">ianswett-recompute-pto</a></h2>
-    <table id="branch-ianswett-recompute-pto">
+    <h2>Preview for branch <a href="lint-args">lint-args</a></h2>
+    <table id="branch-lint-args">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-http.html"
+        <td><a href="lint-args/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-http.txt"
+        <td><a href="lint-args/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-invariants.html"
+        <td><a href="lint-args/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-invariants.txt"
+        <td><a href="lint-args/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-qpack.html"
+        <td><a href="lint-args/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-qpack.txt"
+        <td><a href="lint-args/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-recovery.html"
+        <td><a href="lint-args/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-recovery.txt"
+        <td><a href="lint-args/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-tls.html"
+        <td><a href="lint-args/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-tls.txt"
+        <td><a href="lint-args/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-transport.html"
+        <td><a href="lint-args/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-recompute-pto/draft-ietf-quic-transport.txt"
+        <td><a href="lint-args/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-recompute-pto/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/lint-args/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ianswett-stateless-reset-nits">ianswett-stateless-reset-nits</a></h2>
-    <table id="branch-ianswett-stateless-reset-nits">
+    <h2>Preview for branch <a href="qpack-thanks">qpack-thanks</a></h2>
+    <table id="branch-qpack-thanks">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-http.html"
+        <td><a href="qpack-thanks/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-http.txt"
+        <td><a href="qpack-thanks/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-invariants.html"
+        <td><a href="qpack-thanks/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-invariants.txt"
+        <td><a href="qpack-thanks/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-qpack.html"
+        <td><a href="qpack-thanks/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-qpack.txt"
+        <td><a href="qpack-thanks/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-recovery.html"
+        <td><a href="qpack-thanks/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-recovery.txt"
+        <td><a href="qpack-thanks/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-tls.html"
+        <td><a href="qpack-thanks/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-tls.txt"
+        <td><a href="qpack-thanks/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-transport.html"
+        <td><a href="qpack-thanks/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="ianswett-stateless-reset-nits/draft-ietf-quic-transport.txt"
+        <td><a href="qpack-thanks/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-stateless-reset-nits/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-thanks/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="qpack-pseudocode">qpack-pseudocode</a></h2>
-    <table id="branch-qpack-pseudocode">
+    <h2>Preview for branch <a href="changelog-28">changelog-28</a></h2>
+    <table id="branch-changelog-28">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-http.html"
+        <td><a href="changelog-28/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-http.txt"
+        <td><a href="changelog-28/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-invariants.html"
+        <td><a href="changelog-28/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-invariants.txt"
+        <td><a href="changelog-28/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-qpack.html"
+        <td><a href="changelog-28/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-qpack.txt"
+        <td><a href="changelog-28/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-recovery.html"
+        <td><a href="changelog-28/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-recovery.txt"
+        <td><a href="changelog-28/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-tls.html"
+        <td><a href="changelog-28/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-tls.txt"
+        <td><a href="changelog-28/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-transport.html"
+        <td><a href="changelog-28/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="qpack-pseudocode/draft-ietf-quic-transport.txt"
+        <td><a href="changelog-28/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/qpack-pseudocode/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/changelog-28/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="period-rttvar">period-rttvar</a></h2>
-    <table id="branch-period-rttvar">
+    <h2>Preview for branch <a href="dplpmtud-merge">dplpmtud-merge</a></h2>
+    <table id="branch-dplpmtud-merge">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="period-rttvar/draft-ietf-quic-http.html"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="period-rttvar/draft-ietf-quic-http.txt"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="period-rttvar/draft-ietf-quic-invariants.html"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="period-rttvar/draft-ietf-quic-invariants.txt"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="period-rttvar/draft-ietf-quic-qpack.html"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="period-rttvar/draft-ietf-quic-qpack.txt"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="period-rttvar/draft-ietf-quic-recovery.html"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="period-rttvar/draft-ietf-quic-recovery.txt"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="period-rttvar/draft-ietf-quic-tls.html"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="period-rttvar/draft-ietf-quic-tls.txt"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="period-rttvar/draft-ietf-quic-transport.html"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="period-rttvar/draft-ietf-quic-transport.txt"
+        <td><a href="dplpmtud-merge/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/period-rttvar/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/dplpmtud-merge/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="captions">captions</a></h2>
-    <table id="branch-captions">
+    <h2>Preview for branch <a href="only-ecn">only-ecn</a></h2>
+    <table id="branch-only-ecn">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="captions/draft-ietf-quic-http.html"
+        <td><a href="only-ecn/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="captions/draft-ietf-quic-http.txt"
+        <td><a href="only-ecn/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="captions/draft-ietf-quic-invariants.html"
+        <td><a href="only-ecn/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="captions/draft-ietf-quic-invariants.txt"
+        <td><a href="only-ecn/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="captions/draft-ietf-quic-qpack.html"
+        <td><a href="only-ecn/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="captions/draft-ietf-quic-qpack.txt"
+        <td><a href="only-ecn/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="captions/draft-ietf-quic-recovery.html"
+        <td><a href="only-ecn/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="captions/draft-ietf-quic-recovery.txt"
+        <td><a href="only-ecn/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="captions/draft-ietf-quic-tls.html"
+        <td><a href="only-ecn/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="captions/draft-ietf-quic-tls.txt"
+        <td><a href="only-ecn/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="captions/draft-ietf-quic-transport.html"
+        <td><a href="only-ecn/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="captions/draft-ietf-quic-transport.txt"
+        <td><a href="only-ecn/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/captions/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/only-ecn/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="cite-this">cite-this</a></h2>
-    <table id="branch-cite-this">
+    <h2>Preview for branch <a href="3691-prose">3691-prose</a></h2>
+    <table id="branch-3691-prose">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="cite-this/draft-ietf-quic-http.html"
+        <td><a href="3691-prose/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="cite-this/draft-ietf-quic-http.txt"
+        <td><a href="3691-prose/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="cite-this/draft-ietf-quic-invariants.html"
+        <td><a href="3691-prose/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="cite-this/draft-ietf-quic-invariants.txt"
+        <td><a href="3691-prose/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="cite-this/draft-ietf-quic-qpack.html"
+        <td><a href="3691-prose/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="cite-this/draft-ietf-quic-qpack.txt"
+        <td><a href="3691-prose/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="cite-this/draft-ietf-quic-recovery.html"
+        <td><a href="3691-prose/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="cite-this/draft-ietf-quic-recovery.txt"
+        <td><a href="3691-prose/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="cite-this/draft-ietf-quic-tls.html"
+        <td><a href="3691-prose/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="cite-this/draft-ietf-quic-tls.txt"
+        <td><a href="3691-prose/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="cite-this/draft-ietf-quic-transport.html"
+        <td><a href="3691-prose/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="cite-this/draft-ietf-quic-transport.txt"
+        <td><a href="3691-prose/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/cite-this/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/3691-prose/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="max-udp-pmtud">max-udp-pmtud</a></h2>
-    <table id="branch-max-udp-pmtud">
+    <h2>Preview for branch <a href="ianswett-pto-loss-reorg">ianswett-pto-loss-reorg</a></h2>
+    <table id="branch-ianswett-pto-loss-reorg">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-http.html"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-http.txt"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-invariants.html"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-invariants.txt"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-qpack.html"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-qpack.txt"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-recovery.html"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-recovery.txt"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-tls.html"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-tls.txt"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-transport.html"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="max-udp-pmtud/draft-ietf-quic-transport.txt"
+        <td><a href="ianswett-pto-loss-reorg/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/max-udp-pmtud/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/ianswett-pto-loss-reorg/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="only-transport-close">only-transport-close</a></h2>
-    <table id="branch-only-transport-close">
+    <h2>Preview for branch <a href="samples-29">samples-29</a></h2>
+    <table id="branch-samples-29">
       <tr>
         <th>draft-ietf-quic-http</th>
-        <td><a href="only-transport-close/draft-ietf-quic-http.html"
+        <td><a href="samples-29/draft-ietf-quic-http.html"
            class="html draft-ietf-quic-http">html</a></td>
-        <td><a href="only-transport-close/draft-ietf-quic-http.txt"
+        <td><a href="samples-29/draft-ietf-quic-http.txt"
            class="txt draft-ietf-quic-http">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-http.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-invariants</th>
-        <td><a href="only-transport-close/draft-ietf-quic-invariants.html"
+        <td><a href="samples-29/draft-ietf-quic-invariants.html"
            class="html draft-ietf-quic-invariants">html</a></td>
-        <td><a href="only-transport-close/draft-ietf-quic-invariants.txt"
+        <td><a href="samples-29/draft-ietf-quic-invariants.txt"
            class="txt draft-ietf-quic-invariants">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-invariants.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-qpack</th>
-        <td><a href="only-transport-close/draft-ietf-quic-qpack.html"
+        <td><a href="samples-29/draft-ietf-quic-qpack.html"
            class="html draft-ietf-quic-qpack">html</a></td>
-        <td><a href="only-transport-close/draft-ietf-quic-qpack.txt"
+        <td><a href="samples-29/draft-ietf-quic-qpack.txt"
            class="txt draft-ietf-quic-qpack">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-qpack.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-recovery</th>
-        <td><a href="only-transport-close/draft-ietf-quic-recovery.html"
+        <td><a href="samples-29/draft-ietf-quic-recovery.html"
            class="html draft-ietf-quic-recovery">html</a></td>
-        <td><a href="only-transport-close/draft-ietf-quic-recovery.txt"
+        <td><a href="samples-29/draft-ietf-quic-recovery.txt"
            class="txt draft-ietf-quic-recovery">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-recovery.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-tls</th>
-        <td><a href="only-transport-close/draft-ietf-quic-tls.html"
+        <td><a href="samples-29/draft-ietf-quic-tls.html"
            class="html draft-ietf-quic-tls">html</a></td>
-        <td><a href="only-transport-close/draft-ietf-quic-tls.txt"
+        <td><a href="samples-29/draft-ietf-quic-tls.txt"
            class="txt draft-ietf-quic-tls">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-tls.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
           diff with last submission</a></td>
       </tr>
       <tr>
         <th>draft-ietf-quic-transport</th>
-        <td><a href="only-transport-close/draft-ietf-quic-transport.html"
+        <td><a href="samples-29/draft-ietf-quic-transport.html"
            class="html draft-ietf-quic-transport">html</a></td>
-        <td><a href="only-transport-close/draft-ietf-quic-transport.txt"
+        <td><a href="samples-29/draft-ietf-quic-transport.txt"
            class="txt draft-ietf-quic-transport">plain text</a></td>
-        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-transport.txt>diff with master</a></td>
-        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/only-transport-close/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/samples-29/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
           diff with last submission</a></td>
       </tr>
     </table>
diff --git a/jri/mustnot/draft-ietf-quic-http.html b/jri/mustnot/draft-ietf-quic-http.html
new file mode 100644
index 0000000000..57f3d1d0bf
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-http.html
@@ -0,0 +1,5123 @@
+<!DOCTYPE html>
+<html lang="en" class="Internet-Draft">
+<head>
+<meta charset="utf-8">
+<meta content="Common,Latin" name="scripts">
+<meta content="initial-scale=1.0" name="viewport">
+<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
+<meta content="Mike Bishop" name="author">
+<meta content="
+       The QUIC transport protocol has several features that are desirable in a
+transport for HTTP, such as stream multiplexing, per-stream flow control, and
+low-latency connection establishment.  This document describes a mapping of HTTP
+semantics over QUIC.  This document also identifies HTTP/2 features that are
+subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. 
+    " name="description">
+<meta content="xml2rfc 2.45.2" name="generator">
+<meta content="draft-ietf-quic-http-latest" name="ietf.draft">
+<link href="draft-ietf-quic-http.xml" rel="alternate" type="application/rfc+xml">
+<link href="#copyright" rel="license">
+<style type="text/css">@import url('https://martinthomson.github.io/i-d-template/fonts.css');
+
+html {
+  --background-color: #fff;
+  --text-color: #222;
+  --title-color: #191919;
+  --link-color: #2a6496;
+  --highlight-color: #f9f9f9;
+  --line-color: #eee;
+  --small-font-size: 14.5px;
+}
+body {
+  max-width: 600px;
+  margin: 75px auto;
+  padding: 0 5px;
+  color: var(--text-color);
+  background-color: var(--background-color);
+  font: 16px/22px "Lora", serif;
+  scroll-behavior: smooth;
+}
+
+.ears {
+  display: none;
+}
+
+/* headings */
+#title, h1, h2, h3, h4, h5, h6 {
+  font-family: "Cabin Condensed", sans-serif;
+  font-weight: 600;
+  margin: 0.8em 0 0.3em;
+  font-size-adjust: 0.5;
+  color: var(--title-color);
+}
+#title {
+  padding: 1em 0 0.2em;
+  font-size: 32px;
+  line-height: 40px;
+  clear: both;
+}
+h1, h2, h3 {
+  font-size: 22px;
+  line-height: 26px;
+}
+h4, h5, h6 {
+  font-size: 18px;
+  line-height: 22px;
+}
+
+/* general structure */
+.author {
+  padding-bottom: 0.3em;
+}
+#abstract+p, #abstract+p code, #abstract+p samp, #abstract+p tt {
+  font-size: 18px;
+  line-height: 24px;
+}
+p {
+  padding: 0;
+  margin: 0.5em 0;
+  text-align: left;
+}
+div, span {
+  position: relative;
+}
+div {
+  margin: 0;
+}
+.alignRight.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignRight.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignRight {
+  margin: 1em 0;
+}
+.alignRight > *:first-child {
+  border: none;
+  margin: 0;
+  float: right;
+  clear: both;
+}
+.alignRight > *:nth-child(2) {
+  clear: both;
+  display: block;
+  border: none;
+}
+svg {
+  display: block;
+}
+.alignCenter.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignCenter.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignCenter {
+  margin: 1em 0;
+}
+.alignCenter > *:first-child {
+  border: none;
+  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
+     support flexbox yet.
+  */
+  display: table;
+  margin: 0 auto;
+}
+
+/* lists */
+ol, ul {
+  padding: 0;
+  margin: 0 0 1em 2em;
+}
+ol ol, ul ul, ol ul, ul ol {
+  margin-left: 1em;
+}
+li {
+  margin: 0 0 0.25em 0;
+}
+.ulCompact li {
+  margin: 0;
+}
+ul.empty, .ulEmpty {
+  list-style-type: none;
+}
+ul.empty li, .ulEmpty li {
+  margin-top: 0.5em;
+}
+ul.compact, .ulCompact,
+ol.compact, .olCompact {
+  line-height: 100%;
+  margin: 0 0 0 2em;
+}
+
+/* definition lists */
+dl {
+}
+dl > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl > dd {
+  margin-bottom: .8em;
+  min-height: 1.3em;
+}
+dl.compact > dd, .dlCompact > dd {
+  margin-bottom: 0em;
+}
+dl > dd > dl {
+  margin-top: 0.5em;
+  margin-bottom: 0em;
+}
+dd.break {
+  display: none;
+}
+
+/* links */
+a, a[href].selfRef:hover {
+  text-decoration: none;
+}
+a[href].selfRef {
+  color: var(--text-color);
+}
+a[href] {
+  color: var(--link-color);
+}
+a[href]:hover {
+  text-decoration: underline;
+}
+a[href].selfRef:hover {
+  background-color: var(--highlight-color);
+}
+a.xref {
+  white-space: nowrap;
+}
+
+/* Figures */
+tt, code, pre {
+  background-color: var(--highlight-color);
+  font: 14px/22px 'Oxygen Mono', monospace;
+}
+pre {
+  border: 1px solid var(--line-color);
+  font-size: 13.5px;
+  line-height: 16px;
+  letter-spacing: -0.2px;
+  margin: 5px;
+  padding: 5px;
+}
+img {
+  max-width: 100%;
+}
+figure {
+  margin: 0.5em 0;
+}
+figure blockquote {
+  margin: 0.8em 0.4em 0.4em;
+}
+figcaption, caption {
+  font-style: italic;
+  margin: 0.5em 1.5em;
+  text-align: left;
+}
+@media screen {
+  pre {
+    display: inline-block;
+    overflow-x: auto;
+    max-width: 100%;
+    width: calc(100% - 22px - 1em);
+  }
+  figure pre {
+    display: block;
+    width: calc(100% - 25px);
+  }
+  pre + .pilcrow {
+    display: inline-block;
+    vertical-align: text-bottom;
+    padding-bottom: 8px;
+  }
+  table {
+    display: inline-block;
+    overflow-x: auto;
+  }
+}
+
+/* aside, blockquote */
+aside, blockquote {
+  margin-left: 0;
+  padding: 0 2em;
+  font-style: italic;
+}
+blockquote {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  margin: 1em 0;
+}
+cite {
+  display: block;
+  text-align: right;
+  font-style: italic;
+}
+
+/* tables */
+table {
+  width: 100%;
+  margin: 0 0 1em;
+  border-collapse: collapse;
+}
+thead, tbody {
+  border: 1px solid var(--line-color);
+}
+th, td {
+  text-align: left;
+  vertical-align: top;
+  padding: 5px 10px;
+}
+th {
+  text-align: left;
+  background-color: #eee;
+}
+tr:nth-child(2n) > td {
+  background-color: var(--background-color);
+}
+tr:nth-child(2n+1) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n+1) > td {
+  background-color: var(--background-color);
+}
+table caption {
+  margin: 0;
+  padding: 3px 1em;
+}
+table p {
+  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
+     be allowed within tables more generally, it would be far better to select on a class. */
+  margin: 0;
+}
+
+/* pilcrow */
+a.pilcrow {
+  margin-left: 3px;
+  visibility: hidden;
+  user-select: none;
+}
+a.pilcrow[href] { color: #ddd; }
+a.pilcrow[href]:hover { text-decoration: none; }
+@media screen {
+  :hover > a.pilcrow {
+    visibility: visible;
+  }
+  a.pilcrow:hover {
+    background-color: transparent;
+  }
+}
+
+/* misc */
+hr {
+  border: 0;
+  border-top: 1px solid var(--line-color);
+}
+.bcp14 {
+  font-variant: small-caps;
+}
+
+.role {
+  font-variant: all-small-caps;
+}
+
+/* info block */
+#identifiers {
+  margin: 0;
+  font-size: var(--small-font-size);
+  line-height: 18px;
+  --identifier-width: 8em;
+}
+#identifiers dt {
+  width: var(--identifier-width);
+  margin: 0;
+  clear: left;
+  float: left;
+  text-align: right;
+}
+#identifiers dd {
+  margin: 0 0 0 calc(1em + var(--identifier-width));
+  min-width: 5em;
+}
+#identifiers .authors .author {
+  display: inline-block;
+  margin-right: 1.5em;
+}
+#identifiers .authors .org {
+  font-style: italic;
+}
+
+/* The prepared/rendered info at the very bottom of the page */
+.docInfo {
+  color: #999;
+  font-size: 0.9em;
+  font-style: italic;
+  margin-top: 2em;
+}
+.docInfo .prepared {
+  float: left;
+}
+.docInfo .prepared {
+  float: right;
+}
+
+/* table of contents */
+#toc {
+  padding: 0.75em 0 2em 0;
+  margin-bottom: 1em;
+}
+#toc nav ul {
+  margin: 0 0.5em 0 0;
+  padding: 0;
+  list-style: none;
+}
+#toc nav li {
+  line-height: 1.3em;
+  margin: 0.75em 0;
+  padding-left: 1.2em;
+  text-indent: -1.2em;
+}
+#toc a.xref {
+  white-space: normal;
+}
+/* references */
+.references dt {
+  text-align: right;
+  font-weight: bold;
+  min-width: 7em;
+}
+.references dd {
+  margin-left: 8em;
+  overflow: auto;
+}
+
+.refInstance {
+  margin-bottom: 1.25em;
+}
+
+.references .ascii {
+  margin-bottom: 0.25em;
+}
+
+/* index */
+.index ul {
+  margin: 0 0 0 1em;
+  padding: 0;
+  list-style: none;
+}
+.index ul ul {
+  margin: 0;
+}
+.index li {
+  margin: 0;
+  text-indent: -2em;
+  padding-left: 2em;
+  padding-bottom: 5px;
+}
+.indexIndex {
+  margin: 0.5em 0 1em;
+}
+.index a {
+  font-weight: 700;
+}
+/* make the index two-column on all but the smallest screens */
+@media (min-width: 500px) {
+  .index ul {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  .index ul ul {
+    column-count: 1;
+    column-gap: 0;
+  }
+}
+
+/* authors */
+address.vcard {
+  font-style: normal;
+  margin: 1em 0;
+}
+address.vcard .nameRole {
+  font-weight: 700;
+  margin-left: 0;
+}
+address.vcard .label {
+  margin: 0.5em 0;
+}
+address.vcard .type {
+  display: none;
+}
+.alternative-contact {
+  margin: 1.5em 0 1em;
+}
+hr.addr {
+  border-top: 1px dashed;
+  margin: 0;
+  color: #ddd;
+  max-width: calc(100% - 16px);
+}
+@media (min-width: 500px) {
+  #authors-addresses > section {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  #authors-addresses > section > h2 {
+    column-span: all;
+  }
+  /* hack for break-inside: avoid-column */
+  #authors-addresses address {
+    display: inline-block;
+    break-inside: avoid-column;
+  }
+}
+
+.rfcEditorRemove p:first-of-type {
+  font-style: italic;
+}
+.cref {
+  background-color: rgba(249, 232, 105, 0.3);
+  padding: 2px 4px;
+}
+.crefSource {
+  font-style: italic;
+}
+/* alternative layout for smaller screens */
+@media screen and (max-width: 929px) {
+  #toc {
+    position: fixed;
+    z-index: 2;
+    top: 0;
+    right: 0;
+    padding: 0;
+    margin: 0;
+    border-bottom: 1px solid #ccc;
+    opacity: 0.6;
+  }
+  #toc.active {
+      opacity: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 2px 0 2px 6px;
+    padding-right: 1em;
+    font-size: 18px;
+    line-height: 24px;
+    min-width: 190px;
+    text-align: right;
+    background-color: #444;
+    color: white;
+    cursor: pointer;
+  }
+  #toc h2::before { /* css hamburger */
+    float: right;
+    position: relative;
+    width: 1em;
+    height: 1px;
+    left: -164px;
+    margin: 8px 0 0 0;
+    background: white none repeat scroll 0 0;
+    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
+    content: "";
+  }
+  #toc nav {
+    display: none;
+    background-color: var(--background-color);
+    padding: 0.5em 1em 1em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    height: calc(100vh - 48px);
+    border-left: 1px solid #ddd;
+  }
+  #toc.active nav {
+    display: block;
+  }
+  /* Make the collapsed ToC header render white on gray also when it's a link */
+  #toc h2 a,
+  #toc h2 a:link,
+  #toc h2 a:focus,
+  #toc h2 a:hover,
+  #toc a.toplink,
+  #toc a.toplink:hover {
+    color: white;
+    background-color: #444;
+    text-decoration: none;
+  }
+  #toc a.toplink {
+    margin-top: 2px;
+  }
+}
+
+/* alternative layout for wide screens */
+@media screen and (min-width: 930px) {
+  body {
+    padding-right: 360px;
+    padding-right: calc(min(180px + 20%, 500px));
+  }
+  #toc {
+    position: fixed;
+    bottom: 0;
+    right: 0;
+    right: calc(50vw - 480px);
+    width: 312px;
+    margin: 0;
+    padding: 0;
+    z-index: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 0.25em 1em 1em 0;
+  }
+  #toc nav {
+    display: block;
+    height: calc(90vh - 84px);
+    bottom: 0;
+    padding: 0.5em 0 2em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    scrollbar-width: thin;
+  }
+  #toc nav > ul  {
+    margin-bottom: 2em;
+  }
+  #toc ul {
+    margin: 0 0 0 4px;
+    font-size: var(--small-font-size);
+  }
+  #toc ul p, #toc ul li {
+    margin: 2px 0;
+    line-height: 22px;
+  }
+  img { /* future proofing */
+    max-width: 100%;
+    height: auto;
+  }
+}
+
+/* pagination */
+@media print {
+  body {
+    width: 100%;
+  }
+  p {
+    orphans: 3;
+    widows: 3;
+  }
+  #n-copyright-notice {
+    border-bottom: none;
+  }
+  #toc, #n-introduction {
+    page-break-before: always;
+  }
+  #toc {
+    border-top: none;
+    padding-top: 0;
+  }
+  figure, pre {
+    page-break-inside: avoid;
+  }
+  figure {
+    overflow: scroll;
+  }
+  h1, h2, h3, h4, h5, h6 {
+    page-break-after: avoid;
+  }
+  h2+*, h3+*, h4+*, h5+*, h6+* {
+    page-break-before: avoid;
+  }
+  pre {
+    white-space: pre-wrap;
+    word-wrap: break-word;
+    font-size: 10pt;
+  }
+  table {
+    border: 1px solid #ddd;
+  }
+  td {
+    border-top: 1px solid #ddd;
+  }
+}
+
+@page :first {
+  padding-top: 0;
+  @top-left {
+    content: normal;
+    border: none;
+  }
+  @top-center {
+    content: normal;
+    border: none;
+  }
+  @top-right {
+    content: normal;
+    border: none;
+  }
+}
+
+@page {
+  size: A4;
+  margin-bottom: 45mm;
+  padding-top: 20px;
+}
+
+/* Changes introduced to fix issues found during implementation */
+
+/* Separate body from document info even without intervening H1 */
+section {
+  clear: both;
+}
+
+/* Top align author divs, to avoid names without organization dropping level with org names */
+.author {
+  vertical-align: top;
+}
+
+/* Style section numbers with more space between number and title */
+.section-number {
+  padding-right: 0.5em;
+}
+
+/* Add styling for a link in the ToC that points to the top of the document */
+a.toplink {
+  float: right;
+  margin: 8px 0.5em 0;
+}
+
+/* Fix the dl styling to match the RFC 7992 attributes */
+dl > dt,
+dl.dlParallel > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl.dlNewline > dt {
+  float: none;
+}
+
+/* Provide styling for table cell text alignment */
+table .text-left, table .text-left {
+  text-align: left;
+}
+table .text-center, table .text-center {
+  text-align: center;
+}
+table .text-right, table .text-right {
+  text-align: right;
+}
+
+/* Make the alternative author contact information look less like just another
+   author, and group it closer with the primary author contact information */
+.alternative-contact {
+  margin: 0.5em 0 0.25em 0;
+}
+address .non-ascii {
+  margin: 0 0 0 2em;
+}
+
+/* With it being possible to set tables with alignment
+  left, center, and right, { width: 100%; } does not make sense */
+table {
+  width: auto;
+}
+
+/* Avoid reference text that sits in a block with very wide left margin,
+   because of a long floating dt label.*/
+.references dd {
+  overflow: visible;
+}
+
+/* Control caption placement */
+caption {
+  caption-side: bottom;
+}
+
+/* Limit the width of the author address vcard, so names in right-to-left
+   script don't end up on the other side of the page. */
+
+address.vcard {
+  max-width: 20em;
+  margin-right: auto;
+}
+
+/* For address alignment dependent on LTR or RTL scripts */
+address div.left {
+  text-align: left;
+}
+address div.right {
+  text-align: right;
+}
+
+/* Provide table alignment support.  We can't use the alignX classes above
+   since they do unwanted things with caption and other styling. */
+table.right {
+ margin-left: auto;
+ margin-right: 0;
+}
+table.center {
+ margin-left: auto;
+ margin-right: auto;
+}
+table.left {
+ margin-left: 0;
+ margin-right: auto;
+}
+
+/* Give the table caption label the same styling as the figcaption */
+
+@media print {
+  .toplink {
+    display: none;
+  }
+
+  /* avoid overwriting the top border line with the ToC header */
+  #toc {
+    padding-top: 1px;
+  }
+
+  /* Avoid page breaks inside dl and author address entries */
+  dd {
+    page-break-before: avoid;
+  }
+  .vcard {
+    page-break-inside: avoid;
+  }
+
+}
+/* Tweak the bcp14 keyword presentation */
+.bcp14 {
+  font-variant: small-caps;
+  font-weight: bold;
+  font-size: 0.9em;
+}
+</style>
+<link href="rfc-local.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<table class="ears">
+<thead><tr>
+<td class="left">Internet-Draft</td>
+<td class="center">HTTP/3</td>
+<td class="right">June 2020</td>
+</tr></thead>
+<tfoot><tr>
+<td class="left">Bishop</td>
+<td class="center">Expires 5 December 2020</td>
+<td class="right">[Page]</td>
+</tr></tfoot>
+</table>
+<div id="external-metadata" class="document-information"></div>
+<div id="internal-metadata" class="document-information">
+<dl id="identifiers">
+<dt class="label-workgroup">Workgroup:</dt>
+<dd class="workgroup">QUIC</dd>
+<dt class="label-internet-draft">Internet-Draft:</dt>
+<dd class="internet-draft">draft-ietf-quic-http-latest</dd>
+<dt class="label-published">Published:</dt>
+<dd class="published">
+<time datetime="2020-06-03" class="published">3 June 2020</time>
+    </dd>
+<dt class="label-intended-status">Intended Status:</dt>
+<dd class="intended-status">Standards Track</dd>
+<dt class="label-expires">Expires:</dt>
+<dd class="expires"><time datetime="2020-12-05">5 December 2020</time></dd>
+<dt class="label-authors">Author:</dt>
+<dd class="authors">
+<div class="author">
+      <div class="author-name">M. Bishop, <span class="editor">Ed.</span>
+</div>
+<div class="org">Akamai</div>
+</div>
+</dd>
+</dl>
+</div>
+<h1 id="title">Hypertext Transfer Protocol Version 3 (HTTP/3)</h1>
+<section id="section-abstract">
+      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
+<p id="section-abstract-1">The QUIC transport protocol has several features that are desirable in a
+transport for HTTP, such as stream multiplexing, per-stream flow control, and
+low-latency connection establishment.  This document describes a mapping of HTTP
+semantics over QUIC.  This document also identifies HTTP/2 features that are
+subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.1">
+      <h2 id="name-note-to-readers">
+<a href="#name-note-to-readers" class="section-name selfRef">Note to Readers</a>
+      </h2>
+<p id="section-note.1-1">Discussion of this draft takes place on the QUIC working group mailing list
+(<a href="mailto:quic@ietf.org">quic@ietf.org</a>), which is archived at
+<span><a href="https://mailarchive.ietf.org/arch/search/?email_list=quic">https://mailarchive.ietf.org/arch/search/?email_list=quic</a></span>.<a href="#section-note.1-1" class="pilcrow">¶</a></p>
+<p id="section-note.1-2">Working Group information can be found at <span><a href="https://github.com/quicwg">https://github.com/quicwg</a></span>; source
+code and issues list for this draft can be found at
+<span><a href="https://github.com/quicwg/base-drafts/labels/-http">https://github.com/quicwg/base-drafts/labels/-http</a></span>.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
+</section>
+<div id="status-of-memo">
+<section id="section-boilerplate.1">
+        <h2 id="name-status-of-this-memo">
+<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
+        </h2>
+<p id="section-boilerplate.1-1">
+        This Internet-Draft is submitted in full conformance with the
+        provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-2">
+        Internet-Drafts are working documents of the Internet Engineering Task
+        Force (IETF). Note that other groups may also distribute working
+        documents as Internet-Drafts. The list of current Internet-Drafts is
+        at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-3">
+        Internet-Drafts are draft documents valid for a maximum of six months
+        and may be updated, replaced, or obsoleted by other documents at any
+        time. It is inappropriate to use Internet-Drafts as reference
+        material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-4">
+        This Internet-Draft will expire on 5 December 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="copyright">
+<section id="section-boilerplate.2">
+        <h2 id="name-copyright-notice">
+<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
+        </h2>
+<p id="section-boilerplate.2-1">
+            Copyright (c) 2020 IETF Trust and the persons identified as the
+            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.2-2">
+            This document is subject to BCP 78 and the IETF Trust's Legal
+            Provisions Relating to IETF Documents
+            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
+            publication of this document. Please review these documents
+            carefully, as they describe your rights and restrictions with
+            respect to this document. Code Components extracted from this
+            document must include Simplified BSD License text as described in
+            Section 4.e of the Trust Legal Provisions and are provided without
+            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="toc">
+<section id="section-toc.1">
+        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
+<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
+        </h2>
+<nav class="toc"><ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.1">
+                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-prior-versions-of-http" class="xref">Prior versions of HTTP</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.2">
+                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-delegation-to-quic" class="xref">Delegation to QUIC</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-http-3-protocol-overview" class="xref">HTTP/3 Protocol Overview</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.2.2.1">
+                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-document-organization" class="xref">Document Organization</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.2.2.2">
+                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-conventions-and-terminology" class="xref">Conventions and Terminology</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-connection-setup-and-manage" class="xref">Connection Setup and Management</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1">
+                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-draft-version-identificatio" class="xref">Draft Version Identification</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2">
+                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-discovering-an-http-3-endpo" class="xref">Discovering an HTTP/3 Endpoint</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2.2.1">
+                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-http-alternative-services" class="xref">HTTP Alternative Services</a><a href="#section-toc.1-1.3.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2.2.2">
+                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-other-schemes" class="xref">Other Schemes</a><a href="#section-toc.1-1.3.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.3">
+                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-connection-establishment" class="xref">Connection Establishment</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.4">
+                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-connection-reuse" class="xref">Connection Reuse</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-http-request-lifecycle" class="xref">HTTP Request Lifecycle</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1">
+                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-http-message-exchanges" class="xref">HTTP Message Exchanges</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1.2.1">
+                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-field-formatting-and-compre" class="xref">Field Formatting and Compression</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1.2.2">
+                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-request-cancellation-and-re" class="xref">Request Cancellation and Rejection</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1.2.3">
+                    <p id="section-toc.1-1.4.2.1.2.3.1"><a href="#section-4.1.3" class="xref">4.1.3</a>.  <a href="#name-malformed-requests-and-resp" class="xref">Malformed Requests and Responses</a><a href="#section-toc.1-1.4.2.1.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.2">
+                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-the-connect-method" class="xref">The CONNECT Method</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3">
+                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-http-upgrade" class="xref">HTTP Upgrade</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.4">
+                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-server-push" class="xref">Server Push</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-connection-closure" class="xref">Connection Closure</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1">
+                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-idle-connections" class="xref">Idle Connections</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2">
+                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-connection-shutdown" class="xref">Connection Shutdown</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.3">
+                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-immediate-application-closu" class="xref">Immediate Application Closure</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4">
+                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-transport-closure" class="xref">Transport Closure</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-stream-mapping-and-usage" class="xref">Stream Mapping and Usage</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-bidirectional-streams" class="xref">Bidirectional Streams</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2">
+                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-unidirectional-streams" class="xref">Unidirectional Streams</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2.2.1">
+                    <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="xref">6.2.1</a>.  <a href="#name-control-streams" class="xref">Control Streams</a><a href="#section-toc.1-1.6.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2.2.2">
+                    <p id="section-toc.1-1.6.2.2.2.2.1"><a href="#section-6.2.2" class="xref">6.2.2</a>.  <a href="#name-push-streams" class="xref">Push Streams</a><a href="#section-toc.1-1.6.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2.2.3">
+                    <p id="section-toc.1-1.6.2.2.2.3.1"><a href="#section-6.2.3" class="xref">6.2.3</a>.  <a href="#name-reserved-stream-types" class="xref">Reserved Stream Types</a><a href="#section-toc.1-1.6.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-http-framing-layer" class="xref">HTTP Framing Layer</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-frame-layout" class="xref">Frame Layout</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-frame-definitions" class="xref">Frame Definitions</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.1">
+                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-data" class="xref">DATA</a><a href="#section-toc.1-1.7.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.2">
+                    <p id="section-toc.1-1.7.2.2.2.2.1"><a href="#section-7.2.2" class="xref">7.2.2</a>.  <a href="#name-headers" class="xref">HEADERS</a><a href="#section-toc.1-1.7.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.3">
+                    <p id="section-toc.1-1.7.2.2.2.3.1"><a href="#section-7.2.3" class="xref">7.2.3</a>.  <a href="#name-cancel_push" class="xref">CANCEL_PUSH</a><a href="#section-toc.1-1.7.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.4">
+                    <p id="section-toc.1-1.7.2.2.2.4.1"><a href="#section-7.2.4" class="xref">7.2.4</a>.  <a href="#name-settings" class="xref">SETTINGS</a><a href="#section-toc.1-1.7.2.2.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.5">
+                    <p id="section-toc.1-1.7.2.2.2.5.1"><a href="#section-7.2.5" class="xref">7.2.5</a>.  <a href="#name-push_promise" class="xref">PUSH_PROMISE</a><a href="#section-toc.1-1.7.2.2.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.6">
+                    <p id="section-toc.1-1.7.2.2.2.6.1"><a href="#section-7.2.6" class="xref">7.2.6</a>.  <a href="#name-goaway" class="xref">GOAWAY</a><a href="#section-toc.1-1.7.2.2.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.7">
+                    <p id="section-toc.1-1.7.2.2.2.7.1"><a href="#section-7.2.7" class="xref">7.2.7</a>.  <a href="#name-max_push_id" class="xref">MAX_PUSH_ID</a><a href="#section-toc.1-1.7.2.2.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2.2.8">
+                    <p id="section-toc.1-1.7.2.2.2.8.1"><a href="#section-7.2.8" class="xref">7.2.8</a>.  <a href="#name-reserved-frame-types" class="xref">Reserved Frame Types</a><a href="#section-toc.1-1.7.2.2.2.8.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-error-handling" class="xref">Error Handling</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.1">
+                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-http-3-error-codes" class="xref">HTTP/3 Error Codes</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-extensions-to-http-3" class="xref">Extensions to HTTP/3</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1">
+                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-server-authority" class="xref">Server Authority</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2">
+                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-cross-protocol-attacks" class="xref">Cross-Protocol Attacks</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3">
+                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-intermediary-encapsulation-" class="xref">Intermediary Encapsulation Attacks</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.4">
+                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="xref">10.4</a>.  <a href="#name-cacheability-of-pushed-resp" class="xref">Cacheability of Pushed Responses</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5">
+                <p id="section-toc.1-1.10.2.5.1"><a href="#section-10.5" class="xref">10.5</a>.  <a href="#name-denial-of-service-considera" class="xref">Denial-of-Service Considerations</a><a href="#section-toc.1-1.10.2.5.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5.2.1">
+                    <p id="section-toc.1-1.10.2.5.2.1.1"><a href="#section-10.5.1" class="xref">10.5.1</a>.  <a href="#name-limits-on-field-section-siz" class="xref">Limits on Field Section Size</a><a href="#section-toc.1-1.10.2.5.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5.2.2">
+                    <p id="section-toc.1-1.10.2.5.2.2.1"><a href="#section-10.5.2" class="xref">10.5.2</a>.  <a href="#name-connect-issues" class="xref">CONNECT Issues</a><a href="#section-toc.1-1.10.2.5.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.6">
+                <p id="section-toc.1-1.10.2.6.1"><a href="#section-10.6" class="xref">10.6</a>.  <a href="#name-use-of-compression" class="xref">Use of Compression</a><a href="#section-toc.1-1.10.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.7">
+                <p id="section-toc.1-1.10.2.7.1"><a href="#section-10.7" class="xref">10.7</a>.  <a href="#name-padding-and-traffic-analysi" class="xref">Padding and Traffic Analysis</a><a href="#section-toc.1-1.10.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.8">
+                <p id="section-toc.1-1.10.2.8.1"><a href="#section-10.8" class="xref">10.8</a>.  <a href="#name-frame-parsing" class="xref">Frame Parsing</a><a href="#section-toc.1-1.10.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.9">
+                <p id="section-toc.1-1.10.2.9.1"><a href="#section-10.9" class="xref">10.9</a>.  <a href="#name-early-data" class="xref">Early Data</a><a href="#section-toc.1-1.10.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.10">
+                <p id="section-toc.1-1.10.2.10.1"><a href="#section-10.10" class="xref">10.10</a>. <a href="#name-migration" class="xref">Migration</a><a href="#section-toc.1-1.10.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.11">
+                <p id="section-toc.1-1.10.2.11.1"><a href="#section-10.11" class="xref">10.11</a>. <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a><a href="#section-toc.1-1.10.2.11.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.1">
+                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-registration-of-http-3-iden" class="xref">Registration of HTTP/3 Identification String</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.2">
+                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-new-registries" class="xref">New Registries</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.2.2.1">
+                    <p id="section-toc.1-1.11.2.2.2.1.1"><a href="#section-11.2.1" class="xref">11.2.1</a>.  <a href="#name-frame-types" class="xref">Frame Types</a><a href="#section-toc.1-1.11.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.2.2.2">
+                    <p id="section-toc.1-1.11.2.2.2.2.1"><a href="#section-11.2.2" class="xref">11.2.2</a>.  <a href="#name-settings-parameters" class="xref">Settings Parameters</a><a href="#section-toc.1-1.11.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.2.2.3">
+                    <p id="section-toc.1-1.11.2.2.2.3.1"><a href="#section-11.2.3" class="xref">11.2.3</a>.  <a href="#name-error-codes" class="xref">Error Codes</a><a href="#section-toc.1-1.11.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.2.2.4">
+                    <p id="section-toc.1-1.11.2.2.2.4.1"><a href="#section-11.2.4" class="xref">11.2.4</a>.  <a href="#name-stream-types" class="xref">Stream Types</a><a href="#section-toc.1-1.11.2.2.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12">
+            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.1">
+                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.2">
+                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.13">
+            <p id="section-toc.1-1.13.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-considerations-for-transiti" class="xref">Considerations for Transitioning from HTTP/2</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.1">
+                <p id="section-toc.1-1.13.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-streams" class="xref">Streams</a><a href="#section-toc.1-1.13.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.2">
+                <p id="section-toc.1-1.13.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-http-frame-types" class="xref">HTTP Frame Types</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.2.2.1">
+                    <p id="section-toc.1-1.13.2.2.2.1.1"><a href="#section-a.2.1" class="xref">A.2.1</a>.  <a href="#name-prioritization-differences" class="xref">Prioritization Differences</a><a href="#section-toc.1-1.13.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.2.2.2">
+                    <p id="section-toc.1-1.13.2.2.2.2.1"><a href="#section-a.2.2" class="xref">A.2.2</a>.  <a href="#name-field-compression-differenc" class="xref">Field Compression Differences</a><a href="#section-toc.1-1.13.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.2.2.3">
+                    <p id="section-toc.1-1.13.2.2.2.3.1"><a href="#section-a.2.3" class="xref">A.2.3</a>.  <a href="#name-guidance-for-new-frame-type" class="xref">Guidance for New Frame Type Definitions</a><a href="#section-toc.1-1.13.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.2.2.4">
+                    <p id="section-toc.1-1.13.2.2.2.4.1"><a href="#section-a.2.4" class="xref">A.2.4</a>.  <a href="#name-mapping-between-http-2-and-" class="xref">Mapping Between HTTP/2 and HTTP/3 Frame Types</a><a href="#section-toc.1-1.13.2.2.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.3">
+                <p id="section-toc.1-1.13.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-http-2-settings-parameters" class="xref">HTTP/2 SETTINGS Parameters</a><a href="#section-toc.1-1.13.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.4">
+                <p id="section-toc.1-1.13.2.4.1"><a href="#section-a.4" class="xref">A.4</a>.  <a href="#name-http-2-error-codes" class="xref">HTTP/2 Error Codes</a><a href="#section-toc.1-1.13.2.4.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.13.2.4.2.1">
+                    <p id="section-toc.1-1.13.2.4.2.1.1"><a href="#section-a.4.1" class="xref">A.4.1</a>.  <a href="#name-mapping-between-http-2-and-h" class="xref">Mapping Between HTTP/2 and HTTP/3 Errors</a><a href="#section-toc.1-1.13.2.4.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14">
+            <p id="section-toc.1-1.14.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-change-log" class="xref">Change Log</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.1">
+                <p id="section-toc.1-1.14.2.1.1"><a href="#section-b.1" class="xref">B.1</a>.  <a href="#name-since-draft-ietf-quic-http-" class="xref">Since draft-ietf-quic-http-27</a><a href="#section-toc.1-1.14.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.2">
+                <p id="section-toc.1-1.14.2.2.1"><a href="#section-b.2" class="xref">B.2</a>.  <a href="#name-since-draft-ietf-quic-http-2" class="xref">Since draft-ietf-quic-http-26</a><a href="#section-toc.1-1.14.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.3">
+                <p id="section-toc.1-1.14.2.3.1"><a href="#section-b.3" class="xref">B.3</a>.  <a href="#name-since-draft-ietf-quic-http-25" class="xref">Since draft-ietf-quic-http-25</a><a href="#section-toc.1-1.14.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.4">
+                <p id="section-toc.1-1.14.2.4.1"><a href="#section-b.4" class="xref">B.4</a>.  <a href="#name-since-draft-ietf-quic-http-24" class="xref">Since draft-ietf-quic-http-24</a><a href="#section-toc.1-1.14.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.5">
+                <p id="section-toc.1-1.14.2.5.1"><a href="#section-b.5" class="xref">B.5</a>.  <a href="#name-since-draft-ietf-quic-http-23" class="xref">Since draft-ietf-quic-http-23</a><a href="#section-toc.1-1.14.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.6">
+                <p id="section-toc.1-1.14.2.6.1"><a href="#section-b.6" class="xref">B.6</a>.  <a href="#name-since-draft-ietf-quic-http-22" class="xref">Since draft-ietf-quic-http-22</a><a href="#section-toc.1-1.14.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.7">
+                <p id="section-toc.1-1.14.2.7.1"><a href="#section-b.7" class="xref">B.7</a>.  <a href="#name-since-draft-ietf-quic-http-21" class="xref">Since draft-ietf-quic-http-21</a><a href="#section-toc.1-1.14.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.8">
+                <p id="section-toc.1-1.14.2.8.1"><a href="#section-b.8" class="xref">B.8</a>.  <a href="#name-since-draft-ietf-quic-http-20" class="xref">Since draft-ietf-quic-http-20</a><a href="#section-toc.1-1.14.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.9">
+                <p id="section-toc.1-1.14.2.9.1"><a href="#section-b.9" class="xref">B.9</a>.  <a href="#name-since-draft-ietf-quic-http-1" class="xref">Since draft-ietf-quic-http-19</a><a href="#section-toc.1-1.14.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.10">
+                <p id="section-toc.1-1.14.2.10.1"><a href="#section-b.10" class="xref">B.10</a>. <a href="#name-since-draft-ietf-quic-http-18" class="xref">Since draft-ietf-quic-http-18</a><a href="#section-toc.1-1.14.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.11">
+                <p id="section-toc.1-1.14.2.11.1"><a href="#section-b.11" class="xref">B.11</a>. <a href="#name-since-draft-ietf-quic-http-17" class="xref">Since draft-ietf-quic-http-17</a><a href="#section-toc.1-1.14.2.11.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.12">
+                <p id="section-toc.1-1.14.2.12.1"><a href="#section-b.12" class="xref">B.12</a>. <a href="#name-since-draft-ietf-quic-http-16" class="xref">Since draft-ietf-quic-http-16</a><a href="#section-toc.1-1.14.2.12.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.13">
+                <p id="section-toc.1-1.14.2.13.1"><a href="#section-b.13" class="xref">B.13</a>. <a href="#name-since-draft-ietf-quic-http-15" class="xref">Since draft-ietf-quic-http-15</a><a href="#section-toc.1-1.14.2.13.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.14">
+                <p id="section-toc.1-1.14.2.14.1"><a href="#section-b.14" class="xref">B.14</a>. <a href="#name-since-draft-ietf-quic-http-14" class="xref">Since draft-ietf-quic-http-14</a><a href="#section-toc.1-1.14.2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.15">
+                <p id="section-toc.1-1.14.2.15.1"><a href="#section-b.15" class="xref">B.15</a>. <a href="#name-since-draft-ietf-quic-http-13" class="xref">Since draft-ietf-quic-http-13</a><a href="#section-toc.1-1.14.2.15.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.16">
+                <p id="section-toc.1-1.14.2.16.1"><a href="#section-b.16" class="xref">B.16</a>. <a href="#name-since-draft-ietf-quic-http-12" class="xref">Since draft-ietf-quic-http-12</a><a href="#section-toc.1-1.14.2.16.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.17">
+                <p id="section-toc.1-1.14.2.17.1"><a href="#section-b.17" class="xref">B.17</a>. <a href="#name-since-draft-ietf-quic-http-11" class="xref">Since draft-ietf-quic-http-11</a><a href="#section-toc.1-1.14.2.17.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.18">
+                <p id="section-toc.1-1.14.2.18.1"><a href="#section-b.18" class="xref">B.18</a>. <a href="#name-since-draft-ietf-quic-http-10" class="xref">Since draft-ietf-quic-http-10</a><a href="#section-toc.1-1.14.2.18.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.19">
+                <p id="section-toc.1-1.14.2.19.1"><a href="#section-b.19" class="xref">B.19</a>. <a href="#name-since-draft-ietf-quic-http-0" class="xref">Since draft-ietf-quic-http-09</a><a href="#section-toc.1-1.14.2.19.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.20">
+                <p id="section-toc.1-1.14.2.20.1"><a href="#section-b.20" class="xref">B.20</a>. <a href="#name-since-draft-ietf-quic-http-08" class="xref">Since draft-ietf-quic-http-08</a><a href="#section-toc.1-1.14.2.20.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.21">
+                <p id="section-toc.1-1.14.2.21.1"><a href="#section-b.21" class="xref">B.21</a>. <a href="#name-since-draft-ietf-quic-http-07" class="xref">Since draft-ietf-quic-http-07</a><a href="#section-toc.1-1.14.2.21.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.22">
+                <p id="section-toc.1-1.14.2.22.1"><a href="#section-b.22" class="xref">B.22</a>. <a href="#name-since-draft-ietf-quic-http-06" class="xref">Since draft-ietf-quic-http-06</a><a href="#section-toc.1-1.14.2.22.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.23">
+                <p id="section-toc.1-1.14.2.23.1"><a href="#section-b.23" class="xref">B.23</a>. <a href="#name-since-draft-ietf-quic-http-05" class="xref">Since draft-ietf-quic-http-05</a><a href="#section-toc.1-1.14.2.23.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.24">
+                <p id="section-toc.1-1.14.2.24.1"><a href="#section-b.24" class="xref">B.24</a>. <a href="#name-since-draft-ietf-quic-http-04" class="xref">Since draft-ietf-quic-http-04</a><a href="#section-toc.1-1.14.2.24.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.25">
+                <p id="section-toc.1-1.14.2.25.1"><a href="#section-b.25" class="xref">B.25</a>. <a href="#name-since-draft-ietf-quic-http-03" class="xref">Since draft-ietf-quic-http-03</a><a href="#section-toc.1-1.14.2.25.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.26">
+                <p id="section-toc.1-1.14.2.26.1"><a href="#section-b.26" class="xref">B.26</a>. <a href="#name-since-draft-ietf-quic-http-02" class="xref">Since draft-ietf-quic-http-02</a><a href="#section-toc.1-1.14.2.26.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.27">
+                <p id="section-toc.1-1.14.2.27.1"><a href="#section-b.27" class="xref">B.27</a>. <a href="#name-since-draft-ietf-quic-http-01" class="xref">Since draft-ietf-quic-http-01</a><a href="#section-toc.1-1.14.2.27.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.28">
+                <p id="section-toc.1-1.14.2.28.1"><a href="#section-b.28" class="xref">B.28</a>. <a href="#name-since-draft-ietf-quic-http-00" class="xref">Since draft-ietf-quic-http-00</a><a href="#section-toc.1-1.14.2.28.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14.2.29">
+                <p id="section-toc.1-1.14.2.29.1"><a href="#section-b.29" class="xref">B.29</a>. <a href="#name-since-draft-shade-quic-http" class="xref">Since draft-shade-quic-http2-mapping-00</a><a href="#section-toc.1-1.14.2.29.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.15">
+            <p id="section-toc.1-1.15.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.16">
+            <p id="section-toc.1-1.16.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.16.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</nav>
+</section>
+</div>
+<div id="introduction">
+<section id="section-1">
+      <h2 id="name-introduction">
+<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
+      </h2>
+<p id="section-1-1">HTTP semantics <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span> are used for a broad
+range of services on the Internet. These semantics have most commonly been used
+with two different TCP mappings, HTTP/1.1 and HTTP/2.  HTTP/3 supports the same
+semantics over a new transport protocol, QUIC.<a href="#section-1-1" class="pilcrow">¶</a></p>
+<div id="prior-versions-of-http">
+<section id="section-1.1">
+        <h3 id="name-prior-versions-of-http">
+<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-prior-versions-of-http" class="section-name selfRef">Prior versions of HTTP</a>
+        </h3>
+<p id="section-1.1-1">HTTP/1.1 <span>[<a href="#HTTP11" class="xref">HTTP11</a>]</span> is a TCP mapping which uses
+whitespace-delimited text fields to convey HTTP messages.  While these exchanges
+are human-readable, using whitespace for message formatting leads to parsing
+complexity and motivates tolerance of variant behavior. Because each
+connection can transfer only a single HTTP request or response at a time in each
+direction, multiple parallel TCP connections are often used, reducing the
+ability of the congestion controller to effectively manage traffic between
+endpoints.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
+<p id="section-1.1-2">HTTP/2 <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span> introduced a binary framing and multiplexing layer to
+improve latency without modifying the transport layer.  However, because the
+parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery
+mechanisms, a lost or reordered packet causes all active transactions to
+experience a stall regardless of whether that transaction was directly impacted
+by the lost packet.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="delegation-to-quic">
+<section id="section-1.2">
+        <h3 id="name-delegation-to-quic">
+<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-delegation-to-quic" class="section-name selfRef">Delegation to QUIC</a>
+        </h3>
+<p id="section-1.2-1">The QUIC transport protocol incorporates stream multiplexing and per-stream flow
+control, similar to that provided by the HTTP/2 framing layer. By providing
+reliability at the stream level and congestion control across the entire
+connection, it has the capability to improve the performance of HTTP compared to
+a TCP mapping.  QUIC also incorporates TLS 1.3 <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> at the
+transport layer, offering comparable security to running TLS over TCP, with
+the improved connection setup latency of TCP Fast Open <span>[<a href="#TFO" class="xref">TFO</a>]</span>.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
+<p id="section-1.2-2">This document defines a mapping of HTTP semantics over the QUIC transport
+protocol, drawing heavily on the design of HTTP/2.  While delegating stream
+lifetime and flow control issues to QUIC, a similar binary framing is used on
+each stream. Some HTTP/2 features are subsumed by QUIC, while other features are
+implemented atop QUIC.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
+<p id="section-1.2-3">QUIC is described in <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.  For a full description of HTTP/2, see
+<span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="http3-protocol-overview">
+<section id="section-2">
+      <h2 id="name-http-3-protocol-overview">
+<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-http-3-protocol-overview" class="section-name selfRef">HTTP/3 Protocol Overview</a>
+      </h2>
+<p id="section-2-1">HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol
+and an internal framing layer similar to HTTP/2.<a href="#section-2-1" class="pilcrow">¶</a></p>
+<p id="section-2-2">Once a client knows that an HTTP/3 server exists at a certain endpoint, it opens
+a QUIC connection. QUIC provides protocol negotiation, stream-based
+multiplexing, and flow control.  Discovery of an HTTP/3 endpoint is described in
+<a href="#discovery" class="xref">Section 3.2</a>.<a href="#section-2-2" class="pilcrow">¶</a></p>
+<p id="section-2-3">Within each stream, the basic unit of HTTP/3 communication is a frame
+(<a href="#frames" class="xref">Section 7.2</a>).  Each frame type serves a different purpose.  For example, HEADERS
+and DATA frames form the basis of HTTP requests and responses
+(<a href="#request-response" class="xref">Section 4.1</a>).<a href="#section-2-3" class="pilcrow">¶</a></p>
+<p id="section-2-4">Multiplexing of requests is performed using the QUIC stream abstraction,
+described in Section 2 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.  Each request-response pair
+consumes a single QUIC stream.  Streams are independent of each other, so one
+stream that is blocked or suffers packet loss does not prevent progress on other
+streams.<a href="#section-2-4" class="pilcrow">¶</a></p>
+<p id="section-2-5">Server push is an interaction mode introduced in HTTP/2 <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span> which permits
+a server to push a request-response exchange to a client in anticipation of the
+client making the indicated request.  This trades off network usage against a
+potential latency gain.  Several HTTP/3 frames are used to manage server push,
+such as PUSH_PROMISE, MAX_PUSH_ID, and CANCEL_PUSH.<a href="#section-2-5" class="pilcrow">¶</a></p>
+<p id="section-2-6">As in HTTP/2, request and response fields are compressed for transmission.
+Because HPACK <span>[<a href="#HPACK" class="xref">HPACK</a>]</span> relies on in-order transmission of compressed
+field sections (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with
+QPACK <span>[<a href="#QPACK" class="xref">QPACK</a>]</span>.  QPACK uses separate unidirectional streams to modify and track
+field table state, while encoded field sections refer to the state of the table
+without modifying it.<a href="#section-2-6" class="pilcrow">¶</a></p>
+<div id="document-organization">
+<section id="section-2.1">
+        <h3 id="name-document-organization">
+<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-document-organization" class="section-name selfRef">Document Organization</a>
+        </h3>
+<p id="section-2.1-1">The following sections provide a detailed overview of the connection lifecycle
+and key concepts:<a href="#section-2.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-2.1-2.1">Connection Setup and Management (<a href="#connection-setup" class="xref">Section 3</a>) covers how an HTTP/3
+endpoint is discovered and a connection is established.<a href="#section-2.1-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-2.2">HTTP Request Lifecycle (<a href="#http-request-lifecycle" class="xref">Section 4</a>) describes how HTTP
+semantics are expressed using frames.<a href="#section-2.1-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-2.3">Connection Closure (<a href="#connection-closure" class="xref">Section 5</a>) describes how connections are
+terminated, either gracefully or abruptly.<a href="#section-2.1-2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-2.1-3">The details of the wire protocol and interactions with the transport are
+described in subsequent sections:<a href="#section-2.1-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-2.1-4.1">Stream Mapping and Usage (<a href="#stream-mapping" class="xref">Section 6</a>) describes the way QUIC streams
+are used.<a href="#section-2.1-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-4.2">HTTP Framing Layer (<a href="#http-framing-layer" class="xref">Section 7</a>) describes the frames used on
+most streams.<a href="#section-2.1-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-4.3">Error Handling (<a href="#errors" class="xref">Section 8</a>) describes how error conditions are handled and
+expressed, either on a particular stream or for the connection as a whole.<a href="#section-2.1-4.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-2.1-5">Additional resources are provided in the final sections:<a href="#section-2.1-5" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-2.1-6.1">Extensions to HTTP/3 (<a href="#extensions" class="xref">Section 9</a>) describes how new capabilities can be
+added in future documents.<a href="#section-2.1-6.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-6.2">A more detailed comparison between HTTP/2 and HTTP/3 can be found in
+<a href="#h2-considerations" class="xref">Appendix A</a>.<a href="#section-2.1-6.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="conventions-and-terminology">
+<section id="section-2.2">
+        <h3 id="name-conventions-and-terminology">
+<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-conventions-and-terminology" class="section-name selfRef">Conventions and Terminology</a>
+        </h3>
+<p id="section-2.2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
+"MAY", and "OPTIONAL" in this document are to be interpreted as
+described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they
+appear in all capitals, as shown here.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
+<p id="section-2.2-2">Field definitions are given in Augmented Backus-Naur Form (ABNF), as defined in
+<span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span>.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
+<p id="section-2.2-3">This document uses the variable-length integer encoding from
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
+<p id="section-2.2-4">The following terms are used:<a href="#section-2.2-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-2.2-5">
+          <dt id="section-2.2-5.1">abort:</dt>
+<dd id="section-2.2-5.2">
+  An abrupt termination of a connection or stream, possibly due to an error
+condition.<a href="#section-2.2-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.3">client:</dt>
+<dd id="section-2.2-5.4">
+  The endpoint that initiates an HTTP/3 connection.  Clients send HTTP requests
+and receive HTTP responses.<a href="#section-2.2-5.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.5">connection:</dt>
+<dd id="section-2.2-5.6">
+  A transport-layer connection between two endpoints, using QUIC as the
+transport protocol.<a href="#section-2.2-5.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.7">connection error:</dt>
+<dd id="section-2.2-5.8">
+  An error that affects the entire HTTP/3 connection.<a href="#section-2.2-5.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.9">endpoint:</dt>
+<dd id="section-2.2-5.10">
+  Either the client or server of the connection.<a href="#section-2.2-5.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.11">frame:</dt>
+<dd id="section-2.2-5.12">
+  The smallest unit of communication on a stream in HTTP/3, consisting of a
+header and a variable-length sequence of bytes structured according to the
+frame type.
+
+Protocol elements called "frames" exist in both this document and
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>. Where frames from <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> are referenced, the
+frame name will be prefaced with "QUIC."  For example, "QUIC CONNECTION_CLOSE
+frames."  References without this preface refer to frames defined in
+<a href="#frames" class="xref">Section 7.2</a>.<a href="#section-2.2-5.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.13">peer:</dt>
+<dd id="section-2.2-5.14">
+  An endpoint.  When discussing a particular endpoint, "peer" refers to the
+endpoint that is remote to the primary subject of discussion.<a href="#section-2.2-5.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.15">receiver:</dt>
+<dd id="section-2.2-5.16">
+  An endpoint that is receiving frames.<a href="#section-2.2-5.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.17">sender:</dt>
+<dd id="section-2.2-5.18">
+  An endpoint that is transmitting frames.<a href="#section-2.2-5.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.19">server:</dt>
+<dd id="section-2.2-5.20">
+  The endpoint that accepts an HTTP/3 connection.  Servers receive HTTP requests
+and send HTTP responses.<a href="#section-2.2-5.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.21">stream:</dt>
+<dd id="section-2.2-5.22">
+  A bidirectional or unidirectional bytestream provided by the QUIC transport.<a href="#section-2.2-5.22" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2.2-5.23">stream error:</dt>
+<dd id="section-2.2-5.24">
+  An error on the individual HTTP/3 stream.<a href="#section-2.2-5.24" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-2.2-6">The term "payload body" is defined in Section 6.3.3 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-2.2-6" class="pilcrow">¶</a></p>
+<p id="section-2.2-7">Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are defined
+in Section 2.2 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.  Intermediaries act as both client and server
+at different times.<a href="#section-2.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="connection-setup">
+<section id="section-3">
+      <h2 id="name-connection-setup-and-manage">
+<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-connection-setup-and-manage" class="section-name selfRef">Connection Setup and Management</a>
+      </h2>
+<div id="draft-version-identification">
+<section id="section-3.1">
+        <h3 id="name-draft-version-identificatio">
+<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-draft-version-identificatio" class="section-name selfRef">Draft Version Identification</a>
+        </h3>
+<ul class="normal ulEmpty">
+<li class="normal ulEmpty" id="section-3.1-1.1">
+            <strong>RFC Editor's Note:</strong>  Please remove this section prior to publication of a
+final version of this document.<a href="#section-3.1-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-3.1-2">HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc.  Only
+implementations of the final, published RFC can identify themselves as "h3".
+Until such an RFC exists, implementations MUST NOT identify themselves using
+this string.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
+<p id="section-3.1-3">Implementations of draft versions of the protocol MUST add the string "-" and
+the corresponding draft number to the identifier. For example,
+draft-ietf-quic-http-01 is identified using the string "h3-01".<a href="#section-3.1-3" class="pilcrow">¶</a></p>
+<p id="section-3.1-4">Draft versions MUST use the corresponding draft transport version as their
+transport. For example, the application protocol defined in
+draft-ietf-quic-http-25 uses the transport defined in
+draft-ietf-quic-transport-25.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
+<p id="section-3.1-5">Non-compatible experiments that are based on these draft versions MUST append
+the string "-" and an experiment name to the identifier. For example, an
+experimental implementation based on draft-ietf-quic-http-09 which reserves an
+extra stream for unsolicited transmission of 1980s pop music might identify
+itself as "h3-09-rickroll". Note that any label MUST conform to the "token"
+syntax defined in Section 4.4.1.1 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>. Experimenters are
+encouraged to coordinate their experiments on the
+<a href="mailto:quic@ietf.org">quic@ietf.org</a> mailing list.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="discovery">
+<section id="section-3.2">
+        <h3 id="name-discovering-an-http-3-endpo">
+<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-discovering-an-http-3-endpo" class="section-name selfRef">Discovering an HTTP/3 Endpoint</a>
+        </h3>
+<p id="section-3.2-1">HTTP relies on the notion of an authoritative response: a response that has been
+determined to be the most appropriate response for that request given the state
+of the target resource at the time of response message origination by (or at the
+direction of) the origin server identified within the target URI.  Locating an
+authoritative server for an HTTP URL is discussed in Section 5.4 of
+<span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
+<p id="section-3.2-2">The "https" scheme associates authority with possession of a certificate that
+the client considers to be trustworthy for the host identified by the authority
+component of the URL. If a server presents a certificate and proof that it
+controls the corresponding private key, then a client will accept a secured
+connection to that server as being authoritative for all origins with the
+"https" scheme and a host identified in the certificate.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
+<p id="section-3.2-3">A client MAY attempt access to a resource with an "https" URI by resolving the
+host identifier to an IP address, establishing a QUIC connection to that address
+on the indicated port, and sending an HTTP/3 request message targeting the URI
+to the server over that secured connection.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
+<p id="section-3.2-4">Connectivity problems (e.g., blocking UDP) can result in QUIC connection
+establishment failure; clients SHOULD attempt to use TCP-based versions of HTTP
+in this case.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
+<p id="section-3.2-5">Servers MAY serve HTTP/3 on any UDP port; an alternative service advertisement
+always includes an explicit port, and URLs contain either an explicit port or a
+default port associated with the scheme.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
+<div id="alt-svc">
+<section id="section-3.2.1">
+          <h4 id="name-http-alternative-services">
+<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-http-alternative-services" class="section-name selfRef">HTTP Alternative Services</a>
+          </h4>
+<p id="section-3.2.1-1">An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via
+the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame (<span>[<a href="#ALTSVC" class="xref">ALTSVC</a>]</span>),
+using the ALPN token defined in <a href="#connection-establishment" class="xref">Section 3.3</a>.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-3.2.1-2">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:<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft art-example" id="section-3.2.1-3">
+<pre>
+Alt-Svc: h3=":50781"
+</pre><a href="#section-3.2.1-3" class="pilcrow">¶</a>
+</div>
+<p id="section-3.2.1-4">On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt
+to establish a QUIC connection to the indicated host and port and, if
+successful, send HTTP requests using the mapping described in this document.<a href="#section-3.2.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="other-schemes">
+<section id="section-3.2.2">
+          <h4 id="name-other-schemes">
+<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-other-schemes" class="section-name selfRef">Other Schemes</a>
+          </h4>
+<p id="section-3.2.2-1">Although HTTP is independent of the transport protocol, the "http" scheme
+associates authority with the ability to receive TCP connections on the
+indicated port of whatever host is identified within the authority component.
+Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the
+authoritative server for a resource identified by an "http" URI.  However,
+protocol extensions such as <span>[<a href="#ALTSVC" class="xref">ALTSVC</a>]</span> permit the authoritative server
+to identify other services which are also authoritative and which might be
+reachable over HTTP/3.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-3.2.2-2">Prior to making requests for an origin whose scheme is not "https", the client
+MUST ensure the server is willing to serve that scheme.  If the client intends
+to make requests for an origin whose scheme is "http", this means that it MUST
+obtain a valid <code>http-opportunistic</code> response for the origin as described in
+<span>[<a href="#RFC8164" class="xref">RFC8164</a>]</span> prior to making any such requests.  Other schemes might define
+other mechanisms.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="connection-establishment">
+<section id="section-3.3">
+        <h3 id="name-connection-establishment">
+<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-connection-establishment" class="section-name selfRef">Connection Establishment</a>
+        </h3>
+<p id="section-3.3-1">HTTP/3 relies on QUIC version 1 as the underlying transport.  The use of other
+QUIC transport versions with HTTP/3 MAY be defined by future specifications.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
+<p id="section-3.3-2">QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol.
+HTTP/3 clients MUST support a mechanism to indicate the target host to the
+server during the TLS handshake.  If the server is identified by a DNS name,
+clients MUST send the Server Name Indication (SNI) <span>[<a href="#RFC6066" class="xref">RFC6066</a>]</span> TLS extension
+unless an alternative mechanism to indicate the target host is used.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
+<p id="section-3.3-3">QUIC connections are established as described in <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>. During
+connection establishment, HTTP/3 support is indicated by selecting the ALPN
+token "h3" in the TLS handshake.  Support for other application-layer protocols
+MAY be offered in the same handshake.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
+<p id="section-3.3-4">While connection-level options pertaining to the core QUIC protocol are set in
+the initial crypto handshake, HTTP/3-specific settings are conveyed in the
+SETTINGS frame. After the QUIC connection is established, a SETTINGS frame
+(<a href="#frame-settings" class="xref">Section 7.2.4</a>) MUST be sent by each endpoint as the initial frame of their
+respective HTTP control stream; see <a href="#control-streams" class="xref">Section 6.2.1</a>.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="connection-reuse">
+<section id="section-3.4">
+        <h3 id="name-connection-reuse">
+<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-connection-reuse" class="section-name selfRef">Connection Reuse</a>
+        </h3>
+<p id="section-3.4-1">HTTP/3 connections are persistent across multiple requests.  For best
+performance, it is expected that clients will not close connections until it is
+determined that no further communication with a server is necessary (for
+example, when a user navigates away from a particular web page) or until the
+server closes the connection.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
+<p id="section-3.4-2">Once a connection exists to a server endpoint, this connection MAY be reused for
+requests with multiple different URI authority components.  In general, a server
+is considered authoritative for all URIs with the "https" scheme for which the
+hostname in the URI is present in the authenticated certificate provided by the
+server, either as the CN field of the certificate subject or as a dNSName in the
+subjectAltName field of the certificate; see <span>[<a href="#RFC6125" class="xref">RFC6125</a>]</span>.  For a host that is
+an IP address, the client MUST verify that the address appears as an iPAddress
+in the subjectAltName field of the certificate.  If the hostname or address is
+not present in the certificate, the client MUST NOT consider the server
+authoritative for origins containing that hostname or address.  See Section 5.4
+of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span> for more detail on authoritative access.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
+<p id="section-3.4-3">Clients SHOULD NOT open more than one HTTP/3 connection to a given host and port
+pair, where the host is derived from a URI, a selected alternative service
+<span>[<a href="#ALTSVC" class="xref">ALTSVC</a>]</span>, or a configured proxy.  A client MAY open multiple connections to
+the same IP address and UDP port using different transport or TLS configurations
+but SHOULD avoid creating multiple connections with the same configuration.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
+<p id="section-3.4-4">Servers are encouraged to maintain open connections for as long as possible but
+are permitted to terminate idle connections if necessary.  When either endpoint
+chooses to close the HTTP/3 session, the terminating endpoint SHOULD first send
+a GOAWAY frame (<a href="#connection-shutdown" class="xref">Section 5.2</a>) so that both endpoints can reliably
+determine whether previously sent frames have been processed and gracefully
+complete or terminate any necessary remaining tasks.<a href="#section-3.4-4" class="pilcrow">¶</a></p>
+<p id="section-3.4-5">A server that does not wish clients to reuse connections for a particular origin
+can indicate that it is not authoritative for a request by sending a 421
+(Misdirected Request) status code in response to the request; see Section 9.1.2
+of <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>.<a href="#section-3.4-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="http-request-lifecycle">
+<section id="section-4">
+      <h2 id="name-http-request-lifecycle">
+<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-http-request-lifecycle" class="section-name selfRef">HTTP Request Lifecycle</a>
+      </h2>
+<div id="request-response">
+<section id="section-4.1">
+        <h3 id="name-http-message-exchanges">
+<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-http-message-exchanges" class="section-name selfRef">HTTP Message Exchanges</a>
+        </h3>
+<p id="section-4.1-1">A client sends an HTTP request on a client-initiated bidirectional QUIC stream.
+A client MUST send only a single request on a given stream. A server sends zero
+or more interim HTTP responses on the same stream as the request, followed by a
+single final HTTP response, as detailed below.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.1-2">Pushed responses are sent on a server-initiated unidirectional QUIC stream; see
+<a href="#push-streams" class="xref">Section 6.2.2</a>.  A server sends zero or more interim HTTP responses, followed
+by a single final HTTP response, in the same manner as a standard response.
+Push is described in more detail in <a href="#server-push" class="xref">Section 4.4</a>.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.1-3">On a given stream, receipt of multiple requests or receipt of an additional HTTP
+response following a final HTTP response MUST be treated as malformed
+(<a href="#malformed" class="xref">Section 4.1.3</a>).<a href="#section-4.1-3" class="pilcrow">¶</a></p>
+<p id="section-4.1-4">An HTTP message (request or response) consists of:<a href="#section-4.1-4" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-4.1-5">
+          <li id="section-4.1-5.1">the header field section (see Section 4 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>), sent as a single
+HEADERS frame (see <a href="#frame-headers" class="xref">Section 7.2.2</a>),<a href="#section-4.1-5.1" class="pilcrow">¶</a>
+</li>
+<li id="section-4.1-5.2">optionally, the payload body, if present (see Section 6.3.3 of
+<span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>), sent as a series of DATA frames (see <a href="#frame-data" class="xref">Section 7.2.1</a>),<a href="#section-4.1-5.2" class="pilcrow">¶</a>
+</li>
+<li id="section-4.1-5.3">optionally, the trailer field section, if present (see Section 4.6 of
+<span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>), sent as a single HEADERS frame.<a href="#section-4.1-5.3" class="pilcrow">¶</a>
+</li>
+</ol>
+<p id="section-4.1-6">Receipt of an invalid sequence of frames MUST be treated as a connection error
+of type H3_FRAME_UNEXPECTED (<a href="#errors" class="xref">Section 8</a>).  In particular, a DATA frame before
+any HEADERS frame, or a HEADERS or DATA frame after the trailing HEADERS frame
+is considered invalid.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
+<p id="section-4.1-7">A server MAY send one or more PUSH_PROMISE frames (see <a href="#frame-push-promise" class="xref">Section 7.2.5</a>)
+before, after, or interleaved with the frames of a response message. These
+PUSH_PROMISE frames are not part of the response; see <a href="#server-push" class="xref">Section 4.4</a> for more
+details.  These frames are not permitted in pushed responses; a pushed response
+which includes PUSH_PROMISE frames MUST be treated as a connection error of type
+H3_FRAME_UNEXPECTED.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
+<p id="section-4.1-8">Frames of unknown types (<a href="#extensions" class="xref">Section 9</a>), including reserved frames
+(<a href="#frame-reserved" class="xref">Section 7.2.8</a>) MAY be sent on a request or push stream before, after, or
+interleaved with other frames described in this section.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
+<p id="section-4.1-9">The HEADERS and PUSH_PROMISE frames might reference updates to the QPACK dynamic
+table. While these updates are not directly part of the message exchange, they
+must be received and processed before the message can be consumed.  See
+<a href="#header-formatting" class="xref">Section 4.1.1</a> for more details.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
+<p id="section-4.1-10">The "chunked" transfer encoding defined in Section 7.1 of <span>[<a href="#HTTP11" class="xref">HTTP11</a>]</span> MUST NOT
+be used.<a href="#section-4.1-10" class="pilcrow">¶</a></p>
+<p id="section-4.1-11">A response MAY consist of multiple messages when and only when one or more
+informational responses (1xx; see Section 9.2 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>) precede a final
+response to the same request.  Interim responses do not contain a payload body
+or trailers.<a href="#section-4.1-11" class="pilcrow">¶</a></p>
+<p id="section-4.1-12">An HTTP request/response exchange fully consumes a client-initiated
+bidirectional QUIC stream. After sending a request, a client MUST close the
+stream for sending.  Unless using the CONNECT method (see <a href="#connect" class="xref">Section 4.2</a>), clients
+MUST NOT make stream closure dependent on receiving a response to their request.
+After sending a final response, the server MUST close the stream for sending. At
+this point, the QUIC stream is fully closed.<a href="#section-4.1-12" class="pilcrow">¶</a></p>
+<p id="section-4.1-13">When a stream is closed, this indicates the end of an HTTP message. Because some
+messages are large or unbounded, endpoints SHOULD begin processing partial HTTP
+messages once enough of the message has been received to make progress.  If a
+client stream terminates without enough of the HTTP message to provide a
+complete response, the server SHOULD abort its response with the error code
+H3_REQUEST_INCOMPLETE.<a href="#section-4.1-13" class="pilcrow">¶</a></p>
+<p id="section-4.1-14">A server can send a complete response prior to the client sending an entire
+request if the response does not depend on any portion of the request that has
+not been sent and received. When the server does not need to receive the
+remainder of the request, it MAY abort reading the request stream, send a
+complete response, and cleanly close the sending part of the stream.  The error
+code H3_NO_ERROR SHOULD be used when requesting that the client stop sending on
+the request stream.  Clients MUST NOT discard complete responses as a result of
+having their request terminated abruptly, though clients can always discard
+responses at their discretion for other reasons.  If the server sends a partial
+or complete response but does not abort reading, clients SHOULD continue sending
+the body of the request and close the stream normally.<a href="#section-4.1-14" class="pilcrow">¶</a></p>
+<div id="header-formatting">
+<section id="section-4.1.1">
+          <h4 id="name-field-formatting-and-compre">
+<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-field-formatting-and-compre" class="section-name selfRef">Field Formatting and Compression</a>
+          </h4>
+<p id="section-4.1.1-1">HTTP messages carry metadata as a series of key-value pairs, called HTTP fields.
+For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol
+(HTTP) Field Name Registry" maintained at
+<span><a href="https://www.iana.org/assignments/http-fields/">https://www.iana.org/assignments/http-fields/</a></span>.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.1-2">As in previous versions of HTTP, field names are strings containing a subset of
+ASCII characters that are compared in a case-insensitive fashion.  Properties of
+HTTP field names and values are discussed in more detail in Section 4.3 of
+<span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.  As in HTTP/2, characters in field names MUST be converted to
+lowercase prior to their encoding.  A request or response containing uppercase
+characters in field names MUST be treated as malformed (<a href="#malformed" class="xref">Section 4.1.3</a>).<a href="#section-4.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.1.1-3">Like HTTP/2, HTTP/3 does not use the Connection header field to indicate
+connection-specific fields; in this protocol, connection-specific metadata is
+conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section
+containing connection-specific fields; any message containing
+connection-specific fields MUST be treated as malformed (<a href="#malformed" class="xref">Section 4.1.3</a>).<a href="#section-4.1.1-3" class="pilcrow">¶</a></p>
+<p id="section-4.1.1-4">The only exception to this is the TE header field, which MAY be present in an
+HTTP/3 request header; when it is, it MUST NOT contain any value other than
+"trailers".<a href="#section-4.1.1-4" class="pilcrow">¶</a></p>
+<p id="section-4.1.1-5">This means that an intermediary transforming an HTTP/1.x message to HTTP/3 will
+need to remove any fields nominated by the Connection field, along with the
+Connection field itself.  Such intermediaries SHOULD also remove other
+connection-specific fields, such as Keep-Alive, Proxy-Connection,
+Transfer-Encoding, and Upgrade, even if they are not nominated by the Connection
+field.<a href="#section-4.1.1-5" class="pilcrow">¶</a></p>
+<div id="pseudo-header-fields">
+<section id="section-4.1.1.1">
+            <h5 id="name-pseudo-header-fields">
+<a href="#section-4.1.1.1" class="section-number selfRef">4.1.1.1. </a><a href="#name-pseudo-header-fields" class="section-name selfRef">Pseudo-Header Fields</a>
+            </h5>
+<p id="section-4.1.1.1-1">Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where the field
+name begins with the ':' character (ASCII 0x3a).  These pseudo-header fields
+convey the target URI, the method of the request, and the status code for the
+response.<a href="#section-4.1.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-2">Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT generate
+pseudo-header fields other than those defined in this document, except as
+negotiated via an extension; see <a href="#extensions" class="xref">Section 9</a>.<a href="#section-4.1.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-3">Pseudo-header fields are only valid in the context in which they are defined.
+Pseudo-header fields defined for requests MUST NOT appear in responses;
+pseudo-header fields defined for responses MUST NOT appear in requests.
+Pseudo-header fields MUST NOT appear in trailers.  Endpoints MUST treat a
+request or response that contains undefined or invalid pseudo-header fields as
+malformed (<a href="#malformed" class="xref">Section 4.1.3</a>).<a href="#section-4.1.1.1-3" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-4">All pseudo-header fields MUST appear in the header field section before regular
+header fields.  Any request or response that contains a pseudo-header field that
+appears in a header field section after a regular header field MUST be treated
+as malformed (<a href="#malformed" class="xref">Section 4.1.3</a>).<a href="#section-4.1.1.1-4" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-5">The following pseudo-header fields are defined for requests:<a href="#section-4.1.1.1-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-4.1.1.1-6">
+              <dt id="section-4.1.1.1-6.1">":method":</dt>
+<dd id="section-4.1.1.1-6.2">
+  Contains the HTTP method (Section 7 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>)<a href="#section-4.1.1.1-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4.1.1.1-6.3">":scheme":</dt>
+<dd id="section-4.1.1.1-6.4">
+  Contains the scheme portion of the target URI (Section 3.1 of <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>)<a href="#section-4.1.1.1-6.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4.1.1.1-6.5"></dt>
+<dd id="section-4.1.1.1-6.6">":scheme" is not restricted to "http" and "https" schemed URIs.  A proxy or
+gateway can translate requests for non-HTTP schemes, enabling the use of
+HTTP to interact with non-HTTP services.<a href="#section-4.1.1.1-6.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4.1.1.1-6.7">":authority":</dt>
+<dd id="section-4.1.1.1-6.8">
+  Contains the authority portion of the target URI (Section 3.2 of
+<span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>). The authority MUST NOT include the deprecated "userinfo"
+subcomponent for "http" or "https" schemed URIs.<a href="#section-4.1.1.1-6.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4.1.1.1-6.9"></dt>
+<dd id="section-4.1.1.1-6.10">To ensure that the HTTP/1.1 request line can be reproduced accurately, this
+pseudo-header field MUST be omitted when translating from an HTTP/1.1
+request that has a request target in origin or asterisk form; see Section
+3.2 of <span>[<a href="#HTTP11" class="xref">HTTP11</a>]</span>.  Clients that generate HTTP/3 requests directly SHOULD
+use the ":authority" pseudo-header field instead of the Host field. An
+intermediary that converts an HTTP/3 request to HTTP/1.1 MUST create a Host
+field if one is not present in a request by copying the value of the
+":authority" pseudo-header field.<a href="#section-4.1.1.1-6.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4.1.1.1-6.11">":path":</dt>
+<dd id="section-4.1.1.1-6.12">
+  Contains the path and query parts of the target URI (the "path-absolute"
+production and optionally a '?' character followed by the "query"
+production; see Sections 3.3 and 3.4 of <span>[<a href="#URI" class="xref">URI</a>]</span>.  A request in
+asterisk form includes the value '*' for the ":path" pseudo-header field.<a href="#section-4.1.1.1-6.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4.1.1.1-6.13"></dt>
+<dd id="section-4.1.1.1-6.14">This pseudo-header field MUST NOT be empty for "http" or "https" URIs;
+"http" or "https" URIs that do not contain a path component MUST include a
+value of '/'.  The exception to this rule is an OPTIONS request for an
+"http" or "https" URI that does not include a path component; these MUST
+include a ":path" pseudo-header field with a value of '*'; see Section 3.2.4
+of <span>[<a href="#HTTP11" class="xref">HTTP11</a>]</span>.<a href="#section-4.1.1.1-6.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-4.1.1.1-7">All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme",
+and ":path" pseudo-header fields, unless it is a CONNECT request; see
+<a href="#connect" class="xref">Section 4.2</a>.<a href="#section-4.1.1.1-7" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-8">If the ":scheme" pseudo-header field identifies a scheme which has a mandatory
+authority component (including "http" and "https"), the request MUST contain
+either an ":authority" pseudo-header field or a "Host" header field.  If these
+fields are present, they MUST NOT be empty.  If both fields are present, they
+MUST contain the same value.  If the scheme does not have a mandatory authority
+component and none is provided in the request target, the request MUST NOT
+contain the ":authority" pseudo-header and "Host" header fields.<a href="#section-4.1.1.1-8" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-9">An HTTP request that omits mandatory pseudo-header fields or contains invalid
+values for those pseudo-header fields is malformed (<a href="#malformed" class="xref">Section 4.1.3</a>).<a href="#section-4.1.1.1-9" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-10">HTTP/3 does not define a way to carry the version identifier that is included in
+the HTTP/1.1 request line.<a href="#section-4.1.1.1-10" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-11">For responses, a single ":status" pseudo-header field is defined that carries
+the HTTP status code; see Section 9 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.  This pseudo-header
+field MUST be included in all responses; otherwise, the response is malformed
+(<a href="#malformed" class="xref">Section 4.1.3</a>).<a href="#section-4.1.1.1-11" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.1-12">HTTP/3 does not define a way to carry the version or reason phrase that is
+included in an HTTP/1.1 status line.<a href="#section-4.1.1.1-12" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="field-compression">
+<section id="section-4.1.1.2">
+            <h5 id="name-field-compression">
+<a href="#section-4.1.1.2" class="section-number selfRef">4.1.1.2. </a><a href="#name-field-compression" class="section-name selfRef">Field Compression</a>
+            </h5>
+<p id="section-4.1.1.2-1">HTTP/3 uses QPACK field compression as described in <span>[<a href="#QPACK" class="xref">QPACK</a>]</span>, a variation of
+HPACK which allows the flexibility to avoid compression-induced head-of-line
+blocking.  See that document for additional details.<a href="#section-4.1.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.2-2">To allow for better compression efficiency, the "Cookie" field <span>[<a href="#RFC6265" class="xref">RFC6265</a>]</span> MAY
+be split into separate field lines, each with one or more cookie-pairs, before
+compression. If a decompressed field section contains multiple cookie field
+lines, these MUST be concatenated into a single octet string using the two-octet
+delimiter of 0x3B, 0x20 (the ASCII string "; ") before being passed into a
+context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a
+generic HTTP server application.<a href="#section-4.1.1.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="header-size-constraints">
+<section id="section-4.1.1.3">
+            <h5 id="name-header-size-constraints">
+<a href="#section-4.1.1.3" class="section-number selfRef">4.1.1.3. </a><a href="#name-header-size-constraints" class="section-name selfRef">Header Size Constraints</a>
+            </h5>
+<p id="section-4.1.1.3-1">An HTTP/3 implementation MAY impose a limit on the maximum size of the message
+header it will accept on an individual HTTP message.  A server that receives a
+larger header section than it is willing to handle can send an HTTP 431 (Request
+Header Fields Too Large) status code (<span>[<a href="#RFC6585" class="xref">RFC6585</a>]</span>).  A client can discard
+responses that it cannot process.  The size of a field list is calculated based
+on the uncompressed size of fields, including the length of the name and value
+in bytes plus an overhead of 32 bytes for each field.<a href="#section-4.1.1.3-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.1.3-2">If an implementation wishes to advise its peer of this limit, it can be conveyed
+as a number of bytes in the SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An
+implementation which has received this parameter SHOULD NOT send an HTTP message
+header which exceeds the indicated size, as the peer will likely refuse to
+process it.  However, because this limit is applied at each hop, messages below
+this limit are not guaranteed to be accepted.<a href="#section-4.1.1.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="request-cancellation">
+<section id="section-4.1.2">
+          <h4 id="name-request-cancellation-and-re">
+<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-request-cancellation-and-re" class="section-name selfRef">Request Cancellation and Rejection</a>
+          </h4>
+<p id="section-4.1.2-1">Clients can cancel requests by resetting and aborting the request stream with an
+error code of H3_REQUEST_CANCELLED (<a href="#http-error-codes" class="xref">Section 8.1</a>).  When the client
+aborts reading a response, it indicates that this response is no longer of
+interest. Implementations SHOULD cancel requests by abruptly terminating any
+directions of a stream that are still open.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-2">When the server rejects a request without performing any application processing,
+it SHOULD abort its response stream with the error code H3_REQUEST_REJECTED.
+In this context, "processed" means that some data from the stream was passed to
+some higher layer of software that might have taken some action as a result. The
+client can treat requests rejected by the server as though they had never been
+sent at all, thereby allowing them to be retried later on a new connection.
+Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests which
+were partially or fully processed.  When a server abandons a response after
+partial processing, it SHOULD abort its response stream with the error code
+H3_REQUEST_CANCELLED.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-3">When a client resets a request with the error code H3_REQUEST_CANCELLED, a
+server MAY abruptly terminate the response using the error code
+H3_REQUEST_REJECTED if no processing was performed.  Clients MUST NOT use the
+H3_REQUEST_REJECTED error code, except when a server has requested closure of
+the request stream with this error code.<a href="#section-4.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-4">If a stream is cancelled after receiving a complete response, the client MAY
+ignore the cancellation and use the response.  However, if a stream is cancelled
+after receiving a partial response, the response SHOULD NOT be used.
+Automatically retrying such requests is not possible, unless this is otherwise
+permitted (e.g., idempotent actions like GET, PUT, or DELETE).<a href="#section-4.1.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="malformed">
+<section id="section-4.1.3">
+          <h4 id="name-malformed-requests-and-resp">
+<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-malformed-requests-and-resp" class="section-name selfRef">Malformed Requests and Responses</a>
+          </h4>
+<p id="section-4.1.3-1">A malformed request or response is one that is an otherwise valid sequence of
+frames but is invalid due to:<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.1.3-2.1">the presence of prohibited fields or pseudo-header fields,<a href="#section-4.1.3-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.3-2.2">the absence of mandatory pseudo-header fields,<a href="#section-4.1.3-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.3-2.3">invalid values for pseudo-header fields,<a href="#section-4.1.3-2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.3-2.4">pseudo-header fields after fields,<a href="#section-4.1.3-2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.3-2.5">an invalid sequence of HTTP messages,<a href="#section-4.1.3-2.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.3-2.6">the inclusion of uppercase field names, or<a href="#section-4.1.3-2.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.3-2.7">the inclusion of invalid characters in field names or values<a href="#section-4.1.3-2.7" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.1.3-3">A request or response that includes a payload body can include a
+Content-Length header field.  A request or response is also malformed if the
+value of a content-length header field does not equal the sum of the DATA frame
+payload lengths that form the body.  A response that is defined to have no
+payload, as described in Section 6.3.3 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span> can have a non-zero
+content-length field, even though no content is included in DATA frames.<a href="#section-4.1.3-3" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-4">Intermediaries that process HTTP requests or responses (i.e., any intermediary
+not acting as a tunnel) MUST NOT forward a malformed request or response.
+Malformed requests or responses that are detected MUST be treated as a stream
+error (<a href="#errors" class="xref">Section 8</a>) of type H3_GENERAL_PROTOCOL_ERROR.<a href="#section-4.1.3-4" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-5">For malformed requests, a server MAY send an HTTP response prior to closing or
+resetting the stream.  Clients MUST NOT accept a malformed response.  Note that
+these requirements are intended to protect against several types of common
+attacks against HTTP; they are deliberately strict because being permissive can
+expose implementations to these vulnerabilities.<a href="#section-4.1.3-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="connect">
+<section id="section-4.2">
+        <h3 id="name-the-connect-method">
+<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-the-connect-method" class="section-name selfRef">The CONNECT Method</a>
+        </h3>
+<p id="section-4.2-1">The CONNECT method requests that the recipient establish a tunnel to the
+destination origin server identified by the request-target (Section 3.2 of
+<span>[<a href="#HTTP11" class="xref">HTTP11</a>]</span>).  It is primarily used with HTTP proxies to establish a TLS
+session with an origin server for the purposes of interacting with "https"
+resources.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.2-2">In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnel
+to a remote host. In HTTP/2 and HTTP/3, the CONNECT method is used to establish
+a tunnel over a single stream.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
+<p id="section-4.2-3">A CONNECT request MUST be constructed as follows:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.2-4.1">The ":method" pseudo-header field is set to "CONNECT"<a href="#section-4.2-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.2-4.2">The ":scheme" and ":path" pseudo-header fields are omitted<a href="#section-4.2-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.2-4.3">The ":authority" pseudo-header field contains the host and port to connect to
+(equivalent to the authority-form of the request-target of CONNECT requests;
+see Section 3.2.3 of <span>[<a href="#HTTP11" class="xref">HTTP11</a>]</span>)<a href="#section-4.2-4.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.2-5">The request stream remains open at the end of the request to carry the data to
+be transferred.  A CONNECT request that does not conform to these restrictions
+is malformed; see <a href="#malformed" class="xref">Section 4.1.3</a>.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
+<p id="section-4.2-6">A proxy that supports CONNECT establishes a TCP connection (<span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span>) to the
+server identified in the ":authority" pseudo-header field.  Once this connection
+is successfully established, the proxy sends a HEADERS frame containing a 2xx
+series status code to the client, as defined in Section 9.3 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
+<p id="section-4.2-7">All DATA frames on the stream correspond to data sent or received on the TCP
+connection. Any DATA frame sent by the client is transmitted by the proxy to the
+TCP server; data received from the TCP server is packaged into DATA frames by
+the proxy. Note that the size and number of TCP segments is not guaranteed to
+map predictably to the size and number of HTTP DATA or QUIC STREAM frames.<a href="#section-4.2-7" class="pilcrow">¶</a></p>
+<p id="section-4.2-8">Once the CONNECT method has completed, only DATA frames are permitted
+to be sent on the stream.  Extension frames MAY be used if specifically
+permitted by the definition of the extension.  Receipt of any other frame type
+MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.<a href="#section-4.2-8" class="pilcrow">¶</a></p>
+<p id="section-4.2-9">The TCP connection can be closed by either peer. When the client ends the
+request stream (that is, the receive stream at the proxy enters the "Data Recvd"
+state), the proxy will set the FIN bit on its connection to the TCP server. When
+the proxy receives a packet with the FIN bit set, it will terminate the send
+stream that it sends to the client. TCP connections which remain half-closed in
+a single direction are not invalid, but are often handled poorly by servers, so
+clients SHOULD NOT close a stream for sending while they still expect to receive
+data from the target of the CONNECT.<a href="#section-4.2-9" class="pilcrow">¶</a></p>
+<p id="section-4.2-10">A TCP connection error is signaled by abruptly terminating the stream. A proxy
+treats any error in the TCP connection, which includes receiving a TCP segment
+with the RST bit set, as a stream error of type H3_CONNECT_ERROR
+(<a href="#http-error-codes" class="xref">Section 8.1</a>).  Correspondingly, if a proxy detects an error with the
+stream or the QUIC connection, it MUST close the TCP connection.  If the
+underlying TCP implementation permits it, the proxy SHOULD send a TCP segment
+with the RST bit set.<a href="#section-4.2-10" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="http-upgrade">
+<section id="section-4.3">
+        <h3 id="name-http-upgrade">
+<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-http-upgrade" class="section-name selfRef">HTTP Upgrade</a>
+        </h3>
+<p id="section-4.3-1">HTTP/3 does not support the HTTP Upgrade mechanism (Section 9.9 of <span>[<a href="#HTTP11" class="xref">HTTP11</a>]</span>)
+or 101 (Switching Protocols) informational status code (Section 9.2.2 of
+<span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>).<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="server-push">
+<section id="section-4.4">
+        <h3 id="name-server-push">
+<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-server-push" class="section-name selfRef">Server Push</a>
+        </h3>
+<p id="section-4.4-1">Server push is an interaction mode which permits a server to push a
+request-response exchange to a client in anticipation of the client making the
+indicated request.  This trades off network usage against a potential latency
+gain.  HTTP/3 server push is similar to what is described in HTTP/2 <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>,
+but uses different mechanisms.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
+<p id="section-4.4-2">Each server push is identified by a unique Push ID. This Push ID is used in one
+or more PUSH_PROMISE frames (see <a href="#frame-push-promise" class="xref">Section 7.2.5</a>) that carry the request
+fields, then included with the push stream which ultimately fulfills those
+promises. When the same Push ID is promised on multiple request streams, the
+decompressed request field sections MUST contain the same fields in the
+same order, and both the name and the value in each field MUST be exact
+matches.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
+<p id="section-4.4-3">Server push is only enabled on a connection when a client sends a MAX_PUSH_ID
+frame; see <a href="#frame-max-push-id" class="xref">Section 7.2.7</a>. A server cannot use server push until it
+receives a MAX_PUSH_ID frame. A client sends additional MAX_PUSH_ID frames to
+control the number of pushes that a server can promise. A server SHOULD use Push
+IDs sequentially, starting at 0. A client MUST treat receipt of a push stream
+with a Push ID that is greater than the maximum Push ID as a connection error of
+type H3_ID_ERROR.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
+<p id="section-4.4-4">The header section of the request message is carried by a PUSH_PROMISE frame
+(see <a href="#frame-push-promise" class="xref">Section 7.2.5</a>) on the request stream which generated the push.
+This allows the server push to be associated with a client request.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
+<p id="section-4.4-5">Not all requests can be pushed.  A server MAY push requests which have the
+following properties:<a href="#section-4.4-5" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.4-6.1">cacheable; see Section 7.2.3 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span><a href="#section-4.4-6.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.4-6.2">safe; see Section 7.2.1 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span><a href="#section-4.4-6.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.4-6.3">does not include a request body or trailer section<a href="#section-4.4-6.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.4-7">The server MUST include a value in the ":authority" pseudo-header field for
+which the server is authoritative; see <a href="#connection-reuse" class="xref">Section 3.4</a>.<a href="#section-4.4-7" class="pilcrow">¶</a></p>
+<p id="section-4.4-8">Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame
+carrying a request which is not cacheable, is not known to be safe, that
+indicates the presence of a request body, or for which it does not consider the
+server authoritative.<a href="#section-4.4-8" class="pilcrow">¶</a></p>
+<p id="section-4.4-9">Each pushed response is associated with one or more client requests.  The push
+is associated with the request stream on which the PUSH_PROMISE frame was
+received.  The same server push can be associated with additional client
+requests using a PUSH_PROMISE frame with the same Push ID on multiple request
+streams.  These associations do not affect the operation of the protocol, but
+MAY be considered by user agents when deciding how to use pushed resources.<a href="#section-4.4-9" class="pilcrow">¶</a></p>
+<p id="section-4.4-10">Ordering of a PUSH_PROMISE in relation to certain parts of the response is
+important. The server SHOULD send PUSH_PROMISE frames prior to sending HEADERS
+or DATA frames that reference the promised responses.  This reduces the chance
+that a client requests a resource that will be pushed by the server.<a href="#section-4.4-10" class="pilcrow">¶</a></p>
+<p id="section-4.4-11">When a server later fulfills a promise, the server push response is conveyed on
+a push stream; see <a href="#push-streams" class="xref">Section 6.2.2</a>. The push stream identifies the Push ID of
+the promise that it fulfills, then contains a response to the promised request
+using the same format described for responses in <a href="#request-response" class="xref">Section 4.1</a>.<a href="#section-4.4-11" class="pilcrow">¶</a></p>
+<p id="section-4.4-12">Due to reordering, push stream data can arrive before the corresponding
+PUSH_PROMISE frame.  When a client receives a new push stream with an
+as-yet-unknown Push ID, both the associated client request and the pushed
+request header fields are unknown.  The client can buffer the stream data in
+expectation of the matching PUSH_PROMISE. The client can use stream flow control
+(see section 4.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>) to limit the amount of data a server may
+commit to the pushed stream.<a href="#section-4.4-12" class="pilcrow">¶</a></p>
+<p id="section-4.4-13">If a promised server push is not needed by the client, the client SHOULD send a
+CANCEL_PUSH frame. If the push stream is already open or opens after sending the
+CANCEL_PUSH frame, the client can abort reading the stream with an error code of
+H3_REQUEST_CANCELLED. This asks the server not to transfer additional data and
+indicates that it will be discarded upon receipt.<a href="#section-4.4-13" class="pilcrow">¶</a></p>
+<p id="section-4.4-14">Pushed responses that are cacheable (see Section 3 of
+<span>[<a href="#CACHING" class="xref">CACHING</a>]</span>) can be stored by the client, if it
+implements an HTTP cache.  Pushed responses are considered successfully
+validated on the origin server (e.g., if the "no-cache" cache response directive
+is present (Section 5.2.2.3 of <span>[<a href="#CACHING" class="xref">CACHING</a>]</span>)) at the time the pushed response is
+received.<a href="#section-4.4-14" class="pilcrow">¶</a></p>
+<p id="section-4.4-15">Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache.
+They MAY be made available to the application separately.<a href="#section-4.4-15" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="connection-closure">
+<section id="section-5">
+      <h2 id="name-connection-closure">
+<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-connection-closure" class="section-name selfRef">Connection Closure</a>
+      </h2>
+<p id="section-5-1">Once established, an HTTP/3 connection can be used for many requests and
+responses over time until the connection is closed.  Connection closure can
+happen in any of several different ways.<a href="#section-5-1" class="pilcrow">¶</a></p>
+<div id="idle-connections">
+<section id="section-5.1">
+        <h3 id="name-idle-connections">
+<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-idle-connections" class="section-name selfRef">Idle Connections</a>
+        </h3>
+<p id="section-5.1-1">Each QUIC endpoint declares an idle timeout during the handshake.  If the
+connection remains idle (no packets received) for longer than this duration, the
+peer will assume that the connection has been closed.  HTTP/3 implementations
+will need to open a new connection for new requests if the existing connection
+has been idle for longer than the server's advertised idle timeout, and SHOULD
+do so if approaching the idle timeout.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.1-2">HTTP clients are expected to request that the transport keep connections open
+while there are responses outstanding for requests or server pushes, as
+described in Section 19.2 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>. If the client is not expecting
+a response from the server, allowing an idle connection to time out is preferred
+over expending effort maintaining a connection that might not be needed.  A
+gateway MAY maintain connections in anticipation of need rather than incur the
+latency cost of connection establishment to servers. Servers SHOULD NOT actively
+keep connections open.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="connection-shutdown">
+<section id="section-5.2">
+        <h3 id="name-connection-shutdown">
+<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-connection-shutdown" class="section-name selfRef">Connection Shutdown</a>
+        </h3>
+<p id="section-5.2-1">Even when a connection is not idle, either endpoint can decide to stop using the
+connection and initiate a graceful connection close.  Endpoints initiate the
+graceful shutdown of a connection by sending a GOAWAY frame (<a href="#frame-goaway" class="xref">Section 7.2.6</a>).
+The GOAWAY frame contains an identifier that indicates to the receiver the range
+of requests or pushes that were or might be processed in this connection.  The
+server sends a client-initiated bidirectional Stream ID; the client sends a Push
+ID.  Requests or pushes with the indicated identifier or greater are rejected by
+the sender of the GOAWAY.  This identifier MAY be zero if no requests or pushes
+were processed.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.2-2">The information in the GOAWAY frame enables a client and server to agree on
+which requests or pushes were accepted prior to the connection shutdown. Upon
+sending a GOAWAY frame, the endpoint SHOULD explicitly cancel (see
+<a href="#request-cancellation" class="xref">Section 4.1.2</a> and <a href="#frame-cancel-push" class="xref">Section 7.2.3</a>) any requests or pushes that
+have identifiers greater than or equal to that indicated, in order to clean up
+transport state for the affected streams. The endpoint SHOULD continue to do so
+as more requests or pushes arrive.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
+<p id="section-5.2-3">Endpoints MUST NOT initiate new requests or promise new pushes on the connection
+after receipt of a GOAWAY frame from the peer.  Clients MAY establish a new
+connection to send additional requests.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.2-4">Some requests or pushes might already be in transit:<a href="#section-5.2-4" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.2-5.1">
+            <p id="section-5.2-5.1.1">Upon receipt of a GOAWAY frame, if the client has already sent requests with
+a Stream ID greater than or equal to the identifier received in a GOAWAY
+frame, those requests will not be processed.  Clients can safely retry
+unprocessed requests on a different connection.<a href="#section-5.2-5.1.1" class="pilcrow">¶</a></p>
+<p id="section-5.2-5.1.2">
+Requests on Stream IDs less than the Stream ID in a GOAWAY frame from the
+server might have been processed; their status cannot be known until a
+response is received, the stream is reset individually, another GOAWAY is
+received, or the connection terminates.<a href="#section-5.2-5.1.2" class="pilcrow">¶</a></p>
+<p id="section-5.2-5.1.3">
+Servers MAY reject individual requests on streams below the indicated ID if
+these requests were not processed.<a href="#section-5.2-5.1.3" class="pilcrow">¶</a></p>
+</li>
+<li class="normal" id="section-5.2-5.2">If a server receives a GOAWAY frame after having promised pushes with a Push
+ID greater than or equal to the identifier received in a GOAWAY frame, those
+pushes will not be accepted.<a href="#section-5.2-5.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-5.2-6">Servers SHOULD send a GOAWAY frame when the closing of a connection is known
+in advance, even if the advance notice is small, so that the remote peer can
+know whether a request has been partially processed or not.  For example, if an
+HTTP client sends a POST at the same time that a server closes a QUIC
+connection, the client cannot know if the server started to process that POST
+request if the server does not send a GOAWAY frame to indicate what streams it
+might have acted on.<a href="#section-5.2-6" class="pilcrow">¶</a></p>
+<p id="section-5.2-7">A client that is unable to retry requests loses all requests that are in flight
+when the server closes the connection.  An endpoint MAY send multiple GOAWAY
+frames indicating different identifiers, but MUST NOT increase the identifier
+value they send, since clients might already have retried unprocessed requests
+on another connection.<a href="#section-5.2-7" class="pilcrow">¶</a></p>
+<p id="section-5.2-8">An endpoint that is attempting to gracefully shut down a connection can send a
+GOAWAY frame with a value set to the maximum possible value (2^62-4 for servers,
+2^62-1 for clients). This ensures that the peer stops creating new requests or
+pushes. After allowing time for any in-flight requests or pushes to arrive, the
+endpoint can send another GOAWAY frame indicating which requests or pushes it
+might accept before the end of the connection. This ensures that a connection
+can be cleanly shut down without losing requests.<a href="#section-5.2-8" class="pilcrow">¶</a></p>
+<p id="section-5.2-9">A client has more flexibility in the value it chooses for the Push ID in a
+GOAWAY that it sends.  A value of 2^62 - 1 indicates that the server can
+continue fulfilling pushes which have already been promised, and the client can
+continue granting push credit as needed; see <a href="#frame-max-push-id" class="xref">Section 7.2.7</a>. A smaller
+value indicates the client will reject pushes with Push IDs greater than or
+equal to this value.  Like the server, the client MAY send subsequent GOAWAY
+frames so long as the specified Push ID is strictly smaller than all previously
+sent values.<a href="#section-5.2-9" class="pilcrow">¶</a></p>
+<p id="section-5.2-10">Even when a GOAWAY indicates that a given request or push will not be processed
+or accepted upon receipt, the underlying transport resources still exist.  The
+endpoint that initiated these requests can cancel them to clean up transport
+state.<a href="#section-5.2-10" class="pilcrow">¶</a></p>
+<p id="section-5.2-11">Once all accepted requests and pushes have been processed, the endpoint can
+permit the connection to become idle, or MAY initiate an immediate closure of
+the connection.  An endpoint that completes a graceful shutdown SHOULD use the
+H3_NO_ERROR code when closing the connection.<a href="#section-5.2-11" class="pilcrow">¶</a></p>
+<p id="section-5.2-12">If a client has consumed all available bidirectional stream IDs with requests,
+the server need not send a GOAWAY frame, since the client is unable to make
+further requests.<a href="#section-5.2-12" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="immediate-application-closure">
+<section id="section-5.3">
+        <h3 id="name-immediate-application-closu">
+<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-immediate-application-closu" class="section-name selfRef">Immediate Application Closure</a>
+        </h3>
+<p id="section-5.3-1">An HTTP/3 implementation can immediately close the QUIC connection at any time.
+This results in sending a QUIC CONNECTION_CLOSE frame to the peer indicating
+that the application layer has terminated the connection.  The application error
+code in this frame indicates to the peer why the connection is being closed.
+See <a href="#errors" class="xref">Section 8</a> for error codes which can be used when closing a connection in
+HTTP/3.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
+<p id="section-5.3-2">Before closing the connection, a GOAWAY frame MAY be sent to allow the client to
+retry some requests.  Including the GOAWAY frame in the same packet as the QUIC
+CONNECTION_CLOSE frame improves the chances of the frame being received by
+clients.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="transport-closure">
+<section id="section-5.4">
+        <h3 id="name-transport-closure">
+<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-transport-closure" class="section-name selfRef">Transport Closure</a>
+        </h3>
+<p id="section-5.4-1">For various reasons, the QUIC transport could indicate to the application layer
+that the connection has terminated.  This might be due to an explicit closure
+by the peer, a transport-level error, or a change in network topology which
+interrupts connectivity.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
+<p id="section-5.4-2">If a connection terminates without a GOAWAY frame, clients MUST assume that any
+request which was sent, whether in whole or in part, might have been processed.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="stream-mapping">
+<section id="section-6">
+      <h2 id="name-stream-mapping-and-usage">
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-stream-mapping-and-usage" class="section-name selfRef">Stream Mapping and Usage</a>
+      </h2>
+<p id="section-6-1">A QUIC stream provides reliable in-order delivery of bytes, but makes no
+guarantees about order of delivery with regard to bytes on other streams. On the
+wire, data is framed into QUIC STREAM frames, but this framing is invisible to
+the HTTP framing layer. The transport layer buffers and orders received QUIC
+STREAM frames, exposing the data contained within as a reliable byte stream to
+the application. Although QUIC permits out-of-order delivery within a stream,
+HTTP/3 does not make use of this feature.<a href="#section-6-1" class="pilcrow">¶</a></p>
+<p id="section-6-2">QUIC streams can be either unidirectional, carrying data only from initiator to
+receiver, or bidirectional.  Streams can be initiated by either the client or
+the server.  For more detail on QUIC streams, see Section 2 of
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-6-2" class="pilcrow">¶</a></p>
+<p id="section-6-3">When HTTP fields and data are sent over QUIC, the QUIC layer handles most of
+the stream management.  HTTP does not need to do any separate multiplexing when
+using QUIC - data sent over a QUIC stream always maps to a particular HTTP
+transaction or connection context.<a href="#section-6-3" class="pilcrow">¶</a></p>
+<div id="bidirectional-streams">
+<section id="section-6.1">
+        <h3 id="name-bidirectional-streams">
+<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-bidirectional-streams" class="section-name selfRef">Bidirectional Streams</a>
+        </h3>
+<p id="section-6.1-1">All client-initiated bidirectional streams are used for HTTP requests and
+responses.  A bidirectional stream ensures that the response can be readily
+correlated with the request. This means that the client's first request occurs
+on QUIC stream 0, with subsequent requests on stream 4, 8, and so on. In order
+to permit these streams to open, an HTTP/3 server SHOULD configure non-zero
+minimum values for the number of permitted streams and the initial stream flow
+control window.  So as to not unnecessarily limit parallelism, at least 100
+requests SHOULD be permitted at a time.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
+<p id="section-6.1-2">HTTP/3 does not use server-initiated bidirectional streams, though an extension
+could define a use for these streams.  Clients MUST treat receipt of a
+server-initiated bidirectional stream as a connection error of type
+H3_STREAM_CREATION_ERROR unless such an extension has been negotiated.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="unidirectional-streams">
+<section id="section-6.2">
+        <h3 id="name-unidirectional-streams">
+<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-unidirectional-streams" class="section-name selfRef">Unidirectional Streams</a>
+        </h3>
+<p id="section-6.2-1">Unidirectional streams, in either direction, are used for a range of purposes.
+The purpose is indicated by a stream type, which is sent as a variable-length
+integer at the start of the stream. The format and structure of data that
+follows this integer is determined by the stream type.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
+<span id="name-unidirectional-stream-heade"></span><div id="fig-stream-header">
+<figure id="figure-1">
+          <div class="artwork art-text alignLeft art-drawing" id="section-6.2-2.1">
+<pre>
+Unidirectional Stream Header {
+  Stream Type (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
+<a href="#name-unidirectional-stream-heade" class="selfRef">Unidirectional Stream Header</a>
+          </figcaption></figure>
+</div>
+<p id="section-6.2-3">Some stream types are reserved (<a href="#stream-grease" class="xref">Section 6.2.3</a>).  Two stream types are
+defined in this document: control streams (<a href="#control-streams" class="xref">Section 6.2.1</a>) and push streams
+(<a href="#push-streams" class="xref">Section 6.2.2</a>).  <span>[<a href="#QPACK" class="xref">QPACK</a>]</span> defines two additional stream types.  Other stream
+types can be defined by extensions to HTTP/3; see <a href="#extensions" class="xref">Section 9</a> for more
+details.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
+<p id="section-6.2-4">The performance of HTTP/3 connections in the early phase of their lifetime is
+sensitive to the creation and exchange of data on unidirectional streams.
+Endpoints that excessively restrict the number of streams or the flow control
+window of these streams will increase the chance that the remote peer reaches
+the limit early and becomes blocked. In particular, implementations should
+consider that remote peers may wish to exercise reserved stream behavior
+(<a href="#stream-grease" class="xref">Section 6.2.3</a>) with some of the unidirectional streams they are permitted
+to use. To avoid blocking, the transport parameters sent by both clients and
+servers MUST allow the peer to create at least one unidirectional stream for the
+HTTP control stream plus the number of unidirectional streams required by
+mandatory extensions (three being the minimum number required for the base
+HTTP/3 protocol and QPACK), and SHOULD provide at least 1,024 bytes of flow
+control credit to each stream.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
+<p id="section-6.2-5">Note that an endpoint is not required to grant additional credits to create more
+unidirectional streams if its peer consumes all the initial credits before
+creating the critical unidirectional streams. Endpoints SHOULD create the HTTP
+control stream as well as the unidirectional streams required by mandatory
+extensions (such as the QPACK encoder and decoder streams) first, and then
+create additional streams as allowed by their peer.<a href="#section-6.2-5" class="pilcrow">¶</a></p>
+<p id="section-6.2-6">If the stream header indicates a stream type which is not supported by the
+recipient, the remainder of the stream cannot be consumed as the semantics are
+unknown. Recipients of unknown stream types MAY abort reading of the stream with
+an error code of H3_STREAM_CREATION_ERROR, but MUST NOT consider such streams
+to be a connection error of any kind.<a href="#section-6.2-6" class="pilcrow">¶</a></p>
+<p id="section-6.2-7">Implementations MAY send stream types before knowing whether the peer supports
+them.  However, stream types which could modify the state or semantics of
+existing protocol components, including QPACK or other extensions, MUST NOT be
+sent until the peer is known to support them.<a href="#section-6.2-7" class="pilcrow">¶</a></p>
+<p id="section-6.2-8">A sender can close or reset a unidirectional stream unless otherwise specified.
+A receiver MUST tolerate unidirectional streams being closed or reset prior to
+the reception of the unidirectional stream header.<a href="#section-6.2-8" class="pilcrow">¶</a></p>
+<div id="control-streams">
+<section id="section-6.2.1">
+          <h4 id="name-control-streams">
+<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-control-streams" class="section-name selfRef">Control Streams</a>
+          </h4>
+<p id="section-6.2.1-1">A control stream is indicated by a stream type of 0x00.  Data on this stream
+consists of HTTP/3 frames, as defined in <a href="#frames" class="xref">Section 7.2</a>.<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-2">Each side MUST initiate a single control stream at the beginning of the
+connection and send its SETTINGS frame as the first frame on this stream.  If
+the first frame of the control stream is any other frame type, this MUST be
+treated as a connection error of type H3_MISSING_SETTINGS. Only one control
+stream per peer is permitted; receipt of a second stream which claims to be a
+control stream MUST be treated as a connection error of type
+H3_STREAM_CREATION_ERROR.  The sender MUST NOT close the control stream, and
+the receiver MUST NOT request that the sender close the control stream.  If
+either control stream is closed at any point, this MUST be treated as a
+connection error of type H3_CLOSED_CRITICAL_STREAM.<a href="#section-6.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-3">A pair of unidirectional streams is used rather than a single bidirectional
+stream.  This allows either peer to send data as soon as it is able.  Depending
+on whether 0-RTT is enabled on the connection, either client or server might be
+able to send stream data first after the cryptographic handshake completes.<a href="#section-6.2.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="push-streams">
+<section id="section-6.2.2">
+          <h4 id="name-push-streams">
+<a href="#section-6.2.2" class="section-number selfRef">6.2.2. </a><a href="#name-push-streams" class="section-name selfRef">Push Streams</a>
+          </h4>
+<p id="section-6.2.2-1">Server push is an optional feature introduced in HTTP/2 that allows a server to
+initiate a response before a request has been made.  See <a href="#server-push" class="xref">Section 4.4</a> for
+more details.<a href="#section-6.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-6.2.2-2">A push stream is indicated by a stream type of 0x01, followed by the Push ID
+of the promise that it fulfills, encoded as a variable-length integer. The
+remaining data on this stream consists of HTTP/3 frames, as defined in
+<a href="#frames" class="xref">Section 7.2</a>, and fulfills a promised server push by zero or more interim HTTP
+responses followed by a single final HTTP response, as defined in
+<a href="#request-response" class="xref">Section 4.1</a>.  Server push and Push IDs are described in
+<a href="#server-push" class="xref">Section 4.4</a>.<a href="#section-6.2.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.2.2-3">Only servers can push; if a server receives a client-initiated push stream, this
+MUST be treated as a connection error of type H3_STREAM_CREATION_ERROR.<a href="#section-6.2.2-3" class="pilcrow">¶</a></p>
+<span id="name-push-stream-header"></span><div id="fig-push-stream-header">
+<figure id="figure-2">
+            <div class="artwork art-text alignLeft art-drawing" id="section-6.2.2-4.1">
+<pre>
+Push Stream Header {
+  Stream Type (i) = 0x01,
+  Push ID (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
+<a href="#name-push-stream-header" class="selfRef">Push Stream Header</a>
+            </figcaption></figure>
+</div>
+<p id="section-6.2.2-5">Each Push ID MUST only be used once in a push stream header. If a push stream
+header includes a Push ID that was used in another push stream header, the
+client MUST treat this as a connection error of type H3_ID_ERROR.<a href="#section-6.2.2-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-grease">
+<section id="section-6.2.3">
+          <h4 id="name-reserved-stream-types">
+<a href="#section-6.2.3" class="section-number selfRef">6.2.3. </a><a href="#name-reserved-stream-types" class="section-name selfRef">Reserved Stream Types</a>
+          </h4>
+<p id="section-6.2.3-1">Stream types of the format <code>0x1f * N + 0x21</code> for non-negative integer values of
+N are reserved to exercise the requirement that unknown types be ignored. These
+streams have no semantics, and can be sent when application-layer padding is
+desired. They MAY also be sent on connections where no data is currently being
+transferred. Endpoints MUST NOT consider these streams to have any meaning upon
+receipt.<a href="#section-6.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-6.2.3-2">The payload and length of the stream are selected in any manner the
+implementation chooses.  Implementations MAY terminate these streams cleanly, or
+MAY abruptly terminate them.  When terminating abruptly, the error code
+H3_NO_ERROR or a reserved error code (<a href="#http-error-codes" class="xref">Section 8.1</a>) SHOULD be used.<a href="#section-6.2.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="http-framing-layer">
+<section id="section-7">
+      <h2 id="name-http-framing-layer">
+<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-http-framing-layer" class="section-name selfRef">HTTP Framing Layer</a>
+      </h2>
+<p id="section-7-1">HTTP frames are carried on QUIC streams, as described in <a href="#stream-mapping" class="xref">Section 6</a>.
+HTTP/3 defines three stream types: control stream, request stream, and push
+stream. This section describes HTTP/3 frame formats and the streams types on
+which they are permitted; see <a href="#stream-frame-mapping" class="xref">Table 1</a> for an overview.  A
+comparison between HTTP/2 and HTTP/3 frames is provided in <a href="#h2-frames" class="xref">Appendix A.2</a>.<a href="#section-7-1" class="pilcrow">¶</a></p>
+<span id="name-http-3-frames-and-stream-ty"></span><div id="stream-frame-mapping">
+<table class="center" id="table-1">
+        <caption>
+<a href="#table-1" class="selfRef">Table 1</a>:
+<a href="#name-http-3-frames-and-stream-ty" class="selfRef">HTTP/3 Frames and Stream Type Overview</a>
+        </caption>
+<thead>
+          <tr>
+            <th class="text-left" rowspan="1" colspan="1">Frame</th>
+            <th class="text-left" rowspan="1" colspan="1">Control Stream</th>
+            <th class="text-left" rowspan="1" colspan="1">Request Stream</th>
+            <th class="text-left" rowspan="1" colspan="1">Push Stream</th>
+            <th class="text-left" rowspan="1" colspan="1">Section</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">DATA</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">
+              <a href="#frame-data" class="xref">Section 7.2.1</a>
+</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">HEADERS</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">
+              <a href="#frame-headers" class="xref">Section 7.2.2</a>
+</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">CANCEL_PUSH</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">
+              <a href="#frame-cancel-push" class="xref">Section 7.2.3</a>
+</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">SETTINGS</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes (1)</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">
+              <a href="#frame-settings" class="xref">Section 7.2.4</a>
+</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">PUSH_PROMISE</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">
+              <a href="#frame-push-promise" class="xref">Section 7.2.5</a>
+</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">GOAWAY</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">
+              <a href="#frame-goaway" class="xref">Section 7.2.6</a>
+</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">MAX_PUSH_ID</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">No</td>
+            <td class="text-left" rowspan="1" colspan="1">
+              <a href="#frame-max-push-id" class="xref">Section 7.2.7</a>
+</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">Yes</td>
+            <td class="text-left" rowspan="1" colspan="1">
+              <a href="#frame-reserved" class="xref">Section 7.2.8</a>
+</td>
+          </tr>
+        </tbody>
+      </table>
+</div>
+<p id="section-7-3">Certain frames can only occur as the first frame of a particular stream type;
+these are indicated in <a href="#stream-frame-mapping" class="xref">Table 1</a> with a (1).  Specific guidance
+is provided in the relevant section.<a href="#section-7-3" class="pilcrow">¶</a></p>
+<p id="section-7-4">Note that, unlike QUIC frames, HTTP/3 frames can span multiple packets.<a href="#section-7-4" class="pilcrow">¶</a></p>
+<div id="frame-layout">
+<section id="section-7.1">
+        <h3 id="name-frame-layout">
+<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-frame-layout" class="section-name selfRef">Frame Layout</a>
+        </h3>
+<p id="section-7.1-1">All frames have the following format:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
+<span id="name-http-3-frame-format"></span><div id="fig-frame">
+<figure id="figure-3">
+          <div class="artwork art-text alignLeft art-drawing" id="section-7.1-2.1">
+<pre>
+HTTP/3 Frame Format {
+  Type (i),
+  Length (i),
+  Frame Payload (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
+<a href="#name-http-3-frame-format" class="selfRef">HTTP/3 Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-7.1-3">A frame includes the following fields:<a href="#section-7.1-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7.1-4">
+          <dt id="section-7.1-4.1">Type:</dt>
+<dd id="section-7.1-4.2">
+  A variable-length integer that identifies the frame type.<a href="#section-7.1-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-7.1-4.3">Length:</dt>
+<dd id="section-7.1-4.4">
+  A variable-length integer that describes the length in bytes of
+the Frame Payload.<a href="#section-7.1-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-7.1-4.5">Frame Payload:</dt>
+<dd id="section-7.1-4.6">
+  A payload, the semantics of which are determined by the Type field.<a href="#section-7.1-4.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-7.1-5">Each frame's payload MUST contain exactly the fields identified in its
+description.  A frame payload that contains additional bytes after the
+identified fields or a frame payload that terminates before the end of the
+identified fields MUST be treated as a connection error of type
+H3_FRAME_ERROR.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
+<p id="section-7.1-6">When a stream terminates cleanly, if the last frame on the stream was truncated,
+this MUST be treated as a connection error (<a href="#errors" class="xref">Section 8</a>) of type
+H3_FRAME_ERROR. Streams which terminate abruptly may be reset at any point in
+a frame.<a href="#section-7.1-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frames">
+<section id="section-7.2">
+        <h3 id="name-frame-definitions">
+<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-frame-definitions" class="section-name selfRef">Frame Definitions</a>
+        </h3>
+<div id="frame-data">
+<section id="section-7.2.1">
+          <h4 id="name-data">
+<a href="#section-7.2.1" class="section-number selfRef">7.2.1. </a><a href="#name-data" class="section-name selfRef">DATA</a>
+          </h4>
+<p id="section-7.2.1-1">DATA frames (type=0x0) convey arbitrary, variable-length sequences of bytes
+associated with an HTTP request or response payload.<a href="#section-7.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-7.2.1-2">DATA frames MUST be associated with an HTTP request or response.  If a DATA
+frame is received on a control stream, the recipient MUST respond with a
+connection error (<a href="#errors" class="xref">Section 8</a>) of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.1-2" class="pilcrow">¶</a></p>
+<span id="name-data-frame"></span><div id="fig-data">
+<figure id="figure-4">
+            <div class="artwork art-text alignLeft art-drawing" id="section-7.2.1-3.1">
+<pre>
+DATA Frame {
+  Type (i) = 0x0,
+  Length (i),
+  Data (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
+<a href="#name-data-frame" class="selfRef">DATA Frame</a>
+            </figcaption></figure>
+</div>
+</section>
+</div>
+<div id="frame-headers">
+<section id="section-7.2.2">
+          <h4 id="name-headers">
+<a href="#section-7.2.2" class="section-number selfRef">7.2.2. </a><a href="#name-headers" class="section-name selfRef">HEADERS</a>
+          </h4>
+<p id="section-7.2.2-1">The HEADERS frame (type=0x1) is used to carry an HTTP field section, encoded
+using QPACK. See <span>[<a href="#QPACK" class="xref">QPACK</a>]</span> for more details.<a href="#section-7.2.2-1" class="pilcrow">¶</a></p>
+<span id="name-headers-frame"></span><div id="fig-headers">
+<figure id="figure-5">
+            <div class="artwork art-text alignLeft art-drawing" id="section-7.2.2-2.1">
+<pre>
+HEADERS Frame {
+  Type (i) = 0x1,
+  Length (i),
+  Encoded Field Section (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
+<a href="#name-headers-frame" class="selfRef">HEADERS Frame</a>
+            </figcaption></figure>
+</div>
+<p id="section-7.2.2-3">HEADERS frames can only be sent on request / push streams.  If a HEADERS frame
+is received on a control stream, the recipient MUST respond with a connection
+error (<a href="#errors" class="xref">Section 8</a>) of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-cancel-push">
+<section id="section-7.2.3">
+          <h4 id="name-cancel_push">
+<a href="#section-7.2.3" class="section-number selfRef">7.2.3. </a><a href="#name-cancel_push" class="section-name selfRef">CANCEL_PUSH</a>
+          </h4>
+<p id="section-7.2.3-1">The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a server
+push prior to the push stream being received.  The CANCEL_PUSH frame identifies
+a server push by Push ID (see <a href="#frame-push-promise" class="xref">Section 7.2.5</a>), encoded as a
+variable-length integer.<a href="#section-7.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-7.2.3-2">When a client sends CANCEL_PUSH, it is indicating that it does not wish to
+receive the promised resource.  The server SHOULD abort sending the resource,
+but the mechanism to do so depends on the state of the corresponding push
+stream.  If the server has not yet created a push stream, it does not create
+one.  If the push stream is open, the server SHOULD abruptly terminate that
+stream.  If the push stream has already ended, the server MAY still abruptly
+terminate the stream or MAY take no action.<a href="#section-7.2.3-2" class="pilcrow">¶</a></p>
+<p id="section-7.2.3-3">When a server sends CANCEL_PUSH, it is indicating that it will not be fulfilling
+a promise and has not created a push stream.  The client should not expect the
+corresponding promise to be fulfilled.<a href="#section-7.2.3-3" class="pilcrow">¶</a></p>
+<p id="section-7.2.3-4">Sending CANCEL_PUSH has no direct effect on the state of existing push streams.
+A server SHOULD NOT send a CANCEL_PUSH when it has already created a
+corresponding push stream, and a client SHOULD NOT send a CANCEL_PUSH when it
+has already received a corresponding push stream.  If a push stream arrives
+after a client has sent CANCEL_PUSH, this MAY be treated as a stream error of
+type H3_STREAM_CREATION_ERROR.<a href="#section-7.2.3-4" class="pilcrow">¶</a></p>
+<p id="section-7.2.3-5">A CANCEL_PUSH frame is sent on the control stream.  Receiving a CANCEL_PUSH
+frame on a stream other than the control stream MUST be treated as a connection
+error of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.3-5" class="pilcrow">¶</a></p>
+<span id="name-cancel_push-frame"></span><div id="fig-cancel-push">
+<figure id="figure-6">
+            <div class="artwork art-text alignLeft art-drawing" id="section-7.2.3-6.1">
+<pre>
+CANCEL_PUSH Frame {
+  Type (i) = 0x3,
+  Length (i),
+  Push ID (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
+<a href="#name-cancel_push-frame" class="selfRef">CANCEL_PUSH Frame</a>
+            </figcaption></figure>
+</div>
+<p id="section-7.2.3-7">The CANCEL_PUSH frame carries a Push ID encoded as a variable-length integer.
+The Push ID identifies the server push that is being cancelled; see
+<a href="#frame-push-promise" class="xref">Section 7.2.5</a>.  If a CANCEL_PUSH frame is received which references a
+Push ID greater than currently allowed on the connection, this MUST be treated
+as a connection error of type H3_ID_ERROR.<a href="#section-7.2.3-7" class="pilcrow">¶</a></p>
+<p id="section-7.2.3-8">If the client receives a CANCEL_PUSH frame, that frame might identify a Push ID
+that has not yet been mentioned by a PUSH_PROMISE frame due to reordering.  If a
+server receives a CANCEL_PUSH frame for a Push ID that has not yet been
+mentioned by a PUSH_PROMISE frame, this MUST be treated as a connection error of
+type H3_ID_ERROR.<a href="#section-7.2.3-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-settings">
+<section id="section-7.2.4">
+          <h4 id="name-settings">
+<a href="#section-7.2.4" class="section-number selfRef">7.2.4. </a><a href="#name-settings" class="section-name selfRef">SETTINGS</a>
+          </h4>
+<p id="section-7.2.4-1">The SETTINGS frame (type=0x4) conveys configuration parameters that affect how
+endpoints communicate, such as preferences and constraints on peer behavior.
+Individually, a SETTINGS parameter can also be referred to as a "setting"; the
+identifier and value of each setting parameter can be referred to as a "setting
+identifier" and a "setting value".<a href="#section-7.2.4-1" class="pilcrow">¶</a></p>
+<p id="section-7.2.4-2">SETTINGS frames always apply to a connection, never a single stream.  A SETTINGS
+frame MUST be sent as the first frame of each control stream (see
+<a href="#control-streams" class="xref">Section 6.2.1</a>) by each peer, and MUST NOT be sent subsequently. If
+an endpoint receives a second SETTINGS frame on the control stream, the endpoint
+MUST respond with a connection error of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.4-2" class="pilcrow">¶</a></p>
+<p id="section-7.2.4-3">SETTINGS frames MUST NOT be sent on any stream other than the control stream.
+If an endpoint receives a SETTINGS frame on a different stream, the endpoint
+MUST respond with a connection error of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.4-3" class="pilcrow">¶</a></p>
+<p id="section-7.2.4-4">SETTINGS parameters are not negotiated; they describe characteristics of the
+sending peer, which can be used by the receiving peer. However, a negotiation
+can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a
+set of supported values. The definition of the setting would describe how each
+peer combines the two sets to conclude which choice will be used.  SETTINGS does
+not provide a mechanism to identify when the choice takes effect.<a href="#section-7.2.4-4" class="pilcrow">¶</a></p>
+<p id="section-7.2.4-5">Different values for the same parameter can be advertised by each peer. For
+example, a client might be willing to consume a very large response field
+section, while servers are more cautious about request size.<a href="#section-7.2.4-5" class="pilcrow">¶</a></p>
+<p id="section-7.2.4-6">The same setting identifier MUST NOT occur more than once in the SETTINGS frame.
+A receiver MAY treat the presence of duplicate setting identifiers as a
+connection error of type H3_SETTINGS_ERROR.<a href="#section-7.2.4-6" class="pilcrow">¶</a></p>
+<p id="section-7.2.4-7">The payload of a SETTINGS frame consists of zero or more parameters.  Each
+parameter consists of a setting identifier and a value, both encoded as QUIC
+variable-length integers.<a href="#section-7.2.4-7" class="pilcrow">¶</a></p>
+<span id="name-settings-frame"></span><div id="fig-ext-settings">
+<figure id="figure-7">
+            <div class="artwork art-text alignLeft art-drawing" id="section-7.2.4-8.1">
+<pre>
+Setting {
+  Identifier (i),
+  Value (i),
+}
+
+SETTINGS Frame {
+  Type (i) = 0x4,
+  Length (i),
+  Setting (..) ...,
+}
+</pre>
+</div>
+<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
+<a href="#name-settings-frame" class="selfRef">SETTINGS Frame</a>
+            </figcaption></figure>
+</div>
+<p id="section-7.2.4-9">An implementation MUST ignore the contents for any SETTINGS identifier it does
+not understand.<a href="#section-7.2.4-9" class="pilcrow">¶</a></p>
+<div id="settings-parameters">
+<section id="section-7.2.4.1">
+            <h5 id="name-defined-settings-parameters">
+<a href="#section-7.2.4.1" class="section-number selfRef">7.2.4.1. </a><a href="#name-defined-settings-parameters" class="section-name selfRef">Defined SETTINGS Parameters</a>
+            </h5>
+<p id="section-7.2.4.1-1">The following settings are defined in HTTP/3:<a href="#section-7.2.4.1-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7.2.4.1-2">
+              <dt id="section-7.2.4.1-2.1">SETTINGS_MAX_FIELD_SECTION_SIZE (0x6):</dt>
+<dd id="section-7.2.4.1-2.2">
+  The default value is unlimited.  See <a href="#header-formatting" class="xref">Section 4.1.1</a> for usage.<a href="#section-7.2.4.1-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-7.2.4.1-3">Setting identifiers of the format <code>0x1f * N + 0x21</code> for non-negative integer
+values of N are reserved to exercise the requirement that unknown identifiers be
+ignored.  Such settings have no defined meaning. Endpoints SHOULD include at
+least one such setting in their SETTINGS frame. Endpoints MUST NOT consider such
+settings to have any meaning upon receipt.<a href="#section-7.2.4.1-3" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.1-4">Because the setting has no defined meaning, the value of the setting can be any
+value the implementation selects.<a href="#section-7.2.4.1-4" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.1-5">Additional settings can be defined by extensions to HTTP/3; see <a href="#extensions" class="xref">Section 9</a>
+for more details.<a href="#section-7.2.4.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="settings-initialization">
+<section id="section-7.2.4.2">
+            <h5 id="name-initialization">
+<a href="#section-7.2.4.2" class="section-number selfRef">7.2.4.2. </a><a href="#name-initialization" class="section-name selfRef">Initialization</a>
+            </h5>
+<p id="section-7.2.4.2-1">An HTTP implementation MUST NOT send frames or requests which would be invalid
+based on its current understanding of the peer's settings.<a href="#section-7.2.4.2-1" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.2-2">All settings begin at an initial value.  Each endpoint SHOULD use these initial
+values to send messages before the peer's SETTINGS frame has arrived, as packets
+carrying the settings can be lost or delayed.  When the SETTINGS frame arrives,
+any settings are changed to their new values.<a href="#section-7.2.4.2-2" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.2-3">This removes the need to wait for the SETTINGS frame before sending messages.
+Endpoints MUST NOT require any data to be received from the peer prior to
+sending the SETTINGS frame; settings MUST be sent as soon as the transport is
+ready to send data.<a href="#section-7.2.4.2-3" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.2-4">For servers, the initial value of each client setting is the default value.<a href="#section-7.2.4.2-4" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.2-5">For clients using a 1-RTT QUIC connection, the initial value of each server
+setting is the default value.  1-RTT keys will always become available prior to
+SETTINGS arriving, even if the server sends SETTINGS immediately. Clients SHOULD
+NOT wait indefinitely for SETTINGS to arrive before sending requests, but SHOULD
+process received datagrams in order to increase the likelihood of processing
+SETTINGS before sending the first request.<a href="#section-7.2.4.2-5" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.2-6">When a 0-RTT QUIC connection is being used, the initial value of each server
+setting is the value used in the previous session. Clients SHOULD store the
+settings the server provided in the connection where resumption information was
+provided, but MAY opt not to store settings in certain cases (e.g., if the
+session ticket is received before the SETTINGS frame). A client MUST comply with
+stored settings - or default values, if no values are stored - when attempting
+0-RTT. Once a server has provided new settings, clients MUST comply with those
+values.<a href="#section-7.2.4.2-6" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.2-7">A server can remember the settings that it advertised, or store an
+integrity-protected copy of the values in the ticket and recover the information
+when accepting 0-RTT data. A server uses the HTTP/3 settings values in
+determining whether to accept 0-RTT data.  If the server cannot determine that
+the settings remembered by a client are compatible with its current settings, it
+MUST NOT accept 0-RTT data.  Remembered settings are compatible if a client
+complying with those settings would not violate the server's current settings.<a href="#section-7.2.4.2-7" class="pilcrow">¶</a></p>
+<p id="section-7.2.4.2-8">A server MAY accept 0-RTT and subsequently provide different settings in its
+SETTINGS frame. If 0-RTT data is accepted by the server, its SETTINGS frame MUST
+NOT reduce any limits or alter any values that might be violated by the client
+with its 0-RTT data.  The server MUST include all settings which differ from
+their default values.  If a server accepts 0-RTT but then sends settings that
+are not compatible with the previously specified settings, this MUST be treated
+as a connection error of type H3_SETTINGS_ERROR. If a server accepts 0-RTT but
+then sends a SETTINGS frame that omits a setting value that the client
+understands (apart from reserved setting identifiers) that was previously
+specified to have a non-default value, this MUST be treated as a connection
+error of type H3_SETTINGS_ERROR.<a href="#section-7.2.4.2-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="frame-push-promise">
+<section id="section-7.2.5">
+          <h4 id="name-push_promise">
+<a href="#section-7.2.5" class="section-number selfRef">7.2.5. </a><a href="#name-push_promise" class="section-name selfRef">PUSH_PROMISE</a>
+          </h4>
+<p id="section-7.2.5-1">The PUSH_PROMISE frame (type=0x5) is used to carry a promised request header
+field section from server to client on a request stream, as in HTTP/2.<a href="#section-7.2.5-1" class="pilcrow">¶</a></p>
+<span id="name-push_promise-frame"></span><div id="fig-push-promise">
+<figure id="figure-8">
+            <div class="artwork art-text alignLeft art-drawing" id="section-7.2.5-2.1">
+<pre>
+PUSH_PROMISE Frame {
+  Type (i) = 0x5,
+  Length (i),
+  Push ID (i),
+  Encoded Field Section (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
+<a href="#name-push_promise-frame" class="selfRef">PUSH_PROMISE Frame</a>
+            </figcaption></figure>
+</div>
+<p id="section-7.2.5-3">The payload consists of:<a href="#section-7.2.5-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7.2.5-4">
+            <dt id="section-7.2.5-4.1">Push ID:</dt>
+<dd id="section-7.2.5-4.2">
+  A variable-length integer that identifies the server push operation.  A Push
+ID is used in push stream headers (<a href="#server-push" class="xref">Section 4.4</a>), CANCEL_PUSH frames
+(<a href="#frame-cancel-push" class="xref">Section 7.2.3</a>).<a href="#section-7.2.5-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-7.2.5-4.3">Encoded Field Section:</dt>
+<dd id="section-7.2.5-4.4">
+  QPACK-encoded request header fields for the promised response.  See <span>[<a href="#QPACK" class="xref">QPACK</a>]</span>
+for more details.<a href="#section-7.2.5-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-7.2.5-5">A server MUST NOT use a Push ID that is larger than the client has provided in a
+MAX_PUSH_ID frame (<a href="#frame-max-push-id" class="xref">Section 7.2.7</a>). A client MUST treat receipt of a
+PUSH_PROMISE frame that contains a larger Push ID than the client has advertised
+as a connection error of H3_ID_ERROR.<a href="#section-7.2.5-5" class="pilcrow">¶</a></p>
+<p id="section-7.2.5-6">A server MAY use the same Push ID in multiple PUSH_PROMISE frames. If so, the
+decompressed request header sets MUST contain the same fields in the same order,
+and both the name and the value in each field MUST be exact matches. Clients
+SHOULD compare the request header sections for resources promised multiple
+times. If a client receives a Push ID that has already been promised and detects
+a mismatch, it MUST respond with a connection error of type
+H3_GENERAL_PROTOCOL_ERROR. If the decompressed field sections match exactly, the
+client SHOULD associate the pushed content with each stream on which a
+PUSH_PROMISE was received.<a href="#section-7.2.5-6" class="pilcrow">¶</a></p>
+<p id="section-7.2.5-7">Allowing duplicate references to the same Push ID is primarily to reduce
+duplication caused by concurrent requests.  A server SHOULD avoid reusing a Push
+ID over a long period.  Clients are likely to consume server push responses and
+not retain them for reuse over time.  Clients that see a PUSH_PROMISE that uses
+a Push ID that they have already consumed and discarded are forced to ignore the
+PUSH_PROMISE.<a href="#section-7.2.5-7" class="pilcrow">¶</a></p>
+<p id="section-7.2.5-8">If a PUSH_PROMISE frame is received on the control stream, the client MUST
+respond with a connection error (<a href="#errors" class="xref">Section 8</a>) of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.5-8" class="pilcrow">¶</a></p>
+<p id="section-7.2.5-9">A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the receipt
+of a PUSH_PROMISE frame as a connection error of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.5-9" class="pilcrow">¶</a></p>
+<p id="section-7.2.5-10">See <a href="#server-push" class="xref">Section 4.4</a> for a description of the overall server push mechanism.<a href="#section-7.2.5-10" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-goaway">
+<section id="section-7.2.6">
+          <h4 id="name-goaway">
+<a href="#section-7.2.6" class="section-number selfRef">7.2.6. </a><a href="#name-goaway" class="section-name selfRef">GOAWAY</a>
+          </h4>
+<p id="section-7.2.6-1">The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of a
+connection by either endpoint.  GOAWAY allows an endpoint to stop accepting new
+requests or pushes while still finishing processing of previously received
+requests and pushes.  This enables administrative actions, like server
+maintenance.  GOAWAY by itself does not close a connection.<a href="#section-7.2.6-1" class="pilcrow">¶</a></p>
+<span id="name-goaway-frame"></span><div id="fig-goaway">
+<figure id="figure-9">
+            <div class="artwork art-text alignLeft art-drawing" id="section-7.2.6-2.1">
+<pre>
+GOAWAY Frame {
+  Type (i) = 0x7,
+  Length (i),
+  Stream ID/Push ID (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
+<a href="#name-goaway-frame" class="selfRef">GOAWAY Frame</a>
+            </figcaption></figure>
+</div>
+<p id="section-7.2.6-3">The GOAWAY frame is always sent on the control stream.  In the server to client
+direction, it carries a QUIC Stream ID for a client-initiated bidirectional
+stream encoded as a variable-length integer.  A client MUST treat receipt of a
+GOAWAY frame containing a Stream ID of any other type as a connection error of
+type H3_ID_ERROR.<a href="#section-7.2.6-3" class="pilcrow">¶</a></p>
+<p id="section-7.2.6-4">In the client to server direction, the GOAWAY frame carries a Push ID encoded as
+a variable-length integer.<a href="#section-7.2.6-4" class="pilcrow">¶</a></p>
+<p id="section-7.2.6-5">The GOAWAY frame applies to the connection, not a specific stream.  A client
+MUST treat a GOAWAY frame on a stream other than the control stream as a
+connection error (<a href="#errors" class="xref">Section 8</a>) of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.6-5" class="pilcrow">¶</a></p>
+<p id="section-7.2.6-6">See <a href="#connection-shutdown" class="xref">Section 5.2</a> for more information on the use of the GOAWAY frame.<a href="#section-7.2.6-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-max-push-id">
+<section id="section-7.2.7">
+          <h4 id="name-max_push_id">
+<a href="#section-7.2.7" class="section-number selfRef">7.2.7. </a><a href="#name-max_push_id" class="section-name selfRef">MAX_PUSH_ID</a>
+          </h4>
+<p id="section-7.2.7-1">The MAX_PUSH_ID frame (type=0xD) is used by clients to control the number of
+server pushes that the server can initiate.  This sets the maximum value for a
+Push ID that the server can use in PUSH_PROMISE and CANCEL_PUSH frames.
+Consequently, this also limits the number of push streams that the server can
+initiate in addition to the limit maintained by the QUIC transport.<a href="#section-7.2.7-1" class="pilcrow">¶</a></p>
+<p id="section-7.2.7-2">The MAX_PUSH_ID frame is always sent on the control stream.  Receipt of a
+MAX_PUSH_ID frame on any other stream MUST be treated as a connection error of
+type H3_FRAME_UNEXPECTED.<a href="#section-7.2.7-2" class="pilcrow">¶</a></p>
+<p id="section-7.2.7-3">A server MUST NOT send a MAX_PUSH_ID frame.  A client MUST treat the receipt of
+a MAX_PUSH_ID frame as a connection error of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.7-3" class="pilcrow">¶</a></p>
+<p id="section-7.2.7-4">The maximum Push ID is unset when a connection is created, meaning that a server
+cannot push until it receives a MAX_PUSH_ID frame.  A client that wishes to
+manage the number of promised server pushes can increase the maximum Push ID by
+sending MAX_PUSH_ID frames as the server fulfills or cancels server pushes.<a href="#section-7.2.7-4" class="pilcrow">¶</a></p>
+<span id="name-max_push_id-frame-payload"></span><div id="fig-max-push">
+<figure id="figure-10">
+            <div class="artwork art-text alignLeft art-drawing" id="section-7.2.7-5.1">
+<pre>
+MAX_PUSH_ID Frame {
+  Type (i) = 0x1,
+  Length (i),
+  Push ID (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
+<a href="#name-max_push_id-frame-payload" class="selfRef">MAX_PUSH_ID Frame Payload</a>
+            </figcaption></figure>
+</div>
+<p id="section-7.2.7-6">The MAX_PUSH_ID frame carries a single variable-length integer that identifies
+the maximum value for a Push ID that the server can use; see
+<a href="#frame-push-promise" class="xref">Section 7.2.5</a>.  A MAX_PUSH_ID frame cannot reduce the maximum Push ID;
+receipt of a MAX_PUSH_ID that contains a smaller value than previously received
+MUST be treated as a connection error of type H3_ID_ERROR.<a href="#section-7.2.7-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-reserved">
+<section id="section-7.2.8">
+          <h4 id="name-reserved-frame-types">
+<a href="#section-7.2.8" class="section-number selfRef">7.2.8. </a><a href="#name-reserved-frame-types" class="section-name selfRef">Reserved Frame Types</a>
+          </h4>
+<p id="section-7.2.8-1">Frame types of the format <code>0x1f * N + 0x21</code> for non-negative integer values of N
+are reserved to exercise the requirement that unknown types be ignored
+(<a href="#extensions" class="xref">Section 9</a>).  These frames have no semantics, and can be sent on any open
+stream when application-layer padding is desired. They MAY also be sent on
+connections where no data is currently being transferred. Endpoints MUST NOT
+consider these frames to have any meaning upon receipt.<a href="#section-7.2.8-1" class="pilcrow">¶</a></p>
+<p id="section-7.2.8-2">The payload and length of the frames are selected in any manner the
+implementation chooses.<a href="#section-7.2.8-2" class="pilcrow">¶</a></p>
+<p id="section-7.2.8-3">Frame types which were used in HTTP/2 where there is no corresponding HTTP/3
+frame have also been reserved (<a href="#iana-frames" class="xref">Section 11.2.1</a>).  These frame types MUST NOT be
+sent, and receipt MAY be treated as an error of type H3_FRAME_UNEXPECTED.<a href="#section-7.2.8-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="errors">
+<section id="section-8">
+      <h2 id="name-error-handling">
+<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-error-handling" class="section-name selfRef">Error Handling</a>
+      </h2>
+<p id="section-8-1">QUIC allows the application to abruptly terminate (reset) individual streams or
+the entire connection when an error is encountered.  These are referred to as
+"stream errors" or "connection errors" and are described in more detail in
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-8-1" class="pilcrow">¶</a></p>
+<p id="section-8-2">An endpoint MAY choose to treat a stream error as a connection error under
+certain circumstances.  Implementations need to consider the impact on
+outstanding requests before making this choice.<a href="#section-8-2" class="pilcrow">¶</a></p>
+<p id="section-8-3">Because new error codes can be defined without negotiation (see <a href="#extensions" class="xref">Section 9</a>),
+use of an error code in an unexpected context or receipt of an unknown error
+code MUST be treated as equivalent to H3_NO_ERROR.  However, closing a stream
+can have other effects regardless of the error code; see <a href="#request-response" class="xref">Section 4.1</a>.<a href="#section-8-3" class="pilcrow">¶</a></p>
+<p id="section-8-4">This section describes HTTP/3-specific error codes which can be used to express
+the cause of a connection or stream error.<a href="#section-8-4" class="pilcrow">¶</a></p>
+<div id="http-error-codes">
+<section id="section-8.1">
+        <h3 id="name-http-3-error-codes">
+<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-http-3-error-codes" class="section-name selfRef">HTTP/3 Error Codes</a>
+        </h3>
+<p id="section-8.1-1">The following error codes are defined for use when abruptly terminating streams,
+aborting reading of streams, or immediately closing connections.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-8.1-2">
+          <dt id="section-8.1-2.1">H3_NO_ERROR (0x100):</dt>
+<dd id="section-8.1-2.2">
+  No error.  This is used when the connection or stream needs to be closed, but
+there is no error to signal.<a href="#section-8.1-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.3">H3_GENERAL_PROTOCOL_ERROR (0x101):</dt>
+<dd id="section-8.1-2.4">
+  Peer violated protocol requirements in a way which doesn't match a more
+specific error code, or endpoint declines to use the more specific error code.<a href="#section-8.1-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.5">H3_INTERNAL_ERROR (0x102):</dt>
+<dd id="section-8.1-2.6">
+  An internal error has occurred in the HTTP stack.<a href="#section-8.1-2.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.7">H3_STREAM_CREATION_ERROR (0x103):</dt>
+<dd id="section-8.1-2.8">
+  The endpoint detected that its peer created a stream that it will not accept.<a href="#section-8.1-2.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.9">H3_CLOSED_CRITICAL_STREAM (0x104):</dt>
+<dd id="section-8.1-2.10">
+  A stream required by the connection was closed or reset.<a href="#section-8.1-2.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.11">H3_FRAME_UNEXPECTED (0x105):</dt>
+<dd id="section-8.1-2.12">
+  A frame was received which was not permitted in the current state or on the
+current stream.<a href="#section-8.1-2.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.13">H3_FRAME_ERROR (0x106):</dt>
+<dd id="section-8.1-2.14">
+  A frame that fails to satisfy layout requirements or with an invalid size
+was received.<a href="#section-8.1-2.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.15">H3_EXCESSIVE_LOAD (0x107):</dt>
+<dd id="section-8.1-2.16">
+  The endpoint detected that its peer is exhibiting a behavior that might be
+generating excessive load.<a href="#section-8.1-2.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.17">H3_ID_ERROR (0x108):</dt>
+<dd id="section-8.1-2.18">
+  A Stream ID or Push ID was used incorrectly, such as exceeding a limit,
+reducing a limit, or being reused.<a href="#section-8.1-2.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.19">H3_SETTINGS_ERROR (0x109):</dt>
+<dd id="section-8.1-2.20">
+  An endpoint detected an error in the payload of a SETTINGS frame.<a href="#section-8.1-2.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.21">H3_MISSING_SETTINGS (0x10A):</dt>
+<dd id="section-8.1-2.22">
+  No SETTINGS frame was received at the beginning of the control stream.<a href="#section-8.1-2.22" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.23">H3_REQUEST_REJECTED (0x10B):</dt>
+<dd id="section-8.1-2.24">
+  A server rejected a request without performing any application processing.<a href="#section-8.1-2.24" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.25">H3_REQUEST_CANCELLED (0x10C):</dt>
+<dd id="section-8.1-2.26">
+  The request or its response (including pushed response) is cancelled.<a href="#section-8.1-2.26" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.27">H3_REQUEST_INCOMPLETE (0x10D):</dt>
+<dd id="section-8.1-2.28">
+  The client's stream terminated without containing a fully-formed request.<a href="#section-8.1-2.28" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.29">H3_CONNECT_ERROR (0x10F):</dt>
+<dd id="section-8.1-2.30">
+  The connection established in response to a CONNECT request was reset or
+abnormally closed.<a href="#section-8.1-2.30" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-8.1-2.31">H3_VERSION_FALLBACK (0x110):</dt>
+<dd id="section-8.1-2.32">
+  The requested operation cannot be served over HTTP/3.  The peer should
+retry over HTTP/1.1.<a href="#section-8.1-2.32" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-8.1-3">Error codes of the format <code>0x1f * N + 0x21</code> for non-negative integer values of N
+are reserved to exercise the requirement that unknown error codes be treated as
+equivalent to H3_NO_ERROR (<a href="#extensions" class="xref">Section 9</a>). Implementations SHOULD select an
+error code from this space with some probability when they would have sent
+H3_NO_ERROR.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="extensions">
+<section id="section-9">
+      <h2 id="name-extensions-to-http-3">
+<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-extensions-to-http-3" class="section-name selfRef">Extensions to HTTP/3</a>
+      </h2>
+<p id="section-9-1">HTTP/3 permits extension of the protocol.  Within the limitations described in
+this section, protocol extensions can be used to provide additional services or
+alter any aspect of the protocol.  Extensions are effective only within the
+scope of a single HTTP/3 connection.<a href="#section-9-1" class="pilcrow">¶</a></p>
+<p id="section-9-2">This applies to the protocol elements defined in this document.  This does not
+affect the existing options for extending HTTP, such as defining new methods,
+status codes, or fields.<a href="#section-9-2" class="pilcrow">¶</a></p>
+<p id="section-9-3">Extensions are permitted to use new frame types (<a href="#frames" class="xref">Section 7.2</a>), new settings
+(<a href="#settings-parameters" class="xref">Section 7.2.4.1</a>), new error codes (<a href="#errors" class="xref">Section 8</a>), or new unidirectional
+stream types (<a href="#unidirectional-streams" class="xref">Section 6.2</a>).  Registries are established for
+managing these extension points: frame types (<a href="#iana-frames" class="xref">Section 11.2.1</a>), settings
+(<a href="#iana-settings" class="xref">Section 11.2.2</a>), error codes (<a href="#iana-error-codes" class="xref">Section 11.2.3</a>), and stream types
+(<a href="#iana-stream-types" class="xref">Section 11.2.4</a>).<a href="#section-9-3" class="pilcrow">¶</a></p>
+<p id="section-9-4">Implementations MUST ignore unknown or unsupported values in all extensible
+protocol elements.  Implementations MUST discard frames and unidirectional
+streams that have unknown or unsupported types.  This means that any of these
+extension points can be safely used by extensions without prior arrangement or
+negotiation.  However, where a known frame type is required to be in a specific
+location, such as the SETTINGS frame as the first frame of the control stream
+(see <a href="#control-streams" class="xref">Section 6.2.1</a>), an unknown frame type does not satisfy that
+requirement and SHOULD be treated as an error.<a href="#section-9-4" class="pilcrow">¶</a></p>
+<p id="section-9-5">Extensions that could change the semantics of existing protocol components MUST
+be negotiated before being used.  For example, an extension that changes the
+layout of the HEADERS frame cannot be used until the peer has given a positive
+signal that this is acceptable.  Coordinating when such a revised layout comes
+into effect could prove complex.  As such, allocating new identifiers for
+new definitions of existing protocol elements is likely to be more effective.<a href="#section-9-5" class="pilcrow">¶</a></p>
+<p id="section-9-6">This document doesn't mandate a specific method for negotiating the use of an
+extension but notes that a setting (<a href="#settings-parameters" class="xref">Section 7.2.4.1</a>) could be used for
+that purpose.  If both peers set a value that indicates willingness to use the
+extension, then the extension can be used.  If a setting is used for extension
+negotiation, the default value MUST be defined in such a fashion that the
+extension is disabled if the setting is omitted.<a href="#section-9-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="security-considerations">
+<section id="section-10">
+      <h2 id="name-security-considerations">
+<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
+      </h2>
+<p id="section-10-1">The security considerations of HTTP/3 should be comparable to those of HTTP/2
+with TLS.  However, many of the considerations from Section 10 of <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>
+apply to <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> and are discussed in that document.<a href="#section-10-1" class="pilcrow">¶</a></p>
+<div id="server-authority">
+<section id="section-10.1">
+        <h3 id="name-server-authority">
+<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-server-authority" class="section-name selfRef">Server Authority</a>
+        </h3>
+<p id="section-10.1-1">HTTP/3 relies on the HTTP definition of authority. The security considerations
+of establishing authority are discussed in Section 11.1 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="cross-protocol-attacks">
+<section id="section-10.2">
+        <h3 id="name-cross-protocol-attacks">
+<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-cross-protocol-attacks" class="section-name selfRef">Cross-Protocol Attacks</a>
+        </h3>
+<p id="section-10.2-1">The use of ALPN in the TLS and QUIC handshakes establishes the target
+application protocol before application-layer bytes are processed.  Because all
+QUIC packets are encrypted, it is difficult for an attacker to control the
+plaintext bytes of an HTTP/3 connection which could be used in a cross-protocol
+attack on a plaintext protocol.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="intermediary-encapsulation-attacks">
+<section id="section-10.3">
+        <h3 id="name-intermediary-encapsulation-">
+<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-intermediary-encapsulation-" class="section-name selfRef">Intermediary Encapsulation Attacks</a>
+        </h3>
+<p id="section-10.3-1">The HTTP/3 field encoding allows the expression of names that are not valid
+field names in the syntax used by HTTP (Section 4.3 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>). Requests
+or responses containing invalid field names MUST be treated as malformed
+(<a href="#malformed" class="xref">Section 4.1.3</a>).  An intermediary therefore cannot translate an HTTP/3 request
+or response containing an invalid field name into an HTTP/1.1 message.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
+<p id="section-10.3-2">Similarly, HTTP/3 allows field values that are not valid. While most of the
+values that can be encoded will not alter field parsing, carriage return (CR,
+ASCII 0xd), line feed (LF, ASCII 0xa), and the zero character (NUL, ASCII 0x0)
+might be exploited by an attacker if they are translated verbatim. Any request
+or response that contains a character not permitted in a field value MUST be
+treated as malformed (<a href="#malformed" class="xref">Section 4.1.3</a>).  Valid characters are defined by the
+"field-content" ABNF rule in Section 4.4 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-10.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="cacheability-of-pushed-responses">
+<section id="section-10.4">
+        <h3 id="name-cacheability-of-pushed-resp">
+<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-cacheability-of-pushed-resp" class="section-name selfRef">Cacheability of Pushed Responses</a>
+        </h3>
+<p id="section-10.4-1">Pushed responses do not have an explicit request from the client; the request is
+provided by the server in the PUSH_PROMISE frame.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
+<p id="section-10.4-2">Caching responses that are pushed is possible based on the guidance provided by
+the origin server in the Cache-Control header field. However, this can cause
+issues if a single server hosts more than one tenant.  For example, a server
+might offer multiple users each a small portion of its URI space.<a href="#section-10.4-2" class="pilcrow">¶</a></p>
+<p id="section-10.4-3">Where multiple tenants share space on the same server, that server MUST ensure
+that tenants are not able to push representations of resources that they do not
+have authority over.  Failure to enforce this would allow a tenant to provide a
+representation that would be served out of cache, overriding the actual
+representation that the authoritative tenant provides.<a href="#section-10.4-3" class="pilcrow">¶</a></p>
+<p id="section-10.4-4">Pushed responses for which an origin server is not authoritative (see
+<a href="#connection-reuse" class="xref">Section 3.4</a>) MUST NOT be used or cached.<a href="#section-10.4-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="denial-of-service-considerations">
+<section id="section-10.5">
+        <h3 id="name-denial-of-service-considera">
+<a href="#section-10.5" class="section-number selfRef">10.5. </a><a href="#name-denial-of-service-considera" class="section-name selfRef">Denial-of-Service Considerations</a>
+        </h3>
+<p id="section-10.5-1">An HTTP/3 connection can demand a greater commitment of resources to operate
+than an HTTP/1.1 or HTTP/2 connection.  The use of field compression and flow
+control depend on a commitment of resources for storing a greater amount of
+state.  Settings for these features ensure that memory commitments for these
+features are strictly bounded.<a href="#section-10.5-1" class="pilcrow">¶</a></p>
+<p id="section-10.5-2">The number of PUSH_PROMISE frames is constrained in a similar fashion.  A client
+that accepts server push SHOULD limit the number of Push IDs it issues at a
+time.<a href="#section-10.5-2" class="pilcrow">¶</a></p>
+<p id="section-10.5-3">Processing capacity cannot be guarded as effectively as state capacity.<a href="#section-10.5-3" class="pilcrow">¶</a></p>
+<p id="section-10.5-4">The ability to send undefined protocol elements which the peer is required to
+ignore can be abused to cause a peer to expend additional processing time.  This
+might be done by setting multiple undefined SETTINGS parameters, unknown frame
+types, or unknown stream types.  Note, however, that some uses are entirely
+legitimate, such as optional-to-understand extensions and padding to increase
+resistance to traffic analysis.<a href="#section-10.5-4" class="pilcrow">¶</a></p>
+<p id="section-10.5-5">Compression of field sections also offers some opportunities to waste processing
+resources; see Section 7 of <span>[<a href="#QPACK" class="xref">QPACK</a>]</span> for more details on potential abuses.<a href="#section-10.5-5" class="pilcrow">¶</a></p>
+<p id="section-10.5-6">All these features - i.e., server push, unknown protocol elements, field
+compression - have legitimate uses.  These features become a burden only when
+they are used unnecessarily or to excess.<a href="#section-10.5-6" class="pilcrow">¶</a></p>
+<p id="section-10.5-7">An endpoint that doesn't monitor this behavior exposes itself to a risk of
+denial-of-service attack.  Implementations SHOULD track the use of these
+features and set limits on their use.  An endpoint MAY treat activity that is
+suspicious as a connection error (<a href="#errors" class="xref">Section 8</a>) of type H3_EXCESSIVE_LOAD, but
+false positives will result in disrupting valid connections and requests.<a href="#section-10.5-7" class="pilcrow">¶</a></p>
+<div id="limits-on-field-section-size">
+<section id="section-10.5.1">
+          <h4 id="name-limits-on-field-section-siz">
+<a href="#section-10.5.1" class="section-number selfRef">10.5.1. </a><a href="#name-limits-on-field-section-siz" class="section-name selfRef">Limits on Field Section Size</a>
+          </h4>
+<p id="section-10.5.1-1">A large field section (<a href="#request-response" class="xref">Section 4.1</a>) can cause an implementation to
+commit a large amount of state.  Header fields that are critical for routing can
+appear toward the end of a header field section, which prevents streaming of the
+header field section to its ultimate destination.  This ordering and other
+reasons, such as ensuring cache correctness, mean that an endpoint likely needs
+to buffer the entire header field section.  Since there is no hard limit to the
+size of a field section, some endpoints could be forced to commit a large amount
+of available memory for header fields.<a href="#section-10.5.1-1" class="pilcrow">¶</a></p>
+<p id="section-10.5.1-2">An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE (<a href="#settings-parameters" class="xref">Section 7.2.4.1</a>)
+setting to advise peers of limits that might apply on the size of field
+sections. This setting is only advisory, so endpoints MAY choose to send field
+sections that exceed this limit and risk having the request or response being
+treated as malformed.  This setting is specific to a connection, so any request
+or response could encounter a hop with a lower, unknown limit.  An intermediary
+can attempt to avoid this problem by passing on values presented by different
+peers, but they are not obligated to do so.<a href="#section-10.5.1-2" class="pilcrow">¶</a></p>
+<p id="section-10.5.1-3">A server that receives a larger field section than it is willing to handle can
+send an HTTP 431 (Request Header Fields Too Large) status code <span>[<a href="#RFC6585" class="xref">RFC6585</a>]</span>.  A
+client can discard responses that it cannot process.<a href="#section-10.5.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="connect-issues">
+<section id="section-10.5.2">
+          <h4 id="name-connect-issues">
+<a href="#section-10.5.2" class="section-number selfRef">10.5.2. </a><a href="#name-connect-issues" class="section-name selfRef">CONNECT Issues</a>
+          </h4>
+<p id="section-10.5.2-1">The CONNECT method can be used to create disproportionate load on an proxy,
+since stream creation is relatively inexpensive when compared to the creation
+and maintenance of a TCP connection.  A proxy might also maintain some resources
+for a TCP connection beyond the closing of the stream that carries the CONNECT
+request, since the outgoing TCP connection remains in the TIME_WAIT state.
+Therefore, a proxy cannot rely on QUIC stream limits alone to control the
+resources consumed by CONNECT requests.<a href="#section-10.5.2-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="use-of-compression">
+<section id="section-10.6">
+        <h3 id="name-use-of-compression">
+<a href="#section-10.6" class="section-number selfRef">10.6. </a><a href="#name-use-of-compression" class="section-name selfRef">Use of Compression</a>
+        </h3>
+<p id="section-10.6-1">Compression can allow an attacker to recover secret data when it is compressed
+in the same context as data under attacker control. HTTP/3 enables compression
+of fields (<a href="#header-formatting" class="xref">Section 4.1.1</a>); the following concerns also apply to the use
+of HTTP compressed content-codings; see Section 6.1.2 of <span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-10.6-1" class="pilcrow">¶</a></p>
+<p id="section-10.6-2">There are demonstrable attacks on compression that exploit the characteristics
+of the web (e.g., <span>[<a href="#BREACH" class="xref">BREACH</a>]</span>).  The attacker induces multiple requests
+containing varying plaintext, observing the length of the resulting ciphertext
+in each, which reveals a shorter length when a guess about the secret is
+correct.<a href="#section-10.6-2" class="pilcrow">¶</a></p>
+<p id="section-10.6-3">Implementations communicating on a secure channel MUST NOT compress content that
+includes both confidential and attacker-controlled data unless separate
+compression dictionaries are used for each source of data.  Compression MUST NOT
+be used if the source of data cannot be reliably determined.<a href="#section-10.6-3" class="pilcrow">¶</a></p>
+<p id="section-10.6-4">Further considerations regarding the compression of fields sections are
+described in <span>[<a href="#QPACK" class="xref">QPACK</a>]</span>.<a href="#section-10.6-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="padding-and-traffic-analysis">
+<section id="section-10.7">
+        <h3 id="name-padding-and-traffic-analysi">
+<a href="#section-10.7" class="section-number selfRef">10.7. </a><a href="#name-padding-and-traffic-analysi" class="section-name selfRef">Padding and Traffic Analysis</a>
+        </h3>
+<p id="section-10.7-1">Padding can be used to obscure the exact size of frame content and is provided
+to mitigate specific attacks within HTTP, for example, attacks where compressed
+content includes both attacker-controlled plaintext and secret data (e.g.,
+<span>[<a href="#BREACH" class="xref">BREACH</a>]</span>).<a href="#section-10.7-1" class="pilcrow">¶</a></p>
+<p id="section-10.7-2">Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a
+connection more resistant to traffic analysis, HTTP/3 can either rely on
+transport-layer padding or employ the reserved frame and stream types discussed
+in <a href="#frame-reserved" class="xref">Section 7.2.8</a> and <a href="#stream-grease" class="xref">Section 6.2.3</a>.  These methods of padding produce
+different results in terms of the granularity of padding, how padding is
+arranged in relation to the information that is being protected, whether padding
+is applied in the case of packet loss, and how an implementation might control
+padding.  Redundant padding could even be counterproductive.<a href="#section-10.7-2" class="pilcrow">¶</a></p>
+<p id="section-10.7-3">To mitigate attacks that rely on compression, disabling or limiting compression
+might be preferable to padding as a countermeasure.<a href="#section-10.7-3" class="pilcrow">¶</a></p>
+<p id="section-10.7-4">Use of padding can result in less protection than might seem immediately
+obvious.  At best, padding only makes it more difficult for an attacker to infer
+length information by increasing the number of frames an attacker has to
+observe.  Incorrectly implemented padding schemes can be easily defeated.  In
+particular, randomized padding with a predictable distribution provides very
+little protection; similarly, padding payloads to a fixed size exposes
+information as payload sizes cross the fixed-sized boundary, which could be
+possible if an attacker can control plaintext.<a href="#section-10.7-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-parsing">
+<section id="section-10.8">
+        <h3 id="name-frame-parsing">
+<a href="#section-10.8" class="section-number selfRef">10.8. </a><a href="#name-frame-parsing" class="section-name selfRef">Frame Parsing</a>
+        </h3>
+<p id="section-10.8-1">Several protocol elements contain nested length elements, typically in the form
+of frames with an explicit length containing variable-length integers.  This
+could pose a security risk to an incautious implementer.  An implementation MUST
+ensure that the length of a frame exactly matches the length of the fields it
+contains.<a href="#section-10.8-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="early-data">
+<section id="section-10.9">
+        <h3 id="name-early-data">
+<a href="#section-10.9" class="section-number selfRef">10.9. </a><a href="#name-early-data" class="section-name selfRef">Early Data</a>
+        </h3>
+<p id="section-10.9-1">The use of 0-RTT with HTTP/3 creates an exposure to replay attack.  The
+anti-replay mitigations in <span>[<a href="#HTTP-REPLAY" class="xref">HTTP-REPLAY</a>]</span> MUST be applied when using
+HTTP/3 with 0-RTT.<a href="#section-10.9-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="migration">
+<section id="section-10.10">
+        <h3 id="name-migration">
+<a href="#section-10.10" class="section-number selfRef">10.10. </a><a href="#name-migration" class="section-name selfRef">Migration</a>
+        </h3>
+<p id="section-10.10-1">Certain HTTP implementations use the client address for logging or
+access-control purposes.  Since a QUIC client's address might change during a
+connection (and future versions might support simultaneous use of multiple
+addresses), such implementations will need to either actively retrieve the
+client's current address or addresses when they are relevant or explicitly
+accept that the original address might change.<a href="#section-10.10-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="privacy-considerations">
+<section id="section-10.11">
+        <h3 id="name-privacy-considerations">
+<a href="#section-10.11" class="section-number selfRef">10.11. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
+        </h3>
+<p id="section-10.11-1">Several characteristics of HTTP/3 provide an observer an opportunity to
+correlate actions of a single client or server over time.  These include the
+value of settings, the timing of reactions to stimulus, and the handling of any
+features that are controlled by settings.<a href="#section-10.11-1" class="pilcrow">¶</a></p>
+<p id="section-10.11-2">As far as these create observable differences in behavior, they could be used as
+a basis for fingerprinting a specific client.<a href="#section-10.11-2" class="pilcrow">¶</a></p>
+<p id="section-10.11-3">HTTP/3's preference for using a single QUIC connection allows correlation of a
+user's activity on a site.  Reusing connections for different origins allows
+for correlation of activity across those origins.<a href="#section-10.11-3" class="pilcrow">¶</a></p>
+<p id="section-10.11-4">Several features of QUIC solicit immediate responses and can be used by an
+endpoint to measure latency to their peer; this might have privacy implications
+in certain scenarios.<a href="#section-10.11-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="iana-considerations">
+<section id="section-11">
+      <h2 id="name-iana-considerations">
+<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
+      </h2>
+<p id="section-11-1">This document registers a new ALPN protocol ID (<a href="#iana-alpn" class="xref">Section 11.1</a>) and creates new
+registries that manage the assignment of codepoints in HTTP/3.<a href="#section-11-1" class="pilcrow">¶</a></p>
+<div id="iana-alpn">
+<section id="section-11.1">
+        <h3 id="name-registration-of-http-3-iden">
+<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-registration-of-http-3-iden" class="section-name selfRef">Registration of HTTP/3 Identification String</a>
+        </h3>
+<p id="section-11.1-1">This document creates a new registration for the identification of
+HTTP/3 in the "Application Layer Protocol Negotiation (ALPN)
+Protocol IDs" registry established in <span>[<a href="#RFC7301" class="xref">RFC7301</a>]</span>.<a href="#section-11.1-1" class="pilcrow">¶</a></p>
+<p id="section-11.1-2">The "h3" string identifies HTTP/3:<a href="#section-11.1-2" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-11.1-3">
+          <dt id="section-11.1-3.1">Protocol:</dt>
+<dd id="section-11.1-3.2">
+  HTTP/3<a href="#section-11.1-3.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-11.1-3.3">Identification Sequence:</dt>
+<dd id="section-11.1-3.4">
+  0x68 0x33 ("h3")<a href="#section-11.1-3.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-11.1-3.5">Specification:</dt>
+<dd id="section-11.1-3.6">
+  This document<a href="#section-11.1-3.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="iana-policy">
+<section id="section-11.2">
+        <h3 id="name-new-registries">
+<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-new-registries" class="section-name selfRef">New Registries</a>
+        </h3>
+<p id="section-11.2-1">New registries created in this document operate under the QUIC registration
+policy documented in Section 22.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.  These registries all
+include the common set of fields listed in Section 22.1.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
+<p id="section-11.2-2">The initial allocations in these registries created in this document are all
+assigned permanent status and list as contact both the IESG (iesg@ietf.org) and
+the HTTP working group (ietf-http-wg@w3.org).<a href="#section-11.2-2" class="pilcrow">¶</a></p>
+<div id="iana-frames">
+<section id="section-11.2.1">
+          <h4 id="name-frame-types">
+<a href="#section-11.2.1" class="section-number selfRef">11.2.1. </a><a href="#name-frame-types" class="section-name selfRef">Frame Types</a>
+          </h4>
+<p id="section-11.2.1-1">This document establishes a registry for HTTP/3 frame type codes. The "HTTP/3
+Frame Type" registry governs a 62-bit space.  This registry follows the QUIC
+registry policy; see <a href="#iana-policy" class="xref">Section 11.2</a>.  Permanent registrations in this registry
+are assigned using the Specification Required policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>, except for
+values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned
+using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of
+<span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-11.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-11.2.1-2">While this registry is separate from the "HTTP/2 Frame Type" registry defined in
+<span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>, it is preferable that the assignments parallel each other where the
+code spaces overlap.  If an entry is present in only one registry, every effort
+SHOULD be made to avoid assigning the corresponding value to an unrelated
+operation.<a href="#section-11.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-11.2.1-3">In addition to common fields as described in <a href="#iana-policy" class="xref">Section 11.2</a>, permanent
+registrations in this registry MUST include the following field:<a href="#section-11.2.1-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-11.2.1-4">
+            <dt id="section-11.2.1-4.1">Frame Type:</dt>
+<dd id="section-11.2.1-4.2">
+  A name or label for the frame type.<a href="#section-11.2.1-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-11.2.1-5">Specifications of frame types MUST include a description of the frame layout and
+its semantics, including any parts of the frame that are conditionally present.<a href="#section-11.2.1-5" class="pilcrow">¶</a></p>
+<p id="section-11.2.1-6">The entries in <a href="#iana-frame-table" class="xref">Table 2</a> are registered by this document.<a href="#section-11.2.1-6" class="pilcrow">¶</a></p>
+<span id="name-initial-http-3-frame-types"></span><div id="iana-frame-table">
+<table class="center" id="table-2">
+            <caption>
+<a href="#table-2" class="selfRef">Table 2</a>:
+<a href="#name-initial-http-3-frame-types" class="selfRef">Initial HTTP/3 Frame Types</a>
+            </caption>
+<thead>
+              <tr>
+                <th class="text-left" rowspan="1" colspan="1">Frame Type</th>
+                <th class="text-center" rowspan="1" colspan="1">Value</th>
+                <th class="text-left" rowspan="1" colspan="1">Specification</th>
+              </tr>
+            </thead>
+            <tbody>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">DATA</td>
+                <td class="text-center" rowspan="1" colspan="1">0x0</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#frame-data" class="xref">Section 7.2.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">HEADERS</td>
+                <td class="text-center" rowspan="1" colspan="1">0x1</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#frame-headers" class="xref">Section 7.2.2</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+                <td class="text-center" rowspan="1" colspan="1">0x2</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">CANCEL_PUSH</td>
+                <td class="text-center" rowspan="1" colspan="1">0x3</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#frame-cancel-push" class="xref">Section 7.2.3</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">SETTINGS</td>
+                <td class="text-center" rowspan="1" colspan="1">0x4</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#frame-settings" class="xref">Section 7.2.4</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">PUSH_PROMISE</td>
+                <td class="text-center" rowspan="1" colspan="1">0x5</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#frame-push-promise" class="xref">Section 7.2.5</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+                <td class="text-center" rowspan="1" colspan="1">0x6</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">GOAWAY</td>
+                <td class="text-center" rowspan="1" colspan="1">0x7</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#frame-goaway" class="xref">Section 7.2.6</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+                <td class="text-center" rowspan="1" colspan="1">0x8</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+                <td class="text-center" rowspan="1" colspan="1">0x9</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">MAX_PUSH_ID</td>
+                <td class="text-center" rowspan="1" colspan="1">0xD</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#frame-max-push-id" class="xref">Section 7.2.7</a>
+</td>
+              </tr>
+            </tbody>
+          </table>
+</div>
+<p id="section-11.2.1-8">Additionally, each code of the format <code>0x1f * N + 0x21</code> for non-negative integer
+values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST
+NOT be assigned by IANA.<a href="#section-11.2.1-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-settings">
+<section id="section-11.2.2">
+          <h4 id="name-settings-parameters">
+<a href="#section-11.2.2" class="section-number selfRef">11.2.2. </a><a href="#name-settings-parameters" class="section-name selfRef">Settings Parameters</a>
+          </h4>
+<p id="section-11.2.2-1">This document establishes a registry for HTTP/3 settings.  The "HTTP/3 Settings"
+registry governs a 62-bit space.  This registry follows the QUIC registry
+policy; see <a href="#iana-policy" class="xref">Section 11.2</a>.  Permanent registrations in this registry are
+assigned using the Specification Required policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>, except for values
+between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
+Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of
+<span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-11.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-11.2.2-2">While this registry is separate from the "HTTP/2 Settings" registry defined in
+<span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>, it is preferable that the assignments parallel each other.  If an
+entry is present in only one registry, every effort SHOULD be made to avoid
+assigning the corresponding value to an unrelated operation.<a href="#section-11.2.2-2" class="pilcrow">¶</a></p>
+<p id="section-11.2.2-3">In addition to common fields as described in <a href="#iana-policy" class="xref">Section 11.2</a>, permanent
+registrations in this registry MUST include the following fields:<a href="#section-11.2.2-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-11.2.2-4">
+            <dt id="section-11.2.2-4.1">Setting Name:</dt>
+<dd id="section-11.2.2-4.2">
+  A symbolic name for the setting.  Specifying a setting name is optional.<a href="#section-11.2.2-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-11.2.2-4.3">Default:</dt>
+<dd id="section-11.2.2-4.4">
+  The value of the setting unless otherwise indicated. A default SHOULD be the
+most restrictive possible value.<a href="#section-11.2.2-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-11.2.2-5">The entries in <a href="#iana-setting-table" class="xref">Table 3</a> are registered by this document.<a href="#section-11.2.2-5" class="pilcrow">¶</a></p>
+<span id="name-initial-http-3-settings"></span><div id="iana-setting-table">
+<table class="center" id="table-3">
+            <caption>
+<a href="#table-3" class="selfRef">Table 3</a>:
+<a href="#name-initial-http-3-settings" class="selfRef">Initial HTTP/3 Settings</a>
+            </caption>
+<thead>
+              <tr>
+                <th class="text-left" rowspan="1" colspan="1">Setting Name</th>
+                <th class="text-center" rowspan="1" colspan="1">Value</th>
+                <th class="text-left" rowspan="1" colspan="1">Specification</th>
+                <th class="text-left" rowspan="1" colspan="1">Default</th>
+              </tr>
+            </thead>
+            <tbody>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+                <td class="text-center" rowspan="1" colspan="1">0x2</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+                <td class="text-center" rowspan="1" colspan="1">0x3</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+                <td class="text-center" rowspan="1" colspan="1">0x4</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
+                <td class="text-center" rowspan="1" colspan="1">0x5</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+                <td class="text-left" rowspan="1" colspan="1">N/A</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">MAX_FIELD_SECTION_SIZE</td>
+                <td class="text-center" rowspan="1" colspan="1">0x6</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#settings-parameters" class="xref">Section 7.2.4.1</a>
+</td>
+                <td class="text-left" rowspan="1" colspan="1">Unlimited</td>
+              </tr>
+            </tbody>
+          </table>
+</div>
+<p id="section-11.2.2-7">Additionally, each code of the format <code>0x1f * N + 0x21</code> for non-negative integer
+values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST
+NOT be assigned by IANA.<a href="#section-11.2.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-error-codes">
+<section id="section-11.2.3">
+          <h4 id="name-error-codes">
+<a href="#section-11.2.3" class="section-number selfRef">11.2.3. </a><a href="#name-error-codes" class="section-name selfRef">Error Codes</a>
+          </h4>
+<p id="section-11.2.3-1">This document establishes a registry for HTTP/3 error codes. The "HTTP/3 Error
+Code" registry manages a 62-bit space.  This registry follows the QUIC registry
+policy; see <a href="#iana-policy" class="xref">Section 11.2</a>.  Permanent registrations in this registry are
+assigned using the Specification Required policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>, except for values
+between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
+Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of
+<span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-11.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-11.2.3-2">Registrations for error codes are required to include a description
+of the error code.  An expert reviewer is advised to examine new
+registrations for possible duplication with existing error codes.
+Use of existing registrations is to be encouraged, but not mandated.<a href="#section-11.2.3-2" class="pilcrow">¶</a></p>
+<p id="section-11.2.3-3">In addition to common fields as described in <a href="#iana-policy" class="xref">Section 11.2</a>, permanent
+registrations in this registry MUST include the following fields:<a href="#section-11.2.3-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-11.2.3-4">
+            <dt id="section-11.2.3-4.1">Name:</dt>
+<dd id="section-11.2.3-4.2">
+  A name for the error code.  Specifying an error code name is optional.<a href="#section-11.2.3-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-11.2.3-4.3">Description:</dt>
+<dd id="section-11.2.3-4.4">
+  A brief description of the error code semantics.<a href="#section-11.2.3-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-11.2.3-5">The entries in the <a href="#iana-error-table" class="xref">Table 4</a> are registered by this document.<a href="#section-11.2.3-5" class="pilcrow">¶</a></p>
+<span id="name-initial-http-3-error-codes"></span><div id="iana-error-table">
+<table class="center" id="table-4">
+            <caption>
+<a href="#table-4" class="selfRef">Table 4</a>:
+<a href="#name-initial-http-3-error-codes" class="selfRef">Initial HTTP/3 Error Codes</a>
+            </caption>
+<thead>
+              <tr>
+                <th class="text-left" rowspan="1" colspan="1">Name</th>
+                <th class="text-left" rowspan="1" colspan="1">Value</th>
+                <th class="text-left" rowspan="1" colspan="1">Description</th>
+                <th class="text-left" rowspan="1" colspan="1">Specification</th>
+              </tr>
+            </thead>
+            <tbody>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_NO_ERROR</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0100</td>
+                <td class="text-left" rowspan="1" colspan="1">No error</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_GENERAL_PROTOCOL_ERROR</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0101</td>
+                <td class="text-left" rowspan="1" colspan="1">General protocol error</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_INTERNAL_ERROR</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0102</td>
+                <td class="text-left" rowspan="1" colspan="1">Internal error</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_STREAM_CREATION_ERROR</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0103</td>
+                <td class="text-left" rowspan="1" colspan="1">Stream creation error</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_CLOSED_CRITICAL_STREAM</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0104</td>
+                <td class="text-left" rowspan="1" colspan="1">Critical stream was closed</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_FRAME_UNEXPECTED</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0105</td>
+                <td class="text-left" rowspan="1" colspan="1">Frame not permitted in the current state</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_FRAME_ERROR</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0106</td>
+                <td class="text-left" rowspan="1" colspan="1">Frame violated layout or size rules</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_EXCESSIVE_LOAD</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0107</td>
+                <td class="text-left" rowspan="1" colspan="1">Peer generating excessive load</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_ID_ERROR</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0108</td>
+                <td class="text-left" rowspan="1" colspan="1">An identifier was used incorrectly</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_SETTINGS_ERROR</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0109</td>
+                <td class="text-left" rowspan="1" colspan="1">SETTINGS frame contained invalid values</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_MISSING_SETTINGS</td>
+                <td class="text-left" rowspan="1" colspan="1">0x010A</td>
+                <td class="text-left" rowspan="1" colspan="1">No SETTINGS frame received</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_REQUEST_REJECTED</td>
+                <td class="text-left" rowspan="1" colspan="1">0x010B</td>
+                <td class="text-left" rowspan="1" colspan="1">Request not processed</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_REQUEST_CANCELLED</td>
+                <td class="text-left" rowspan="1" colspan="1">0x010C</td>
+                <td class="text-left" rowspan="1" colspan="1">Data no longer needed</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_REQUEST_INCOMPLETE</td>
+                <td class="text-left" rowspan="1" colspan="1">0x010D</td>
+                <td class="text-left" rowspan="1" colspan="1">Stream terminated early</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_CONNECT_ERROR</td>
+                <td class="text-left" rowspan="1" colspan="1">0x010F</td>
+                <td class="text-left" rowspan="1" colspan="1">TCP reset or error on CONNECT request</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">H3_VERSION_FALLBACK</td>
+                <td class="text-left" rowspan="1" colspan="1">0x0110</td>
+                <td class="text-left" rowspan="1" colspan="1">Retry over HTTP/1.1</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#http-error-codes" class="xref">Section 8.1</a>
+</td>
+              </tr>
+            </tbody>
+          </table>
+</div>
+<p id="section-11.2.3-7">Additionally, each code of the format <code>0x1f * N + 0x21</code> for non-negative integer
+values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST
+NOT be assigned by IANA.<a href="#section-11.2.3-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-stream-types">
+<section id="section-11.2.4">
+          <h4 id="name-stream-types">
+<a href="#section-11.2.4" class="section-number selfRef">11.2.4. </a><a href="#name-stream-types" class="section-name selfRef">Stream Types</a>
+          </h4>
+<p id="section-11.2.4-1">This document establishes a registry for HTTP/3 unidirectional stream types. The
+"HTTP/3 Stream Type" registry governs a 62-bit space.  This registry follows the
+QUIC registry policy; see <a href="#iana-policy" class="xref">Section 11.2</a>.  Permanent registrations in this
+registry are assigned using the Specification Required policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>,
+except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are
+assigned using Standards Action or IESG Approval as defined in Section 4.9 and
+4.10 of <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-11.2.4-1" class="pilcrow">¶</a></p>
+<p id="section-11.2.4-2">In addition to common fields as described in <a href="#iana-policy" class="xref">Section 11.2</a>, permanent
+registrations in this registry MUST include the following fields:<a href="#section-11.2.4-2" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-11.2.4-3">
+            <dt id="section-11.2.4-3.1">Stream Type:</dt>
+<dd id="section-11.2.4-3.2">
+  A name or label for the stream type.<a href="#section-11.2.4-3.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-11.2.4-3.3">Sender:</dt>
+<dd id="section-11.2.4-3.4">
+  Which endpoint on a connection may initiate a stream of this type. Values are
+"Client", "Server", or "Both".<a href="#section-11.2.4-3.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-11.2.4-4">Specifications for permanent registrations MUST include a description of the
+stream type, including the layout semantics of the stream contents.<a href="#section-11.2.4-4" class="pilcrow">¶</a></p>
+<p id="section-11.2.4-5">The entries in the following table are registered by this document.<a href="#section-11.2.4-5" class="pilcrow">¶</a></p>
+<table class="center" id="table-5">
+            <caption><a href="#table-5" class="selfRef">Table 5</a></caption>
+<thead>
+              <tr>
+                <th class="text-left" rowspan="1" colspan="1">Stream Type</th>
+                <th class="text-center" rowspan="1" colspan="1">Value</th>
+                <th class="text-left" rowspan="1" colspan="1">Specification</th>
+                <th class="text-left" rowspan="1" colspan="1">Sender</th>
+              </tr>
+            </thead>
+            <tbody>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Control Stream</td>
+                <td class="text-center" rowspan="1" colspan="1">0x00</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#control-streams" class="xref">Section 6.2.1</a>
+</td>
+                <td class="text-left" rowspan="1" colspan="1">Both</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">Push Stream</td>
+                <td class="text-center" rowspan="1" colspan="1">0x01</td>
+                <td class="text-left" rowspan="1" colspan="1">
+                  <a href="#server-push" class="xref">Section 4.4</a>
+</td>
+                <td class="text-left" rowspan="1" colspan="1">Server</td>
+              </tr>
+            </tbody>
+          </table>
+<p id="section-11.2.4-7">Additionally, each code of the format <code>0x1f * N + 0x21</code> for non-negative integer
+values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST
+NOT be assigned by IANA.<a href="#section-11.2.4-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<section id="section-12">
+      <h2 id="name-references">
+<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
+      </h2>
+<section id="section-12.1">
+        <h3 id="name-normative-references">
+<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
+        </h3>
+<dl class="references">
+<dt id="ALTSVC">[ALTSVC]</dt>
+<dd>
+<span class="refAuthor">Nottingham, M.</span><span class="refAuthor">, McManus, P.</span><span class="refAuthor">, and J. Reschke</span>, <span class="refTitle">"HTTP Alternative Services"</span>, <span class="seriesInfo">RFC 7838</span>, <span class="seriesInfo">DOI 10.17487/RFC7838</span>, <time datetime="2016-04">April 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7838">https://www.rfc-editor.org/info/rfc7838</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="CACHING">[CACHING]</dt>
+<dd>
+<span class="refAuthor">Fielding, R.</span><span class="refAuthor">, Nottingham, M.</span><span class="refAuthor">, and J. Reschke</span>, <span class="refTitle">"HTTP Caching"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-httpbis-cache-08</span>, <time datetime="2020-05-26">26 May 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-cache-08.txt">http://www.ietf.org/internet-drafts/draft-ietf-httpbis-cache-08.txt</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="HTTP-REPLAY">[HTTP-REPLAY]</dt>
+<dd>
+<span class="refAuthor">Thomson, M.</span><span class="refAuthor">, Nottingham, M.</span><span class="refAuthor">, and W. Tarreau</span>, <span class="refTitle">"Using Early Data in HTTP"</span>, <span class="seriesInfo">RFC 8470</span>, <span class="seriesInfo">DOI 10.17487/RFC8470</span>, <time datetime="2018-09">September 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8470">https://www.rfc-editor.org/info/rfc8470</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QPACK">[QPACK]</dt>
+<dd>
+<span class="refAuthor">Krasic, C.</span><span class="refAuthor">, Bishop, M.</span><span class="refAuthor">, and A. Frindell, Ed.</span>, <span class="refTitle">"QPACK: Header Compression for HTTP over QUIC"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-qpack-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-qpack-latest">https://tools.ietf.org/html/draft-ietf-quic-qpack-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-TRANSPORT">[QUIC-TRANSPORT]</dt>
+<dd>
+<span class="refAuthor">Iyengar, J., Ed.</span><span class="refAuthor"> and M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-transport-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-transport-latest">https://tools.ietf.org/html/draft-ietf-quic-transport-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC0793">[RFC0793]</dt>
+<dd>
+<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2119">[RFC2119]</dt>
+<dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC3986">[RFC3986]</dt>
+<dd>
+<span class="refAuthor">Berners-Lee, T.</span><span class="refAuthor">, Fielding, R.</span><span class="refAuthor">, and L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5234">[RFC5234]</dt>
+<dd>
+<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6066">[RFC6066]</dt>
+<dd>
+<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Transport Layer Security (TLS) Extensions: Extension Definitions"</span>, <span class="seriesInfo">RFC 6066</span>, <span class="seriesInfo">DOI 10.17487/RFC6066</span>, <time datetime="2011-01">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6066">https://www.rfc-editor.org/info/rfc6066</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6125">[RFC6125]</dt>
+<dd>
+<span class="refAuthor">Saint-Andre, P.</span><span class="refAuthor"> and J. Hodges</span>, <span class="refTitle">"Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 6125</span>, <span class="seriesInfo">DOI 10.17487/RFC6125</span>, <time datetime="2011-03">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6125">https://www.rfc-editor.org/info/rfc6125</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6265">[RFC6265]</dt>
+<dd>
+<span class="refAuthor">Barth, A.</span>, <span class="refTitle">"HTTP State Management Mechanism"</span>, <span class="seriesInfo">RFC 6265</span>, <span class="seriesInfo">DOI 10.17487/RFC6265</span>, <time datetime="2011-04">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6265">https://www.rfc-editor.org/info/rfc6265</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8126">[RFC8126]</dt>
+<dd>
+<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8164">[RFC8164]</dt>
+<dd>
+<span class="refAuthor">Nottingham, M.</span><span class="refAuthor"> and M. Thomson</span>, <span class="refTitle">"Opportunistic Security for HTTP/2"</span>, <span class="seriesInfo">RFC 8164</span>, <span class="seriesInfo">DOI 10.17487/RFC8164</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8164">https://www.rfc-editor.org/info/rfc8164</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8174">[RFC8174]</dt>
+<dd>
+<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="SEMANTICS">[SEMANTICS]</dt>
+<dd>
+<span class="refAuthor">Fielding, R.</span><span class="refAuthor">, Nottingham, M.</span><span class="refAuthor">, and J. Reschke</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-httpbis-semantics-08</span>, <time datetime="2020-05-26">26 May 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-semantics-08.txt">http://www.ietf.org/internet-drafts/draft-ietf-httpbis-semantics-08.txt</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+<section id="section-12.2">
+        <h3 id="name-informative-references">
+<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
+        </h3>
+<dl class="references">
+<dt id="BREACH">[BREACH]</dt>
+<dd>
+<span class="refAuthor">Gluck, Y.</span><span class="refAuthor">, Harris, N.</span><span class="refAuthor">, and A. Prado</span>, <span class="refTitle">"BREACH: Reviving the CRIME Attack"</span>, <time datetime="2013-07">July 2013</time>, <span>&lt;<a href="http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf">http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="HPACK">[HPACK]</dt>
+<dd>
+<span class="refAuthor">Peon, R.</span><span class="refAuthor"> and H. Ruellan</span>, <span class="refTitle">"HPACK: Header Compression for HTTP/2"</span>, <span class="seriesInfo">RFC 7541</span>, <span class="seriesInfo">DOI 10.17487/RFC7541</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7541">https://www.rfc-editor.org/info/rfc7541</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="HTTP11">[HTTP11]</dt>
+<dd>
+<span class="refAuthor">Fielding, R.</span><span class="refAuthor">, Nottingham, M.</span><span class="refAuthor">, and J. Reschke</span>, <span class="refTitle">"HTTP/1.1 Messaging"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-httpbis-messaging-08</span>, <time datetime="2020-05-26">26 May 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-messaging-08.txt">http://www.ietf.org/internet-drafts/draft-ietf-httpbis-messaging-08.txt</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="HTTP2">[HTTP2]</dt>
+<dd>
+<span class="refAuthor">Belshe, M.</span><span class="refAuthor">, Peon, R.</span><span class="refAuthor">, and M. Thomson, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol Version 2 (HTTP/2)"</span>, <span class="seriesInfo">RFC 7540</span>, <span class="seriesInfo">DOI 10.17487/RFC7540</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7540">https://www.rfc-editor.org/info/rfc7540</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6585">[RFC6585]</dt>
+<dd>
+<span class="refAuthor">Nottingham, M.</span><span class="refAuthor"> and R. Fielding</span>, <span class="refTitle">"Additional HTTP Status Codes"</span>, <span class="seriesInfo">RFC 6585</span>, <span class="seriesInfo">DOI 10.17487/RFC6585</span>, <time datetime="2012-04">April 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6585">https://www.rfc-editor.org/info/rfc6585</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC7301">[RFC7301]</dt>
+<dd>
+<span class="refAuthor">Friedl, S.</span><span class="refAuthor">, Popov, A.</span><span class="refAuthor">, Langley, A.</span><span class="refAuthor">, and E. Stephan</span>, <span class="refTitle">"Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension"</span>, <span class="seriesInfo">RFC 7301</span>, <span class="seriesInfo">DOI 10.17487/RFC7301</span>, <time datetime="2014-07">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7301">https://www.rfc-editor.org/info/rfc7301</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="TFO">[TFO]</dt>
+<dd>
+<span class="refAuthor">Cheng, Y.</span><span class="refAuthor">, Chu, J.</span><span class="refAuthor">, Radhakrishnan, S.</span><span class="refAuthor">, and A. Jain</span>, <span class="refTitle">"TCP Fast Open"</span>, <span class="seriesInfo">RFC 7413</span>, <span class="seriesInfo">DOI 10.17487/RFC7413</span>, <time datetime="2014-12">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7413">https://www.rfc-editor.org/info/rfc7413</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="TLS13">[TLS13]</dt>
+<dd>
+<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="URI">[URI]</dt>
+<dd>
+<span class="refAuthor">Berners-Lee, T.</span><span class="refAuthor">, Fielding, R.</span><span class="refAuthor">, and L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</section>
+<div id="h2-considerations">
+<section id="section-appendix.a">
+      <h2 id="name-considerations-for-transiti">
+<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-considerations-for-transiti" class="section-name selfRef">Considerations for Transitioning from HTTP/2</a>
+      </h2>
+<p id="section-appendix.a-1">HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  This
+section describes the approach taken to design HTTP/3, points out important
+differences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
+<p id="section-appendix.a-2">HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but not
+a hard requirement.  HTTP/3 departs from HTTP/2 where QUIC differs from TCP,
+either to take advantage of QUIC features (like streams) or to accommodate
+important shortcomings (such as a lack of total ordering). These differences
+make HTTP/3 similar to HTTP/2 in key aspects, such as the relationship of
+requests and responses to streams. However, the details of the HTTP/3 design are
+substantially different than HTTP/2.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
+<p id="section-appendix.a-3">These departures are noted in this section.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
+<div id="h2-streams">
+<section id="section-a.1">
+        <h2 id="name-streams">
+<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-streams" class="section-name selfRef">Streams</a>
+        </h2>
+<p id="section-a.1-1">HTTP/3 permits use of a larger number of streams (2^62-1) than HTTP/2.  The
+considerations about exhaustion of stream identifier space apply, though the
+space is significantly larger such that it is likely that other limits in QUIC
+are reached first, such as the limit on the connection flow control window.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
+<p id="section-a.1-2">In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC.  QUIC
+considers a stream closed when all data has been received and sent data has been
+acknowledged by the peer.  HTTP/2 considers a stream closed when the frame
+containing the END_STREAM bit has been committed to the transport. As a result,
+the stream for an equivalent exchange could remain "active" for a longer period
+of time.  HTTP/3 servers might choose to permit a larger number of concurrent
+client-initiated bidirectional streams to achieve equivalent concurrency to
+HTTP/2, depending on the expected usage patterns.<a href="#section-a.1-2" class="pilcrow">¶</a></p>
+<p id="section-a.1-3">Due to the presence of other unidirectional stream types, HTTP/3 does not rely
+exclusively on the number of concurrent unidirectional streams to control the
+number of concurrent in-flight pushes.  Instead, HTTP/3 clients use the
+MAX_PUSH_ID frame to control the number of pushes received from an HTTP/3
+server.<a href="#section-a.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="h2-frames">
+<section id="section-a.2">
+        <h2 id="name-http-frame-types">
+<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-http-frame-types" class="section-name selfRef">HTTP Frame Types</a>
+        </h2>
+<p id="section-a.2-1">Many framing concepts from HTTP/2 can be elided on QUIC, because the transport
+deals with them. Because frames are already on a stream, they can omit the
+stream number. Because frames do not block multiplexing (QUIC's multiplexing
+occurs below this layer), the support for variable-maximum-length packets can be
+removed. Because stream termination is handled by QUIC, an END_STREAM flag is
+not required.  This permits the removal of the Flags field from the generic
+frame layout.<a href="#section-a.2-1" class="pilcrow">¶</a></p>
+<p id="section-a.2-2">Frame payloads are largely drawn from <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>. However, QUIC includes many
+features (e.g., flow control) which are also present in HTTP/2. In these cases,
+the HTTP mapping does not re-implement them. As a result, several HTTP/2 frame
+types are not required in HTTP/3. Where an HTTP/2-defined frame is no longer
+used, the frame ID has been reserved in order to maximize portability between
+HTTP/2 and HTTP/3 implementations. However, even equivalent frames between the
+two mappings are not identical.<a href="#section-a.2-2" class="pilcrow">¶</a></p>
+<p id="section-a.2-3">Many of the differences arise from the fact that HTTP/2 provides an absolute
+ordering between frames across all streams, while QUIC provides this guarantee
+on each stream only.  As a result, if a frame type makes assumptions that frames
+from different streams will still be received in the order sent, HTTP/3 will
+break them.<a href="#section-a.2-3" class="pilcrow">¶</a></p>
+<p id="section-a.2-4">Some examples of feature adaptations are described below, as well as general
+guidance to extension frame implementors converting an HTTP/2 extension to
+HTTP/3.<a href="#section-a.2-4" class="pilcrow">¶</a></p>
+<div id="h2-diff-priority">
+<section id="section-a.2.1">
+          <h3 id="name-prioritization-differences">
+<a href="#section-a.2.1" class="section-number selfRef">A.2.1. </a><a href="#name-prioritization-differences" class="section-name selfRef">Prioritization Differences</a>
+          </h3>
+<p id="section-a.2.1-1">HTTP/2 specifies priority assignments in PRIORITY frames and (optionally) in
+HEADERS frames. HTTP/3 does not provide a means of signaling priority.<a href="#section-a.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-a.2.1-2">Note that while there is no explicit signaling for priority, this does not mean
+that prioritization is not important for achieving good performance.<a href="#section-a.2.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="field-compression-differences">
+<section id="section-a.2.2">
+          <h3 id="name-field-compression-differenc">
+<a href="#section-a.2.2" class="section-number selfRef">A.2.2. </a><a href="#name-field-compression-differenc" class="section-name selfRef">Field Compression Differences</a>
+          </h3>
+<p id="section-a.2.2-1">HPACK was designed with the assumption of in-order delivery. A sequence of
+encoded field sections must arrive (and be decoded) at an endpoint in the same
+order in which they were encoded. This ensures that the dynamic state at the two
+endpoints remains in sync.<a href="#section-a.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-a.2.2-2">Because this total ordering is not provided by QUIC, HTTP/3 uses a modified
+version of HPACK, called QPACK.  QPACK uses a single unidirectional stream to
+make all modifications to the dynamic table, ensuring a total order of updates.
+All frames which contain encoded fields merely reference the table state at a
+given time without modifying it.<a href="#section-a.2.2-2" class="pilcrow">¶</a></p>
+<p id="section-a.2.2-3"><span>[<a href="#QPACK" class="xref">QPACK</a>]</span> provides additional details.<a href="#section-a.2.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="guidance-for-new-frame-type-definitions">
+<section id="section-a.2.3">
+          <h3 id="name-guidance-for-new-frame-type">
+<a href="#section-a.2.3" class="section-number selfRef">A.2.3. </a><a href="#name-guidance-for-new-frame-type" class="section-name selfRef">Guidance for New Frame Type Definitions</a>
+          </h3>
+<p id="section-a.2.3-1">Frame type definitions in HTTP/3 often use the QUIC variable-length integer
+encoding.  In particular, Stream IDs use this encoding, which allows for a
+larger range of possible values than the encoding used in HTTP/2.  Some frames
+in HTTP/3 use an identifier rather than a Stream ID (e.g., Push
+IDs). Redefinition of the encoding of extension frame types might be necessary
+if the encoding includes a Stream ID.<a href="#section-a.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-a.2.3-2">Because the Flags field is not present in generic HTTP/3 frames, those frames
+which depend on the presence of flags need to allocate space for flags as part
+of their frame payload.<a href="#section-a.2.3-2" class="pilcrow">¶</a></p>
+<p id="section-a.2.3-3">Other than this issue, frame type HTTP/2 extensions are typically portable to
+QUIC simply by replacing Stream 0 in HTTP/2 with a control stream in HTTP/3.
+HTTP/3 extensions will not assume ordering, but would not be harmed by ordering,
+and would be portable to HTTP/2 in the same manner.<a href="#section-a.2.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="mapping-between-http2-and-http3-frame-types">
+<section id="section-a.2.4">
+          <h3 id="name-mapping-between-http-2-and-">
+<a href="#section-a.2.4" class="section-number selfRef">A.2.4. </a><a href="#name-mapping-between-http-2-and-" class="section-name selfRef">Mapping Between HTTP/2 and HTTP/3 Frame Types</a>
+          </h3>
+<dl class="dlParallel" id="section-a.2.4-1">
+            <dt id="section-a.2.4-1.1">DATA (0x0):</dt>
+<dd id="section-a.2.4-1.2">
+  Padding is not defined in HTTP/3 frames.  See <a href="#frame-data" class="xref">Section 7.2.1</a>.<a href="#section-a.2.4-1.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.3">HEADERS (0x1):</dt>
+<dd id="section-a.2.4-1.4">
+  The PRIORITY region of HEADERS is not defined in HTTP/3 frames. Padding is not
+defined in HTTP/3 frames.  See <a href="#frame-headers" class="xref">Section 7.2.2</a>.<a href="#section-a.2.4-1.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.5">PRIORITY (0x2):</dt>
+<dd id="section-a.2.4-1.6">
+  As described in <a href="#h2-diff-priority" class="xref">Appendix A.2.1</a>, HTTP/3 does not provide a means of
+signaling priority.<a href="#section-a.2.4-1.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.7">RST_STREAM (0x3):</dt>
+<dd id="section-a.2.4-1.8">
+  RST_STREAM frames do not exist, since QUIC provides stream lifecycle
+management.  The same code point is used for the CANCEL_PUSH frame
+(<a href="#frame-cancel-push" class="xref">Section 7.2.3</a>).<a href="#section-a.2.4-1.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.9">SETTINGS (0x4):</dt>
+<dd id="section-a.2.4-1.10">
+  SETTINGS frames are sent only at the beginning of the connection.  See
+<a href="#frame-settings" class="xref">Section 7.2.4</a> and <a href="#h2-settings" class="xref">Appendix A.3</a>.<a href="#section-a.2.4-1.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.11">PUSH_PROMISE (0x5):</dt>
+<dd id="section-a.2.4-1.12">
+  The PUSH_PROMISE does not reference a stream; instead the push stream
+references the PUSH_PROMISE frame using a Push ID.  See
+<a href="#frame-push-promise" class="xref">Section 7.2.5</a>.<a href="#section-a.2.4-1.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.13">PING (0x6):</dt>
+<dd id="section-a.2.4-1.14">
+  PING frames do not exist, since QUIC provides equivalent functionality.<a href="#section-a.2.4-1.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.15">GOAWAY (0x7):</dt>
+<dd id="section-a.2.4-1.16">
+  GOAWAY does not contain an error code.  In the client to server direction,
+it carries a Push ID instead of a server initiated stream ID.
+See <a href="#frame-goaway" class="xref">Section 7.2.6</a>.<a href="#section-a.2.4-1.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.17">WINDOW_UPDATE (0x8):</dt>
+<dd id="section-a.2.4-1.18">
+  WINDOW_UPDATE frames do not exist, since QUIC provides flow control.<a href="#section-a.2.4-1.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2.4-1.19">CONTINUATION (0x9):</dt>
+<dd id="section-a.2.4-1.20">
+  CONTINUATION frames do not exist; instead, larger HEADERS/PUSH_PROMISE
+frames than HTTP/2 are permitted.<a href="#section-a.2.4-1.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-a.2.4-2">Frame types defined by extensions to HTTP/2 need to be separately registered for
+HTTP/3 if still applicable.  The IDs of frames defined in <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span> have been
+reserved for simplicity.  Note that the frame type space in HTTP/3 is
+substantially larger (62 bits versus 8 bits), so many HTTP/3 frame types have no
+equivalent HTTP/2 code points.  See <a href="#iana-frames" class="xref">Section 11.2.1</a>.<a href="#section-a.2.4-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="h2-settings">
+<section id="section-a.3">
+        <h2 id="name-http-2-settings-parameters">
+<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-http-2-settings-parameters" class="section-name selfRef">HTTP/2 SETTINGS Parameters</a>
+        </h2>
+<p id="section-a.3-1">An important difference from HTTP/2 is that settings are sent once, as the first
+frame of the control stream, and thereafter cannot change.  This eliminates many
+corner cases around synchronization of changes.<a href="#section-a.3-1" class="pilcrow">¶</a></p>
+<p id="section-a.3-2">Some transport-level options that HTTP/2 specifies via the SETTINGS frame are
+superseded by QUIC transport parameters in HTTP/3. The HTTP-level options that
+are retained in HTTP/3 have the same value as in HTTP/2.<a href="#section-a.3-2" class="pilcrow">¶</a></p>
+<p id="section-a.3-3">Below is a listing of how each HTTP/2 SETTINGS parameter is mapped:<a href="#section-a.3-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-a.3-4">
+          <dt id="section-a.3-4.1">SETTINGS_HEADER_TABLE_SIZE:</dt>
+<dd id="section-a.3-4.2">
+  See <span>[<a href="#QPACK" class="xref">QPACK</a>]</span>.<a href="#section-a.3-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-4.3">SETTINGS_ENABLE_PUSH:</dt>
+<dd id="section-a.3-4.4">
+  This is removed in favor of the MAX_PUSH_ID which provides a more granular
+control over server push.<a href="#section-a.3-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-4.5">SETTINGS_MAX_CONCURRENT_STREAMS:</dt>
+<dd id="section-a.3-4.6">
+  QUIC controls the largest open Stream ID as part of its flow control logic.
+Specifying SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error.<a href="#section-a.3-4.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-4.7">SETTINGS_INITIAL_WINDOW_SIZE:</dt>
+<dd id="section-a.3-4.8">
+  QUIC requires both stream and connection flow control window sizes to be
+specified in the initial transport handshake.  Specifying
+SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error.<a href="#section-a.3-4.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-4.9">SETTINGS_MAX_FRAME_SIZE:</dt>
+<dd id="section-a.3-4.10">
+  This setting has no equivalent in HTTP/3.  Specifying it in the SETTINGS frame
+is an error.<a href="#section-a.3-4.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-4.11">SETTINGS_MAX_FIELD_SECTION_SIZE:</dt>
+<dd id="section-a.3-4.12">
+  See <a href="#settings-parameters" class="xref">Section 7.2.4.1</a>.<a href="#section-a.3-4.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-a.3-5">In HTTP/3, setting values are variable-length integers (6, 14, 30, or 62 bits
+long) rather than fixed-length 32-bit fields as in HTTP/2.  This will often
+produce a shorter encoding, but can produce a longer encoding for settings which
+use the full 32-bit space.  Settings ported from HTTP/2 might choose to redefine
+their value to limit it to 30 bits for more efficient encoding, or to make use
+of the 62-bit space if more than 30 bits are required.<a href="#section-a.3-5" class="pilcrow">¶</a></p>
+<p id="section-a.3-6">Settings need to be defined separately for HTTP/2 and HTTP/3. The IDs of
+settings defined in <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span> have been reserved for simplicity.  Note that
+the settings identifier space in HTTP/3 is substantially larger (62 bits versus
+16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See
+<a href="#iana-settings" class="xref">Section 11.2.2</a>.<a href="#section-a.3-6" class="pilcrow">¶</a></p>
+<p id="section-a.3-7">As QUIC streams might arrive out-of-order, endpoints are advised to not wait for
+the peers' settings to arrive before responding to other streams.  See
+<a href="#settings-initialization" class="xref">Section 7.2.4.2</a>.<a href="#section-a.3-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="http2-error-codes">
+<section id="section-a.4">
+        <h2 id="name-http-2-error-codes">
+<a href="#section-a.4" class="section-number selfRef">A.4. </a><a href="#name-http-2-error-codes" class="section-name selfRef">HTTP/2 Error Codes</a>
+        </h2>
+<p id="section-a.4-1">QUIC has the same concepts of "stream" and "connection" errors that HTTP/2
+provides. However, the differences between HTTP/2 and HTTP/3 mean that error
+codes are not directly portable between versions.<a href="#section-a.4-1" class="pilcrow">¶</a></p>
+<p id="section-a.4-2">The HTTP/2 error codes defined in Section 7 of <span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span> logically map to
+the HTTP/3 error codes as follows:<a href="#section-a.4-2" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-a.4-3">
+          <dt id="section-a.4-3.1">NO_ERROR (0x0):</dt>
+<dd id="section-a.4-3.2">
+  H3_NO_ERROR in <a href="#http-error-codes" class="xref">Section 8.1</a>.<a href="#section-a.4-3.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.3">PROTOCOL_ERROR (0x1):</dt>
+<dd id="section-a.4-3.4">
+  This is mapped to H3_GENERAL_PROTOCOL_ERROR except in cases where more
+specific error codes have been defined. This includes H3_FRAME_UNEXPECTED
+and H3_CLOSED_CRITICAL_STREAM defined in <a href="#http-error-codes" class="xref">Section 8.1</a>.<a href="#section-a.4-3.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.5">INTERNAL_ERROR (0x2):</dt>
+<dd id="section-a.4-3.6">
+  H3_INTERNAL_ERROR in <a href="#http-error-codes" class="xref">Section 8.1</a>.<a href="#section-a.4-3.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.7">FLOW_CONTROL_ERROR (0x3):</dt>
+<dd id="section-a.4-3.8">
+  Not applicable, since QUIC handles flow control.<a href="#section-a.4-3.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.9">SETTINGS_TIMEOUT (0x4):</dt>
+<dd id="section-a.4-3.10">
+  Not applicable, since no acknowledgement of SETTINGS is defined.<a href="#section-a.4-3.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.11">STREAM_CLOSED (0x5):</dt>
+<dd id="section-a.4-3.12">
+  Not applicable, since QUIC handles stream management.<a href="#section-a.4-3.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.13">FRAME_SIZE_ERROR (0x6):</dt>
+<dd id="section-a.4-3.14">
+  H3_FRAME_ERROR error code defined in <a href="#http-error-codes" class="xref">Section 8.1</a>.<a href="#section-a.4-3.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.15">REFUSED_STREAM (0x7):</dt>
+<dd id="section-a.4-3.16">
+  H3_REQUEST_REJECTED (in <a href="#http-error-codes" class="xref">Section 8.1</a>) is used to indicate that a
+request was not processed. Otherwise, not applicable because QUIC handles
+stream management.<a href="#section-a.4-3.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.17">CANCEL (0x8):</dt>
+<dd id="section-a.4-3.18">
+  H3_REQUEST_CANCELLED in <a href="#http-error-codes" class="xref">Section 8.1</a>.<a href="#section-a.4-3.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.19">COMPRESSION_ERROR (0x9):</dt>
+<dd id="section-a.4-3.20">
+  Multiple error codes are defined in <span>[<a href="#QPACK" class="xref">QPACK</a>]</span>.<a href="#section-a.4-3.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.21">CONNECT_ERROR (0xa):</dt>
+<dd id="section-a.4-3.22">
+  H3_CONNECT_ERROR in <a href="#http-error-codes" class="xref">Section 8.1</a>.<a href="#section-a.4-3.22" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.23">ENHANCE_YOUR_CALM (0xb):</dt>
+<dd id="section-a.4-3.24">
+  H3_EXCESSIVE_LOAD in <a href="#http-error-codes" class="xref">Section 8.1</a>.<a href="#section-a.4-3.24" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.25">INADEQUATE_SECURITY (0xc):</dt>
+<dd id="section-a.4-3.26">
+  Not applicable, since QUIC is assumed to provide sufficient security on all
+connections.<a href="#section-a.4-3.26" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.4-3.27">H3_1_1_REQUIRED (0xd):</dt>
+<dd id="section-a.4-3.28">
+  H3_VERSION_FALLBACK in <a href="#http-error-codes" class="xref">Section 8.1</a>.<a href="#section-a.4-3.28" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-a.4-4">Error codes need to be defined for HTTP/2 and HTTP/3 separately.  See
+<a href="#iana-error-codes" class="xref">Section 11.2.3</a>.<a href="#section-a.4-4" class="pilcrow">¶</a></p>
+<div id="mapping-between-http2-and-http3-errors">
+<section id="section-a.4.1">
+          <h3 id="name-mapping-between-http-2-and-h">
+<a href="#section-a.4.1" class="section-number selfRef">A.4.1. </a><a href="#name-mapping-between-http-2-and-h" class="section-name selfRef">Mapping Between HTTP/2 and HTTP/3 Errors</a>
+          </h3>
+<p id="section-a.4.1-1">An intermediary that converts between HTTP/2 and HTTP/3 may encounter error
+conditions from either upstream. It is useful to communicate the occurrence of
+error to the downstream but error codes largely reflect connection-local
+problems that generally do not make sense to propagate.<a href="#section-a.4.1-1" class="pilcrow">¶</a></p>
+<p id="section-a.4.1-2">An intermediary that encounters an error from an upstream origin can indicate
+this by sending an HTTP status code such as 502, which is suitable for a broad
+class of errors.<a href="#section-a.4.1-2" class="pilcrow">¶</a></p>
+<p id="section-a.4.1-3">There are some rare cases where it is beneficial to propagate the error by
+mapping it to the closest matching error type to the receiver. For example, an
+intermediary that receives an HTTP/2 stream error of type REFUSED_STREAM from
+the origin has a clear signal that the request was not processed and that the
+request is safe to retry. Propagating this error condition to the client as an
+HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to take the
+action it deems most appropriate. In the reverse direction the intermediary
+might deem it beneficial to pass on client request cancellations that are
+indicated by terminating a stream with H3_REQUEST_CANCELLED.<a href="#section-a.4.1-3" class="pilcrow">¶</a></p>
+<p id="section-a.4.1-4">Conversion between errors is described in the logical mapping. The error codes
+are defined in non-overlapping spaces in order to protect against accidental
+conversion that could result in the use of inappropriate or unknown error codes
+for the target version. An intermediary is permitted to promote stream errors to
+connection errors but they should be aware of the cost to the connection for
+what might be a temporary or intermittent error.<a href="#section-a.4.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="change-log">
+<section id="section-appendix.b">
+      <h2 id="name-change-log">
+<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-change-log" class="section-name selfRef">Change Log</a>
+      </h2>
+<ul class="normal ulEmpty">
+<li class="normal ulEmpty" id="section-appendix.b-1.1">
+          <strong>RFC Editor's Note:</strong>  Please remove this section prior to publication of a
+final version of this document.<a href="#section-appendix.b-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+<div id="since-draft-ietf-quic-http-27">
+<section id="section-b.1">
+        <h2 id="name-since-draft-ietf-quic-http-">
+<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-since-draft-ietf-quic-http-" class="section-name selfRef">Since draft-ietf-quic-http-27</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.1-1.1">Updated text to refer to latest HTTP revisions<a href="#section-b.1-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.1-1.2">Use the HTTP definition of authority for establishing and coalescing
+connections (#253, #2223, #3558)<a href="#section-b.1-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.1-1.3">Define use of GOAWAY from both endpoints (#2632, #3129)<a href="#section-b.1-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.1-1.4">Require either :authority or Host if the URI scheme has a mandatory
+authority component (#3408, #3475)<a href="#section-b.1-1.4" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-26">
+<section id="section-b.2">
+        <h2 id="name-since-draft-ietf-quic-http-2">
+<a href="#section-b.2" class="section-number selfRef">B.2. </a><a href="#name-since-draft-ietf-quic-http-2" class="section-name selfRef">Since draft-ietf-quic-http-26</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.2-1.1">No changes<a href="#section-b.2-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-25">
+<section id="section-b.3">
+        <h2 id="name-since-draft-ietf-quic-http-25">
+<a href="#section-b.3" class="section-number selfRef">B.3. </a><a href="#name-since-draft-ietf-quic-http-25" class="section-name selfRef">Since draft-ietf-quic-http-25</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.3-1.1">Require QUICv1 for HTTP/3 (#3117, #3323)<a href="#section-b.3-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.3-1.2">Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3275, #3309)<a href="#section-b.3-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.3-1.3">Clarify the definition of "malformed" (#3352, #3345)<a href="#section-b.3-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-24">
+<section id="section-b.4">
+        <h2 id="name-since-draft-ietf-quic-http-24">
+<a href="#section-b.4" class="section-number selfRef">B.4. </a><a href="#name-since-draft-ietf-quic-http-24" class="section-name selfRef">Since draft-ietf-quic-http-24</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.4-1.1">Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended instead
+(#3130,#3208)<a href="#section-b.4-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.4-1.2">Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331)<a href="#section-b.4-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.4-1.3">Some error codes are reserved for greasing (#3325,#3360)<a href="#section-b.4-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-23">
+<section id="section-b.5">
+        <h2 id="name-since-draft-ietf-quic-http-23">
+<a href="#section-b.5" class="section-number selfRef">B.5. </a><a href="#name-since-draft-ietf-quic-http-23" class="section-name selfRef">Since draft-ietf-quic-http-23</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.5-1.1">Removed <code>quic</code> Alt-Svc parameter (#3061,#3118)<a href="#section-b.5-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.5-1.2">Clients need not persist unknown settings for use in 0-RTT (#3110,#3113)<a href="#section-b.5-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.5-1.3">Clarify error cases around CANCEL_PUSH (#2819,#3083)<a href="#section-b.5-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-22">
+<section id="section-b.6">
+        <h2 id="name-since-draft-ietf-quic-http-22">
+<a href="#section-b.6" class="section-number selfRef">B.6. </a><a href="#name-since-draft-ietf-quic-http-22" class="section-name selfRef">Since draft-ietf-quic-http-22</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.6-1.1">Removed priority signaling (#2922,#2924)<a href="#section-b.6-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.2">
+            <p id="section-b.6-1.2.1">Further changes to error codes (#2662,#2551):<a href="#section-b.6-1.2.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.6-1.2.2.1">Error codes renumbered<a href="#section-b.6-1.2.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.2.2.2">HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR, HTTP_ID_ERROR, and others<a href="#section-b.6-1.2.2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.6-1.3">Clarify how unknown frame types interact with required frame sequence
+(#2867,#2858)<a href="#section-b.6-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.4">Describe interactions with the transport in terms of defined interface terms
+(#2857,#2805)<a href="#section-b.6-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.5">Require the use of the <code>http-opportunistic</code> resource (RFC 8164) when scheme is
+<code>http</code> (#2439,#2973)<a href="#section-b.6-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.6">Settings identifiers cannot be duplicated (#2979)<a href="#section-b.6-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.7">
+            <p id="section-b.6-1.7.1">Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945):<a href="#section-b.6-1.7.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.6-1.7.2.1">Servers must send all settings with non-default values in their SETTINGS
+frame, even when resuming<a href="#section-b.6-1.7.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.7.2.2">If a client doesn't have settings associated with a 0-RTT ticket, it uses
+the defaults<a href="#section-b.6-1.7.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.7.2.3">Servers can't accept early data if they cannot recover the settings the
+client will have remembered<a href="#section-b.6-1.7.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.6-1.8">Clarify that Upgrade and the 101 status code are prohibited (#2898,#2889)<a href="#section-b.6-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.9">Clarify that frame types reserved for greasing can occur on any stream, but
+frame types reserved due to HTTP/2 correspondence are prohibited
+(#2997,#2692,#2693)<a href="#section-b.6-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.6-1.10">Unknown error codes cannot be treated as errors (#2998,#2816)<a href="#section-b.6-1.10" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-21">
+<section id="section-b.7">
+        <h2 id="name-since-draft-ietf-quic-http-21">
+<a href="#section-b.7" class="section-number selfRef">B.7. </a><a href="#name-since-draft-ietf-quic-http-21" class="section-name selfRef">Since draft-ietf-quic-http-21</a>
+        </h2>
+<p id="section-b.7-1">No changes<a href="#section-b.7-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-20">
+<section id="section-b.8">
+        <h2 id="name-since-draft-ietf-quic-http-20">
+<a href="#section-b.8" class="section-number selfRef">B.8. </a><a href="#name-since-draft-ietf-quic-http-20" class="section-name selfRef">Since draft-ietf-quic-http-20</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.8-1.1">Prohibit closing the control stream (#2509, #2666)<a href="#section-b.8-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.2">Change default priority to use an orphan node (#2502, #2690)<a href="#section-b.8-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.3">Exclusive priorities are restored (#2754, #2781)<a href="#section-b.8-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.4">Restrict use of frames when using CONNECT (#2229, #2702)<a href="#section-b.8-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.5">Close and maybe reset streams if a connection error occurs for CONNECT (#2228,
+#2703)<a href="#section-b.8-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.6">Encourage provision of sufficient unidirectional streams for QPACK (#2100,
+#2529, #2762)<a href="#section-b.8-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.7">Allow extensions to use server-initiated bidirectional streams (#2711, #2773)<a href="#section-b.8-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.8">Clarify use of maximum header list size setting (#2516, #2774)<a href="#section-b.8-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9">
+            <p id="section-b.8-1.9.1">Extensive changes to error codes and conditions of their sending<a href="#section-b.8-1.9.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.8-1.9.2.1">Require connection errors for more error conditions (#2511, #2510)<a href="#section-b.8-1.9.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9.2.2">Updated the error codes for illegal GOAWAY frames (#2714, #2707)<a href="#section-b.8-1.9.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9.2.3">Specified error code for HEADERS on control stream (#2708)<a href="#section-b.8-1.9.2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9.2.4">Specified error code for servers receiving PUSH_PROMISE (#2709)<a href="#section-b.8-1.9.2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9.2.5">Specified error code for receiving DATA before HEADERS (#2715)<a href="#section-b.8-1.9.2.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9.2.6">Describe malformed messages and their handling (#2410, #2764)<a href="#section-b.8-1.9.2.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9.2.7">Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813)<a href="#section-b.8-1.9.2.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9.2.8">Refactor Push ID related errors (#2818, #2820)<a href="#section-b.8-1.9.2.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.9.2.9">Rationalize HTTP/3 stream creation errors (#2821, #2822)<a href="#section-b.8-1.9.2.9" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-19">
+<section id="section-b.9">
+        <h2 id="name-since-draft-ietf-quic-http-1">
+<a href="#section-b.9" class="section-number selfRef">B.9. </a><a href="#name-since-draft-ietf-quic-http-1" class="section-name selfRef">Since draft-ietf-quic-http-19</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.9-1.1">SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530)<a href="#section-b.9-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.9-1.2">Non-zero bits in the Empty field of the PRIORITY frame MAY be treated as an
+error (#2501)<a href="#section-b.9-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-18">
+<section id="section-b.10">
+        <h2 id="name-since-draft-ietf-quic-http-18">
+<a href="#section-b.10" class="section-number selfRef">B.10. </a><a href="#name-since-draft-ietf-quic-http-18" class="section-name selfRef">Since draft-ietf-quic-http-18</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.10-1.1">Resetting streams following a GOAWAY is recommended, but not required
+(#2256,#2457)<a href="#section-b.10-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.10-1.2">
+            <p id="section-b.10-1.2.1">Use variable-length integers throughout (#2437,#2233,#2253,#2275)<a href="#section-b.10-1.2.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.10-1.2.2.1">Variable-length frame types, stream types, and settings identifiers<a href="#section-b.10-1.2.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.10-1.2.2.2">Renumbered stream type assignments<a href="#section-b.10-1.2.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.10-1.2.2.3">Modified associated reserved values<a href="#section-b.10-1.2.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.10-1.3">Frame layout switched from Length-Type-Value to Type-Length-Value
+(#2395,#2235)<a href="#section-b.10-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.10-1.4">Specified error code for servers receiving DUPLICATE_PUSH (#2497)<a href="#section-b.10-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.10-1.5">Use connection error for invalid PRIORITY (#2507, #2508)<a href="#section-b.10-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-17">
+<section id="section-b.11">
+        <h2 id="name-since-draft-ietf-quic-http-17">
+<a href="#section-b.11" class="section-number selfRef">B.11. </a><a href="#name-since-draft-ietf-quic-http-17" class="section-name selfRef">Since draft-ietf-quic-http-17</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.11-1.1">HTTP_REQUEST_REJECTED is used to indicate a request can be retried (#2106,
+#2325)<a href="#section-b.11-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.11-1.2">Changed error code for GOAWAY on the wrong stream (#2231, #2343)<a href="#section-b.11-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-16">
+<section id="section-b.12">
+        <h2 id="name-since-draft-ietf-quic-http-16">
+<a href="#section-b.12" class="section-number selfRef">B.12. </a><a href="#name-since-draft-ietf-quic-http-16" class="section-name selfRef">Since draft-ietf-quic-http-16</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.12-1.1">Rename "HTTP/QUIC" to "HTTP/3" (#1973)<a href="#section-b.12-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.12-1.2">
+            <p id="section-b.12-1.2.1">Changes to PRIORITY frame (#1865, #2075)<a href="#section-b.12-1.2.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.12-1.2.2.1">Permitted as first frame of request streams<a href="#section-b.12-1.2.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.12-1.2.2.2">Remove exclusive reprioritization<a href="#section-b.12-1.2.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.12-1.2.2.3">Changes to Prioritized Element Type bits<a href="#section-b.12-1.2.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.12-1.3">Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE (#2072)<a href="#section-b.12-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.12-1.4">Set defaults for settings, allow request before receiving SETTINGS (#1809,
+#1846, #2038)<a href="#section-b.12-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.12-1.5">Clarify message processing rules for streams that aren't closed (#1972, #2003)<a href="#section-b.12-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.12-1.6">Removed reservation of error code 0 and moved HTTP_NO_ERROR to this value
+(#1922)<a href="#section-b.12-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.12-1.7">Removed prohibition of zero-length DATA frames (#2098)<a href="#section-b.12-1.7" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-15">
+<section id="section-b.13">
+        <h2 id="name-since-draft-ietf-quic-http-15">
+<a href="#section-b.13" class="section-number selfRef">B.13. </a><a href="#name-since-draft-ietf-quic-http-15" class="section-name selfRef">Since draft-ietf-quic-http-15</a>
+        </h2>
+<p id="section-b.13-1">Substantial editorial reorganization; no technical changes.<a href="#section-b.13-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-14">
+<section id="section-b.14">
+        <h2 id="name-since-draft-ietf-quic-http-14">
+<a href="#section-b.14" class="section-number selfRef">B.14. </a><a href="#name-since-draft-ietf-quic-http-14" class="section-name selfRef">Since draft-ietf-quic-http-14</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.14-1.1">Recommend sensible values for QUIC transport parameters (#1720,#1806)<a href="#section-b.14-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.14-1.2">Define error for missing SETTINGS frame (#1697,#1808)<a href="#section-b.14-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.14-1.3">Setting values are variable-length integers (#1556,#1807) and do not have
+separate maximum values (#1820)<a href="#section-b.14-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.14-1.4">Expanded discussion of connection closure (#1599,#1717,#1712)<a href="#section-b.14-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.14-1.5">HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)<a href="#section-b.14-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-13">
+<section id="section-b.15">
+        <h2 id="name-since-draft-ietf-quic-http-13">
+<a href="#section-b.15" class="section-number selfRef">B.15. </a><a href="#name-since-draft-ietf-quic-http-13" class="section-name selfRef">Since draft-ietf-quic-http-13</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.15-1.1">Reserved some frame types for grease (#1333, #1446)<a href="#section-b.15-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.15-1.2">Unknown unidirectional stream types are tolerated, not errors; some reserved
+for grease (#1490, #1525)<a href="#section-b.15-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.15-1.3">Require settings to be remembered for 0-RTT, prohibit reductions (#1541,
+#1641)<a href="#section-b.15-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.15-1.4">Specify behavior for truncated requests (#1596, #1643)<a href="#section-b.15-1.4" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-12">
+<section id="section-b.16">
+        <h2 id="name-since-draft-ietf-quic-http-12">
+<a href="#section-b.16" class="section-number selfRef">B.16. </a><a href="#name-since-draft-ietf-quic-http-12" class="section-name selfRef">Since draft-ietf-quic-http-12</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.16-1.1">TLS SNI extension isn't mandatory if an alternative method is used (#1459,
+#1462, #1466)<a href="#section-b.16-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.16-1.2">Removed flags from HTTP/3 frames (#1388, #1398)<a href="#section-b.16-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.16-1.3">Reserved frame types and settings for use in preserving extensibility (#1333,
+#1446)<a href="#section-b.16-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.16-1.4">Added general error code (#1391, #1397)<a href="#section-b.16-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.16-1.5">Unidirectional streams carry a type byte and are extensible (#910,#1359)<a href="#section-b.16-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.16-1.6">Priority mechanism now uses explicit placeholders to enable persistent
+structure in the tree (#441,#1421,#1422)<a href="#section-b.16-1.6" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-11">
+<section id="section-b.17">
+        <h2 id="name-since-draft-ietf-quic-http-11">
+<a href="#section-b.17" class="section-number selfRef">B.17. </a><a href="#name-since-draft-ietf-quic-http-11" class="section-name selfRef">Since draft-ietf-quic-http-11</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.17-1.1">Moved QPACK table updates and acknowledgments to dedicated streams (#1121,
+#1122, #1238)<a href="#section-b.17-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-10">
+<section id="section-b.18">
+        <h2 id="name-since-draft-ietf-quic-http-10">
+<a href="#section-b.18" class="section-number selfRef">B.18. </a><a href="#name-since-draft-ietf-quic-http-10" class="section-name selfRef">Since draft-ietf-quic-http-10</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.18-1.1">Settings need to be remembered when attempting and accepting 0-RTT (#1157,
+#1207)<a href="#section-b.18-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-09">
+<section id="section-b.19">
+        <h2 id="name-since-draft-ietf-quic-http-0">
+<a href="#section-b.19" class="section-number selfRef">B.19. </a><a href="#name-since-draft-ietf-quic-http-0" class="section-name selfRef">Since draft-ietf-quic-http-09</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.19-1.1">Selected QCRAM for header compression (#228, #1117)<a href="#section-b.19-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.19-1.2">The server_name TLS extension is now mandatory (#296, #495)<a href="#section-b.19-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.19-1.3">Specified handling of unsupported versions in Alt-Svc (#1093, #1097)<a href="#section-b.19-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-08">
+<section id="section-b.20">
+        <h2 id="name-since-draft-ietf-quic-http-08">
+<a href="#section-b.20" class="section-number selfRef">B.20. </a><a href="#name-since-draft-ietf-quic-http-08" class="section-name selfRef">Since draft-ietf-quic-http-08</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.20-1.1">Clarified connection coalescing rules (#940, #1024)<a href="#section-b.20-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-07">
+<section id="section-b.21">
+        <h2 id="name-since-draft-ietf-quic-http-07">
+<a href="#section-b.21" class="section-number selfRef">B.21. </a><a href="#name-since-draft-ietf-quic-http-07" class="section-name selfRef">Since draft-ietf-quic-http-07</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.21-1.1">Changes for integer encodings in QUIC (#595,#905)<a href="#section-b.21-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.21-1.2">Use unidirectional streams as appropriate (#515, #240, #281, #886)<a href="#section-b.21-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.21-1.3">Improvement to the description of GOAWAY (#604, #898)<a href="#section-b.21-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.21-1.4">Improve description of server push usage (#947, #950, #957)<a href="#section-b.21-1.4" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-06">
+<section id="section-b.22">
+        <h2 id="name-since-draft-ietf-quic-http-06">
+<a href="#section-b.22" class="section-number selfRef">B.22. </a><a href="#name-since-draft-ietf-quic-http-06" class="section-name selfRef">Since draft-ietf-quic-http-06</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.22-1.1">Track changes in QUIC error code usage (#485)<a href="#section-b.22-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-05">
+<section id="section-b.23">
+        <h2 id="name-since-draft-ietf-quic-http-05">
+<a href="#section-b.23" class="section-number selfRef">B.23. </a><a href="#name-since-draft-ietf-quic-http-05" class="section-name selfRef">Since draft-ietf-quic-http-05</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.23-1.1">Made push ID sequential, add MAX_PUSH_ID, remove SETTINGS_ENABLE_PUSH (#709)<a href="#section-b.23-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.2">Guidance about keep-alive and QUIC PINGs (#729)<a href="#section-b.23-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.3">Expanded text on GOAWAY and cancellation (#757)<a href="#section-b.23-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-04">
+<section id="section-b.24">
+        <h2 id="name-since-draft-ietf-quic-http-04">
+<a href="#section-b.24" class="section-number selfRef">B.24. </a><a href="#name-since-draft-ietf-quic-http-04" class="section-name selfRef">Since draft-ietf-quic-http-04</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.24-1.1">Cite RFC 5234 (#404)<a href="#section-b.24-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.2">Return to a single stream per request (#245,#557)<a href="#section-b.24-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.3">Use separate frame type and settings registries from HTTP/2 (#81)<a href="#section-b.24-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.4">SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)<a href="#section-b.24-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.5">Restored GOAWAY (#696)<a href="#section-b.24-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.6">Identify server push using Push ID rather than a stream ID (#702,#281)<a href="#section-b.24-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.7">DATA frames cannot be empty (#700)<a href="#section-b.24-1.7" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-03">
+<section id="section-b.25">
+        <h2 id="name-since-draft-ietf-quic-http-03">
+<a href="#section-b.25" class="section-number selfRef">B.25. </a><a href="#name-since-draft-ietf-quic-http-03" class="section-name selfRef">Since draft-ietf-quic-http-03</a>
+        </h2>
+<p id="section-b.25-1">None.<a href="#section-b.25-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-02">
+<section id="section-b.26">
+        <h2 id="name-since-draft-ietf-quic-http-02">
+<a href="#section-b.26" class="section-number selfRef">B.26. </a><a href="#name-since-draft-ietf-quic-http-02" class="section-name selfRef">Since draft-ietf-quic-http-02</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.26-1.1">Track changes in transport draft<a href="#section-b.26-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-01">
+<section id="section-b.27">
+        <h2 id="name-since-draft-ietf-quic-http-01">
+<a href="#section-b.27" class="section-number selfRef">B.27. </a><a href="#name-since-draft-ietf-quic-http-01" class="section-name selfRef">Since draft-ietf-quic-http-01</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.27-1.1">
+            <p id="section-b.27-1.1.1">SETTINGS changes (#181):<a href="#section-b.27-1.1.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.27-1.1.2.1">SETTINGS can be sent only once at the start of a connection;
+no changes thereafter<a href="#section-b.27-1.1.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.27-1.1.2.2">SETTINGS_ACK removed<a href="#section-b.27-1.1.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.27-1.1.2.3">Settings can only occur in the SETTINGS frame a single time<a href="#section-b.27-1.1.2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.27-1.1.2.4">Boolean format updated<a href="#section-b.27-1.1.2.4" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.27-1.2">Alt-Svc parameter changed from "v" to "quic"; format updated (#229)<a href="#section-b.27-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.27-1.3">Closing the connection control stream or any message control stream is a
+fatal error (#176)<a href="#section-b.27-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.27-1.4">HPACK Sequence counter can wrap (#173)<a href="#section-b.27-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.27-1.5">0-RTT guidance added<a href="#section-b.27-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.27-1.6">Guide to differences from HTTP/2 and porting HTTP/2 extensions added
+(#127,#242)<a href="#section-b.27-1.6" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-http-00">
+<section id="section-b.28">
+        <h2 id="name-since-draft-ietf-quic-http-00">
+<a href="#section-b.28" class="section-number selfRef">B.28. </a><a href="#name-since-draft-ietf-quic-http-00" class="section-name selfRef">Since draft-ietf-quic-http-00</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.28-1.1">Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)<a href="#section-b.28-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.28-1.2">Changed from using HTTP/2 framing within Stream 3 to new framing format and
+two-stream-per-request model (#71,#72,#73)<a href="#section-b.28-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.28-1.3">Adopted SETTINGS format from draft-bishop-httpbis-extended-settings-01<a href="#section-b.28-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.28-1.4">Reworked SETTINGS_ACK to account for indeterminate inter-stream order (#75)<a href="#section-b.28-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.28-1.5">Described CONNECT pseudo-method (#95)<a href="#section-b.28-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.28-1.6">Updated ALPN token and Alt-Svc guidance (#13,#87)<a href="#section-b.28-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.28-1.7">Application-layer-defined error codes (#19,#74)<a href="#section-b.28-1.7" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-shade-quic-http2-mapping-00">
+<section id="section-b.29">
+        <h2 id="name-since-draft-shade-quic-http">
+<a href="#section-b.29" class="section-number selfRef">B.29. </a><a href="#name-since-draft-shade-quic-http" class="section-name selfRef">Since draft-shade-quic-http2-mapping-00</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.29-1.1">Adopted as base for draft-ietf-quic-http<a href="#section-b.29-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.29-1.2">Updated authors/editors list<a href="#section-b.29-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+</section>
+</div>
+<div id="acknowledgements">
+<section id="section-appendix.c">
+      <h2 id="name-acknowledgements">
+<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
+      </h2>
+<p id="section-appendix.c-1">The original authors of this specification were Robbie Shade and Mike Warres.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
+<p id="section-appendix.c-2">The IETF QUIC Working Group received an enormous amount of support from many
+people. Among others, the following people provided substantial contributions to
+this document:<a href="#section-appendix.c-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-appendix.c-3.1">Bence Beky<a href="#section-appendix.c-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.2">Daan De Meyer<a href="#section-appendix.c-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.3">Martin Duke<a href="#section-appendix.c-3.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.4">Roy Fielding<a href="#section-appendix.c-3.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.5">Alan Frindell<a href="#section-appendix.c-3.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.6">Alessandro Ghedini<a href="#section-appendix.c-3.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.7">Nick Harper<a href="#section-appendix.c-3.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.8">Ryan Hamilton<a href="#section-appendix.c-3.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.9">Christian Huitema<a href="#section-appendix.c-3.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.10">Subodh Iyengar<a href="#section-appendix.c-3.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.11">Robin Marx<a href="#section-appendix.c-3.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.12">Patrick McManus<a href="#section-appendix.c-3.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.13">Luca Nicco<a href="#section-appendix.c-3.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.14">
+          <p id="section-appendix.c-3.14.1">        <span class="contact-name"><span class="non-ascii">奥 一穂</span> (<span class="ascii">Kazuho Oku</span>)</span><a href="#section-appendix.c-3.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="normal" id="section-appendix.c-3.15">Lucas Pardue<a href="#section-appendix.c-3.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.16">Roberto Peon<a href="#section-appendix.c-3.16" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.17">Julian Reschke<a href="#section-appendix.c-3.17" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.18">Eric Rescorla<a href="#section-appendix.c-3.18" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.19">Martin Seemann<a href="#section-appendix.c-3.19" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.20">Ben Schwartz<a href="#section-appendix.c-3.20" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.21">Ian Swett<a href="#section-appendix.c-3.21" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.22">Willy Taureau<a href="#section-appendix.c-3.22" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.23">Martin Thomson<a href="#section-appendix.c-3.23" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.24">Dmitri Tikhonov<a href="#section-appendix.c-3.24" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-3.25">Tatsuhiro Tsujikawa<a href="#section-appendix.c-3.25" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-appendix.c-4">A portion of Mike's contribution was supported by Microsoft during his
+employment there.<a href="#section-appendix.c-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="authors-addresses">
+<section id="section-appendix.d">
+      <h2 id="name-authors-address">
+<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
+      </h2>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Mike Bishop (<span class="role">editor</span>)</span></div>
+<div dir="auto" class="left"><span class="org">Akamai</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:mbishop@evequefou.be" class="email">mbishop@evequefou.be</a>
+</div>
+</address>
+</section>
+</div>
+<script>const toc = document.getElementById("toc");
+toc.querySelector("h2").addEventListener("click", e => {
+  toc.classList.toggle("active");
+});
+toc.querySelector("nav").addEventListener("click", e => {
+  toc.classList.remove("active");
+});
+</script>
+</body>
+</html>
diff --git a/jri/mustnot/draft-ietf-quic-http.txt b/jri/mustnot/draft-ietf-quic-http.txt
new file mode 100644
index 0000000000..4ff3a2a706
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-http.txt
@@ -0,0 +1,3920 @@
+
+
+
+
+QUIC                                                      M. Bishop, Ed.
+Internet-Draft                                                    Akamai
+Intended status: Standards Track                             3 June 2020
+Expires: 5 December 2020
+
+
+             Hypertext Transfer Protocol Version 3 (HTTP/3)
+                      draft-ietf-quic-http-latest
+
+Abstract
+
+   The QUIC transport protocol has several features that are desirable
+   in a transport for HTTP, such as stream multiplexing, per-stream flow
+   control, and low-latency connection establishment.  This document
+   describes a mapping of HTTP semantics over QUIC.  This document also
+   identifies HTTP/2 features that are subsumed by QUIC, and describes
+   how HTTP/2 extensions can be ported to HTTP/3.
+
+Note to Readers
+
+   Discussion of this draft takes place on the QUIC working group
+   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
+   archived at https://mailarchive.ietf.org/arch/
+   search/?email_list=quic.
+
+   Working Group information can be found at https://github.com/quicwg;
+   source code and issues list for this draft can be found at
+   https://github.com/quicwg/base-drafts/labels/-http.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at https://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on 5 December 2020.
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020                [Page 1]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (https://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.  Code Components
+   extracted from this document must include Simplified BSD License text
+   as described in Section 4.e of the Trust Legal Provisions and are
+   provided without warranty as described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.1.  Prior versions of HTTP  . . . . . . . . . . . . . . . . .   4
+     1.2.  Delegation to QUIC  . . . . . . . . . . . . . . . . . . .   5
+   2.  HTTP/3 Protocol Overview  . . . . . . . . . . . . . . . . . .   5
+     2.1.  Document Organization . . . . . . . . . . . . . . . . . .   6
+     2.2.  Conventions and Terminology . . . . . . . . . . . . . . .   7
+   3.  Connection Setup and Management . . . . . . . . . . . . . . .   8
+     3.1.  Draft Version Identification  . . . . . . . . . . . . . .   8
+     3.2.  Discovering an HTTP/3 Endpoint  . . . . . . . . . . . . .   9
+       3.2.1.  HTTP Alternative Services . . . . . . . . . . . . . .   9
+       3.2.2.  Other Schemes . . . . . . . . . . . . . . . . . . . .  10
+     3.3.  Connection Establishment  . . . . . . . . . . . . . . . .  10
+     3.4.  Connection Reuse  . . . . . . . . . . . . . . . . . . . .  11
+   4.  HTTP Request Lifecycle  . . . . . . . . . . . . . . . . . . .  12
+     4.1.  HTTP Message Exchanges  . . . . . . . . . . . . . . . . .  12
+       4.1.1.  Field Formatting and Compression  . . . . . . . . . .  13
+       4.1.2.  Request Cancellation and Rejection  . . . . . . . . .  17
+       4.1.3.  Malformed Requests and Responses  . . . . . . . . . .  18
+     4.2.  The CONNECT Method  . . . . . . . . . . . . . . . . . . .  18
+     4.3.  HTTP Upgrade  . . . . . . . . . . . . . . . . . . . . . .  20
+     4.4.  Server Push . . . . . . . . . . . . . . . . . . . . . . .  20
+   5.  Connection Closure  . . . . . . . . . . . . . . . . . . . . .  22
+     5.1.  Idle Connections  . . . . . . . . . . . . . . . . . . . .  22
+     5.2.  Connection Shutdown . . . . . . . . . . . . . . . . . . .  23
+     5.3.  Immediate Application Closure . . . . . . . . . . . . . .  25
+     5.4.  Transport Closure . . . . . . . . . . . . . . . . . . . .  25
+   6.  Stream Mapping and Usage  . . . . . . . . . . . . . . . . . .  25
+     6.1.  Bidirectional Streams . . . . . . . . . . . . . . . . . .  26
+     6.2.  Unidirectional Streams  . . . . . . . . . . . . . . . . .  26
+       6.2.1.  Control Streams . . . . . . . . . . . . . . . . . . .  27
+       6.2.2.  Push Streams  . . . . . . . . . . . . . . . . . . . .  28
+       6.2.3.  Reserved Stream Types . . . . . . . . . . . . . . . .  28
+
+
+
+Bishop                   Expires 5 December 2020                [Page 2]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   7.  HTTP Framing Layer  . . . . . . . . . . . . . . . . . . . . .  29
+     7.1.  Frame Layout  . . . . . . . . . . . . . . . . . . . . . .  30
+     7.2.  Frame Definitions . . . . . . . . . . . . . . . . . . . .  30
+       7.2.1.  DATA  . . . . . . . . . . . . . . . . . . . . . . . .  30
+       7.2.2.  HEADERS . . . . . . . . . . . . . . . . . . . . . . .  31
+       7.2.3.  CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . .  31
+       7.2.4.  SETTINGS  . . . . . . . . . . . . . . . . . . . . . .  32
+       7.2.5.  PUSH_PROMISE  . . . . . . . . . . . . . . . . . . . .  35
+       7.2.6.  GOAWAY  . . . . . . . . . . . . . . . . . . . . . . .  37
+       7.2.7.  MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . .  37
+       7.2.8.  Reserved Frame Types  . . . . . . . . . . . . . . . .  38
+   8.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  38
+     8.1.  HTTP/3 Error Codes  . . . . . . . . . . . . . . . . . . .  39
+   9.  Extensions to HTTP/3  . . . . . . . . . . . . . . . . . . . .  40
+   10. Security Considerations . . . . . . . . . . . . . . . . . . .  41
+     10.1.  Server Authority . . . . . . . . . . . . . . . . . . . .  41
+     10.2.  Cross-Protocol Attacks . . . . . . . . . . . . . . . . .  41
+     10.3.  Intermediary Encapsulation Attacks . . . . . . . . . . .  42
+     10.4.  Cacheability of Pushed Responses . . . . . . . . . . . .  42
+     10.5.  Denial-of-Service Considerations . . . . . . . . . . . .  42
+       10.5.1.  Limits on Field Section Size . . . . . . . . . . . .  43
+       10.5.2.  CONNECT Issues . . . . . . . . . . . . . . . . . . .  44
+     10.6.  Use of Compression . . . . . . . . . . . . . . . . . . .  44
+     10.7.  Padding and Traffic Analysis . . . . . . . . . . . . . .  45
+     10.8.  Frame Parsing  . . . . . . . . . . . . . . . . . . . . .  45
+     10.9.  Early Data . . . . . . . . . . . . . . . . . . . . . . .  45
+     10.10. Migration  . . . . . . . . . . . . . . . . . . . . . . .  46
+     10.11. Privacy Considerations . . . . . . . . . . . . . . . . .  46
+   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  46
+     11.1.  Registration of HTTP/3 Identification String . . . . . .  46
+     11.2.  New Registries . . . . . . . . . . . . . . . . . . . . .  47
+       11.2.1.  Frame Types  . . . . . . . . . . . . . . . . . . . .  47
+       11.2.2.  Settings Parameters  . . . . . . . . . . . . . . . .  48
+       11.2.3.  Error Codes  . . . . . . . . . . . . . . . . . . . .  49
+       11.2.4.  Stream Types . . . . . . . . . . . . . . . . . . . .  52
+   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  52
+     12.1.  Normative References . . . . . . . . . . . . . . . . . .  52
+     12.2.  Informative References . . . . . . . . . . . . . . . . .  54
+   Appendix A.  Considerations for Transitioning from HTTP/2 . . . .  55
+     A.1.  Streams . . . . . . . . . . . . . . . . . . . . . . . . .  56
+     A.2.  HTTP Frame Types  . . . . . . . . . . . . . . . . . . . .  56
+       A.2.1.  Prioritization Differences  . . . . . . . . . . . . .  57
+       A.2.2.  Field Compression Differences . . . . . . . . . . . .  57
+       A.2.3.  Guidance for New Frame Type Definitions . . . . . . .  57
+       A.2.4.  Mapping Between HTTP/2 and HTTP/3 Frame Types . . . .  58
+     A.3.  HTTP/2 SETTINGS Parameters  . . . . . . . . . . . . . . .  59
+     A.4.  HTTP/2 Error Codes  . . . . . . . . . . . . . . . . . . .  60
+       A.4.1.  Mapping Between HTTP/2 and HTTP/3 Errors  . . . . . .  61
+
+
+
+Bishop                   Expires 5 December 2020                [Page 3]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  61
+     B.1.  Since draft-ietf-quic-http-27 . . . . . . . . . . . . . .  62
+     B.2.  Since draft-ietf-quic-http-26 . . . . . . . . . . . . . .  62
+     B.3.  Since draft-ietf-quic-http-25 . . . . . . . . . . . . . .  62
+     B.4.  Since draft-ietf-quic-http-24 . . . . . . . . . . . . . .  62
+     B.5.  Since draft-ietf-quic-http-23 . . . . . . . . . . . . . .  62
+     B.6.  Since draft-ietf-quic-http-22 . . . . . . . . . . . . . .  62
+     B.7.  Since draft-ietf-quic-http-21 . . . . . . . . . . . . . .  63
+     B.8.  Since draft-ietf-quic-http-20 . . . . . . . . . . . . . .  63
+     B.9.  Since draft-ietf-quic-http-19 . . . . . . . . . . . . . .  64
+     B.10. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . .  64
+     B.11. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . .  65
+     B.12. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . .  65
+     B.13. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . .  66
+     B.14. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . .  66
+     B.15. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . .  66
+     B.16. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . .  66
+     B.17. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . .  67
+     B.18. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . .  67
+     B.19. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . .  67
+     B.20. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . .  67
+     B.21. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . .  67
+     B.22. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . .  67
+     B.23. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . .  67
+     B.24. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . .  67
+     B.25. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . .  68
+     B.26. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . .  68
+     B.27. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . .  68
+     B.28. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . .  69
+     B.29. Since draft-shade-quic-http2-mapping-00 . . . . . . . . .  69
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  69
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  70
+
+1.  Introduction
+
+   HTTP semantics [SEMANTICS] are used for a broad range of services on
+   the Internet.  These semantics have most commonly been used with two
+   different TCP mappings, HTTP/1.1 and HTTP/2.  HTTP/3 supports the
+   same semantics over a new transport protocol, QUIC.
+
+1.1.  Prior versions of HTTP
+
+   HTTP/1.1 [HTTP11] is a TCP mapping which uses whitespace-delimited
+   text fields to convey HTTP messages.  While these exchanges are
+   human-readable, using whitespace for message formatting leads to
+   parsing complexity and motivates tolerance of variant behavior.
+   Because each connection can transfer only a single HTTP request or
+   response at a time in each direction, multiple parallel TCP
+
+
+
+Bishop                   Expires 5 December 2020                [Page 4]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   connections are often used, reducing the ability of the congestion
+   controller to effectively manage traffic between endpoints.
+
+   HTTP/2 [HTTP2] introduced a binary framing and multiplexing layer to
+   improve latency without modifying the transport layer.  However,
+   because the parallel nature of HTTP/2's multiplexing is not visible
+   to TCP's loss recovery mechanisms, a lost or reordered packet causes
+   all active transactions to experience a stall regardless of whether
+   that transaction was directly impacted by the lost packet.
+
+1.2.  Delegation to QUIC
+
+   The QUIC transport protocol incorporates stream multiplexing and per-
+   stream flow control, similar to that provided by the HTTP/2 framing
+   layer.  By providing reliability at the stream level and congestion
+   control across the entire connection, it has the capability to
+   improve the performance of HTTP compared to a TCP mapping.  QUIC also
+   incorporates TLS 1.3 [TLS13] at the transport layer, offering
+   comparable security to running TLS over TCP, with the improved
+   connection setup latency of TCP Fast Open [TFO].
+
+   This document defines a mapping of HTTP semantics over the QUIC
+   transport protocol, drawing heavily on the design of HTTP/2.  While
+   delegating stream lifetime and flow control issues to QUIC, a similar
+   binary framing is used on each stream.  Some HTTP/2 features are
+   subsumed by QUIC, while other features are implemented atop QUIC.
+
+   QUIC is described in [QUIC-TRANSPORT].  For a full description of
+   HTTP/2, see [HTTP2].
+
+2.  HTTP/3 Protocol Overview
+
+   HTTP/3 provides a transport for HTTP semantics using the QUIC
+   transport protocol and an internal framing layer similar to HTTP/2.
+
+   Once a client knows that an HTTP/3 server exists at a certain
+   endpoint, it opens a QUIC connection.  QUIC provides protocol
+   negotiation, stream-based multiplexing, and flow control.  Discovery
+   of an HTTP/3 endpoint is described in Section 3.2.
+
+   Within each stream, the basic unit of HTTP/3 communication is a frame
+   (Section 7.2).  Each frame type serves a different purpose.  For
+   example, HEADERS and DATA frames form the basis of HTTP requests and
+   responses (Section 4.1).
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020                [Page 5]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Multiplexing of requests is performed using the QUIC stream
+   abstraction, described in Section 2 of [QUIC-TRANSPORT].  Each
+   request-response pair consumes a single QUIC stream.  Streams are
+   independent of each other, so one stream that is blocked or suffers
+   packet loss does not prevent progress on other streams.
+
+   Server push is an interaction mode introduced in HTTP/2 [HTTP2] which
+   permits a server to push a request-response exchange to a client in
+   anticipation of the client making the indicated request.  This trades
+   off network usage against a potential latency gain.  Several HTTP/3
+   frames are used to manage server push, such as PUSH_PROMISE,
+   MAX_PUSH_ID, and CANCEL_PUSH.
+
+   As in HTTP/2, request and response fields are compressed for
+   transmission.  Because HPACK [HPACK] relies on in-order transmission
+   of compressed field sections (a guarantee not provided by QUIC),
+   HTTP/3 replaces HPACK with QPACK [QPACK].  QPACK uses separate
+   unidirectional streams to modify and track field table state, while
+   encoded field sections refer to the state of the table without
+   modifying it.
+
+2.1.  Document Organization
+
+   The following sections provide a detailed overview of the connection
+   lifecycle and key concepts:
+
+   *  Connection Setup and Management (Section 3) covers how an HTTP/3
+      endpoint is discovered and a connection is established.
+
+   *  HTTP Request Lifecycle (Section 4) describes how HTTP semantics
+      are expressed using frames.
+
+   *  Connection Closure (Section 5) describes how connections are
+      terminated, either gracefully or abruptly.
+
+   The details of the wire protocol and interactions with the transport
+   are described in subsequent sections:
+
+   *  Stream Mapping and Usage (Section 6) describes the way QUIC
+      streams are used.
+
+   *  HTTP Framing Layer (Section 7) describes the frames used on most
+      streams.
+
+   *  Error Handling (Section 8) describes how error conditions are
+      handled and expressed, either on a particular stream or for the
+      connection as a whole.
+
+
+
+
+Bishop                   Expires 5 December 2020                [Page 6]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Additional resources are provided in the final sections:
+
+   *  Extensions to HTTP/3 (Section 9) describes how new capabilities
+      can be added in future documents.
+
+   *  A more detailed comparison between HTTP/2 and HTTP/3 can be found
+      in Appendix A.
+
+2.2.  Conventions and Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Field definitions are given in Augmented Backus-Naur Form (ABNF), as
+   defined in [RFC5234].
+
+   This document uses the variable-length integer encoding from
+   [QUIC-TRANSPORT].
+
+   The following terms are used:
+
+   abort:  An abrupt termination of a connection or stream, possibly due
+      to an error condition.
+
+   client:  The endpoint that initiates an HTTP/3 connection.  Clients
+      send HTTP requests and receive HTTP responses.
+
+   connection:  A transport-layer connection between two endpoints,
+      using QUIC as the transport protocol.
+
+   connection error:  An error that affects the entire HTTP/3
+      connection.
+
+   endpoint:  Either the client or server of the connection.
+
+   frame:  The smallest unit of communication on a stream in HTTP/3,
+      consisting of a header and a variable-length sequence of bytes
+      structured according to the frame type.  Protocol elements called
+      "frames" exist in both this document and [QUIC-TRANSPORT].  Where
+      frames from [QUIC-TRANSPORT] are referenced, the frame name will
+      be prefaced with "QUIC."  For example, "QUIC CONNECTION_CLOSE
+      frames."  References without this preface refer to frames defined
+      in Section 7.2.
+
+   peer:  An endpoint.  When discussing a particular endpoint, "peer"
+
+
+
+Bishop                   Expires 5 December 2020                [Page 7]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+      refers to the endpoint that is remote to the primary subject of
+      discussion.
+
+   receiver:  An endpoint that is receiving frames.
+
+   sender:  An endpoint that is transmitting frames.
+
+   server:  The endpoint that accepts an HTTP/3 connection.  Servers
+      receive HTTP requests and send HTTP responses.
+
+   stream:  A bidirectional or unidirectional bytestream provided by the
+      QUIC transport.
+
+   stream error:  An error on the individual HTTP/3 stream.
+
+   The term "payload body" is defined in Section 6.3.3 of [SEMANTICS].
+
+   Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"
+   are defined in Section 2.2 of [SEMANTICS].  Intermediaries act as
+   both client and server at different times.
+
+3.  Connection Setup and Management
+
+3.1.  Draft Version Identification
+
+      *RFC Editor's Note:* Please remove this section prior to
+      publication of a final version of this document.
+
+   HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc.
+   Only implementations of the final, published RFC can identify
+   themselves as "h3".  Until such an RFC exists, implementations MUST
+   NOT identify themselves using this string.
+
+   Implementations of draft versions of the protocol MUST add the string
+   "-" and the corresponding draft number to the identifier.  For
+   example, draft-ietf-quic-http-01 is identified using the string
+   "h3-01".
+
+   Draft versions MUST use the corresponding draft transport version as
+   their transport.  For example, the application protocol defined in
+   draft-ietf-quic-http-25 uses the transport defined in draft-ietf-
+   quic-transport-25.
+
+   Non-compatible experiments that are based on these draft versions
+   MUST append the string "-" and an experiment name to the identifier.
+   For example, an experimental implementation based on draft-ietf-quic-
+   http-09 which reserves an extra stream for unsolicited transmission
+   of 1980s pop music might identify itself as "h3-09-rickroll".  Note
+
+
+
+Bishop                   Expires 5 December 2020                [Page 8]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   that any label MUST conform to the "token" syntax defined in
+   Section 4.4.1.1 of [SEMANTICS].  Experimenters are encouraged to
+   coordinate their experiments on the quic@ietf.org
+   (mailto:quic@ietf.org) mailing list.
+
+3.2.  Discovering an HTTP/3 Endpoint
+
+   HTTP relies on the notion of an authoritative response: a response
+   that has been determined to be the most appropriate response for that
+   request given the state of the target resource at the time of
+   response message origination by (or at the direction of) the origin
+   server identified within the target URI.  Locating an authoritative
+   server for an HTTP URL is discussed in Section 5.4 of [SEMANTICS].
+
+   The "https" scheme associates authority with possession of a
+   certificate that the client considers to be trustworthy for the host
+   identified by the authority component of the URL.  If a server
+   presents a certificate and proof that it controls the corresponding
+   private key, then a client will accept a secured connection to that
+   server as being authoritative for all origins with the "https" scheme
+   and a host identified in the certificate.
+
+   A client MAY attempt access to a resource with an "https" URI by
+   resolving the host identifier to an IP address, establishing a QUIC
+   connection to that address on the indicated port, and sending an
+   HTTP/3 request message targeting the URI to the server over that
+   secured connection.
+
+   Connectivity problems (e.g., blocking UDP) can result in QUIC
+   connection establishment failure; clients SHOULD attempt to use TCP-
+   based versions of HTTP in this case.
+
+   Servers MAY serve HTTP/3 on any UDP port; an alternative service
+   advertisement always includes an explicit port, and URLs contain
+   either an explicit port or a default port associated with the scheme.
+
+3.2.1.  HTTP Alternative Services
+
+   An HTTP origin advertises the availability of an equivalent HTTP/3
+   endpoint via the Alt-Svc HTTP response header field or the HTTP/2
+   ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 3.3.
+
+   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:
+
+   Alt-Svc: h3=":50781"
+
+
+
+
+Bishop                   Expires 5 December 2020                [Page 9]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   On receipt of an Alt-Svc record indicating HTTP/3 support, a client
+   MAY attempt to establish a QUIC connection to the indicated host and
+   port and, if successful, send HTTP requests using the mapping
+   described in this document.
+
+3.2.2.  Other Schemes
+
+   Although HTTP is independent of the transport protocol, the "http"
+   scheme associates authority with the ability to receive TCP
+   connections on the indicated port of whatever host is identified
+   within the authority component.  Because HTTP/3 does not use TCP,
+   HTTP/3 cannot be used for direct access to the authoritative server
+   for a resource identified by an "http" URI.  However, protocol
+   extensions such as [ALTSVC] permit the authoritative server to
+   identify other services which are also authoritative and which might
+   be reachable over HTTP/3.
+
+   Prior to making requests for an origin whose scheme is not "https",
+   the client MUST ensure the server is willing to serve that scheme.
+   If the client intends to make requests for an origin whose scheme is
+   "http", this means that it MUST obtain a valid "http-opportunistic"
+   response for the origin as described in [RFC8164] prior to making any
+   such requests.  Other schemes might define other mechanisms.
+
+3.3.  Connection Establishment
+
+   HTTP/3 relies on QUIC version 1 as the underlying transport.  The use
+   of other QUIC transport versions with HTTP/3 MAY be defined by future
+   specifications.
+
+   QUIC version 1 uses TLS version 1.3 or greater as its handshake
+   protocol.  HTTP/3 clients MUST support a mechanism to indicate the
+   target host to the server during the TLS handshake.  If the server is
+   identified by a DNS name, clients MUST send the Server Name
+   Indication (SNI) [RFC6066] TLS extension unless an alternative
+   mechanism to indicate the target host is used.
+
+   QUIC connections are established as described in [QUIC-TRANSPORT].
+   During connection establishment, HTTP/3 support is indicated by
+   selecting the ALPN token "h3" in the TLS handshake.  Support for
+   other application-layer protocols MAY be offered in the same
+   handshake.
+
+
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 10]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   While connection-level options pertaining to the core QUIC protocol
+   are set in the initial crypto handshake, HTTP/3-specific settings are
+   conveyed in the SETTINGS frame.  After the QUIC connection is
+   established, a SETTINGS frame (Section 7.2.4) MUST be sent by each
+   endpoint as the initial frame of their respective HTTP control
+   stream; see Section 6.2.1.
+
+3.4.  Connection Reuse
+
+   HTTP/3 connections are persistent across multiple requests.  For best
+   performance, it is expected that clients will not close connections
+   until it is determined that no further communication with a server is
+   necessary (for example, when a user navigates away from a particular
+   web page) or until the server closes the connection.
+
+   Once a connection exists to a server endpoint, this connection MAY be
+   reused for requests with multiple different URI authority components.
+   In general, a server is considered authoritative for all URIs with
+   the "https" scheme for which the hostname in the URI is present in
+   the authenticated certificate provided by the server, either as the
+   CN field of the certificate subject or as a dNSName in the
+   subjectAltName field of the certificate; see [RFC6125].  For a host
+   that is an IP address, the client MUST verify that the address
+   appears as an iPAddress in the subjectAltName field of the
+   certificate.  If the hostname or address is not present in the
+   certificate, the client MUST NOT consider the server authoritative
+   for origins containing that hostname or address.  See Section 5.4 of
+   [SEMANTICS] for more detail on authoritative access.
+
+   Clients SHOULD NOT open more than one HTTP/3 connection to a given
+   host and port pair, where the host is derived from a URI, a selected
+   alternative service [ALTSVC], or a configured proxy.  A client MAY
+   open multiple connections to the same IP address and UDP port using
+   different transport or TLS configurations but SHOULD avoid creating
+   multiple connections with the same configuration.
+
+   Servers are encouraged to maintain open connections for as long as
+   possible but are permitted to terminate idle connections if
+   necessary.  When either endpoint chooses to close the HTTP/3 session,
+   the terminating endpoint SHOULD first send a GOAWAY frame
+   (Section 5.2) so that both endpoints can reliably determine whether
+   previously sent frames have been processed and gracefully complete or
+   terminate any necessary remaining tasks.
+
+   A server that does not wish clients to reuse connections for a
+   particular origin can indicate that it is not authoritative for a
+   request by sending a 421 (Misdirected Request) status code in
+   response to the request; see Section 9.1.2 of [HTTP2].
+
+
+
+Bishop                   Expires 5 December 2020               [Page 11]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+4.  HTTP Request Lifecycle
+
+4.1.  HTTP Message Exchanges
+
+   A client sends an HTTP request on a client-initiated bidirectional
+   QUIC stream.  A client MUST send only a single request on a given
+   stream.  A server sends zero or more interim HTTP responses on the
+   same stream as the request, followed by a single final HTTP response,
+   as detailed below.
+
+   Pushed responses are sent on a server-initiated unidirectional QUIC
+   stream; see Section 6.2.2.  A server sends zero or more interim HTTP
+   responses, followed by a single final HTTP response, in the same
+   manner as a standard response.  Push is described in more detail in
+   Section 4.4.
+
+   On a given stream, receipt of multiple requests or receipt of an
+   additional HTTP response following a final HTTP response MUST be
+   treated as malformed (Section 4.1.3).
+
+   An HTTP message (request or response) consists of:
+
+   1.  the header field section (see Section 4 of [SEMANTICS]), sent as
+       a single HEADERS frame (see Section 7.2.2),
+
+   2.  optionally, the payload body, if present (see Section 6.3.3 of
+       [SEMANTICS]), sent as a series of DATA frames (see
+       Section 7.2.1),
+
+   3.  optionally, the trailer field section, if present (see
+       Section 4.6 of [SEMANTICS]), sent as a single HEADERS frame.
+
+   Receipt of an invalid sequence of frames MUST be treated as a
+   connection error of type H3_FRAME_UNEXPECTED (Section 8).  In
+   particular, a DATA frame before any HEADERS frame, or a HEADERS or
+   DATA frame after the trailing HEADERS frame is considered invalid.
+
+   A server MAY send one or more PUSH_PROMISE frames (see Section 7.2.5)
+   before, after, or interleaved with the frames of a response message.
+   These PUSH_PROMISE frames are not part of the response; see
+   Section 4.4 for more details.  These frames are not permitted in
+   pushed responses; a pushed response which includes PUSH_PROMISE
+   frames MUST be treated as a connection error of type
+   H3_FRAME_UNEXPECTED.
+
+   Frames of unknown types (Section 9), including reserved frames
+   (Section 7.2.8) MAY be sent on a request or push stream before,
+   after, or interleaved with other frames described in this section.
+
+
+
+Bishop                   Expires 5 December 2020               [Page 12]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   The HEADERS and PUSH_PROMISE frames might reference updates to the
+   QPACK dynamic table.  While these updates are not directly part of
+   the message exchange, they must be received and processed before the
+   message can be consumed.  See Section 4.1.1 for more details.
+
+   The "chunked" transfer encoding defined in Section 7.1 of [HTTP11]
+   MUST NOT be used.
+
+   A response MAY consist of multiple messages when and only when one or
+   more informational responses (1xx; see Section 9.2 of [SEMANTICS])
+   precede a final response to the same request.  Interim responses do
+   not contain a payload body or trailers.
+
+   An HTTP request/response exchange fully consumes a client-initiated
+   bidirectional QUIC stream.  After sending a request, a client MUST
+   close the stream for sending.  Unless using the CONNECT method (see
+   Section 4.2), clients MUST NOT make stream closure dependent on
+   receiving a response to their request.  After sending a final
+   response, the server MUST close the stream for sending.  At this
+   point, the QUIC stream is fully closed.
+
+   When a stream is closed, this indicates the end of an HTTP message.
+   Because some messages are large or unbounded, endpoints SHOULD begin
+   processing partial HTTP messages once enough of the message has been
+   received to make progress.  If a client stream terminates without
+   enough of the HTTP message to provide a complete response, the server
+   SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE.
+
+   A server can send a complete response prior to the client sending an
+   entire request if the response does not depend on any portion of the
+   request that has not been sent and received.  When the server does
+   not need to receive the remainder of the request, it MAY abort
+   reading the request stream, send a complete response, and cleanly
+   close the sending part of the stream.  The error code H3_NO_ERROR
+   SHOULD be used when requesting that the client stop sending on the
+   request stream.  Clients MUST NOT discard complete responses as a
+   result of having their request terminated abruptly, though clients
+   can always discard responses at their discretion for other reasons.
+   If the server sends a partial or complete response but does not abort
+   reading, clients SHOULD continue sending the body of the request and
+   close the stream normally.
+
+4.1.1.  Field Formatting and Compression
+
+   HTTP messages carry metadata as a series of key-value pairs, called
+   HTTP fields.  For a listing of registered HTTP fields, see the
+   "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained
+   at https://www.iana.org/assignments/http-fields/.
+
+
+
+Bishop                   Expires 5 December 2020               [Page 13]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   As in previous versions of HTTP, field names are strings containing a
+   subset of ASCII characters that are compared in a case-insensitive
+   fashion.  Properties of HTTP field names and values are discussed in
+   more detail in Section 4.3 of [SEMANTICS].  As in HTTP/2, characters
+   in field names MUST be converted to lowercase prior to their
+   encoding.  A request or response containing uppercase characters in
+   field names MUST be treated as malformed (Section 4.1.3).
+
+   Like HTTP/2, HTTP/3 does not use the Connection header field to
+   indicate connection-specific fields; in this protocol, connection-
+   specific metadata is conveyed by other means.  An endpoint MUST NOT
+   generate an HTTP/3 field section containing connection-specific
+   fields; any message containing connection-specific fields MUST be
+   treated as malformed (Section 4.1.3).
+
+   The only exception to this is the TE header field, which MAY be
+   present in an HTTP/3 request header; when it is, it MUST NOT contain
+   any value other than "trailers".
+
+   This means that an intermediary transforming an HTTP/1.x message to
+   HTTP/3 will need to remove any fields nominated by the Connection
+   field, along with the Connection field itself.  Such intermediaries
+   SHOULD also remove other connection-specific fields, such as Keep-
+   Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they
+   are not nominated by the Connection field.
+
+4.1.1.1.  Pseudo-Header Fields
+
+   Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where
+   the field name begins with the ':' character (ASCII 0x3a).  These
+   pseudo-header fields convey the target URI, the method of the
+   request, and the status code for the response.
+
+   Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT
+   generate pseudo-header fields other than those defined in this
+   document, except as negotiated via an extension; see Section 9.
+
+   Pseudo-header fields are only valid in the context in which they are
+   defined.  Pseudo-header fields defined for requests MUST NOT appear
+   in responses; pseudo-header fields defined for responses MUST NOT
+   appear in requests.  Pseudo-header fields MUST NOT appear in
+   trailers.  Endpoints MUST treat a request or response that contains
+   undefined or invalid pseudo-header fields as malformed
+   (Section 4.1.3).
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 14]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   All pseudo-header fields MUST appear in the header field section
+   before regular header fields.  Any request or response that contains
+   a pseudo-header field that appears in a header field section after a
+   regular header field MUST be treated as malformed (Section 4.1.3).
+
+   The following pseudo-header fields are defined for requests:
+
+   ":method":  Contains the HTTP method (Section 7 of [SEMANTICS])
+
+   ":scheme":  Contains the scheme portion of the target URI
+      (Section 3.1 of [RFC3986])
+
+      ":scheme" is not restricted to "http" and "https" schemed URIs.  A
+      proxy or gateway can translate requests for non-HTTP schemes,
+      enabling the use of HTTP to interact with non-HTTP services.
+
+   ":authority":  Contains the authority portion of the target URI
+      (Section 3.2 of [RFC3986]).  The authority MUST NOT include the
+      deprecated "userinfo" subcomponent for "http" or "https" schemed
+      URIs.
+
+      To ensure that the HTTP/1.1 request line can be reproduced
+      accurately, this pseudo-header field MUST be omitted when
+      translating from an HTTP/1.1 request that has a request target in
+      origin or asterisk form; see Section 3.2 of [HTTP11].  Clients
+      that generate HTTP/3 requests directly SHOULD use the ":authority"
+      pseudo-header field instead of the Host field.  An intermediary
+      that converts an HTTP/3 request to HTTP/1.1 MUST create a Host
+      field if one is not present in a request by copying the value of
+      the ":authority" pseudo-header field.
+
+   ":path":  Contains the path and query parts of the target URI (the
+      "path-absolute" production and optionally a '?' character followed
+      by the "query" production; see Sections 3.3 and 3.4 of [URI].  A
+      request in asterisk form includes the value '*' for the ":path"
+      pseudo-header field.
+
+      This pseudo-header field MUST NOT be empty for "http" or "https"
+      URIs; "http" or "https" URIs that do not contain a path component
+      MUST include a value of '/'.  The exception to this rule is an
+      OPTIONS request for an "http" or "https" URI that does not include
+      a path component; these MUST include a ":path" pseudo-header field
+      with a value of '*'; see Section 3.2.4 of [HTTP11].
+
+   All HTTP/3 requests MUST include exactly one value for the ":method",
+   ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
+   request; see Section 4.2.
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 15]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   If the ":scheme" pseudo-header field identifies a scheme which has a
+   mandatory authority component (including "http" and "https"), the
+   request MUST contain either an ":authority" pseudo-header field or a
+   "Host" header field.  If these fields are present, they MUST NOT be
+   empty.  If both fields are present, they MUST contain the same value.
+   If the scheme does not have a mandatory authority component and none
+   is provided in the request target, the request MUST NOT contain the
+   ":authority" pseudo-header and "Host" header fields.
+
+   An HTTP request that omits mandatory pseudo-header fields or contains
+   invalid values for those pseudo-header fields is malformed
+   (Section 4.1.3).
+
+   HTTP/3 does not define a way to carry the version identifier that is
+   included in the HTTP/1.1 request line.
+
+   For responses, a single ":status" pseudo-header field is defined that
+   carries the HTTP status code; see Section 9 of [SEMANTICS].  This
+   pseudo-header field MUST be included in all responses; otherwise, the
+   response is malformed (Section 4.1.3).
+
+   HTTP/3 does not define a way to carry the version or reason phrase
+   that is included in an HTTP/1.1 status line.
+
+4.1.1.2.  Field Compression
+
+   HTTP/3 uses QPACK field compression as described in [QPACK], a
+   variation of HPACK which allows the flexibility to avoid compression-
+   induced head-of-line blocking.  See that document for additional
+   details.
+
+   To allow for better compression efficiency, the "Cookie" field
+   [RFC6265] MAY be split into separate field lines, each with one or
+   more cookie-pairs, before compression.  If a decompressed field
+   section contains multiple cookie field lines, these MUST be
+   concatenated into a single octet string using the two-octet delimiter
+   of 0x3B, 0x20 (the ASCII string "; ") before being passed into a
+   context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection,
+   or a generic HTTP server application.
+
+4.1.1.3.  Header Size Constraints
+
+   An HTTP/3 implementation MAY impose a limit on the maximum size of
+   the message header it will accept on an individual HTTP message.  A
+   server that receives a larger header section than it is willing to
+   handle can send an HTTP 431 (Request Header Fields Too Large) status
+   code ([RFC6585]).  A client can discard responses that it cannot
+   process.  The size of a field list is calculated based on the
+
+
+
+Bishop                   Expires 5 December 2020               [Page 16]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   uncompressed size of fields, including the length of the name and
+   value in bytes plus an overhead of 32 bytes for each field.
+
+   If an implementation wishes to advise its peer of this limit, it can
+   be conveyed as a number of bytes in the
+   SETTINGS_MAX_FIELD_SECTION_SIZE parameter.  An implementation which
+   has received this parameter SHOULD NOT send an HTTP message header
+   which exceeds the indicated size, as the peer will likely refuse to
+   process it.  However, because this limit is applied at each hop,
+   messages below this limit are not guaranteed to be accepted.
+
+4.1.2.  Request Cancellation and Rejection
+
+   Clients can cancel requests by resetting and aborting the request
+   stream with an error code of H3_REQUEST_CANCELLED (Section 8.1).
+   When the client aborts reading a response, it indicates that this
+   response is no longer of interest.  Implementations SHOULD cancel
+   requests by abruptly terminating any directions of a stream that are
+   still open.
+
+   When the server rejects a request without performing any application
+   processing, it SHOULD abort its response stream with the error code
+   H3_REQUEST_REJECTED.  In this context, "processed" means that some
+   data from the stream was passed to some higher layer of software that
+   might have taken some action as a result.  The client can treat
+   requests rejected by the server as though they had never been sent at
+   all, thereby allowing them to be retried later on a new connection.
+   Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests
+   which were partially or fully processed.  When a server abandons a
+   response after partial processing, it SHOULD abort its response
+   stream with the error code H3_REQUEST_CANCELLED.
+
+   When a client resets a request with the error code
+   H3_REQUEST_CANCELLED, a server MAY abruptly terminate the response
+   using the error code H3_REQUEST_REJECTED if no processing was
+   performed.  Clients MUST NOT use the H3_REQUEST_REJECTED error code,
+   except when a server has requested closure of the request stream with
+   this error code.
+
+   If a stream is cancelled after receiving a complete response, the
+   client MAY ignore the cancellation and use the response.  However, if
+   a stream is cancelled after receiving a partial response, the
+   response SHOULD NOT be used.  Automatically retrying such requests is
+   not possible, unless this is otherwise permitted (e.g., idempotent
+   actions like GET, PUT, or DELETE).
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 17]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+4.1.3.  Malformed Requests and Responses
+
+   A malformed request or response is one that is an otherwise valid
+   sequence of frames but is invalid due to:
+
+   *  the presence of prohibited fields or pseudo-header fields,
+
+   *  the absence of mandatory pseudo-header fields,
+
+   *  invalid values for pseudo-header fields,
+
+   *  pseudo-header fields after fields,
+
+   *  an invalid sequence of HTTP messages,
+
+   *  the inclusion of uppercase field names, or
+
+   *  the inclusion of invalid characters in field names or values
+
+   A request or response that includes a payload body can include a
+   Content-Length header field.  A request or response is also malformed
+   if the value of a content-length header field does not equal the sum
+   of the DATA frame payload lengths that form the body.  A response
+   that is defined to have no payload, as described in Section 6.3.3 of
+   [SEMANTICS] can have a non-zero content-length field, even though no
+   content is included in DATA frames.
+
+   Intermediaries that process HTTP requests or responses (i.e., any
+   intermediary not acting as a tunnel) MUST NOT forward a malformed
+   request or response.  Malformed requests or responses that are
+   detected MUST be treated as a stream error (Section 8) of type
+   H3_GENERAL_PROTOCOL_ERROR.
+
+   For malformed requests, a server MAY send an HTTP response prior to
+   closing or resetting the stream.  Clients MUST NOT accept a malformed
+   response.  Note that these requirements are intended to protect
+   against several types of common attacks against HTTP; they are
+   deliberately strict because being permissive can expose
+   implementations to these vulnerabilities.
+
+4.2.  The CONNECT Method
+
+   The CONNECT method requests that the recipient establish a tunnel to
+   the destination origin server identified by the request-target
+   (Section 3.2 of [HTTP11]).  It is primarily used with HTTP proxies to
+   establish a TLS session with an origin server for the purposes of
+   interacting with "https" resources.
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 18]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   In HTTP/1.x, CONNECT is used to convert an entire HTTP connection
+   into a tunnel to a remote host.  In HTTP/2 and HTTP/3, the CONNECT
+   method is used to establish a tunnel over a single stream.
+
+   A CONNECT request MUST be constructed as follows:
+
+   *  The ":method" pseudo-header field is set to "CONNECT"
+
+   *  The ":scheme" and ":path" pseudo-header fields are omitted
+
+   *  The ":authority" pseudo-header field contains the host and port to
+      connect to (equivalent to the authority-form of the request-target
+      of CONNECT requests; see Section 3.2.3 of [HTTP11])
+
+   The request stream remains open at the end of the request to carry
+   the data to be transferred.  A CONNECT request that does not conform
+   to these restrictions is malformed; see Section 4.1.3.
+
+   A proxy that supports CONNECT establishes a TCP connection
+   ([RFC0793]) to the server identified in the ":authority" pseudo-
+   header field.  Once this connection is successfully established, the
+   proxy sends a HEADERS frame containing a 2xx series status code to
+   the client, as defined in Section 9.3 of [SEMANTICS].
+
+   All DATA frames on the stream correspond to data sent or received on
+   the TCP connection.  Any DATA frame sent by the client is transmitted
+   by the proxy to the TCP server; data received from the TCP server is
+   packaged into DATA frames by the proxy.  Note that the size and
+   number of TCP segments is not guaranteed to map predictably to the
+   size and number of HTTP DATA or QUIC STREAM frames.
+
+   Once the CONNECT method has completed, only DATA frames are permitted
+   to be sent on the stream.  Extension frames MAY be used if
+   specifically permitted by the definition of the extension.  Receipt
+   of any other frame type MUST be treated as a connection error of type
+   H3_FRAME_UNEXPECTED.
+
+   The TCP connection can be closed by either peer.  When the client
+   ends the request stream (that is, the receive stream at the proxy
+   enters the "Data Recvd" state), the proxy will set the FIN bit on its
+   connection to the TCP server.  When the proxy receives a packet with
+   the FIN bit set, it will terminate the send stream that it sends to
+   the client.  TCP connections which remain half-closed in a single
+   direction are not invalid, but are often handled poorly by servers,
+   so clients SHOULD NOT close a stream for sending while they still
+   expect to receive data from the target of the CONNECT.
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 19]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   A TCP connection error is signaled by abruptly terminating the
+   stream.  A proxy treats any error in the TCP connection, which
+   includes receiving a TCP segment with the RST bit set, as a stream
+   error of type H3_CONNECT_ERROR (Section 8.1).  Correspondingly, if a
+   proxy detects an error with the stream or the QUIC connection, it
+   MUST close the TCP connection.  If the underlying TCP implementation
+   permits it, the proxy SHOULD send a TCP segment with the RST bit set.
+
+4.3.  HTTP Upgrade
+
+   HTTP/3 does not support the HTTP Upgrade mechanism (Section 9.9 of
+   [HTTP11]) or 101 (Switching Protocols) informational status code
+   (Section 9.2.2 of [SEMANTICS]).
+
+4.4.  Server Push
+
+   Server push is an interaction mode which permits a server to push a
+   request-response exchange to a client in anticipation of the client
+   making the indicated request.  This trades off network usage against
+   a potential latency gain.  HTTP/3 server push is similar to what is
+   described in HTTP/2 [HTTP2], but uses different mechanisms.
+
+   Each server push is identified by a unique Push ID.  This Push ID is
+   used in one or more PUSH_PROMISE frames (see Section 7.2.5) that
+   carry the request fields, then included with the push stream which
+   ultimately fulfills those promises.  When the same Push ID is
+   promised on multiple request streams, the decompressed request field
+   sections MUST contain the same fields in the same order, and both the
+   name and the value in each field MUST be exact matches.
+
+   Server push is only enabled on a connection when a client sends a
+   MAX_PUSH_ID frame; see Section 7.2.7.  A server cannot use server
+   push until it receives a MAX_PUSH_ID frame.  A client sends
+   additional MAX_PUSH_ID frames to control the number of pushes that a
+   server can promise.  A server SHOULD use Push IDs sequentially,
+   starting at 0.  A client MUST treat receipt of a push stream with a
+   Push ID that is greater than the maximum Push ID as a connection
+   error of type H3_ID_ERROR.
+
+   The header section of the request message is carried by a
+   PUSH_PROMISE frame (see Section 7.2.5) on the request stream which
+   generated the push.  This allows the server push to be associated
+   with a client request.
+
+   Not all requests can be pushed.  A server MAY push requests which
+   have the following properties:
+
+   *  cacheable; see Section 7.2.3 of [SEMANTICS]
+
+
+
+Bishop                   Expires 5 December 2020               [Page 20]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   *  safe; see Section 7.2.1 of [SEMANTICS]
+
+   *  does not include a request body or trailer section
+
+   The server MUST include a value in the ":authority" pseudo-header
+   field for which the server is authoritative; see Section 3.4.
+
+   Clients SHOULD send a CANCEL_PUSH frame upon receipt of a
+   PUSH_PROMISE frame carrying a request which is not cacheable, is not
+   known to be safe, that indicates the presence of a request body, or
+   for which it does not consider the server authoritative.
+
+   Each pushed response is associated with one or more client requests.
+   The push is associated with the request stream on which the
+   PUSH_PROMISE frame was received.  The same server push can be
+   associated with additional client requests using a PUSH_PROMISE frame
+   with the same Push ID on multiple request streams.  These
+   associations do not affect the operation of the protocol, but MAY be
+   considered by user agents when deciding how to use pushed resources.
+
+   Ordering of a PUSH_PROMISE in relation to certain parts of the
+   response is important.  The server SHOULD send PUSH_PROMISE frames
+   prior to sending HEADERS or DATA frames that reference the promised
+   responses.  This reduces the chance that a client requests a resource
+   that will be pushed by the server.
+
+   When a server later fulfills a promise, the server push response is
+   conveyed on a push stream; see Section 6.2.2.  The push stream
+   identifies the Push ID of the promise that it fulfills, then contains
+   a response to the promised request using the same format described
+   for responses in Section 4.1.
+
+   Due to reordering, push stream data can arrive before the
+   corresponding PUSH_PROMISE frame.  When a client receives a new push
+   stream with an as-yet-unknown Push ID, both the associated client
+   request and the pushed request header fields are unknown.  The client
+   can buffer the stream data in expectation of the matching
+   PUSH_PROMISE.  The client can use stream flow control (see section
+   4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server may
+   commit to the pushed stream.
+
+   If a promised server push is not needed by the client, the client
+   SHOULD send a CANCEL_PUSH frame.  If the push stream is already open
+   or opens after sending the CANCEL_PUSH frame, the client can abort
+   reading the stream with an error code of H3_REQUEST_CANCELLED.  This
+   asks the server not to transfer additional data and indicates that it
+   will be discarded upon receipt.
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 21]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Pushed responses that are cacheable (see Section 3 of [CACHING]) can
+   be stored by the client, if it implements an HTTP cache.  Pushed
+   responses are considered successfully validated on the origin server
+   (e.g., if the "no-cache" cache response directive is present
+   (Section 5.2.2.3 of [CACHING])) at the time the pushed response is
+   received.
+
+   Pushed responses that are not cacheable MUST NOT be stored by any
+   HTTP cache.  They MAY be made available to the application
+   separately.
+
+5.  Connection Closure
+
+   Once established, an HTTP/3 connection can be used for many requests
+   and responses over time until the connection is closed.  Connection
+   closure can happen in any of several different ways.
+
+5.1.  Idle Connections
+
+   Each QUIC endpoint declares an idle timeout during the handshake.  If
+   the connection remains idle (no packets received) for longer than
+   this duration, the peer will assume that the connection has been
+   closed.  HTTP/3 implementations will need to open a new connection
+   for new requests if the existing connection has been idle for longer
+   than the server's advertised idle timeout, and SHOULD do so if
+   approaching the idle timeout.
+
+   HTTP clients are expected to request that the transport keep
+   connections open while there are responses outstanding for requests
+   or server pushes, as described in Section 19.2 of [QUIC-TRANSPORT].
+   If the client is not expecting a response from the server, allowing
+   an idle connection to time out is preferred over expending effort
+   maintaining a connection that might not be needed.  A gateway MAY
+   maintain connections in anticipation of need rather than incur the
+   latency cost of connection establishment to servers.  Servers SHOULD
+   NOT actively keep connections open.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 22]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+5.2.  Connection Shutdown
+
+   Even when a connection is not idle, either endpoint can decide to
+   stop using the connection and initiate a graceful connection close.
+   Endpoints initiate the graceful shutdown of a connection by sending a
+   GOAWAY frame (Section 7.2.6).  The GOAWAY frame contains an
+   identifier that indicates to the receiver the range of requests or
+   pushes that were or might be processed in this connection.  The
+   server sends a client-initiated bidirectional Stream ID; the client
+   sends a Push ID.  Requests or pushes with the indicated identifier or
+   greater are rejected by the sender of the GOAWAY.  This identifier
+   MAY be zero if no requests or pushes were processed.
+
+   The information in the GOAWAY frame enables a client and server to
+   agree on which requests or pushes were accepted prior to the
+   connection shutdown.  Upon sending a GOAWAY frame, the endpoint
+   SHOULD explicitly cancel (see Section 4.1.2 and Section 7.2.3) any
+   requests or pushes that have identifiers greater than or equal to
+   that indicated, in order to clean up transport state for the affected
+   streams.  The endpoint SHOULD continue to do so as more requests or
+   pushes arrive.
+
+   Endpoints MUST NOT initiate new requests or promise new pushes on the
+   connection after receipt of a GOAWAY frame from the peer.  Clients
+   MAY establish a new connection to send additional requests.
+
+   Some requests or pushes might already be in transit:
+
+   *  Upon receipt of a GOAWAY frame, if the client has already sent
+      requests with a Stream ID greater than or equal to the identifier
+      received in a GOAWAY frame, those requests will not be processed.
+      Clients can safely retry unprocessed requests on a different
+      connection.
+
+      Requests on Stream IDs less than the Stream ID in a GOAWAY frame
+      from the server might have been processed; their status cannot be
+      known until a response is received, the stream is reset
+      individually, another GOAWAY is received, or the connection
+      terminates.
+
+      Servers MAY reject individual requests on streams below the
+      indicated ID if these requests were not processed.
+
+   *  If a server receives a GOAWAY frame after having promised pushes
+      with a Push ID greater than or equal to the identifier received in
+      a GOAWAY frame, those pushes will not be accepted.
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 23]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Servers SHOULD send a GOAWAY frame when the closing of a connection
+   is known in advance, even if the advance notice is small, so that the
+   remote peer can know whether a request has been partially processed
+   or not.  For example, if an HTTP client sends a POST at the same time
+   that a server closes a QUIC connection, the client cannot know if the
+   server started to process that POST request if the server does not
+   send a GOAWAY frame to indicate what streams it might have acted on.
+
+   A client that is unable to retry requests loses all requests that are
+   in flight when the server closes the connection.  An endpoint MAY
+   send multiple GOAWAY frames indicating different identifiers, but
+   MUST NOT increase the identifier value they send, since clients might
+   already have retried unprocessed requests on another connection.
+
+   An endpoint that is attempting to gracefully shut down a connection
+   can send a GOAWAY frame with a value set to the maximum possible
+   value (2^62-4 for servers, 2^62-1 for clients).  This ensures that
+   the peer stops creating new requests or pushes.  After allowing time
+   for any in-flight requests or pushes to arrive, the endpoint can send
+   another GOAWAY frame indicating which requests or pushes it might
+   accept before the end of the connection.  This ensures that a
+   connection can be cleanly shut down without losing requests.
+
+   A client has more flexibility in the value it chooses for the Push ID
+   in a GOAWAY that it sends.  A value of 2^62 - 1 indicates that the
+   server can continue fulfilling pushes which have already been
+   promised, and the client can continue granting push credit as needed;
+   see Section 7.2.7.  A smaller value indicates the client will reject
+   pushes with Push IDs greater than or equal to this value.  Like the
+   server, the client MAY send subsequent GOAWAY frames so long as the
+   specified Push ID is strictly smaller than all previously sent
+   values.
+
+   Even when a GOAWAY indicates that a given request or push will not be
+   processed or accepted upon receipt, the underlying transport
+   resources still exist.  The endpoint that initiated these requests
+   can cancel them to clean up transport state.
+
+   Once all accepted requests and pushes have been processed, the
+   endpoint can permit the connection to become idle, or MAY initiate an
+   immediate closure of the connection.  An endpoint that completes a
+   graceful shutdown SHOULD use the H3_NO_ERROR code when closing the
+   connection.
+
+   If a client has consumed all available bidirectional stream IDs with
+   requests, the server need not send a GOAWAY frame, since the client
+   is unable to make further requests.
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 24]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+5.3.  Immediate Application Closure
+
+   An HTTP/3 implementation can immediately close the QUIC connection at
+   any time.  This results in sending a QUIC CONNECTION_CLOSE frame to
+   the peer indicating that the application layer has terminated the
+   connection.  The application error code in this frame indicates to
+   the peer why the connection is being closed.  See Section 8 for error
+   codes which can be used when closing a connection in HTTP/3.
+
+   Before closing the connection, a GOAWAY frame MAY be sent to allow
+   the client to retry some requests.  Including the GOAWAY frame in the
+   same packet as the QUIC CONNECTION_CLOSE frame improves the chances
+   of the frame being received by clients.
+
+5.4.  Transport Closure
+
+   For various reasons, the QUIC transport could indicate to the
+   application layer that the connection has terminated.  This might be
+   due to an explicit closure by the peer, a transport-level error, or a
+   change in network topology which interrupts connectivity.
+
+   If a connection terminates without a GOAWAY frame, clients MUST
+   assume that any request which was sent, whether in whole or in part,
+   might have been processed.
+
+6.  Stream Mapping and Usage
+
+   A QUIC stream provides reliable in-order delivery of bytes, but makes
+   no guarantees about order of delivery with regard to bytes on other
+   streams.  On the wire, data is framed into QUIC STREAM frames, but
+   this framing is invisible to the HTTP framing layer.  The transport
+   layer buffers and orders received QUIC STREAM frames, exposing the
+   data contained within as a reliable byte stream to the application.
+   Although QUIC permits out-of-order delivery within a stream, HTTP/3
+   does not make use of this feature.
+
+   QUIC streams can be either unidirectional, carrying data only from
+   initiator to receiver, or bidirectional.  Streams can be initiated by
+   either the client or the server.  For more detail on QUIC streams,
+   see Section 2 of [QUIC-TRANSPORT].
+
+   When HTTP fields and data are sent over QUIC, the QUIC layer handles
+   most of the stream management.  HTTP does not need to do any separate
+   multiplexing when using QUIC - data sent over a QUIC stream always
+   maps to a particular HTTP transaction or connection context.
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 25]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+6.1.  Bidirectional Streams
+
+   All client-initiated bidirectional streams are used for HTTP requests
+   and responses.  A bidirectional stream ensures that the response can
+   be readily correlated with the request.  This means that the client's
+   first request occurs on QUIC stream 0, with subsequent requests on
+   stream 4, 8, and so on.  In order to permit these streams to open, an
+   HTTP/3 server SHOULD configure non-zero minimum values for the number
+   of permitted streams and the initial stream flow control window.  So
+   as to not unnecessarily limit parallelism, at least 100 requests
+   SHOULD be permitted at a time.
+
+   HTTP/3 does not use server-initiated bidirectional streams, though an
+   extension could define a use for these streams.  Clients MUST treat
+   receipt of a server-initiated bidirectional stream as a connection
+   error of type H3_STREAM_CREATION_ERROR unless such an extension has
+   been negotiated.
+
+6.2.  Unidirectional Streams
+
+   Unidirectional streams, in either direction, are used for a range of
+   purposes.  The purpose is indicated by a stream type, which is sent
+   as a variable-length integer at the start of the stream.  The format
+   and structure of data that follows this integer is determined by the
+   stream type.
+
+   Unidirectional Stream Header {
+     Stream Type (i),
+   }
+
+                   Figure 1: Unidirectional Stream Header
+
+   Some stream types are reserved (Section 6.2.3).  Two stream types are
+   defined in this document: control streams (Section 6.2.1) and push
+   streams (Section 6.2.2).  [QPACK] defines two additional stream
+   types.  Other stream types can be defined by extensions to HTTP/3;
+   see Section 9 for more details.
+
+   The performance of HTTP/3 connections in the early phase of their
+   lifetime is sensitive to the creation and exchange of data on
+   unidirectional streams.  Endpoints that excessively restrict the
+   number of streams or the flow control window of these streams will
+   increase the chance that the remote peer reaches the limit early and
+   becomes blocked.  In particular, implementations should consider that
+   remote peers may wish to exercise reserved stream behavior
+   (Section 6.2.3) with some of the unidirectional streams they are
+   permitted to use.  To avoid blocking, the transport parameters sent
+   by both clients and servers MUST allow the peer to create at least
+
+
+
+Bishop                   Expires 5 December 2020               [Page 26]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   one unidirectional stream for the HTTP control stream plus the number
+   of unidirectional streams required by mandatory extensions (three
+   being the minimum number required for the base HTTP/3 protocol and
+   QPACK), and SHOULD provide at least 1,024 bytes of flow control
+   credit to each stream.
+
+   Note that an endpoint is not required to grant additional credits to
+   create more unidirectional streams if its peer consumes all the
+   initial credits before creating the critical unidirectional streams.
+   Endpoints SHOULD create the HTTP control stream as well as the
+   unidirectional streams required by mandatory extensions (such as the
+   QPACK encoder and decoder streams) first, and then create additional
+   streams as allowed by their peer.
+
+   If the stream header indicates a stream type which is not supported
+   by the recipient, the remainder of the stream cannot be consumed as
+   the semantics are unknown.  Recipients of unknown stream types MAY
+   abort reading of the stream with an error code of
+   H3_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be a
+   connection error of any kind.
+
+   Implementations MAY send stream types before knowing whether the peer
+   supports them.  However, stream types which could modify the state or
+   semantics of existing protocol components, including QPACK or other
+   extensions, MUST NOT be sent until the peer is known to support them.
+
+   A sender can close or reset a unidirectional stream unless otherwise
+   specified.  A receiver MUST tolerate unidirectional streams being
+   closed or reset prior to the reception of the unidirectional stream
+   header.
+
+6.2.1.  Control Streams
+
+   A control stream is indicated by a stream type of 0x00.  Data on this
+   stream consists of HTTP/3 frames, as defined in Section 7.2.
+
+   Each side MUST initiate a single control stream at the beginning of
+   the connection and send its SETTINGS frame as the first frame on this
+   stream.  If the first frame of the control stream is any other frame
+   type, this MUST be treated as a connection error of type
+   H3_MISSING_SETTINGS.  Only one control stream per peer is permitted;
+   receipt of a second stream which claims to be a control stream MUST
+   be treated as a connection error of type H3_STREAM_CREATION_ERROR.
+   The sender MUST NOT close the control stream, and the receiver MUST
+   NOT request that the sender close the control stream.  If either
+   control stream is closed at any point, this MUST be treated as a
+   connection error of type H3_CLOSED_CRITICAL_STREAM.
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 27]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   A pair of unidirectional streams is used rather than a single
+   bidirectional stream.  This allows either peer to send data as soon
+   as it is able.  Depending on whether 0-RTT is enabled on the
+   connection, either client or server might be able to send stream data
+   first after the cryptographic handshake completes.
+
+6.2.2.  Push Streams
+
+   Server push is an optional feature introduced in HTTP/2 that allows a
+   server to initiate a response before a request has been made.  See
+   Section 4.4 for more details.
+
+   A push stream is indicated by a stream type of 0x01, followed by the
+   Push ID of the promise that it fulfills, encoded as a variable-length
+   integer.  The remaining data on this stream consists of HTTP/3
+   frames, as defined in Section 7.2, and fulfills a promised server
+   push by zero or more interim HTTP responses followed by a single
+   final HTTP response, as defined in Section 4.1.  Server push and Push
+   IDs are described in Section 4.4.
+
+   Only servers can push; if a server receives a client-initiated push
+   stream, this MUST be treated as a connection error of type
+   H3_STREAM_CREATION_ERROR.
+
+   Push Stream Header {
+     Stream Type (i) = 0x01,
+     Push ID (i),
+   }
+
+                        Figure 2: Push Stream Header
+
+   Each Push ID MUST only be used once in a push stream header.  If a
+   push stream header includes a Push ID that was used in another push
+   stream header, the client MUST treat this as a connection error of
+   type H3_ID_ERROR.
+
+6.2.3.  Reserved Stream Types
+
+   Stream types of the format "0x1f * N + 0x21" for non-negative integer
+   values of N are reserved to exercise the requirement that unknown
+   types be ignored.  These streams have no semantics, and can be sent
+   when application-layer padding is desired.  They MAY also be sent on
+   connections where no data is currently being transferred.  Endpoints
+   MUST NOT consider these streams to have any meaning upon receipt.
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 28]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   The payload and length of the stream are selected in any manner the
+   implementation chooses.  Implementations MAY terminate these streams
+   cleanly, or MAY abruptly terminate them.  When terminating abruptly,
+   the error code H3_NO_ERROR or a reserved error code (Section 8.1)
+   SHOULD be used.
+
+7.  HTTP Framing Layer
+
+   HTTP frames are carried on QUIC streams, as described in Section 6.
+   HTTP/3 defines three stream types: control stream, request stream,
+   and push stream.  This section describes HTTP/3 frame formats and the
+   streams types on which they are permitted; see Table 1 for an
+   overview.  A comparison between HTTP/2 and HTTP/3 frames is provided
+   in Appendix A.2.
+
+   +--------------+----------------+----------------+--------+---------+
+   | Frame        | Control Stream | Request        | Push   | Section |
+   |              |                | Stream         | Stream |         |
+   +==============+================+================+========+=========+
+   | DATA         | No             | Yes            | Yes    | Section |
+   |              |                |                |        | 7.2.1   |
+   +--------------+----------------+----------------+--------+---------+
+   | HEADERS      | No             | Yes            | Yes    | Section |
+   |              |                |                |        | 7.2.2   |
+   +--------------+----------------+----------------+--------+---------+
+   | CANCEL_PUSH  | Yes            | No             | No     | Section |
+   |              |                |                |        | 7.2.3   |
+   +--------------+----------------+----------------+--------+---------+
+   | SETTINGS     | Yes (1)        | No             | No     | Section |
+   |              |                |                |        | 7.2.4   |
+   +--------------+----------------+----------------+--------+---------+
+   | PUSH_PROMISE | No             | Yes            | No     | Section |
+   |              |                |                |        | 7.2.5   |
+   +--------------+----------------+----------------+--------+---------+
+   | GOAWAY       | Yes            | No             | No     | Section |
+   |              |                |                |        | 7.2.6   |
+   +--------------+----------------+----------------+--------+---------+
+   | MAX_PUSH_ID  | Yes            | No             | No     | Section |
+   |              |                |                |        | 7.2.7   |
+   +--------------+----------------+----------------+--------+---------+
+   | Reserved     | Yes            | Yes            | Yes    | Section |
+   |              |                |                |        | 7.2.8   |
+   +--------------+----------------+----------------+--------+---------+
+
+              Table 1: HTTP/3 Frames and Stream Type Overview
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 29]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Certain frames can only occur as the first frame of a particular
+   stream type; these are indicated in Table 1 with a (1).  Specific
+   guidance is provided in the relevant section.
+
+   Note that, unlike QUIC frames, HTTP/3 frames can span multiple
+   packets.
+
+7.1.  Frame Layout
+
+   All frames have the following format:
+
+   HTTP/3 Frame Format {
+     Type (i),
+     Length (i),
+     Frame Payload (..),
+   }
+
+                       Figure 3: HTTP/3 Frame Format
+
+   A frame includes the following fields:
+
+   Type:  A variable-length integer that identifies the frame type.
+
+   Length:  A variable-length integer that describes the length in bytes
+      of the Frame Payload.
+
+   Frame Payload:  A payload, the semantics of which are determined by
+      the Type field.
+
+   Each frame's payload MUST contain exactly the fields identified in
+   its description.  A frame payload that contains additional bytes
+   after the identified fields or a frame payload that terminates before
+   the end of the identified fields MUST be treated as a connection
+   error of type H3_FRAME_ERROR.
+
+   When a stream terminates cleanly, if the last frame on the stream was
+   truncated, this MUST be treated as a connection error (Section 8) of
+   type H3_FRAME_ERROR.  Streams which terminate abruptly may be reset
+   at any point in a frame.
+
+7.2.  Frame Definitions
+
+7.2.1.  DATA
+
+   DATA frames (type=0x0) convey arbitrary, variable-length sequences of
+   bytes associated with an HTTP request or response payload.
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 30]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   DATA frames MUST be associated with an HTTP request or response.  If
+   a DATA frame is received on a control stream, the recipient MUST
+   respond with a connection error (Section 8) of type
+   H3_FRAME_UNEXPECTED.
+
+   DATA Frame {
+     Type (i) = 0x0,
+     Length (i),
+     Data (..),
+   }
+
+                            Figure 4: DATA Frame
+
+7.2.2.  HEADERS
+
+   The HEADERS frame (type=0x1) is used to carry an HTTP field section,
+   encoded using QPACK.  See [QPACK] for more details.
+
+   HEADERS Frame {
+     Type (i) = 0x1,
+     Length (i),
+     Encoded Field Section (..),
+   }
+
+                          Figure 5: HEADERS Frame
+
+   HEADERS frames can only be sent on request / push streams.  If a
+   HEADERS frame is received on a control stream, the recipient MUST
+   respond with a connection error (Section 8) of type
+   H3_FRAME_UNEXPECTED.
+
+7.2.3.  CANCEL_PUSH
+
+   The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a
+   server push prior to the push stream being received.  The CANCEL_PUSH
+   frame identifies a server push by Push ID (see Section 7.2.5),
+   encoded as a variable-length integer.
+
+   When a client sends CANCEL_PUSH, it is indicating that it does not
+   wish to receive the promised resource.  The server SHOULD abort
+   sending the resource, but the mechanism to do so depends on the state
+   of the corresponding push stream.  If the server has not yet created
+   a push stream, it does not create one.  If the push stream is open,
+   the server SHOULD abruptly terminate that stream.  If the push stream
+   has already ended, the server MAY still abruptly terminate the stream
+   or MAY take no action.
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 31]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   When a server sends CANCEL_PUSH, it is indicating that it will not be
+   fulfilling a promise and has not created a push stream.  The client
+   should not expect the corresponding promise to be fulfilled.
+
+   Sending CANCEL_PUSH has no direct effect on the state of existing
+   push streams.  A server SHOULD NOT send a CANCEL_PUSH when it has
+   already created a corresponding push stream, and a client SHOULD NOT
+   send a CANCEL_PUSH when it has already received a corresponding push
+   stream.  If a push stream arrives after a client has sent
+   CANCEL_PUSH, this MAY be treated as a stream error of type
+   H3_STREAM_CREATION_ERROR.
+
+   A CANCEL_PUSH frame is sent on the control stream.  Receiving a
+   CANCEL_PUSH frame on a stream other than the control stream MUST be
+   treated as a connection error of type H3_FRAME_UNEXPECTED.
+
+   CANCEL_PUSH Frame {
+     Type (i) = 0x3,
+     Length (i),
+     Push ID (..),
+   }
+
+                        Figure 6: CANCEL_PUSH Frame
+
+   The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
+   integer.  The Push ID identifies the server push that is being
+   cancelled; see Section 7.2.5.  If a CANCEL_PUSH frame is received
+   which references a Push ID greater than currently allowed on the
+   connection, this MUST be treated as a connection error of type
+   H3_ID_ERROR.
+
+   If the client receives a CANCEL_PUSH frame, that frame might identify
+   a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due
+   to reordering.  If a server receives a CANCEL_PUSH frame for a Push
+   ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST
+   be treated as a connection error of type H3_ID_ERROR.
+
+7.2.4.  SETTINGS
+
+   The SETTINGS frame (type=0x4) conveys configuration parameters that
+   affect how endpoints communicate, such as preferences and constraints
+   on peer behavior.  Individually, a SETTINGS parameter can also be
+   referred to as a "setting"; the identifier and value of each setting
+   parameter can be referred to as a "setting identifier" and a "setting
+   value".
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 32]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   SETTINGS frames always apply to a connection, never a single stream.
+   A SETTINGS frame MUST be sent as the first frame of each control
+   stream (see Section 6.2.1) by each peer, and MUST NOT be sent
+   subsequently.  If an endpoint receives a second SETTINGS frame on the
+   control stream, the endpoint MUST respond with a connection error of
+   type H3_FRAME_UNEXPECTED.
+
+   SETTINGS frames MUST NOT be sent on any stream other than the control
+   stream.  If an endpoint receives a SETTINGS frame on a different
+   stream, the endpoint MUST respond with a connection error of type
+   H3_FRAME_UNEXPECTED.
+
+   SETTINGS parameters are not negotiated; they describe characteristics
+   of the sending peer, which can be used by the receiving peer.
+   However, a negotiation can be implied by the use of SETTINGS - each
+   peer uses SETTINGS to advertise a set of supported values.  The
+   definition of the setting would describe how each peer combines the
+   two sets to conclude which choice will be used.  SETTINGS does not
+   provide a mechanism to identify when the choice takes effect.
+
+   Different values for the same parameter can be advertised by each
+   peer.  For example, a client might be willing to consume a very large
+   response field section, while servers are more cautious about request
+   size.
+
+   The same setting identifier MUST NOT occur more than once in the
+   SETTINGS frame.  A receiver MAY treat the presence of duplicate
+   setting identifiers as a connection error of type H3_SETTINGS_ERROR.
+
+   The payload of a SETTINGS frame consists of zero or more parameters.
+   Each parameter consists of a setting identifier and a value, both
+   encoded as QUIC variable-length integers.
+
+   Setting {
+     Identifier (i),
+     Value (i),
+   }
+
+   SETTINGS Frame {
+     Type (i) = 0x4,
+     Length (i),
+     Setting (..) ...,
+   }
+
+                          Figure 7: SETTINGS Frame
+
+   An implementation MUST ignore the contents for any SETTINGS
+   identifier it does not understand.
+
+
+
+Bishop                   Expires 5 December 2020               [Page 33]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+7.2.4.1.  Defined SETTINGS Parameters
+
+   The following settings are defined in HTTP/3:
+
+   SETTINGS_MAX_FIELD_SECTION_SIZE (0x6):  The default value is
+      unlimited.  See Section 4.1.1 for usage.
+
+   Setting identifiers of the format "0x1f * N + 0x21" for non-negative
+   integer values of N are reserved to exercise the requirement that
+   unknown identifiers be ignored.  Such settings have no defined
+   meaning.  Endpoints SHOULD include at least one such setting in their
+   SETTINGS frame.  Endpoints MUST NOT consider such settings to have
+   any meaning upon receipt.
+
+   Because the setting has no defined meaning, the value of the setting
+   can be any value the implementation selects.
+
+   Additional settings can be defined by extensions to HTTP/3; see
+   Section 9 for more details.
+
+7.2.4.2.  Initialization
+
+   An HTTP implementation MUST NOT send frames or requests which would
+   be invalid based on its current understanding of the peer's settings.
+
+   All settings begin at an initial value.  Each endpoint SHOULD use
+   these initial values to send messages before the peer's SETTINGS
+   frame has arrived, as packets carrying the settings can be lost or
+   delayed.  When the SETTINGS frame arrives, any settings are changed
+   to their new values.
+
+   This removes the need to wait for the SETTINGS frame before sending
+   messages.  Endpoints MUST NOT require any data to be received from
+   the peer prior to sending the SETTINGS frame; settings MUST be sent
+   as soon as the transport is ready to send data.
+
+   For servers, the initial value of each client setting is the default
+   value.
+
+   For clients using a 1-RTT QUIC connection, the initial value of each
+   server setting is the default value.  1-RTT keys will always become
+   available prior to SETTINGS arriving, even if the server sends
+   SETTINGS immediately.  Clients SHOULD NOT wait indefinitely for
+   SETTINGS to arrive before sending requests, but SHOULD process
+   received datagrams in order to increase the likelihood of processing
+   SETTINGS before sending the first request.
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 34]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   When a 0-RTT QUIC connection is being used, the initial value of each
+   server setting is the value used in the previous session.  Clients
+   SHOULD store the settings the server provided in the connection where
+   resumption information was provided, but MAY opt not to store
+   settings in certain cases (e.g., if the session ticket is received
+   before the SETTINGS frame).  A client MUST comply with stored
+   settings - or default values, if no values are stored - when
+   attempting 0-RTT.  Once a server has provided new settings, clients
+   MUST comply with those values.
+
+   A server can remember the settings that it advertised, or store an
+   integrity-protected copy of the values in the ticket and recover the
+   information when accepting 0-RTT data.  A server uses the HTTP/3
+   settings values in determining whether to accept 0-RTT data.  If the
+   server cannot determine that the settings remembered by a client are
+   compatible with its current settings, it MUST NOT accept 0-RTT data.
+   Remembered settings are compatible if a client complying with those
+   settings would not violate the server's current settings.
+
+   A server MAY accept 0-RTT and subsequently provide different settings
+   in its SETTINGS frame.  If 0-RTT data is accepted by the server, its
+   SETTINGS frame MUST NOT reduce any limits or alter any values that
+   might be violated by the client with its 0-RTT data.  The server MUST
+   include all settings which differ from their default values.  If a
+   server accepts 0-RTT but then sends settings that are not compatible
+   with the previously specified settings, this MUST be treated as a
+   connection error of type H3_SETTINGS_ERROR.  If a server accepts
+   0-RTT but then sends a SETTINGS frame that omits a setting value that
+   the client understands (apart from reserved setting identifiers) that
+   was previously specified to have a non-default value, this MUST be
+   treated as a connection error of type H3_SETTINGS_ERROR.
+
+7.2.5.  PUSH_PROMISE
+
+   The PUSH_PROMISE frame (type=0x5) is used to carry a promised request
+   header field section from server to client on a request stream, as in
+   HTTP/2.
+
+   PUSH_PROMISE Frame {
+     Type (i) = 0x5,
+     Length (i),
+     Push ID (i),
+     Encoded Field Section (..),
+   }
+
+                        Figure 8: PUSH_PROMISE Frame
+
+   The payload consists of:
+
+
+
+Bishop                   Expires 5 December 2020               [Page 35]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Push ID:  A variable-length integer that identifies the server push
+      operation.  A Push ID is used in push stream headers
+      (Section 4.4), CANCEL_PUSH frames (Section 7.2.3).
+
+   Encoded Field Section:  QPACK-encoded request header fields for the
+      promised response.  See [QPACK] for more details.
+
+   A server MUST NOT use a Push ID that is larger than the client has
+   provided in a MAX_PUSH_ID frame (Section 7.2.7).  A client MUST treat
+   receipt of a PUSH_PROMISE frame that contains a larger Push ID than
+   the client has advertised as a connection error of H3_ID_ERROR.
+
+   A server MAY use the same Push ID in multiple PUSH_PROMISE frames.
+   If so, the decompressed request header sets MUST contain the same
+   fields in the same order, and both the name and the value in each
+   field MUST be exact matches.  Clients SHOULD compare the request
+   header sections for resources promised multiple times.  If a client
+   receives a Push ID that has already been promised and detects a
+   mismatch, it MUST respond with a connection error of type
+   H3_GENERAL_PROTOCOL_ERROR.  If the decompressed field sections match
+   exactly, the client SHOULD associate the pushed content with each
+   stream on which a PUSH_PROMISE was received.
+
+   Allowing duplicate references to the same Push ID is primarily to
+   reduce duplication caused by concurrent requests.  A server SHOULD
+   avoid reusing a Push ID over a long period.  Clients are likely to
+   consume server push responses and not retain them for reuse over
+   time.  Clients that see a PUSH_PROMISE that uses a Push ID that they
+   have already consumed and discarded are forced to ignore the
+   PUSH_PROMISE.
+
+   If a PUSH_PROMISE frame is received on the control stream, the client
+   MUST respond with a connection error (Section 8) of type
+   H3_FRAME_UNEXPECTED.
+
+   A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the
+   receipt of a PUSH_PROMISE frame as a connection error of type
+   H3_FRAME_UNEXPECTED.
+
+   See Section 4.4 for a description of the overall server push
+   mechanism.
+
+
+
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 36]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+7.2.6.  GOAWAY
+
+   The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of
+   a connection by either endpoint.  GOAWAY allows an endpoint to stop
+   accepting new requests or pushes while still finishing processing of
+   previously received requests and pushes.  This enables administrative
+   actions, like server maintenance.  GOAWAY by itself does not close a
+   connection.
+
+   GOAWAY Frame {
+     Type (i) = 0x7,
+     Length (i),
+     Stream ID/Push ID (..),
+   }
+
+                           Figure 9: GOAWAY Frame
+
+   The GOAWAY frame is always sent on the control stream.  In the server
+   to client direction, it carries a QUIC Stream ID for a client-
+   initiated bidirectional stream encoded as a variable-length integer.
+   A client MUST treat receipt of a GOAWAY frame containing a Stream ID
+   of any other type as a connection error of type H3_ID_ERROR.
+
+   In the client to server direction, the GOAWAY frame carries a Push ID
+   encoded as a variable-length integer.
+
+   The GOAWAY frame applies to the connection, not a specific stream.  A
+   client MUST treat a GOAWAY frame on a stream other than the control
+   stream as a connection error (Section 8) of type H3_FRAME_UNEXPECTED.
+
+   See Section 5.2 for more information on the use of the GOAWAY frame.
+
+7.2.7.  MAX_PUSH_ID
+
+   The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
+   number of server pushes that the server can initiate.  This sets the
+   maximum value for a Push ID that the server can use in PUSH_PROMISE
+   and CANCEL_PUSH frames.  Consequently, this also limits the number of
+   push streams that the server can initiate in addition to the limit
+   maintained by the QUIC transport.
+
+   The MAX_PUSH_ID frame is always sent on the control stream.  Receipt
+   of a MAX_PUSH_ID frame on any other stream MUST be treated as a
+   connection error of type H3_FRAME_UNEXPECTED.
+
+   A server MUST NOT send a MAX_PUSH_ID frame.  A client MUST treat the
+   receipt of a MAX_PUSH_ID frame as a connection error of type
+   H3_FRAME_UNEXPECTED.
+
+
+
+Bishop                   Expires 5 December 2020               [Page 37]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   The maximum Push ID is unset when a connection is created, meaning
+   that a server cannot push until it receives a MAX_PUSH_ID frame.  A
+   client that wishes to manage the number of promised server pushes can
+   increase the maximum Push ID by sending MAX_PUSH_ID frames as the
+   server fulfills or cancels server pushes.
+
+   MAX_PUSH_ID Frame {
+     Type (i) = 0x1,
+     Length (i),
+     Push ID (..),
+   }
+
+                    Figure 10: MAX_PUSH_ID Frame Payload
+
+   The MAX_PUSH_ID frame carries a single variable-length integer that
+   identifies the maximum value for a Push ID that the server can use;
+   see Section 7.2.5.  A MAX_PUSH_ID frame cannot reduce the maximum
+   Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than
+   previously received MUST be treated as a connection error of type
+   H3_ID_ERROR.
+
+7.2.8.  Reserved Frame Types
+
+   Frame types of the format "0x1f * N + 0x21" for non-negative integer
+   values of N are reserved to exercise the requirement that unknown
+   types be ignored (Section 9).  These frames have no semantics, and
+   can be sent on any open stream when application-layer padding is
+   desired.  They MAY also be sent on connections where no data is
+   currently being transferred.  Endpoints MUST NOT consider these
+   frames to have any meaning upon receipt.
+
+   The payload and length of the frames are selected in any manner the
+   implementation chooses.
+
+   Frame types which were used in HTTP/2 where there is no corresponding
+   HTTP/3 frame have also been reserved (Section 11.2.1).  These frame
+   types MUST NOT be sent, and receipt MAY be treated as an error of
+   type H3_FRAME_UNEXPECTED.
+
+8.  Error Handling
+
+   QUIC allows the application to abruptly terminate (reset) individual
+   streams or the entire connection when an error is encountered.  These
+   are referred to as "stream errors" or "connection errors" and are
+   described in more detail in [QUIC-TRANSPORT].
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 38]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   An endpoint MAY choose to treat a stream error as a connection error
+   under certain circumstances.  Implementations need to consider the
+   impact on outstanding requests before making this choice.
+
+   Because new error codes can be defined without negotiation (see
+   Section 9), use of an error code in an unexpected context or receipt
+   of an unknown error code MUST be treated as equivalent to
+   H3_NO_ERROR.  However, closing a stream can have other effects
+   regardless of the error code; see Section 4.1.
+
+   This section describes HTTP/3-specific error codes which can be used
+   to express the cause of a connection or stream error.
+
+8.1.  HTTP/3 Error Codes
+
+   The following error codes are defined for use when abruptly
+   terminating streams, aborting reading of streams, or immediately
+   closing connections.
+
+   H3_NO_ERROR (0x100):  No error.  This is used when the connection or
+      stream needs to be closed, but there is no error to signal.
+
+   H3_GENERAL_PROTOCOL_ERROR (0x101):  Peer violated protocol
+      requirements in a way which doesn't match a more specific error
+      code, or endpoint declines to use the more specific error code.
+
+   H3_INTERNAL_ERROR (0x102):  An internal error has occurred in the
+      HTTP stack.
+
+   H3_STREAM_CREATION_ERROR (0x103):  The endpoint detected that its
+      peer created a stream that it will not accept.
+
+   H3_CLOSED_CRITICAL_STREAM (0x104):  A stream required by the
+      connection was closed or reset.
+
+   H3_FRAME_UNEXPECTED (0x105):  A frame was received which was not
+      permitted in the current state or on the current stream.
+
+   H3_FRAME_ERROR (0x106):  A frame that fails to satisfy layout
+      requirements or with an invalid size was received.
+
+   H3_EXCESSIVE_LOAD (0x107):  The endpoint detected that its peer is
+      exhibiting a behavior that might be generating excessive load.
+
+   H3_ID_ERROR (0x108):  A Stream ID or Push ID was used incorrectly,
+      such as exceeding a limit, reducing a limit, or being reused.
+
+   H3_SETTINGS_ERROR (0x109):  An endpoint detected an error in the
+
+
+
+Bishop                   Expires 5 December 2020               [Page 39]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+      payload of a SETTINGS frame.
+
+   H3_MISSING_SETTINGS (0x10A):  No SETTINGS frame was received at the
+      beginning of the control stream.
+
+   H3_REQUEST_REJECTED (0x10B):  A server rejected a request without
+      performing any application processing.
+
+   H3_REQUEST_CANCELLED (0x10C):  The request or its response (including
+      pushed response) is cancelled.
+
+   H3_REQUEST_INCOMPLETE (0x10D):  The client's stream terminated
+      without containing a fully-formed request.
+
+   H3_CONNECT_ERROR (0x10F):  The connection established in response to
+      a CONNECT request was reset or abnormally closed.
+
+   H3_VERSION_FALLBACK (0x110):  The requested operation cannot be
+      served over HTTP/3.  The peer should retry over HTTP/1.1.
+
+   Error codes of the format "0x1f * N + 0x21" for non-negative integer
+   values of N are reserved to exercise the requirement that unknown
+   error codes be treated as equivalent to H3_NO_ERROR (Section 9).
+   Implementations SHOULD select an error code from this space with some
+   probability when they would have sent H3_NO_ERROR.
+
+9.  Extensions to HTTP/3
+
+   HTTP/3 permits extension of the protocol.  Within the limitations
+   described in this section, protocol extensions can be used to provide
+   additional services or alter any aspect of the protocol.  Extensions
+   are effective only within the scope of a single HTTP/3 connection.
+
+   This applies to the protocol elements defined in this document.  This
+   does not affect the existing options for extending HTTP, such as
+   defining new methods, status codes, or fields.
+
+   Extensions are permitted to use new frame types (Section 7.2), new
+   settings (Section 7.2.4.1), new error codes (Section 8), or new
+   unidirectional stream types (Section 6.2).  Registries are
+   established for managing these extension points: frame types
+   (Section 11.2.1), settings (Section 11.2.2), error codes
+   (Section 11.2.3), and stream types (Section 11.2.4).
+
+   Implementations MUST ignore unknown or unsupported values in all
+   extensible protocol elements.  Implementations MUST discard frames
+   and unidirectional streams that have unknown or unsupported types.
+   This means that any of these extension points can be safely used by
+
+
+
+Bishop                   Expires 5 December 2020               [Page 40]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   extensions without prior arrangement or negotiation.  However, where
+   a known frame type is required to be in a specific location, such as
+   the SETTINGS frame as the first frame of the control stream (see
+   Section 6.2.1), an unknown frame type does not satisfy that
+   requirement and SHOULD be treated as an error.
+
+   Extensions that could change the semantics of existing protocol
+   components MUST be negotiated before being used.  For example, an
+   extension that changes the layout of the HEADERS frame cannot be used
+   until the peer has given a positive signal that this is acceptable.
+   Coordinating when such a revised layout comes into effect could prove
+   complex.  As such, allocating new identifiers for new definitions of
+   existing protocol elements is likely to be more effective.
+
+   This document doesn't mandate a specific method for negotiating the
+   use of an extension but notes that a setting (Section 7.2.4.1) could
+   be used for that purpose.  If both peers set a value that indicates
+   willingness to use the extension, then the extension can be used.  If
+   a setting is used for extension negotiation, the default value MUST
+   be defined in such a fashion that the extension is disabled if the
+   setting is omitted.
+
+10.  Security Considerations
+
+   The security considerations of HTTP/3 should be comparable to those
+   of HTTP/2 with TLS.  However, many of the considerations from
+   Section 10 of [HTTP2] apply to [QUIC-TRANSPORT] and are discussed in
+   that document.
+
+10.1.  Server Authority
+
+   HTTP/3 relies on the HTTP definition of authority.  The security
+   considerations of establishing authority are discussed in
+   Section 11.1 of [SEMANTICS].
+
+10.2.  Cross-Protocol Attacks
+
+   The use of ALPN in the TLS and QUIC handshakes establishes the target
+   application protocol before application-layer bytes are processed.
+   Because all QUIC packets are encrypted, it is difficult for an
+   attacker to control the plaintext bytes of an HTTP/3 connection which
+   could be used in a cross-protocol attack on a plaintext protocol.
+
+
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 41]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+10.3.  Intermediary Encapsulation Attacks
+
+   The HTTP/3 field encoding allows the expression of names that are not
+   valid field names in the syntax used by HTTP (Section 4.3 of
+   [SEMANTICS]).  Requests or responses containing invalid field names
+   MUST be treated as malformed (Section 4.1.3).  An intermediary
+   therefore cannot translate an HTTP/3 request or response containing
+   an invalid field name into an HTTP/1.1 message.
+
+   Similarly, HTTP/3 allows field values that are not valid.  While most
+   of the values that can be encoded will not alter field parsing,
+   carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the
+   zero character (NUL, ASCII 0x0) might be exploited by an attacker if
+   they are translated verbatim.  Any request or response that contains
+   a character not permitted in a field value MUST be treated as
+   malformed (Section 4.1.3).  Valid characters are defined by the
+   "field-content" ABNF rule in Section 4.4 of [SEMANTICS].
+
+10.4.  Cacheability of Pushed Responses
+
+   Pushed responses do not have an explicit request from the client; the
+   request is provided by the server in the PUSH_PROMISE frame.
+
+   Caching responses that are pushed is possible based on the guidance
+   provided by the origin server in the Cache-Control header field.
+   However, this can cause issues if a single server hosts more than one
+   tenant.  For example, a server might offer multiple users each a
+   small portion of its URI space.
+
+   Where multiple tenants share space on the same server, that server
+   MUST ensure that tenants are not able to push representations of
+   resources that they do not have authority over.  Failure to enforce
+   this would allow a tenant to provide a representation that would be
+   served out of cache, overriding the actual representation that the
+   authoritative tenant provides.
+
+   Pushed responses for which an origin server is not authoritative (see
+   Section 3.4) MUST NOT be used or cached.
+
+10.5.  Denial-of-Service Considerations
+
+   An HTTP/3 connection can demand a greater commitment of resources to
+   operate than an HTTP/1.1 or HTTP/2 connection.  The use of field
+   compression and flow control depend on a commitment of resources for
+   storing a greater amount of state.  Settings for these features
+   ensure that memory commitments for these features are strictly
+   bounded.
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 42]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   The number of PUSH_PROMISE frames is constrained in a similar
+   fashion.  A client that accepts server push SHOULD limit the number
+   of Push IDs it issues at a time.
+
+   Processing capacity cannot be guarded as effectively as state
+   capacity.
+
+   The ability to send undefined protocol elements which the peer is
+   required to ignore can be abused to cause a peer to expend additional
+   processing time.  This might be done by setting multiple undefined
+   SETTINGS parameters, unknown frame types, or unknown stream types.
+   Note, however, that some uses are entirely legitimate, such as
+   optional-to-understand extensions and padding to increase resistance
+   to traffic analysis.
+
+   Compression of field sections also offers some opportunities to waste
+   processing resources; see Section 7 of [QPACK] for more details on
+   potential abuses.
+
+   All these features - i.e., server push, unknown protocol elements,
+   field compression - have legitimate uses.  These features become a
+   burden only when they are used unnecessarily or to excess.
+
+   An endpoint that doesn't monitor this behavior exposes itself to a
+   risk of denial-of-service attack.  Implementations SHOULD track the
+   use of these features and set limits on their use.  An endpoint MAY
+   treat activity that is suspicious as a connection error (Section 8)
+   of type H3_EXCESSIVE_LOAD, but false positives will result in
+   disrupting valid connections and requests.
+
+10.5.1.  Limits on Field Section Size
+
+   A large field section (Section 4.1) can cause an implementation to
+   commit a large amount of state.  Header fields that are critical for
+   routing can appear toward the end of a header field section, which
+   prevents streaming of the header field section to its ultimate
+   destination.  This ordering and other reasons, such as ensuring cache
+   correctness, mean that an endpoint likely needs to buffer the entire
+   header field section.  Since there is no hard limit to the size of a
+   field section, some endpoints could be forced to commit a large
+   amount of available memory for header fields.
+
+   An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE
+   (Section 7.2.4.1) setting to advise peers of limits that might apply
+   on the size of field sections.  This setting is only advisory, so
+   endpoints MAY choose to send field sections that exceed this limit
+   and risk having the request or response being treated as malformed.
+   This setting is specific to a connection, so any request or response
+
+
+
+Bishop                   Expires 5 December 2020               [Page 43]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   could encounter a hop with a lower, unknown limit.  An intermediary
+   can attempt to avoid this problem by passing on values presented by
+   different peers, but they are not obligated to do so.
+
+   A server that receives a larger field section than it is willing to
+   handle can send an HTTP 431 (Request Header Fields Too Large) status
+   code [RFC6585].  A client can discard responses that it cannot
+   process.
+
+10.5.2.  CONNECT Issues
+
+   The CONNECT method can be used to create disproportionate load on an
+   proxy, since stream creation is relatively inexpensive when compared
+   to the creation and maintenance of a TCP connection.  A proxy might
+   also maintain some resources for a TCP connection beyond the closing
+   of the stream that carries the CONNECT request, since the outgoing
+   TCP connection remains in the TIME_WAIT state.  Therefore, a proxy
+   cannot rely on QUIC stream limits alone to control the resources
+   consumed by CONNECT requests.
+
+10.6.  Use of Compression
+
+   Compression can allow an attacker to recover secret data when it is
+   compressed in the same context as data under attacker control.
+   HTTP/3 enables compression of fields (Section 4.1.1); the following
+   concerns also apply to the use of HTTP compressed content-codings;
+   see Section 6.1.2 of [SEMANTICS].
+
+   There are demonstrable attacks on compression that exploit the
+   characteristics of the web (e.g., [BREACH]).  The attacker induces
+   multiple requests containing varying plaintext, observing the length
+   of the resulting ciphertext in each, which reveals a shorter length
+   when a guess about the secret is correct.
+
+   Implementations communicating on a secure channel MUST NOT compress
+   content that includes both confidential and attacker-controlled data
+   unless separate compression dictionaries are used for each source of
+   data.  Compression MUST NOT be used if the source of data cannot be
+   reliably determined.
+
+   Further considerations regarding the compression of fields sections
+   are described in [QPACK].
+
+
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 44]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+10.7.  Padding and Traffic Analysis
+
+   Padding can be used to obscure the exact size of frame content and is
+   provided to mitigate specific attacks within HTTP, for example,
+   attacks where compressed content includes both attacker-controlled
+   plaintext and secret data (e.g., [BREACH]).
+
+   Where HTTP/2 employs PADDING frames and Padding fields in other
+   frames to make a connection more resistant to traffic analysis,
+   HTTP/3 can either rely on transport-layer padding or employ the
+   reserved frame and stream types discussed in Section 7.2.8 and
+   Section 6.2.3.  These methods of padding produce different results in
+   terms of the granularity of padding, how padding is arranged in
+   relation to the information that is being protected, whether padding
+   is applied in the case of packet loss, and how an implementation
+   might control padding.  Redundant padding could even be
+   counterproductive.
+
+   To mitigate attacks that rely on compression, disabling or limiting
+   compression might be preferable to padding as a countermeasure.
+
+   Use of padding can result in less protection than might seem
+   immediately obvious.  At best, padding only makes it more difficult
+   for an attacker to infer length information by increasing the number
+   of frames an attacker has to observe.  Incorrectly implemented
+   padding schemes can be easily defeated.  In particular, randomized
+   padding with a predictable distribution provides very little
+   protection; similarly, padding payloads to a fixed size exposes
+   information as payload sizes cross the fixed-sized boundary, which
+   could be possible if an attacker can control plaintext.
+
+10.8.  Frame Parsing
+
+   Several protocol elements contain nested length elements, typically
+   in the form of frames with an explicit length containing variable-
+   length integers.  This could pose a security risk to an incautious
+   implementer.  An implementation MUST ensure that the length of a
+   frame exactly matches the length of the fields it contains.
+
+10.9.  Early Data
+
+   The use of 0-RTT with HTTP/3 creates an exposure to replay attack.
+   The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when
+   using HTTP/3 with 0-RTT.
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 45]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+10.10.  Migration
+
+   Certain HTTP implementations use the client address for logging or
+   access-control purposes.  Since a QUIC client's address might change
+   during a connection (and future versions might support simultaneous
+   use of multiple addresses), such implementations will need to either
+   actively retrieve the client's current address or addresses when they
+   are relevant or explicitly accept that the original address might
+   change.
+
+10.11.  Privacy Considerations
+
+   Several characteristics of HTTP/3 provide an observer an opportunity
+   to correlate actions of a single client or server over time.  These
+   include the value of settings, the timing of reactions to stimulus,
+   and the handling of any features that are controlled by settings.
+
+   As far as these create observable differences in behavior, they could
+   be used as a basis for fingerprinting a specific client.
+
+   HTTP/3's preference for using a single QUIC connection allows
+   correlation of a user's activity on a site.  Reusing connections for
+   different origins allows for correlation of activity across those
+   origins.
+
+   Several features of QUIC solicit immediate responses and can be used
+   by an endpoint to measure latency to their peer; this might have
+   privacy implications in certain scenarios.
+
+11.  IANA Considerations
+
+   This document registers a new ALPN protocol ID (Section 11.1) and
+   creates new registries that manage the assignment of codepoints in
+   HTTP/3.
+
+11.1.  Registration of HTTP/3 Identification String
+
+   This document creates a new registration for the identification of
+   HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol
+   IDs" registry established in [RFC7301].
+
+   The "h3" string identifies HTTP/3:
+
+   Protocol:  HTTP/3
+
+   Identification Sequence:  0x68 0x33 ("h3")
+
+   Specification:  This document
+
+
+
+Bishop                   Expires 5 December 2020               [Page 46]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+11.2.  New Registries
+
+   New registries created in this document operate under the QUIC
+   registration policy documented in Section 22.1 of [QUIC-TRANSPORT].
+   These registries all include the common set of fields listed in
+   Section 22.1.1 of [QUIC-TRANSPORT].
+
+   The initial allocations in these registries created in this document
+   are all assigned permanent status and list as contact both the IESG
+   (iesg@ietf.org) and the HTTP working group (ietf-http-wg@w3.org).
+
+11.2.1.  Frame Types
+
+   This document establishes a registry for HTTP/3 frame type codes.
+   The "HTTP/3 Frame Type" registry governs a 62-bit space.  This
+   registry follows the QUIC registry policy; see Section 11.2.
+   Permanent registrations in this registry are assigned using the
+   Specification Required policy [RFC8126], except for values between
+   0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
+   Standards Action or IESG Approval as defined in Section 4.9 and 4.10
+   of [RFC8126].
+
+   While this registry is separate from the "HTTP/2 Frame Type" registry
+   defined in [HTTP2], it is preferable that the assignments parallel
+   each other where the code spaces overlap.  If an entry is present in
+   only one registry, every effort SHOULD be made to avoid assigning the
+   corresponding value to an unrelated operation.
+
+   In addition to common fields as described in Section 11.2, permanent
+   registrations in this registry MUST include the following field:
+
+   Frame Type:  A name or label for the frame type.
+
+   Specifications of frame types MUST include a description of the frame
+   layout and its semantics, including any parts of the frame that are
+   conditionally present.
+
+   The entries in Table 2 are registered by this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 47]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+                 +--------------+-------+---------------+
+                 | Frame Type   | Value | Specification |
+                 +==============+=======+===============+
+                 | DATA         |  0x0  | Section 7.2.1 |
+                 +--------------+-------+---------------+
+                 | HEADERS      |  0x1  | Section 7.2.2 |
+                 +--------------+-------+---------------+
+                 | Reserved     |  0x2  | N/A           |
+                 +--------------+-------+---------------+
+                 | CANCEL_PUSH  |  0x3  | Section 7.2.3 |
+                 +--------------+-------+---------------+
+                 | SETTINGS     |  0x4  | Section 7.2.4 |
+                 +--------------+-------+---------------+
+                 | PUSH_PROMISE |  0x5  | Section 7.2.5 |
+                 +--------------+-------+---------------+
+                 | Reserved     |  0x6  | N/A           |
+                 +--------------+-------+---------------+
+                 | GOAWAY       |  0x7  | Section 7.2.6 |
+                 +--------------+-------+---------------+
+                 | Reserved     |  0x8  | N/A           |
+                 +--------------+-------+---------------+
+                 | Reserved     |  0x9  | N/A           |
+                 +--------------+-------+---------------+
+                 | MAX_PUSH_ID  |  0xD  | Section 7.2.7 |
+                 +--------------+-------+---------------+
+
+                   Table 2: Initial HTTP/3 Frame Types
+
+   Additionally, each code of the format "0x1f * N + 0x21" for non-
+   negative integer values of N (that is, 0x21, 0x40, ..., through
+   0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA.
+
+11.2.2.  Settings Parameters
+
+   This document establishes a registry for HTTP/3 settings.  The
+   "HTTP/3 Settings" registry governs a 62-bit space.  This registry
+   follows the QUIC registry policy; see Section 11.2.  Permanent
+   registrations in this registry are assigned using the Specification
+   Required policy [RFC8126], except for values between 0x00 and 0x3f
+   (in hexadecimal; inclusive), which are assigned using Standards
+   Action or IESG Approval as defined in Section 4.9 and 4.10 of
+   [RFC8126].
+
+   While this registry is separate from the "HTTP/2 Settings" registry
+   defined in [HTTP2], it is preferable that the assignments parallel
+   each other.  If an entry is present in only one registry, every
+   effort SHOULD be made to avoid assigning the corresponding value to
+   an unrelated operation.
+
+
+
+Bishop                   Expires 5 December 2020               [Page 48]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   In addition to common fields as described in Section 11.2, permanent
+   registrations in this registry MUST include the following fields:
+
+   Setting Name:  A symbolic name for the setting.  Specifying a setting
+      name is optional.
+
+   Default:  The value of the setting unless otherwise indicated.  A
+      default SHOULD be the most restrictive possible value.
+
+   The entries in Table 3 are registered by this document.
+
+     +------------------------+-------+-----------------+-----------+
+     | Setting Name           | Value | Specification   | Default   |
+     +========================+=======+=================+===========+
+     | Reserved               |  0x2  | N/A             | N/A       |
+     +------------------------+-------+-----------------+-----------+
+     | Reserved               |  0x3  | N/A             | N/A       |
+     +------------------------+-------+-----------------+-----------+
+     | Reserved               |  0x4  | N/A             | N/A       |
+     +------------------------+-------+-----------------+-----------+
+     | Reserved               |  0x5  | N/A             | N/A       |
+     +------------------------+-------+-----------------+-----------+
+     | MAX_FIELD_SECTION_SIZE |  0x6  | Section 7.2.4.1 | Unlimited |
+     +------------------------+-------+-----------------+-----------+
+
+                     Table 3: Initial HTTP/3 Settings
+
+   Additionally, each code of the format "0x1f * N + 0x21" for non-
+   negative integer values of N (that is, 0x21, 0x40, ..., through
+   0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA.
+
+11.2.3.  Error Codes
+
+   This document establishes a registry for HTTP/3 error codes.  The
+   "HTTP/3 Error Code" registry manages a 62-bit space.  This registry
+   follows the QUIC registry policy; see Section 11.2.  Permanent
+   registrations in this registry are assigned using the Specification
+   Required policy [RFC8126], except for values between 0x00 and 0x3f
+   (in hexadecimal; inclusive), which are assigned using Standards
+   Action or IESG Approval as defined in Section 4.9 and 4.10 of
+   [RFC8126].
+
+   Registrations for error codes are required to include a description
+   of the error code.  An expert reviewer is advised to examine new
+   registrations for possible duplication with existing error codes.
+   Use of existing registrations is to be encouraged, but not mandated.
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 49]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   In addition to common fields as described in Section 11.2, permanent
+   registrations in this registry MUST include the following fields:
+
+   Name:  A name for the error code.  Specifying an error code name is
+      optional.
+
+   Description:  A brief description of the error code semantics.
+
+   The entries in the Table 4 are registered by this document.
+
+   +---------------------------+--------+--------------+---------------+
+   | Name                      | Value  | Description  | Specification |
+   +===========================+========+==============+===============+
+   | H3_NO_ERROR               | 0x0100 | No error     | Section 8.1   |
+   +---------------------------+--------+--------------+---------------+
+   | H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General      | Section 8.1   |
+   |                           |        | protocol     |               |
+   |                           |        | error        |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_INTERNAL_ERROR         | 0x0102 | Internal     | Section 8.1   |
+   |                           |        | error        |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_STREAM_CREATION_ERROR  | 0x0103 | Stream       | Section 8.1   |
+   |                           |        | creation     |               |
+   |                           |        | error        |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical     | Section 8.1   |
+   |                           |        | stream was   |               |
+   |                           |        | closed       |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_FRAME_UNEXPECTED       | 0x0105 | Frame not    | Section 8.1   |
+   |                           |        | permitted    |               |
+   |                           |        | in the       |               |
+   |                           |        | current      |               |
+   |                           |        | state        |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_FRAME_ERROR            | 0x0106 | Frame        | Section 8.1   |
+   |                           |        | violated     |               |
+   |                           |        | layout or    |               |
+   |                           |        | size rules   |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_EXCESSIVE_LOAD         | 0x0107 | Peer         | Section 8.1   |
+   |                           |        | generating   |               |
+   |                           |        | excessive    |               |
+   |                           |        | load         |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_ID_ERROR               | 0x0108 | An           | Section 8.1   |
+   |                           |        | identifier   |               |
+
+
+
+Bishop                   Expires 5 December 2020               [Page 50]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   |                           |        | was used     |               |
+   |                           |        | incorrectly  |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_SETTINGS_ERROR         | 0x0109 | SETTINGS     | Section 8.1   |
+   |                           |        | frame        |               |
+   |                           |        | contained    |               |
+   |                           |        | invalid      |               |
+   |                           |        | values       |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_MISSING_SETTINGS       | 0x010A | No SETTINGS  | Section 8.1   |
+   |                           |        | frame        |               |
+   |                           |        | received     |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_REQUEST_REJECTED       | 0x010B | Request not  | Section 8.1   |
+   |                           |        | processed    |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_REQUEST_CANCELLED      | 0x010C | Data no      | Section 8.1   |
+   |                           |        | longer       |               |
+   |                           |        | needed       |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_REQUEST_INCOMPLETE     | 0x010D | Stream       | Section 8.1   |
+   |                           |        | terminated   |               |
+   |                           |        | early        |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_CONNECT_ERROR          | 0x010F | TCP reset    | Section 8.1   |
+   |                           |        | or error on  |               |
+   |                           |        | CONNECT      |               |
+   |                           |        | request      |               |
+   +---------------------------+--------+--------------+---------------+
+   | H3_VERSION_FALLBACK       | 0x0110 | Retry over   | Section 8.1   |
+   |                           |        | HTTP/1.1     |               |
+   +---------------------------+--------+--------------+---------------+
+
+                    Table 4: Initial HTTP/3 Error Codes
+
+   Additionally, each code of the format "0x1f * N + 0x21" for non-
+   negative integer values of N (that is, 0x21, 0x40, ..., through
+   0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 51]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+11.2.4.  Stream Types
+
+   This document establishes a registry for HTTP/3 unidirectional stream
+   types.  The "HTTP/3 Stream Type" registry governs a 62-bit space.
+   This registry follows the QUIC registry policy; see Section 11.2.
+   Permanent registrations in this registry are assigned using the
+   Specification Required policy [RFC8126], except for values between
+   0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
+   Standards Action or IESG Approval as defined in Section 4.9 and 4.10
+   of [RFC8126].
+
+   In addition to common fields as described in Section 11.2, permanent
+   registrations in this registry MUST include the following fields:
+
+   Stream Type:  A name or label for the stream type.
+
+   Sender:  Which endpoint on a connection may initiate a stream of this
+      type.  Values are "Client", "Server", or "Both".
+
+   Specifications for permanent registrations MUST include a description
+   of the stream type, including the layout semantics of the stream
+   contents.
+
+   The entries in the following table are registered by this document.
+
+            +----------------+-------+---------------+--------+
+            | Stream Type    | Value | Specification | Sender |
+            +================+=======+===============+========+
+            | Control Stream |  0x00 | Section 6.2.1 | Both   |
+            +----------------+-------+---------------+--------+
+            | Push Stream    |  0x01 | Section 4.4   | Server |
+            +----------------+-------+---------------+--------+
+
+                                  Table 5
+
+   Additionally, each code of the format "0x1f * N + 0x21" for non-
+   negative integer values of N (that is, 0x21, 0x40, ..., through
+   0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA.
+
+12.  References
+
+12.1.  Normative References
+
+   [ALTSVC]   Nottingham, M., McManus, P., and J. Reschke, "HTTP
+              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
+              April 2016, <https://www.rfc-editor.org/info/rfc7838>.
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 52]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   [CACHING]  Fielding, R., Nottingham, M., and J. Reschke, "HTTP
+              Caching", Work in Progress, Internet-Draft, draft-ietf-
+              httpbis-cache-08, 26 May 2020, <http://www.ietf.org/
+              internet-drafts/draft-ietf-httpbis-cache-08.txt>.
+
+   [HTTP-REPLAY]
+              Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
+              Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
+              2018, <https://www.rfc-editor.org/info/rfc8470>.
+
+   [QPACK]    Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
+              Header Compression for HTTP over QUIC", Work in Progress,
+              Internet-Draft, draft-ietf-quic-qpack-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-qpack-
+              latest>.
+
+   [QUIC-TRANSPORT]
+              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", Work in Progress,
+              Internet-Draft, draft-ietf-quic-transport-latest, 3 June
+              2020, <https://tools.ietf.org/html/draft-ietf-quic-
+              transport-latest>.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <https://www.rfc-editor.org/info/rfc793>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <https://www.rfc-editor.org/info/rfc6066>.
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 53]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
+              2011, <https://www.rfc-editor.org/info/rfc6125>.
+
+   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
+              DOI 10.17487/RFC6265, April 2011,
+              <https://www.rfc-editor.org/info/rfc6265>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8164]  Nottingham, M. and M. Thomson, "Opportunistic Security for
+              HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,
+              <https://www.rfc-editor.org/info/rfc8164>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [SEMANTICS]
+              Fielding, R., Nottingham, M., and J. Reschke, "HTTP
+              Semantics", Work in Progress, Internet-Draft, draft-ietf-
+              httpbis-semantics-08, 26 May 2020, <http://www.ietf.org/
+              internet-drafts/draft-ietf-httpbis-semantics-08.txt>.
+
+12.2.  Informative References
+
+   [BREACH]   Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
+              CRIME Attack", July 2013,
+              <http://breachattack.com/resources/
+              BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
+
+   [HPACK]    Peon, R. and H. Ruellan, "HPACK: Header Compression for
+              HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
+              <https://www.rfc-editor.org/info/rfc7541>.
+
+   [HTTP11]   Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1
+              Messaging", Work in Progress, Internet-Draft, draft-ietf-
+              httpbis-messaging-08, 26 May 2020, <http://www.ietf.org/
+              internet-drafts/draft-ietf-httpbis-messaging-08.txt>.
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 54]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   [HTTP2]    Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
+              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
+              DOI 10.17487/RFC7540, May 2015,
+              <https://www.rfc-editor.org/info/rfc7540>.
+
+   [RFC6585]  Nottingham, M. and R. Fielding, "Additional HTTP Status
+              Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
+              <https://www.rfc-editor.org/info/rfc6585>.
+
+   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
+              "Transport Layer Security (TLS) Application-Layer Protocol
+              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
+              July 2014, <https://www.rfc-editor.org/info/rfc7301>.
+
+   [TFO]      Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
+              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
+              <https://www.rfc-editor.org/info/rfc7413>.
+
+   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+Appendix A.  Considerations for Transitioning from HTTP/2
+
+   HTTP/3 is strongly informed by HTTP/2, and bears many similarities.
+   This section describes the approach taken to design HTTP/3, points
+   out important differences from HTTP/2, and describes how to map
+   HTTP/2 extensions into HTTP/3.
+
+   HTTP/3 begins from the premise that similarity to HTTP/2 is
+   preferable, but not a hard requirement.  HTTP/3 departs from HTTP/2
+   where QUIC differs from TCP, either to take advantage of QUIC
+   features (like streams) or to accommodate important shortcomings
+   (such as a lack of total ordering).  These differences make HTTP/3
+   similar to HTTP/2 in key aspects, such as the relationship of
+   requests and responses to streams.  However, the details of the
+   HTTP/3 design are substantially different than HTTP/2.
+
+   These departures are noted in this section.
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 55]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+A.1.  Streams
+
+   HTTP/3 permits use of a larger number of streams (2^62-1) than
+   HTTP/2.  The considerations about exhaustion of stream identifier
+   space apply, though the space is significantly larger such that it is
+   likely that other limits in QUIC are reached first, such as the limit
+   on the connection flow control window.
+
+   In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by
+   QUIC.  QUIC considers a stream closed when all data has been received
+   and sent data has been acknowledged by the peer.  HTTP/2 considers a
+   stream closed when the frame containing the END_STREAM bit has been
+   committed to the transport.  As a result, the stream for an
+   equivalent exchange could remain "active" for a longer period of
+   time.  HTTP/3 servers might choose to permit a larger number of
+   concurrent client-initiated bidirectional streams to achieve
+   equivalent concurrency to HTTP/2, depending on the expected usage
+   patterns.
+
+   Due to the presence of other unidirectional stream types, HTTP/3 does
+   not rely exclusively on the number of concurrent unidirectional
+   streams to control the number of concurrent in-flight pushes.
+   Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the
+   number of pushes received from an HTTP/3 server.
+
+A.2.  HTTP Frame Types
+
+   Many framing concepts from HTTP/2 can be elided on QUIC, because the
+   transport deals with them.  Because frames are already on a stream,
+   they can omit the stream number.  Because frames do not block
+   multiplexing (QUIC's multiplexing occurs below this layer), the
+   support for variable-maximum-length packets can be removed.  Because
+   stream termination is handled by QUIC, an END_STREAM flag is not
+   required.  This permits the removal of the Flags field from the
+   generic frame layout.
+
+   Frame payloads are largely drawn from [HTTP2].  However, QUIC
+   includes many features (e.g., flow control) which are also present in
+   HTTP/2.  In these cases, the HTTP mapping does not re-implement them.
+   As a result, several HTTP/2 frame types are not required in HTTP/3.
+   Where an HTTP/2-defined frame is no longer used, the frame ID has
+   been reserved in order to maximize portability between HTTP/2 and
+   HTTP/3 implementations.  However, even equivalent frames between the
+   two mappings are not identical.
+
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 56]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Many of the differences arise from the fact that HTTP/2 provides an
+   absolute ordering between frames across all streams, while QUIC
+   provides this guarantee on each stream only.  As a result, if a frame
+   type makes assumptions that frames from different streams will still
+   be received in the order sent, HTTP/3 will break them.
+
+   Some examples of feature adaptations are described below, as well as
+   general guidance to extension frame implementors converting an HTTP/2
+   extension to HTTP/3.
+
+A.2.1.  Prioritization Differences
+
+   HTTP/2 specifies priority assignments in PRIORITY frames and
+   (optionally) in HEADERS frames.  HTTP/3 does not provide a means of
+   signaling priority.
+
+   Note that while there is no explicit signaling for priority, this
+   does not mean that prioritization is not important for achieving good
+   performance.
+
+A.2.2.  Field Compression Differences
+
+   HPACK was designed with the assumption of in-order delivery.  A
+   sequence of encoded field sections must arrive (and be decoded) at an
+   endpoint in the same order in which they were encoded.  This ensures
+   that the dynamic state at the two endpoints remains in sync.
+
+   Because this total ordering is not provided by QUIC, HTTP/3 uses a
+   modified version of HPACK, called QPACK.  QPACK uses a single
+   unidirectional stream to make all modifications to the dynamic table,
+   ensuring a total order of updates.  All frames which contain encoded
+   fields merely reference the table state at a given time without
+   modifying it.
+
+   [QPACK] provides additional details.
+
+A.2.3.  Guidance for New Frame Type Definitions
+
+   Frame type definitions in HTTP/3 often use the QUIC variable-length
+   integer encoding.  In particular, Stream IDs use this encoding, which
+   allows for a larger range of possible values than the encoding used
+   in HTTP/2.  Some frames in HTTP/3 use an identifier rather than a
+   Stream ID (e.g., Push IDs).  Redefinition of the encoding of
+   extension frame types might be necessary if the encoding includes a
+   Stream ID.
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 57]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Because the Flags field is not present in generic HTTP/3 frames,
+   those frames which depend on the presence of flags need to allocate
+   space for flags as part of their frame payload.
+
+   Other than this issue, frame type HTTP/2 extensions are typically
+   portable to QUIC simply by replacing Stream 0 in HTTP/2 with a
+   control stream in HTTP/3.  HTTP/3 extensions will not assume
+   ordering, but would not be harmed by ordering, and would be portable
+   to HTTP/2 in the same manner.
+
+A.2.4.  Mapping Between HTTP/2 and HTTP/3 Frame Types
+
+   DATA (0x0):  Padding is not defined in HTTP/3 frames.  See
+      Section 7.2.1.
+
+   HEADERS (0x1):  The PRIORITY region of HEADERS is not defined in
+      HTTP/3 frames.  Padding is not defined in HTTP/3 frames.  See
+      Section 7.2.2.
+
+   PRIORITY (0x2):  As described in Appendix A.2.1, HTTP/3 does not
+      provide a means of signaling priority.
+
+   RST_STREAM (0x3):  RST_STREAM frames do not exist, since QUIC
+      provides stream lifecycle management.  The same code point is used
+      for the CANCEL_PUSH frame (Section 7.2.3).
+
+   SETTINGS (0x4):  SETTINGS frames are sent only at the beginning of
+      the connection.  See Section 7.2.4 and Appendix A.3.
+
+   PUSH_PROMISE (0x5):  The PUSH_PROMISE does not reference a stream;
+      instead the push stream references the PUSH_PROMISE frame using a
+      Push ID.  See Section 7.2.5.
+
+   PING (0x6):  PING frames do not exist, since QUIC provides equivalent
+      functionality.
+
+   GOAWAY (0x7):  GOAWAY does not contain an error code.  In the client
+      to server direction, it carries a Push ID instead of a server
+      initiated stream ID.  See Section 7.2.6.
+
+   WINDOW_UPDATE (0x8):  WINDOW_UPDATE frames do not exist, since QUIC
+      provides flow control.
+
+   CONTINUATION (0x9):  CONTINUATION frames do not exist; instead,
+      larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted.
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 58]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Frame types defined by extensions to HTTP/2 need to be separately
+   registered for HTTP/3 if still applicable.  The IDs of frames defined
+   in [HTTP2] have been reserved for simplicity.  Note that the frame
+   type space in HTTP/3 is substantially larger (62 bits versus 8 bits),
+   so many HTTP/3 frame types have no equivalent HTTP/2 code points.
+   See Section 11.2.1.
+
+A.3.  HTTP/2 SETTINGS Parameters
+
+   An important difference from HTTP/2 is that settings are sent once,
+   as the first frame of the control stream, and thereafter cannot
+   change.  This eliminates many corner cases around synchronization of
+   changes.
+
+   Some transport-level options that HTTP/2 specifies via the SETTINGS
+   frame are superseded by QUIC transport parameters in HTTP/3.  The
+   HTTP-level options that are retained in HTTP/3 have the same value as
+   in HTTP/2.
+
+   Below is a listing of how each HTTP/2 SETTINGS parameter is mapped:
+
+   SETTINGS_HEADER_TABLE_SIZE:  See [QPACK].
+
+   SETTINGS_ENABLE_PUSH:  This is removed in favor of the MAX_PUSH_ID
+      which provides a more granular control over server push.
+
+   SETTINGS_MAX_CONCURRENT_STREAMS:  QUIC controls the largest open
+      Stream ID as part of its flow control logic.  Specifying
+      SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error.
+
+   SETTINGS_INITIAL_WINDOW_SIZE:  QUIC requires both stream and
+      connection flow control window sizes to be specified in the
+      initial transport handshake.  Specifying
+      SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error.
+
+   SETTINGS_MAX_FRAME_SIZE:  This setting has no equivalent in HTTP/3.
+      Specifying it in the SETTINGS frame is an error.
+
+   SETTINGS_MAX_FIELD_SECTION_SIZE:  See Section 7.2.4.1.
+
+   In HTTP/3, setting values are variable-length integers (6, 14, 30, or
+   62 bits long) rather than fixed-length 32-bit fields as in HTTP/2.
+   This will often produce a shorter encoding, but can produce a longer
+   encoding for settings which use the full 32-bit space.  Settings
+   ported from HTTP/2 might choose to redefine their value to limit it
+   to 30 bits for more efficient encoding, or to make use of the 62-bit
+   space if more than 30 bits are required.
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 59]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   Settings need to be defined separately for HTTP/2 and HTTP/3.  The
+   IDs of settings defined in [HTTP2] have been reserved for simplicity.
+   Note that the settings identifier space in HTTP/3 is substantially
+   larger (62 bits versus 16 bits), so many HTTP/3 settings have no
+   equivalent HTTP/2 code point.  See Section 11.2.2.
+
+   As QUIC streams might arrive out-of-order, endpoints are advised to
+   not wait for the peers' settings to arrive before responding to other
+   streams.  See Section 7.2.4.2.
+
+A.4.  HTTP/2 Error Codes
+
+   QUIC has the same concepts of "stream" and "connection" errors that
+   HTTP/2 provides.  However, the differences between HTTP/2 and HTTP/3
+   mean that error codes are not directly portable between versions.
+
+   The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map
+   to the HTTP/3 error codes as follows:
+
+   NO_ERROR (0x0):  H3_NO_ERROR in Section 8.1.
+
+   PROTOCOL_ERROR (0x1):  This is mapped to H3_GENERAL_PROTOCOL_ERROR
+      except in cases where more specific error codes have been defined.
+      This includes H3_FRAME_UNEXPECTED and H3_CLOSED_CRITICAL_STREAM
+      defined in Section 8.1.
+
+   INTERNAL_ERROR (0x2):  H3_INTERNAL_ERROR in Section 8.1.
+
+   FLOW_CONTROL_ERROR (0x3):  Not applicable, since QUIC handles flow
+      control.
+
+   SETTINGS_TIMEOUT (0x4):  Not applicable, since no acknowledgement of
+      SETTINGS is defined.
+
+   STREAM_CLOSED (0x5):  Not applicable, since QUIC handles stream
+      management.
+
+   FRAME_SIZE_ERROR (0x6):  H3_FRAME_ERROR error code defined in
+      Section 8.1.
+
+   REFUSED_STREAM (0x7):  H3_REQUEST_REJECTED (in Section 8.1) is used
+      to indicate that a request was not processed.  Otherwise, not
+      applicable because QUIC handles stream management.
+
+   CANCEL (0x8):  H3_REQUEST_CANCELLED in Section 8.1.
+
+   COMPRESSION_ERROR (0x9):  Multiple error codes are defined in
+      [QPACK].
+
+
+
+Bishop                   Expires 5 December 2020               [Page 60]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   CONNECT_ERROR (0xa):  H3_CONNECT_ERROR in Section 8.1.
+
+   ENHANCE_YOUR_CALM (0xb):  H3_EXCESSIVE_LOAD in Section 8.1.
+
+   INADEQUATE_SECURITY (0xc):  Not applicable, since QUIC is assumed to
+      provide sufficient security on all connections.
+
+   H3_1_1_REQUIRED (0xd):  H3_VERSION_FALLBACK in Section 8.1.
+
+   Error codes need to be defined for HTTP/2 and HTTP/3 separately.  See
+   Section 11.2.3.
+
+A.4.1.  Mapping Between HTTP/2 and HTTP/3 Errors
+
+   An intermediary that converts between HTTP/2 and HTTP/3 may encounter
+   error conditions from either upstream.  It is useful to communicate
+   the occurrence of error to the downstream but error codes largely
+   reflect connection-local problems that generally do not make sense to
+   propagate.
+
+   An intermediary that encounters an error from an upstream origin can
+   indicate this by sending an HTTP status code such as 502, which is
+   suitable for a broad class of errors.
+
+   There are some rare cases where it is beneficial to propagate the
+   error by mapping it to the closest matching error type to the
+   receiver.  For example, an intermediary that receives an HTTP/2
+   stream error of type REFUSED_STREAM from the origin has a clear
+   signal that the request was not processed and that the request is
+   safe to retry.  Propagating this error condition to the client as an
+   HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to
+   take the action it deems most appropriate.  In the reverse direction
+   the intermediary might deem it beneficial to pass on client request
+   cancellations that are indicated by terminating a stream with
+   H3_REQUEST_CANCELLED.
+
+   Conversion between errors is described in the logical mapping.  The
+   error codes are defined in non-overlapping spaces in order to protect
+   against accidental conversion that could result in the use of
+   inappropriate or unknown error codes for the target version.  An
+   intermediary is permitted to promote stream errors to connection
+   errors but they should be aware of the cost to the connection for
+   what might be a temporary or intermittent error.
+
+Appendix B.  Change Log
+
+      *RFC Editor's Note:* Please remove this section prior to
+      publication of a final version of this document.
+
+
+
+Bishop                   Expires 5 December 2020               [Page 61]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+B.1.  Since draft-ietf-quic-http-27
+
+   *  Updated text to refer to latest HTTP revisions
+
+   *  Use the HTTP definition of authority for establishing and
+      coalescing connections (#253, #2223, #3558)
+
+   *  Define use of GOAWAY from both endpoints (#2632, #3129)
+
+   *  Require either :authority or Host if the URI scheme has a
+      mandatory authority component (#3408, #3475)
+
+B.2.  Since draft-ietf-quic-http-26
+
+   *  No changes
+
+B.3.  Since draft-ietf-quic-http-25
+
+   *  Require QUICv1 for HTTP/3 (#3117, #3323)
+
+   *  Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3275,
+      #3309)
+
+   *  Clarify the definition of "malformed" (#3352, #3345)
+
+B.4.  Since draft-ietf-quic-http-24
+
+   *  Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended
+      instead (#3130,#3208)
+
+   *  Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331)
+
+   *  Some error codes are reserved for greasing (#3325,#3360)
+
+B.5.  Since draft-ietf-quic-http-23
+
+   *  Removed "quic" Alt-Svc parameter (#3061,#3118)
+
+   *  Clients need not persist unknown settings for use in 0-RTT
+      (#3110,#3113)
+
+   *  Clarify error cases around CANCEL_PUSH (#2819,#3083)
+
+B.6.  Since draft-ietf-quic-http-22
+
+   *  Removed priority signaling (#2922,#2924)
+
+   *  Further changes to error codes (#2662,#2551):
+
+
+
+Bishop                   Expires 5 December 2020               [Page 62]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+      -  Error codes renumbered
+
+      -  HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR,
+         HTTP_ID_ERROR, and others
+
+   *  Clarify how unknown frame types interact with required frame
+      sequence (#2867,#2858)
+
+   *  Describe interactions with the transport in terms of defined
+      interface terms (#2857,#2805)
+
+   *  Require the use of the "http-opportunistic" resource (RFC 8164)
+      when scheme is "http" (#2439,#2973)
+
+   *  Settings identifiers cannot be duplicated (#2979)
+
+   *  Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945):
+
+      -  Servers must send all settings with non-default values in their
+         SETTINGS frame, even when resuming
+
+      -  If a client doesn't have settings associated with a 0-RTT
+         ticket, it uses the defaults
+
+      -  Servers can't accept early data if they cannot recover the
+         settings the client will have remembered
+
+   *  Clarify that Upgrade and the 101 status code are prohibited
+      (#2898,#2889)
+
+   *  Clarify that frame types reserved for greasing can occur on any
+      stream, but frame types reserved due to HTTP/2 correspondence are
+      prohibited (#2997,#2692,#2693)
+
+   *  Unknown error codes cannot be treated as errors (#2998,#2816)
+
+B.7.  Since draft-ietf-quic-http-21
+
+   No changes
+
+B.8.  Since draft-ietf-quic-http-20
+
+   *  Prohibit closing the control stream (#2509, #2666)
+
+   *  Change default priority to use an orphan node (#2502, #2690)
+
+   *  Exclusive priorities are restored (#2754, #2781)
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 63]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   *  Restrict use of frames when using CONNECT (#2229, #2702)
+
+   *  Close and maybe reset streams if a connection error occurs for
+      CONNECT (#2228, #2703)
+
+   *  Encourage provision of sufficient unidirectional streams for QPACK
+      (#2100, #2529, #2762)
+
+   *  Allow extensions to use server-initiated bidirectional streams
+      (#2711, #2773)
+
+   *  Clarify use of maximum header list size setting (#2516, #2774)
+
+   *  Extensive changes to error codes and conditions of their sending
+
+      -  Require connection errors for more error conditions (#2511,
+         #2510)
+
+      -  Updated the error codes for illegal GOAWAY frames (#2714,
+         #2707)
+
+      -  Specified error code for HEADERS on control stream (#2708)
+
+      -  Specified error code for servers receiving PUSH_PROMISE (#2709)
+
+      -  Specified error code for receiving DATA before HEADERS (#2715)
+
+      -  Describe malformed messages and their handling (#2410, #2764)
+
+      -  Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813)
+
+      -  Refactor Push ID related errors (#2818, #2820)
+
+      -  Rationalize HTTP/3 stream creation errors (#2821, #2822)
+
+B.9.  Since draft-ietf-quic-http-19
+
+   *  SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530)
+
+   *  Non-zero bits in the Empty field of the PRIORITY frame MAY be
+      treated as an error (#2501)
+
+B.10.  Since draft-ietf-quic-http-18
+
+   *  Resetting streams following a GOAWAY is recommended, but not
+      required (#2256,#2457)
+
+   *  Use variable-length integers throughout (#2437,#2233,#2253,#2275)
+
+
+
+Bishop                   Expires 5 December 2020               [Page 64]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+      -  Variable-length frame types, stream types, and settings
+         identifiers
+
+      -  Renumbered stream type assignments
+
+      -  Modified associated reserved values
+
+   *  Frame layout switched from Length-Type-Value to Type-Length-Value
+      (#2395,#2235)
+
+   *  Specified error code for servers receiving DUPLICATE_PUSH (#2497)
+
+   *  Use connection error for invalid PRIORITY (#2507, #2508)
+
+B.11.  Since draft-ietf-quic-http-17
+
+   *  HTTP_REQUEST_REJECTED is used to indicate a request can be retried
+      (#2106, #2325)
+
+   *  Changed error code for GOAWAY on the wrong stream (#2231, #2343)
+
+B.12.  Since draft-ietf-quic-http-16
+
+   *  Rename "HTTP/QUIC" to "HTTP/3" (#1973)
+
+   *  Changes to PRIORITY frame (#1865, #2075)
+
+      -  Permitted as first frame of request streams
+
+      -  Remove exclusive reprioritization
+
+      -  Changes to Prioritized Element Type bits
+
+   *  Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE
+      (#2072)
+
+   *  Set defaults for settings, allow request before receiving SETTINGS
+      (#1809, #1846, #2038)
+
+   *  Clarify message processing rules for streams that aren't closed
+      (#1972, #2003)
+
+   *  Removed reservation of error code 0 and moved HTTP_NO_ERROR to
+      this value (#1922)
+
+   *  Removed prohibition of zero-length DATA frames (#2098)
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 65]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+B.13.  Since draft-ietf-quic-http-15
+
+   Substantial editorial reorganization; no technical changes.
+
+B.14.  Since draft-ietf-quic-http-14
+
+   *  Recommend sensible values for QUIC transport parameters
+      (#1720,#1806)
+
+   *  Define error for missing SETTINGS frame (#1697,#1808)
+
+   *  Setting values are variable-length integers (#1556,#1807) and do
+      not have separate maximum values (#1820)
+
+   *  Expanded discussion of connection closure (#1599,#1717,#1712)
+
+   *  HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)
+
+B.15.  Since draft-ietf-quic-http-13
+
+   *  Reserved some frame types for grease (#1333, #1446)
+
+   *  Unknown unidirectional stream types are tolerated, not errors;
+      some reserved for grease (#1490, #1525)
+
+   *  Require settings to be remembered for 0-RTT, prohibit reductions
+      (#1541, #1641)
+
+   *  Specify behavior for truncated requests (#1596, #1643)
+
+B.16.  Since draft-ietf-quic-http-12
+
+   *  TLS SNI extension isn't mandatory if an alternative method is used
+      (#1459, #1462, #1466)
+
+   *  Removed flags from HTTP/3 frames (#1388, #1398)
+
+   *  Reserved frame types and settings for use in preserving
+      extensibility (#1333, #1446)
+
+   *  Added general error code (#1391, #1397)
+
+   *  Unidirectional streams carry a type byte and are extensible
+      (#910,#1359)
+
+   *  Priority mechanism now uses explicit placeholders to enable
+      persistent structure in the tree (#441,#1421,#1422)
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 66]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+B.17.  Since draft-ietf-quic-http-11
+
+   *  Moved QPACK table updates and acknowledgments to dedicated streams
+      (#1121, #1122, #1238)
+
+B.18.  Since draft-ietf-quic-http-10
+
+   *  Settings need to be remembered when attempting and accepting 0-RTT
+      (#1157, #1207)
+
+B.19.  Since draft-ietf-quic-http-09
+
+   *  Selected QCRAM for header compression (#228, #1117)
+
+   *  The server_name TLS extension is now mandatory (#296, #495)
+
+   *  Specified handling of unsupported versions in Alt-Svc (#1093,
+      #1097)
+
+B.20.  Since draft-ietf-quic-http-08
+
+   *  Clarified connection coalescing rules (#940, #1024)
+
+B.21.  Since draft-ietf-quic-http-07
+
+   *  Changes for integer encodings in QUIC (#595,#905)
+
+   *  Use unidirectional streams as appropriate (#515, #240, #281, #886)
+
+   *  Improvement to the description of GOAWAY (#604, #898)
+
+   *  Improve description of server push usage (#947, #950, #957)
+
+B.22.  Since draft-ietf-quic-http-06
+
+   *  Track changes in QUIC error code usage (#485)
+
+B.23.  Since draft-ietf-quic-http-05
+
+   *  Made push ID sequential, add MAX_PUSH_ID, remove
+      SETTINGS_ENABLE_PUSH (#709)
+
+   *  Guidance about keep-alive and QUIC PINGs (#729)
+
+   *  Expanded text on GOAWAY and cancellation (#757)
+
+B.24.  Since draft-ietf-quic-http-04
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 67]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   *  Cite RFC 5234 (#404)
+
+   *  Return to a single stream per request (#245,#557)
+
+   *  Use separate frame type and settings registries from HTTP/2 (#81)
+
+   *  SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)
+
+   *  Restored GOAWAY (#696)
+
+   *  Identify server push using Push ID rather than a stream ID
+      (#702,#281)
+
+   *  DATA frames cannot be empty (#700)
+
+B.25.  Since draft-ietf-quic-http-03
+
+   None.
+
+B.26.  Since draft-ietf-quic-http-02
+
+   *  Track changes in transport draft
+
+B.27.  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)
+
+
+
+Bishop                   Expires 5 December 2020               [Page 68]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+B.28.  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)
+
+B.29.  Since draft-shade-quic-http2-mapping-00
+
+   *  Adopted as base for draft-ietf-quic-http
+
+   *  Updated authors/editors list
+
+Acknowledgements
+
+   The original authors of this specification were Robbie Shade and Mike
+   Warres.
+
+   The IETF QUIC Working Group received an enormous amount of support
+   from many people.  Among others, the following people provided
+   substantial contributions to this document:
+
+   *  Bence Beky
+
+   *  Daan De Meyer
+
+   *  Martin Duke
+
+   *  Roy Fielding
+
+   *  Alan Frindell
+
+   *  Alessandro Ghedini
+
+   *  Nick Harper
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 69]
+
+Internet-Draft                   HTTP/3                        June 2020
+
+
+   *  Ryan Hamilton
+
+   *  Christian Huitema
+
+   *  Subodh Iyengar
+
+   *  Robin Marx
+
+   *  Patrick McManus
+
+   *  Luca Nicco
+
+   *  奥 一穂 (Kazuho Oku)
+
+   *  Lucas Pardue
+
+   *  Roberto Peon
+
+   *  Julian Reschke
+
+   *  Eric Rescorla
+
+   *  Martin Seemann
+
+   *  Ben Schwartz
+
+   *  Ian Swett
+
+   *  Willy Taureau
+
+   *  Martin Thomson
+
+   *  Dmitri Tikhonov
+
+   *  Tatsuhiro Tsujikawa
+
+   A portion of Mike's contribution was supported by Microsoft during
+   his employment there.
+
+Author's Address
+
+   Mike Bishop (editor)
+   Akamai
+
+   Email: mbishop@evequefou.be
+
+
+
+
+
+
+Bishop                   Expires 5 December 2020               [Page 70]
diff --git a/jri/mustnot/draft-ietf-quic-invariants.html b/jri/mustnot/draft-ietf-quic-invariants.html
new file mode 100644
index 0000000000..54a7d3f3d2
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-invariants.html
@@ -0,0 +1,1395 @@
+<!DOCTYPE html>
+<html lang="en" class="Internet-Draft">
+<head>
+<meta charset="utf-8">
+<meta content="Common,Latin" name="scripts">
+<meta content="initial-scale=1.0" name="viewport">
+<title>Version-Independent Properties of QUIC</title>
+<meta content="Martin Thomson" name="author">
+<meta content="
+       This document defines the properties of the QUIC transport protocol that are
+expected to remain unchanged over time as new versions of the protocol are
+developed. 
+    " name="description">
+<meta content="xml2rfc 2.45.2" name="generator">
+<meta content="draft-ietf-quic-invariants-latest" name="ietf.draft">
+<link href="draft-ietf-quic-invariants.xml" rel="alternate" type="application/rfc+xml">
+<link href="#copyright" rel="license">
+<style type="text/css">@import url('https://martinthomson.github.io/i-d-template/fonts.css');
+
+html {
+  --background-color: #fff;
+  --text-color: #222;
+  --title-color: #191919;
+  --link-color: #2a6496;
+  --highlight-color: #f9f9f9;
+  --line-color: #eee;
+  --small-font-size: 14.5px;
+}
+body {
+  max-width: 600px;
+  margin: 75px auto;
+  padding: 0 5px;
+  color: var(--text-color);
+  background-color: var(--background-color);
+  font: 16px/22px "Lora", serif;
+  scroll-behavior: smooth;
+}
+
+.ears {
+  display: none;
+}
+
+/* headings */
+#title, h1, h2, h3, h4, h5, h6 {
+  font-family: "Cabin Condensed", sans-serif;
+  font-weight: 600;
+  margin: 0.8em 0 0.3em;
+  font-size-adjust: 0.5;
+  color: var(--title-color);
+}
+#title {
+  padding: 1em 0 0.2em;
+  font-size: 32px;
+  line-height: 40px;
+  clear: both;
+}
+h1, h2, h3 {
+  font-size: 22px;
+  line-height: 26px;
+}
+h4, h5, h6 {
+  font-size: 18px;
+  line-height: 22px;
+}
+
+/* general structure */
+.author {
+  padding-bottom: 0.3em;
+}
+#abstract+p, #abstract+p code, #abstract+p samp, #abstract+p tt {
+  font-size: 18px;
+  line-height: 24px;
+}
+p {
+  padding: 0;
+  margin: 0.5em 0;
+  text-align: left;
+}
+div, span {
+  position: relative;
+}
+div {
+  margin: 0;
+}
+.alignRight.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignRight.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignRight {
+  margin: 1em 0;
+}
+.alignRight > *:first-child {
+  border: none;
+  margin: 0;
+  float: right;
+  clear: both;
+}
+.alignRight > *:nth-child(2) {
+  clear: both;
+  display: block;
+  border: none;
+}
+svg {
+  display: block;
+}
+.alignCenter.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignCenter.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignCenter {
+  margin: 1em 0;
+}
+.alignCenter > *:first-child {
+  border: none;
+  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
+     support flexbox yet.
+  */
+  display: table;
+  margin: 0 auto;
+}
+
+/* lists */
+ol, ul {
+  padding: 0;
+  margin: 0 0 1em 2em;
+}
+ol ol, ul ul, ol ul, ul ol {
+  margin-left: 1em;
+}
+li {
+  margin: 0 0 0.25em 0;
+}
+.ulCompact li {
+  margin: 0;
+}
+ul.empty, .ulEmpty {
+  list-style-type: none;
+}
+ul.empty li, .ulEmpty li {
+  margin-top: 0.5em;
+}
+ul.compact, .ulCompact,
+ol.compact, .olCompact {
+  line-height: 100%;
+  margin: 0 0 0 2em;
+}
+
+/* definition lists */
+dl {
+}
+dl > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl > dd {
+  margin-bottom: .8em;
+  min-height: 1.3em;
+}
+dl.compact > dd, .dlCompact > dd {
+  margin-bottom: 0em;
+}
+dl > dd > dl {
+  margin-top: 0.5em;
+  margin-bottom: 0em;
+}
+dd.break {
+  display: none;
+}
+
+/* links */
+a, a[href].selfRef:hover {
+  text-decoration: none;
+}
+a[href].selfRef {
+  color: var(--text-color);
+}
+a[href] {
+  color: var(--link-color);
+}
+a[href]:hover {
+  text-decoration: underline;
+}
+a[href].selfRef:hover {
+  background-color: var(--highlight-color);
+}
+a.xref {
+  white-space: nowrap;
+}
+
+/* Figures */
+tt, code, pre {
+  background-color: var(--highlight-color);
+  font: 14px/22px 'Oxygen Mono', monospace;
+}
+pre {
+  border: 1px solid var(--line-color);
+  font-size: 13.5px;
+  line-height: 16px;
+  letter-spacing: -0.2px;
+  margin: 5px;
+  padding: 5px;
+}
+img {
+  max-width: 100%;
+}
+figure {
+  margin: 0.5em 0;
+}
+figure blockquote {
+  margin: 0.8em 0.4em 0.4em;
+}
+figcaption, caption {
+  font-style: italic;
+  margin: 0.5em 1.5em;
+  text-align: left;
+}
+@media screen {
+  pre {
+    display: inline-block;
+    overflow-x: auto;
+    max-width: 100%;
+    width: calc(100% - 22px - 1em);
+  }
+  figure pre {
+    display: block;
+    width: calc(100% - 25px);
+  }
+  pre + .pilcrow {
+    display: inline-block;
+    vertical-align: text-bottom;
+    padding-bottom: 8px;
+  }
+  table {
+    display: inline-block;
+    overflow-x: auto;
+  }
+}
+
+/* aside, blockquote */
+aside, blockquote {
+  margin-left: 0;
+  padding: 0 2em;
+  font-style: italic;
+}
+blockquote {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  margin: 1em 0;
+}
+cite {
+  display: block;
+  text-align: right;
+  font-style: italic;
+}
+
+/* tables */
+table {
+  width: 100%;
+  margin: 0 0 1em;
+  border-collapse: collapse;
+}
+thead, tbody {
+  border: 1px solid var(--line-color);
+}
+th, td {
+  text-align: left;
+  vertical-align: top;
+  padding: 5px 10px;
+}
+th {
+  text-align: left;
+  background-color: #eee;
+}
+tr:nth-child(2n) > td {
+  background-color: var(--background-color);
+}
+tr:nth-child(2n+1) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n+1) > td {
+  background-color: var(--background-color);
+}
+table caption {
+  margin: 0;
+  padding: 3px 1em;
+}
+table p {
+  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
+     be allowed within tables more generally, it would be far better to select on a class. */
+  margin: 0;
+}
+
+/* pilcrow */
+a.pilcrow {
+  margin-left: 3px;
+  visibility: hidden;
+  user-select: none;
+}
+a.pilcrow[href] { color: #ddd; }
+a.pilcrow[href]:hover { text-decoration: none; }
+@media screen {
+  :hover > a.pilcrow {
+    visibility: visible;
+  }
+  a.pilcrow:hover {
+    background-color: transparent;
+  }
+}
+
+/* misc */
+hr {
+  border: 0;
+  border-top: 1px solid var(--line-color);
+}
+.bcp14 {
+  font-variant: small-caps;
+}
+
+.role {
+  font-variant: all-small-caps;
+}
+
+/* info block */
+#identifiers {
+  margin: 0;
+  font-size: var(--small-font-size);
+  line-height: 18px;
+  --identifier-width: 8em;
+}
+#identifiers dt {
+  width: var(--identifier-width);
+  margin: 0;
+  clear: left;
+  float: left;
+  text-align: right;
+}
+#identifiers dd {
+  margin: 0 0 0 calc(1em + var(--identifier-width));
+  min-width: 5em;
+}
+#identifiers .authors .author {
+  display: inline-block;
+  margin-right: 1.5em;
+}
+#identifiers .authors .org {
+  font-style: italic;
+}
+
+/* The prepared/rendered info at the very bottom of the page */
+.docInfo {
+  color: #999;
+  font-size: 0.9em;
+  font-style: italic;
+  margin-top: 2em;
+}
+.docInfo .prepared {
+  float: left;
+}
+.docInfo .prepared {
+  float: right;
+}
+
+/* table of contents */
+#toc {
+  padding: 0.75em 0 2em 0;
+  margin-bottom: 1em;
+}
+#toc nav ul {
+  margin: 0 0.5em 0 0;
+  padding: 0;
+  list-style: none;
+}
+#toc nav li {
+  line-height: 1.3em;
+  margin: 0.75em 0;
+  padding-left: 1.2em;
+  text-indent: -1.2em;
+}
+#toc a.xref {
+  white-space: normal;
+}
+/* references */
+.references dt {
+  text-align: right;
+  font-weight: bold;
+  min-width: 7em;
+}
+.references dd {
+  margin-left: 8em;
+  overflow: auto;
+}
+
+.refInstance {
+  margin-bottom: 1.25em;
+}
+
+.references .ascii {
+  margin-bottom: 0.25em;
+}
+
+/* index */
+.index ul {
+  margin: 0 0 0 1em;
+  padding: 0;
+  list-style: none;
+}
+.index ul ul {
+  margin: 0;
+}
+.index li {
+  margin: 0;
+  text-indent: -2em;
+  padding-left: 2em;
+  padding-bottom: 5px;
+}
+.indexIndex {
+  margin: 0.5em 0 1em;
+}
+.index a {
+  font-weight: 700;
+}
+/* make the index two-column on all but the smallest screens */
+@media (min-width: 500px) {
+  .index ul {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  .index ul ul {
+    column-count: 1;
+    column-gap: 0;
+  }
+}
+
+/* authors */
+address.vcard {
+  font-style: normal;
+  margin: 1em 0;
+}
+address.vcard .nameRole {
+  font-weight: 700;
+  margin-left: 0;
+}
+address.vcard .label {
+  margin: 0.5em 0;
+}
+address.vcard .type {
+  display: none;
+}
+.alternative-contact {
+  margin: 1.5em 0 1em;
+}
+hr.addr {
+  border-top: 1px dashed;
+  margin: 0;
+  color: #ddd;
+  max-width: calc(100% - 16px);
+}
+@media (min-width: 500px) {
+  #authors-addresses > section {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  #authors-addresses > section > h2 {
+    column-span: all;
+  }
+  /* hack for break-inside: avoid-column */
+  #authors-addresses address {
+    display: inline-block;
+    break-inside: avoid-column;
+  }
+}
+
+.rfcEditorRemove p:first-of-type {
+  font-style: italic;
+}
+.cref {
+  background-color: rgba(249, 232, 105, 0.3);
+  padding: 2px 4px;
+}
+.crefSource {
+  font-style: italic;
+}
+/* alternative layout for smaller screens */
+@media screen and (max-width: 929px) {
+  #toc {
+    position: fixed;
+    z-index: 2;
+    top: 0;
+    right: 0;
+    padding: 0;
+    margin: 0;
+    border-bottom: 1px solid #ccc;
+    opacity: 0.6;
+  }
+  #toc.active {
+      opacity: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 2px 0 2px 6px;
+    padding-right: 1em;
+    font-size: 18px;
+    line-height: 24px;
+    min-width: 190px;
+    text-align: right;
+    background-color: #444;
+    color: white;
+    cursor: pointer;
+  }
+  #toc h2::before { /* css hamburger */
+    float: right;
+    position: relative;
+    width: 1em;
+    height: 1px;
+    left: -164px;
+    margin: 8px 0 0 0;
+    background: white none repeat scroll 0 0;
+    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
+    content: "";
+  }
+  #toc nav {
+    display: none;
+    background-color: var(--background-color);
+    padding: 0.5em 1em 1em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    height: calc(100vh - 48px);
+    border-left: 1px solid #ddd;
+  }
+  #toc.active nav {
+    display: block;
+  }
+  /* Make the collapsed ToC header render white on gray also when it's a link */
+  #toc h2 a,
+  #toc h2 a:link,
+  #toc h2 a:focus,
+  #toc h2 a:hover,
+  #toc a.toplink,
+  #toc a.toplink:hover {
+    color: white;
+    background-color: #444;
+    text-decoration: none;
+  }
+  #toc a.toplink {
+    margin-top: 2px;
+  }
+}
+
+/* alternative layout for wide screens */
+@media screen and (min-width: 930px) {
+  body {
+    padding-right: 360px;
+    padding-right: calc(min(180px + 20%, 500px));
+  }
+  #toc {
+    position: fixed;
+    bottom: 0;
+    right: 0;
+    right: calc(50vw - 480px);
+    width: 312px;
+    margin: 0;
+    padding: 0;
+    z-index: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 0.25em 1em 1em 0;
+  }
+  #toc nav {
+    display: block;
+    height: calc(90vh - 84px);
+    bottom: 0;
+    padding: 0.5em 0 2em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    scrollbar-width: thin;
+  }
+  #toc nav > ul  {
+    margin-bottom: 2em;
+  }
+  #toc ul {
+    margin: 0 0 0 4px;
+    font-size: var(--small-font-size);
+  }
+  #toc ul p, #toc ul li {
+    margin: 2px 0;
+    line-height: 22px;
+  }
+  img { /* future proofing */
+    max-width: 100%;
+    height: auto;
+  }
+}
+
+/* pagination */
+@media print {
+  body {
+    width: 100%;
+  }
+  p {
+    orphans: 3;
+    widows: 3;
+  }
+  #n-copyright-notice {
+    border-bottom: none;
+  }
+  #toc, #n-introduction {
+    page-break-before: always;
+  }
+  #toc {
+    border-top: none;
+    padding-top: 0;
+  }
+  figure, pre {
+    page-break-inside: avoid;
+  }
+  figure {
+    overflow: scroll;
+  }
+  h1, h2, h3, h4, h5, h6 {
+    page-break-after: avoid;
+  }
+  h2+*, h3+*, h4+*, h5+*, h6+* {
+    page-break-before: avoid;
+  }
+  pre {
+    white-space: pre-wrap;
+    word-wrap: break-word;
+    font-size: 10pt;
+  }
+  table {
+    border: 1px solid #ddd;
+  }
+  td {
+    border-top: 1px solid #ddd;
+  }
+}
+
+@page :first {
+  padding-top: 0;
+  @top-left {
+    content: normal;
+    border: none;
+  }
+  @top-center {
+    content: normal;
+    border: none;
+  }
+  @top-right {
+    content: normal;
+    border: none;
+  }
+}
+
+@page {
+  size: A4;
+  margin-bottom: 45mm;
+  padding-top: 20px;
+}
+
+/* Changes introduced to fix issues found during implementation */
+
+/* Separate body from document info even without intervening H1 */
+section {
+  clear: both;
+}
+
+/* Top align author divs, to avoid names without organization dropping level with org names */
+.author {
+  vertical-align: top;
+}
+
+/* Style section numbers with more space between number and title */
+.section-number {
+  padding-right: 0.5em;
+}
+
+/* Add styling for a link in the ToC that points to the top of the document */
+a.toplink {
+  float: right;
+  margin: 8px 0.5em 0;
+}
+
+/* Fix the dl styling to match the RFC 7992 attributes */
+dl > dt,
+dl.dlParallel > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl.dlNewline > dt {
+  float: none;
+}
+
+/* Provide styling for table cell text alignment */
+table .text-left, table .text-left {
+  text-align: left;
+}
+table .text-center, table .text-center {
+  text-align: center;
+}
+table .text-right, table .text-right {
+  text-align: right;
+}
+
+/* Make the alternative author contact information look less like just another
+   author, and group it closer with the primary author contact information */
+.alternative-contact {
+  margin: 0.5em 0 0.25em 0;
+}
+address .non-ascii {
+  margin: 0 0 0 2em;
+}
+
+/* With it being possible to set tables with alignment
+  left, center, and right, { width: 100%; } does not make sense */
+table {
+  width: auto;
+}
+
+/* Avoid reference text that sits in a block with very wide left margin,
+   because of a long floating dt label.*/
+.references dd {
+  overflow: visible;
+}
+
+/* Control caption placement */
+caption {
+  caption-side: bottom;
+}
+
+/* Limit the width of the author address vcard, so names in right-to-left
+   script don't end up on the other side of the page. */
+
+address.vcard {
+  max-width: 20em;
+  margin-right: auto;
+}
+
+/* For address alignment dependent on LTR or RTL scripts */
+address div.left {
+  text-align: left;
+}
+address div.right {
+  text-align: right;
+}
+
+/* Provide table alignment support.  We can't use the alignX classes above
+   since they do unwanted things with caption and other styling. */
+table.right {
+ margin-left: auto;
+ margin-right: 0;
+}
+table.center {
+ margin-left: auto;
+ margin-right: auto;
+}
+table.left {
+ margin-left: 0;
+ margin-right: auto;
+}
+
+/* Give the table caption label the same styling as the figcaption */
+
+@media print {
+  .toplink {
+    display: none;
+  }
+
+  /* avoid overwriting the top border line with the ToC header */
+  #toc {
+    padding-top: 1px;
+  }
+
+  /* Avoid page breaks inside dl and author address entries */
+  dd {
+    page-break-before: avoid;
+  }
+  .vcard {
+    page-break-inside: avoid;
+  }
+
+}
+/* Tweak the bcp14 keyword presentation */
+.bcp14 {
+  font-variant: small-caps;
+  font-weight: bold;
+  font-size: 0.9em;
+}
+</style>
+<link href="rfc-local.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<table class="ears">
+<thead><tr>
+<td class="left">Internet-Draft</td>
+<td class="center">QUIC Invariants</td>
+<td class="right">June 2020</td>
+</tr></thead>
+<tfoot><tr>
+<td class="left">Thomson</td>
+<td class="center">Expires 5 December 2020</td>
+<td class="right">[Page]</td>
+</tr></tfoot>
+</table>
+<div id="external-metadata" class="document-information"></div>
+<div id="internal-metadata" class="document-information">
+<dl id="identifiers">
+<dt class="label-workgroup">Workgroup:</dt>
+<dd class="workgroup">QUIC</dd>
+<dt class="label-internet-draft">Internet-Draft:</dt>
+<dd class="internet-draft">draft-ietf-quic-invariants-latest</dd>
+<dt class="label-published">Published:</dt>
+<dd class="published">
+<time datetime="2020-06-03" class="published">3 June 2020</time>
+    </dd>
+<dt class="label-intended-status">Intended Status:</dt>
+<dd class="intended-status">Standards Track</dd>
+<dt class="label-expires">Expires:</dt>
+<dd class="expires"><time datetime="2020-12-05">5 December 2020</time></dd>
+<dt class="label-authors">Author:</dt>
+<dd class="authors">
+<div class="author">
+      <div class="author-name">M. Thomson</div>
+<div class="org">Mozilla</div>
+</div>
+</dd>
+</dl>
+</div>
+<h1 id="title">Version-Independent Properties of QUIC</h1>
+<section id="section-abstract">
+      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
+<p id="section-abstract-1">This document defines the properties of the QUIC transport protocol that are
+expected to remain unchanged over time as new versions of the protocol are
+developed.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.1">
+      <h2 id="name-note-to-readers">
+<a href="#name-note-to-readers" class="section-name selfRef">Note to Readers</a>
+      </h2>
+<p id="section-note.1-1">Discussion of this draft takes place on the QUIC working group mailing list
+(<a href="mailto:quic@ietf.org">quic@ietf.org</a>), which is archived at
+<span><a href="https://mailarchive.ietf.org/arch/search/?email_list=quic">https://mailarchive.ietf.org/arch/search/?email_list=quic</a></span>.<a href="#section-note.1-1" class="pilcrow">¶</a></p>
+<p id="section-note.1-2">Working Group information can be found at <span><a href="https://github.com/quicwg">https://github.com/quicwg</a></span>; source
+code and issues list for this draft can be found at
+<span><a href="https://github.com/quicwg/base-drafts/labels/-invariants">https://github.com/quicwg/base-drafts/labels/-invariants</a></span>.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
+</section>
+<div id="status-of-memo">
+<section id="section-boilerplate.1">
+        <h2 id="name-status-of-this-memo">
+<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
+        </h2>
+<p id="section-boilerplate.1-1">
+        This Internet-Draft is submitted in full conformance with the
+        provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-2">
+        Internet-Drafts are working documents of the Internet Engineering Task
+        Force (IETF). Note that other groups may also distribute working
+        documents as Internet-Drafts. The list of current Internet-Drafts is
+        at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-3">
+        Internet-Drafts are draft documents valid for a maximum of six months
+        and may be updated, replaced, or obsoleted by other documents at any
+        time. It is inappropriate to use Internet-Drafts as reference
+        material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-4">
+        This Internet-Draft will expire on 5 December 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="copyright">
+<section id="section-boilerplate.2">
+        <h2 id="name-copyright-notice">
+<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
+        </h2>
+<p id="section-boilerplate.2-1">
+            Copyright (c) 2020 IETF Trust and the persons identified as the
+            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.2-2">
+            This document is subject to BCP 78 and the IETF Trust's Legal
+            Provisions Relating to IETF Documents
+            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
+            publication of this document. Please review these documents
+            carefully, as they describe your rights and restrictions with
+            respect to this document. Code Components extracted from this
+            document must include Simplified BSD License text as described in
+            Section 4.e of the Trust Legal Provisions and are provided without
+            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="toc">
+<section id="section-toc.1">
+        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
+<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
+        </h2>
+<nav class="toc"><ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-definitions" class="xref">Conventions and Definitions</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-an-extremely-abstract-descr" class="xref">An Extremely Abstract Description of QUIC</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-notational-conventions" class="xref">Notational Conventions</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-quic-packet-headers" class="xref">QUIC Packet Headers</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.1">
+                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-long-header" class="xref">Long Header</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.2">
+                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-short-header" class="xref">Short Header</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.3">
+                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-connection-id" class="xref">Connection ID</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.4">
+                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-version" class="xref">Version</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-version-negotiation" class="xref">Version Negotiation</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-and-privacy-consid" class="xref">Security and Privacy Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty toc compact">
+<li class="ulEmpty toc compact" id="section-toc.1-1.9.2.1">
+                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.9.2.2">
+                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-incorrect-assumptions" class="xref">Incorrect Assumptions</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty toc compact" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</nav>
+</section>
+</div>
+<div id="introduction">
+<section id="section-1">
+      <h2 id="name-introduction">
+<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
+      </h2>
+<p id="section-1-1">In addition to providing secure, multiplexed transport, QUIC <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>
+includes the ability to negotiate a version.  This allows the protocol to change
+over time in response to new requirements.  Many characteristics of the protocol
+will change between versions.<a href="#section-1-1" class="pilcrow">¶</a></p>
+<p id="section-1-2">This document describes the subset of QUIC that is intended to remain stable as
+new versions are developed and deployed.  All of these invariants are
+IP-version-independent.<a href="#section-1-2" class="pilcrow">¶</a></p>
+<p id="section-1-3">The primary goal of this document is to ensure that it is possible to deploy new
+versions of QUIC.  By documenting the properties that can't change, this
+document aims to preserve the ability to change any other aspect of the
+protocol.  Thus, unless specifically described in this document, any aspect of
+the protocol can change between different versions.<a href="#section-1-3" class="pilcrow">¶</a></p>
+<p id="section-1-4"><a href="#bad-assumptions" class="xref">Appendix A</a> is a non-exhaustive list of some incorrect assumptions that
+might be made based on knowledge of QUIC version 1; these do not apply to every
+version of QUIC.<a href="#section-1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="conventions-and-definitions">
+<section id="section-2">
+      <h2 id="name-conventions-and-definitions">
+<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-definitions" class="section-name selfRef">Conventions and Definitions</a>
+      </h2>
+<p id="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
+"MAY", and "OPTIONAL" in this document are to be interpreted as
+described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they
+appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
+<p id="section-2-2">This document uses terms and notational conventions from <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="an-extremely-abstract-description-of-quic">
+<section id="section-3">
+      <h2 id="name-an-extremely-abstract-descr">
+<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-an-extremely-abstract-descr" class="section-name selfRef">An Extremely Abstract Description of QUIC</a>
+      </h2>
+<p id="section-3-1">QUIC is a connection-oriented protocol between two endpoints.  Those endpoints
+exchange UDP datagrams.  These UDP datagrams contain QUIC packets.  QUIC
+endpoints use QUIC packets to establish a QUIC connection, which is shared
+protocol state between those endpoints.<a href="#section-3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="notational-conventions">
+<section id="section-4">
+      <h2 id="name-notational-conventions">
+<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-notational-conventions" class="section-name selfRef">Notational Conventions</a>
+      </h2>
+<p id="section-4-1">Packet diagrams in this document use a format defined in <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> to
+illustrate the order and size of fields.<a href="#section-4-1" class="pilcrow">¶</a></p>
+<p id="section-4-2">Complex fields are named and then followed by a list of fields surrounded by a
+pair of matching braces. Each field in this list is separated by commas.<a href="#section-4-2" class="pilcrow">¶</a></p>
+<p id="section-4-3">Individual fields include length information, plus indications about fixed
+value, optionality, or repetitions. Individual fields use the following
+notational conventions, with all lengths in bits:<a href="#section-4-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-4-4">
+        <dt id="section-4-4.1">x (A):</dt>
+<dd id="section-4-4.2">
+  Indicates that x is A bits long<a href="#section-4-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4-4.3">x (A..B):</dt>
+<dd id="section-4-4.4">
+  Indicates that x can be any length from A to B; A can be omitted to indicate
+a minimum of zero bits and B can be omitted to indicate no set upper limit;
+values in this format always end on an octet boundary<a href="#section-4-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4-4.5">x (?) = C:</dt>
+<dd id="section-4-4.6">
+  Indicates that x has a fixed value of C<a href="#section-4-4.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-4-4.7">x (E) ...:</dt>
+<dd id="section-4-4.8">
+  Indicates that x is repeated zero or more times (and that each instance is
+length E)<a href="#section-4-4.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-4-5"><a href="#fig-ex-format" class="xref">Figure 1</a> shows an example structure:<a href="#section-4-5" class="pilcrow">¶</a></p>
+<span id="name-example-format"></span><div id="fig-ex-format">
+<figure id="figure-1">
+        <div class="artwork art-text alignLeft" id="section-4-6.1">
+<pre>
+Example Structure {
+  One-bit Field (1),
+  7-bit Field with Fixed Value (7) = 61,
+  Arbitrary-Length Field (..),
+  Variable-Length Field (8..24),
+  Repeated Field (8) ...,
+}
+</pre>
+</div>
+<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
+<a href="#name-example-format" class="selfRef">Example Format</a>
+        </figcaption></figure>
+</div>
+</section>
+</div>
+<div id="quic-packet-headers">
+<section id="section-5">
+      <h2 id="name-quic-packet-headers">
+<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-quic-packet-headers" class="section-name selfRef">QUIC Packet Headers</a>
+      </h2>
+<p id="section-5-1">QUIC endpoints exchange UDP datagrams that contain one or more QUIC packets.
+This section describes the invariant characteristics of a QUIC packet.  A
+version of QUIC could permit multiple QUIC packets in a single UDP datagram, but
+the invariant properties only describe the first packet in a datagram.<a href="#section-5-1" class="pilcrow">¶</a></p>
+<p id="section-5-2">QUIC defines two types of packet header: long and short.  Packets with long
+headers are identified by the most significant bit of the first byte being set;
+packets with a short header have that bit cleared.<a href="#section-5-2" class="pilcrow">¶</a></p>
+<p id="section-5-3">Aside from the values described here, the payload of QUIC packets is
+version-specific and of arbitrary length.<a href="#section-5-3" class="pilcrow">¶</a></p>
+<div id="long-header">
+<section id="section-5.1">
+        <h3 id="name-long-header">
+<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-long-header" class="section-name selfRef">Long Header</a>
+        </h3>
+<p id="section-5.1-1">Long headers take the form described in <a href="#fig-long" class="xref">Figure 2</a>.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
+<span id="name-quic-long-header"></span><div id="fig-long">
+<figure id="figure-2">
+          <div class="artwork art-text alignLeft" id="section-5.1-2.1">
+<pre>
+Long Header Packet {
+  Header Form (1) = 1,
+  Version-Specific Bits (7),
+  Version (32),
+  DCID Length (8),
+  Destination Connection ID (0..2040),
+  SCID Length (8),
+  Source Connection ID (0..2040),
+  Version-Specific Data (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
+<a href="#name-quic-long-header" class="selfRef">QUIC Long Header</a>
+          </figcaption></figure>
+</div>
+<p id="section-5.1-3">A QUIC packet with a long header has the high bit of the first byte set to 1.
+All other bits in that byte are version specific.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
+<p id="section-5.1-4">The next four bytes include a 32-bit Version field (see <a href="#version" class="xref">Section 5.4</a>).<a href="#section-5.1-4" class="pilcrow">¶</a></p>
+<p id="section-5.1-5">The next byte contains the length in bytes of the Destination Connection ID (see
+<a href="#connection-id" class="xref">Section 5.3</a>) field that follows it.  This length is encoded as an 8-bit
+unsigned integer.  The Destination Connection ID field follows the DCID Length
+field and is between 0 and 255 bytes in length.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
+<p id="section-5.1-6">The next byte contains the length in bytes of the Source Connection ID field
+that follows it.  This length is encoded as a 8-bit unsigned integer.  The
+Source Connection ID field follows the SCID Length field and is between 0 and
+255 bytes in length.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
+<p id="section-5.1-7">The remainder of the packet contains version-specific content.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="short-header">
+<section id="section-5.2">
+        <h3 id="name-short-header">
+<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-short-header" class="section-name selfRef">Short Header</a>
+        </h3>
+<p id="section-5.2-1">Short headers take the form described in <a href="#fig-short" class="xref">Figure 3</a>.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
+<span id="name-quic-short-header"></span><div id="fig-short">
+<figure id="figure-3">
+          <div class="artwork art-text alignLeft" id="section-5.2-2.1">
+<pre>
+Short Header Packet {
+  Header Form (1) = 0,
+  Version-Specific Bits (7),
+  Destination Connection ID (..),
+  Version-Specific Data (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
+<a href="#name-quic-short-header" class="selfRef">QUIC Short Header</a>
+          </figcaption></figure>
+</div>
+<p id="section-5.2-3">A QUIC packet with a short header has the high bit of the first byte set to 0.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.2-4">A QUIC packet with a short header includes a Destination Connection ID
+immediately following the first byte.  The short header does not include the
+Connection ID Lengths, Source Connection ID, or Version fields.  The length of
+the Destination Connection ID is not specified in packets with a short header
+and is not constrained by this specification.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
+<p id="section-5.2-5">The remainder of the packet has version-specific semantics.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="connection-id">
+<section id="section-5.3">
+        <h3 id="name-connection-id">
+<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-connection-id" class="section-name selfRef">Connection ID</a>
+        </h3>
+<p id="section-5.3-1">A connection ID is an opaque field of arbitrary length.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
+<p id="section-5.3-2">The primary function of a connection ID is to ensure that changes in addressing
+at lower protocol layers (UDP, IP, and below) don't cause packets for a QUIC
+connection to be delivered to the wrong endpoint.  The connection ID is used by
+endpoints and the intermediaries that support them to ensure that each QUIC
+packet can be delivered to the correct instance of an endpoint.  At the
+endpoint, the connection ID is used to identify which QUIC connection the packet
+is intended for.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
+<p id="section-5.3-3">The connection ID is chosen by each endpoint using version-specific methods.
+Packets for the same QUIC connection might use different connection ID values.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="version">
+<section id="section-5.4">
+        <h3 id="name-version">
+<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-version" class="section-name selfRef">Version</a>
+        </h3>
+<p id="section-5.4-1">QUIC versions are identified with a 32-bit integer, encoded in network byte
+order.  Version 0 is reserved for version negotiation (see
+<a href="#version-negotiation" class="xref">Section 6</a>).  All other version numbers are potentially valid.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
+<p id="section-5.4-2">The properties described in this document apply to all versions of QUIC. A
+protocol that does not conform to the properties described in this document is
+not QUIC.  Future documents might describe additional properties which apply to
+a specific QUIC version, or to a range of QUIC versions.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="version-negotiation">
+<section id="section-6">
+      <h2 id="name-version-negotiation">
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-version-negotiation" class="section-name selfRef">Version Negotiation</a>
+      </h2>
+<p id="section-6-1">A QUIC endpoint that receives a packet with a long header and a version it
+either does not understand or does not support might send a Version Negotiation
+packet in response.  Packets with a short header do not trigger version
+negotiation.<a href="#section-6-1" class="pilcrow">¶</a></p>
+<p id="section-6-2">A Version Negotiation packet sets the high bit of the first byte, and thus it
+conforms with the format of a packet with a long header as defined in
+<a href="#long-header" class="xref">Section 5.1</a>.  A Version Negotiation packet is identifiable as such by the
+Version field, which is set to 0x00000000.<a href="#section-6-2" class="pilcrow">¶</a></p>
+<span id="name-version-negotiation-packet"></span><div id="version-negotiation-format">
+<figure id="figure-4">
+        <div class="artwork art-text alignLeft" id="section-6-3.1">
+<pre>
+Version Negotiation Packet {
+  Header Form (1) = 1,
+  Unused (7),
+  Version (32) = 0,
+  DCID Length (8),
+  Destination Connection ID (0..2040),
+  SCID Length (8),
+  Source Connection ID (0..2040),
+  Supported Version (32) ...,
+}
+</pre>
+</div>
+<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
+<a href="#name-version-negotiation-packet" class="selfRef">Version Negotiation Packet</a>
+        </figcaption></figure>
+</div>
+<p id="section-6-4">The Version Negotiation packet contains a list of Supported Version fields, each
+identifying a version that the endpoint sending the packet supports.  The
+Supported Version fields follow the Version field.  A Version Negotiation packet
+contains no other fields.  An endpoint MUST ignore a packet that contains no
+Supported Version fields, or a truncated Supported Version.<a href="#section-6-4" class="pilcrow">¶</a></p>
+<p id="section-6-5">Version Negotiation packets do not use integrity or confidentiality protection.
+A specific QUIC version might authenticate the packet as part of its connection
+establishment process.<a href="#section-6-5" class="pilcrow">¶</a></p>
+<p id="section-6-6">An endpoint MUST include the value from the Source Connection ID field of the
+packet it receives in the Destination Connection ID field.  The value for Source
+Connection ID MUST be copied from the Destination Connection ID of the received
+packet, which is initially randomly selected by a client.  Echoing both
+connection IDs gives clients some assurance that the server received the packet
+and that the Version Negotiation packet was not generated by an off-path
+attacker.<a href="#section-6-6" class="pilcrow">¶</a></p>
+<p id="section-6-7">An endpoint that receives a Version Negotiation packet might change the version
+that it decides to use for subsequent packets.  The conditions under which an
+endpoint changes QUIC version will depend on the version of QUIC that it
+chooses.<a href="#section-6-7" class="pilcrow">¶</a></p>
+<p id="section-6-8">See <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> for a more thorough description of how an endpoint that
+supports QUIC version 1 generates and consumes a Version Negotiation packet.<a href="#section-6-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="security-and-privacy-considerations">
+<section id="section-7">
+      <h2 id="name-security-and-privacy-consid">
+<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-and-privacy-consid" class="section-name selfRef">Security and Privacy Considerations</a>
+      </h2>
+<p id="section-7-1">It is possible that middleboxes could use traits of a specific version of QUIC
+and assume that when other versions of QUIC exhibit similar traits the same
+underlying semantic is being expressed.  There are potentially many such traits
+(see <a href="#bad-assumptions" class="xref">Appendix A</a>).  Some effort has been made to either eliminate or
+obscure some observable traits in QUIC version 1, but many of these remain.
+Other QUIC versions might make different design decisions and so exhibit
+different traits.<a href="#section-7-1" class="pilcrow">¶</a></p>
+<p id="section-7-2">The QUIC version number does not appear in all QUIC packets, which means that
+reliably extracting information from a flow based on version-specific traits
+requires that middleboxes retain state for every connection ID they see.<a href="#section-7-2" class="pilcrow">¶</a></p>
+<p id="section-7-3">The Version Negotiation packet described in this document is not
+integrity-protected; it only has modest protection against insertion by off-path
+attackers.  QUIC versions MUST define a mechanism that authenticates the values
+it contains.<a href="#section-7-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-considerations">
+<section id="section-8">
+      <h2 id="name-iana-considerations">
+<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
+      </h2>
+<p id="section-8-1">This document makes no request of IANA.<a href="#section-8-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<section id="section-9">
+      <h2 id="name-references">
+<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
+      </h2>
+<section id="section-9.1">
+        <h3 id="name-normative-references">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
+        </h3>
+<dl class="references">
+<dt id="RFC2119">[RFC2119]</dt>
+<dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8174">[RFC8174]</dt>
+<dd>
+<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+<section id="section-9.2">
+        <h3 id="name-informative-references">
+<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
+        </h3>
+<dl class="references">
+<dt id="QUIC-TLS">[QUIC-TLS]</dt>
+<dd>
+<span class="refAuthor">Thomson, M., Ed.</span><span class="refAuthor"> and S. Turner, Ed.</span>, <span class="refTitle">"Using Transport Layer Security (TLS) to Secure QUIC"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-tls-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-tls-latest">https://tools.ietf.org/html/draft-ietf-quic-tls-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-TRANSPORT">[QUIC-TRANSPORT]</dt>
+<dd>
+<span class="refAuthor">Iyengar, J., Ed.</span><span class="refAuthor"> and M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-transport-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-transport-latest">https://tools.ietf.org/html/draft-ietf-quic-transport-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5116">[RFC5116]</dt>
+<dd>
+<span class="refAuthor">McGrew, D.</span>, <span class="refTitle">"An Interface and Algorithms for Authenticated Encryption"</span>, <span class="seriesInfo">RFC 5116</span>, <span class="seriesInfo">DOI 10.17487/RFC5116</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5116">https://www.rfc-editor.org/info/rfc5116</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</section>
+<div id="bad-assumptions">
+<section id="section-appendix.a">
+      <h2 id="name-incorrect-assumptions">
+<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-incorrect-assumptions" class="section-name selfRef">Incorrect Assumptions</a>
+      </h2>
+<p id="section-appendix.a-1">There are several traits of QUIC version 1 <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> that are not
+protected from observation, but are nonetheless considered to be changeable when
+a new version is deployed.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
+<p id="section-appendix.a-2">This section lists a sampling of incorrect assumptions that might be made based
+on knowledge of QUIC version 1.  Some of these statements are not even true for
+QUIC version 1.  This is not an exhaustive list, it is intended to be
+illustrative only.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
+<p id="section-appendix.a-3">The following statements are NOT guaranteed to be true for every QUIC version:<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-appendix.a-4.1">QUIC uses TLS <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span> and some TLS messages are visible on the wire<a href="#section-appendix.a-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.2">QUIC long headers are only exchanged during connection establishment<a href="#section-appendix.a-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.3">Every flow on a given 5-tuple will include a connection establishment phase<a href="#section-appendix.a-4.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.4">The first packets exchanged on a flow use the long header<a href="#section-appendix.a-4.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.5">QUIC forbids acknowledgments of packets that only contain ACK frames,
+therefore the last packet before a long period of quiescence might be assumed
+to contain an acknowledgment<a href="#section-appendix.a-4.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.6">QUIC uses an AEAD (AEAD_AES_128_GCM <span>[<a href="#RFC5116" class="xref">RFC5116</a>]</span>) to protect the packets it
+exchanges during connection establishment<a href="#section-appendix.a-4.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.7">QUIC packet numbers are encrypted and appear as the first encrypted bytes<a href="#section-appendix.a-4.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.8">QUIC packet numbers increase by one for every packet sent<a href="#section-appendix.a-4.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.9">QUIC has a minimum size for the first handshake packet sent by a client<a href="#section-appendix.a-4.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.10">QUIC stipulates that a client speaks first<a href="#section-appendix.a-4.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.11">QUIC packets always have the second bit of the first byte (0x40) set<a href="#section-appendix.a-4.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.12">A QUIC Version Negotiation packet is only sent by a server<a href="#section-appendix.a-4.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.13">A QUIC connection ID changes infrequently<a href="#section-appendix.a-4.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.14">QUIC endpoints change the version they speak if they are sent a Version
+Negotiation packet<a href="#section-appendix.a-4.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.15">The version field in a QUIC long header is the same in both directions<a href="#section-appendix.a-4.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.a-4.16">Only one connection at a time is established between any pair of QUIC
+endpoints<a href="#section-appendix.a-4.16" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="authors-addresses">
+<section id="section-appendix.b">
+      <h2 id="name-authors-address">
+<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
+      </h2>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Martin Thomson</span></div>
+<div dir="auto" class="left"><span class="org">Mozilla</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:mt@lowentropy.net" class="email">mt@lowentropy.net</a>
+</div>
+</address>
+</section>
+</div>
+<script>const toc = document.getElementById("toc");
+toc.querySelector("h2").addEventListener("click", e => {
+  toc.classList.toggle("active");
+});
+toc.querySelector("nav").addEventListener("click", e => {
+  toc.classList.remove("active");
+});
+</script>
+</body>
+</html>
diff --git a/jri/mustnot/draft-ietf-quic-invariants.txt b/jri/mustnot/draft-ietf-quic-invariants.txt
new file mode 100644
index 0000000000..9d108b8bfe
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-invariants.txt
@@ -0,0 +1,560 @@
+
+
+
+
+QUIC                                                          M. Thomson
+Internet-Draft                                                   Mozilla
+Intended status: Standards Track                             3 June 2020
+Expires: 5 December 2020
+
+
+                 Version-Independent Properties of QUIC
+                   draft-ietf-quic-invariants-latest
+
+Abstract
+
+   This document defines the properties of the QUIC transport protocol
+   that are expected to remain unchanged over time as new versions of
+   the protocol are developed.
+
+Note to Readers
+
+   Discussion of this draft takes place on the QUIC working group
+   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
+   archived at https://mailarchive.ietf.org/arch/
+   search/?email_list=quic.
+
+   Working Group information can be found at https://github.com/quicwg;
+   source code and issues list for this draft can be found at
+   https://github.com/quicwg/base-drafts/labels/-invariants.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at https://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on 5 December 2020.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Thomson                  Expires 5 December 2020                [Page 1]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (https://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.  Code Components
+   extracted from this document must include Simplified BSD License text
+   as described in Section 4.e of the Trust Legal Provisions and are
+   provided without warranty as described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
+   3.  An Extremely Abstract Description of QUIC . . . . . . . . . .   3
+   4.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
+   5.  QUIC Packet Headers . . . . . . . . . . . . . . . . . . . . .   4
+     5.1.  Long Header . . . . . . . . . . . . . . . . . . . . . . .   4
+     5.2.  Short Header  . . . . . . . . . . . . . . . . . . . . . .   5
+     5.3.  Connection ID . . . . . . . . . . . . . . . . . . . . . .   5
+     5.4.  Version . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   6.  Version Negotiation . . . . . . . . . . . . . . . . . . . . .   6
+   7.  Security and Privacy Considerations . . . . . . . . . . . . .   7
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
+   Appendix A.  Incorrect Assumptions  . . . . . . . . . . . . . . .   8
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10
+
+1.  Introduction
+
+   In addition to providing secure, multiplexed transport, QUIC
+   [QUIC-TRANSPORT] includes the ability to negotiate a version.  This
+   allows the protocol to change over time in response to new
+   requirements.  Many characteristics of the protocol will change
+   between versions.
+
+   This document describes the subset of QUIC that is intended to remain
+   stable as new versions are developed and deployed.  All of these
+   invariants are IP-version-independent.
+
+   The primary goal of this document is to ensure that it is possible to
+   deploy new versions of QUIC.  By documenting the properties that
+   can't change, this document aims to preserve the ability to change
+   any other aspect of the protocol.  Thus, unless specifically
+   described in this document, any aspect of the protocol can change
+   between different versions.
+
+
+
+
+Thomson                  Expires 5 December 2020                [Page 2]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   Appendix A is a non-exhaustive list of some incorrect assumptions
+   that might be made based on knowledge of QUIC version 1; these do not
+   apply to every version of QUIC.
+
+2.  Conventions and Definitions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This document uses terms and notational conventions from
+   [QUIC-TRANSPORT].
+
+3.  An Extremely Abstract Description of QUIC
+
+   QUIC is a connection-oriented protocol between two endpoints.  Those
+   endpoints exchange UDP datagrams.  These UDP datagrams contain QUIC
+   packets.  QUIC endpoints use QUIC packets to establish a QUIC
+   connection, which is shared protocol state between those endpoints.
+
+4.  Notational Conventions
+
+   Packet diagrams in this document use a format defined in
+   [QUIC-TRANSPORT] to illustrate the order and size of fields.
+
+   Complex fields are named and then followed by a list of fields
+   surrounded by a pair of matching braces.  Each field in this list is
+   separated by commas.
+
+   Individual fields include length information, plus indications about
+   fixed value, optionality, or repetitions.  Individual fields use the
+   following notational conventions, with all lengths in bits:
+
+   x (A):  Indicates that x is A bits long
+
+   x (A..B):  Indicates that x can be any length from A to B; A can be
+      omitted to indicate a minimum of zero bits and B can be omitted to
+      indicate no set upper limit; values in this format always end on
+      an octet boundary
+
+   x (?) = C:  Indicates that x has a fixed value of C
+
+   x (E) ...:  Indicates that x is repeated zero or more times (and that
+      each instance is length E)
+
+   Figure 1 shows an example structure:
+
+
+
+Thomson                  Expires 5 December 2020                [Page 3]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   Example Structure {
+     One-bit Field (1),
+     7-bit Field with Fixed Value (7) = 61,
+     Arbitrary-Length Field (..),
+     Variable-Length Field (8..24),
+     Repeated Field (8) ...,
+   }
+
+                          Figure 1: Example Format
+
+5.  QUIC Packet Headers
+
+   QUIC endpoints exchange UDP datagrams that contain one or more QUIC
+   packets.  This section describes the invariant characteristics of a
+   QUIC packet.  A version of QUIC could permit multiple QUIC packets in
+   a single UDP datagram, but the invariant properties only describe the
+   first packet in a datagram.
+
+   QUIC defines two types of packet header: long and short.  Packets
+   with long headers are identified by the most significant bit of the
+   first byte being set; packets with a short header have that bit
+   cleared.
+
+   Aside from the values described here, the payload of QUIC packets is
+   version-specific and of arbitrary length.
+
+5.1.  Long Header
+
+   Long headers take the form described in Figure 2.
+
+   Long Header Packet {
+     Header Form (1) = 1,
+     Version-Specific Bits (7),
+     Version (32),
+     DCID Length (8),
+     Destination Connection ID (0..2040),
+     SCID Length (8),
+     Source Connection ID (0..2040),
+     Version-Specific Data (..),
+   }
+
+                         Figure 2: QUIC Long Header
+
+   A QUIC packet with a long header has the high bit of the first byte
+   set to 1.  All other bits in that byte are version specific.
+
+   The next four bytes include a 32-bit Version field (see Section 5.4).
+
+
+
+
+Thomson                  Expires 5 December 2020                [Page 4]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   The next byte contains the length in bytes of the Destination
+   Connection ID (see Section 5.3) field that follows it.  This length
+   is encoded as an 8-bit unsigned integer.  The Destination Connection
+   ID field follows the DCID Length field and is between 0 and 255 bytes
+   in length.
+
+   The next byte contains the length in bytes of the Source Connection
+   ID field that follows it.  This length is encoded as a 8-bit unsigned
+   integer.  The Source Connection ID field follows the SCID Length
+   field and is between 0 and 255 bytes in length.
+
+   The remainder of the packet contains version-specific content.
+
+5.2.  Short Header
+
+   Short headers take the form described in Figure 3.
+
+   Short Header Packet {
+     Header Form (1) = 0,
+     Version-Specific Bits (7),
+     Destination Connection ID (..),
+     Version-Specific Data (..),
+   }
+
+                        Figure 3: QUIC Short Header
+
+   A QUIC packet with a short header has the high bit of the first byte
+   set to 0.
+
+   A QUIC packet with a short header includes a Destination Connection
+   ID immediately following the first byte.  The short header does not
+   include the Connection ID Lengths, Source Connection ID, or Version
+   fields.  The length of the Destination Connection ID is not specified
+   in packets with a short header and is not constrained by this
+   specification.
+
+   The remainder of the packet has version-specific semantics.
+
+5.3.  Connection ID
+
+   A connection ID is an opaque field of arbitrary length.
+
+
+
+
+
+
+
+
+
+
+Thomson                  Expires 5 December 2020                [Page 5]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   The primary function of a connection ID is to ensure that changes in
+   addressing at lower protocol layers (UDP, IP, and below) don't cause
+   packets for a QUIC connection to be delivered to the wrong endpoint.
+   The connection ID is used by endpoints and the intermediaries that
+   support them to ensure that each QUIC packet can be delivered to the
+   correct instance of an endpoint.  At the endpoint, the connection ID
+   is used to identify which QUIC connection the packet is intended for.
+
+   The connection ID is chosen by each endpoint using version-specific
+   methods.  Packets for the same QUIC connection might use different
+   connection ID values.
+
+5.4.  Version
+
+   QUIC versions are identified with a 32-bit integer, encoded in
+   network byte order.  Version 0 is reserved for version negotiation
+   (see Section 6).  All other version numbers are potentially valid.
+
+   The properties described in this document apply to all versions of
+   QUIC.  A protocol that does not conform to the properties described
+   in this document is not QUIC.  Future documents might describe
+   additional properties which apply to a specific QUIC version, or to a
+   range of QUIC versions.
+
+6.  Version Negotiation
+
+   A QUIC endpoint that receives a packet with a long header and a
+   version it either does not understand or does not support might send
+   a Version Negotiation packet in response.  Packets with a short
+   header do not trigger version negotiation.
+
+   A Version Negotiation packet sets the high bit of the first byte, and
+   thus it conforms with the format of a packet with a long header as
+   defined in Section 5.1.  A Version Negotiation packet is identifiable
+   as such by the Version field, which is set to 0x00000000.
+
+   Version Negotiation Packet {
+     Header Form (1) = 1,
+     Unused (7),
+     Version (32) = 0,
+     DCID Length (8),
+     Destination Connection ID (0..2040),
+     SCID Length (8),
+     Source Connection ID (0..2040),
+     Supported Version (32) ...,
+   }
+
+                    Figure 4: Version Negotiation Packet
+
+
+
+Thomson                  Expires 5 December 2020                [Page 6]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   The Version Negotiation packet contains a list of Supported Version
+   fields, each identifying a version that the endpoint sending the
+   packet supports.  The Supported Version fields follow the Version
+   field.  A Version Negotiation packet contains no other fields.  An
+   endpoint MUST ignore a packet that contains no Supported Version
+   fields, or a truncated Supported Version.
+
+   Version Negotiation packets do not use integrity or confidentiality
+   protection.  A specific QUIC version might authenticate the packet as
+   part of its connection establishment process.
+
+   An endpoint MUST include the value from the Source Connection ID
+   field of the packet it receives in the Destination Connection ID
+   field.  The value for Source Connection ID MUST be copied from the
+   Destination Connection ID of the received packet, which is initially
+   randomly selected by a client.  Echoing both connection IDs gives
+   clients some assurance that the server received the packet and that
+   the Version Negotiation packet was not generated by an off-path
+   attacker.
+
+   An endpoint that receives a Version Negotiation packet might change
+   the version that it decides to use for subsequent packets.  The
+   conditions under which an endpoint changes QUIC version will depend
+   on the version of QUIC that it chooses.
+
+   See [QUIC-TRANSPORT] for a more thorough description of how an
+   endpoint that supports QUIC version 1 generates and consumes a
+   Version Negotiation packet.
+
+7.  Security and Privacy Considerations
+
+   It is possible that middleboxes could use traits of a specific
+   version of QUIC and assume that when other versions of QUIC exhibit
+   similar traits the same underlying semantic is being expressed.
+   There are potentially many such traits (see Appendix A).  Some effort
+   has been made to either eliminate or obscure some observable traits
+   in QUIC version 1, but many of these remain.  Other QUIC versions
+   might make different design decisions and so exhibit different
+   traits.
+
+   The QUIC version number does not appear in all QUIC packets, which
+   means that reliably extracting information from a flow based on
+   version-specific traits requires that middleboxes retain state for
+   every connection ID they see.
+
+
+
+
+
+
+
+Thomson                  Expires 5 December 2020                [Page 7]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   The Version Negotiation packet described in this document is not
+   integrity-protected; it only has modest protection against insertion
+   by off-path attackers.  QUIC versions MUST define a mechanism that
+   authenticates the values it contains.
+
+8.  IANA Considerations
+
+   This document makes no request of IANA.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2.  Informative References
+
+   [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport
+              Layer Security (TLS) to Secure QUIC", Work in Progress,
+              Internet-Draft, draft-ietf-quic-tls-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-tls-latest>.
+
+   [QUIC-TRANSPORT]
+              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", Work in Progress,
+              Internet-Draft, draft-ietf-quic-transport-latest, 3 June
+              2020, <https://tools.ietf.org/html/draft-ietf-quic-
+              transport-latest>.
+
+   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
+              <https://www.rfc-editor.org/info/rfc5116>.
+
+Appendix A.  Incorrect Assumptions
+
+   There are several traits of QUIC version 1 [QUIC-TRANSPORT] that are
+   not protected from observation, but are nonetheless considered to be
+   changeable when a new version is deployed.
+
+
+
+
+
+
+Thomson                  Expires 5 December 2020                [Page 8]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   This section lists a sampling of incorrect assumptions that might be
+   made based on knowledge of QUIC version 1.  Some of these statements
+   are not even true for QUIC version 1.  This is not an exhaustive
+   list, it is intended to be illustrative only.
+
+   The following statements are NOT guaranteed to be true for every QUIC
+   version:
+
+   *  QUIC uses TLS [QUIC-TLS] and some TLS messages are visible on the
+      wire
+
+   *  QUIC long headers are only exchanged during connection
+      establishment
+
+   *  Every flow on a given 5-tuple will include a connection
+      establishment phase
+
+   *  The first packets exchanged on a flow use the long header
+
+   *  QUIC forbids acknowledgments of packets that only contain ACK
+      frames, therefore the last packet before a long period of
+      quiescence might be assumed to contain an acknowledgment
+
+   *  QUIC uses an AEAD (AEAD_AES_128_GCM [RFC5116]) to protect the
+      packets it exchanges during connection establishment
+
+   *  QUIC packet numbers are encrypted and appear as the first
+      encrypted bytes
+
+   *  QUIC packet numbers increase by one for every packet sent
+
+   *  QUIC has a minimum size for the first handshake packet sent by a
+      client
+
+   *  QUIC stipulates that a client speaks first
+
+   *  QUIC packets always have the second bit of the first byte (0x40)
+      set
+
+   *  A QUIC Version Negotiation packet is only sent by a server
+
+   *  A QUIC connection ID changes infrequently
+
+   *  QUIC endpoints change the version they speak if they are sent a
+      Version Negotiation packet
+
+   *  The version field in a QUIC long header is the same in both
+      directions
+
+
+
+Thomson                  Expires 5 December 2020                [Page 9]
+
+Internet-Draft               QUIC Invariants                   June 2020
+
+
+   *  Only one connection at a time is established between any pair of
+      QUIC endpoints
+
+Author's Address
+
+   Martin Thomson
+   Mozilla
+
+   Email: mt@lowentropy.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson                  Expires 5 December 2020               [Page 10]
diff --git a/jri/mustnot/draft-ietf-quic-qpack.html b/jri/mustnot/draft-ietf-quic-qpack.html
new file mode 100644
index 0000000000..b0fd9a452f
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-qpack.html
@@ -0,0 +1,3815 @@
+<!DOCTYPE html>
+<html lang="en" class="Internet-Draft">
+<head>
+<meta charset="utf-8">
+<meta content="Common,Latin" name="scripts">
+<meta content="initial-scale=1.0" name="viewport">
+<title>QPACK: Header Compression for HTTP/3</title>
+<meta content="Charles 'Buck' Krasic" name="author">
+<meta content="Mike Bishop" name="author">
+<meta content="Alan Frindell" name="author">
+<meta content="
+       This specification defines QPACK, a compression format for efficiently
+representing HTTP fields, to be used in HTTP/3. This is a variation of HPACK
+compression that seeks to reduce head-of-line blocking. 
+    " name="description">
+<meta content="xml2rfc 2.45.2" name="generator">
+<meta content="draft-ietf-quic-qpack-latest" name="ietf.draft">
+<link href="draft-ietf-quic-qpack.xml" rel="alternate" type="application/rfc+xml">
+<link href="#copyright" rel="license">
+<style type="text/css">@import url('https://martinthomson.github.io/i-d-template/fonts.css');
+
+html {
+  --background-color: #fff;
+  --text-color: #222;
+  --title-color: #191919;
+  --link-color: #2a6496;
+  --highlight-color: #f9f9f9;
+  --line-color: #eee;
+  --small-font-size: 14.5px;
+}
+body {
+  max-width: 600px;
+  margin: 75px auto;
+  padding: 0 5px;
+  color: var(--text-color);
+  background-color: var(--background-color);
+  font: 16px/22px "Lora", serif;
+  scroll-behavior: smooth;
+}
+
+.ears {
+  display: none;
+}
+
+/* headings */
+#title, h1, h2, h3, h4, h5, h6 {
+  font-family: "Cabin Condensed", sans-serif;
+  font-weight: 600;
+  margin: 0.8em 0 0.3em;
+  font-size-adjust: 0.5;
+  color: var(--title-color);
+}
+#title {
+  padding: 1em 0 0.2em;
+  font-size: 32px;
+  line-height: 40px;
+  clear: both;
+}
+h1, h2, h3 {
+  font-size: 22px;
+  line-height: 26px;
+}
+h4, h5, h6 {
+  font-size: 18px;
+  line-height: 22px;
+}
+
+/* general structure */
+.author {
+  padding-bottom: 0.3em;
+}
+#abstract+p, #abstract+p code, #abstract+p samp, #abstract+p tt {
+  font-size: 18px;
+  line-height: 24px;
+}
+p {
+  padding: 0;
+  margin: 0.5em 0;
+  text-align: left;
+}
+div, span {
+  position: relative;
+}
+div {
+  margin: 0;
+}
+.alignRight.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignRight.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignRight {
+  margin: 1em 0;
+}
+.alignRight > *:first-child {
+  border: none;
+  margin: 0;
+  float: right;
+  clear: both;
+}
+.alignRight > *:nth-child(2) {
+  clear: both;
+  display: block;
+  border: none;
+}
+svg {
+  display: block;
+}
+.alignCenter.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignCenter.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignCenter {
+  margin: 1em 0;
+}
+.alignCenter > *:first-child {
+  border: none;
+  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
+     support flexbox yet.
+  */
+  display: table;
+  margin: 0 auto;
+}
+
+/* lists */
+ol, ul {
+  padding: 0;
+  margin: 0 0 1em 2em;
+}
+ol ol, ul ul, ol ul, ul ol {
+  margin-left: 1em;
+}
+li {
+  margin: 0 0 0.25em 0;
+}
+.ulCompact li {
+  margin: 0;
+}
+ul.empty, .ulEmpty {
+  list-style-type: none;
+}
+ul.empty li, .ulEmpty li {
+  margin-top: 0.5em;
+}
+ul.compact, .ulCompact,
+ol.compact, .olCompact {
+  line-height: 100%;
+  margin: 0 0 0 2em;
+}
+
+/* definition lists */
+dl {
+}
+dl > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl > dd {
+  margin-bottom: .8em;
+  min-height: 1.3em;
+}
+dl.compact > dd, .dlCompact > dd {
+  margin-bottom: 0em;
+}
+dl > dd > dl {
+  margin-top: 0.5em;
+  margin-bottom: 0em;
+}
+dd.break {
+  display: none;
+}
+
+/* links */
+a, a[href].selfRef:hover {
+  text-decoration: none;
+}
+a[href].selfRef {
+  color: var(--text-color);
+}
+a[href] {
+  color: var(--link-color);
+}
+a[href]:hover {
+  text-decoration: underline;
+}
+a[href].selfRef:hover {
+  background-color: var(--highlight-color);
+}
+a.xref {
+  white-space: nowrap;
+}
+
+/* Figures */
+tt, code, pre {
+  background-color: var(--highlight-color);
+  font: 14px/22px 'Oxygen Mono', monospace;
+}
+pre {
+  border: 1px solid var(--line-color);
+  font-size: 13.5px;
+  line-height: 16px;
+  letter-spacing: -0.2px;
+  margin: 5px;
+  padding: 5px;
+}
+img {
+  max-width: 100%;
+}
+figure {
+  margin: 0.5em 0;
+}
+figure blockquote {
+  margin: 0.8em 0.4em 0.4em;
+}
+figcaption, caption {
+  font-style: italic;
+  margin: 0.5em 1.5em;
+  text-align: left;
+}
+@media screen {
+  pre {
+    display: inline-block;
+    overflow-x: auto;
+    max-width: 100%;
+    width: calc(100% - 22px - 1em);
+  }
+  figure pre {
+    display: block;
+    width: calc(100% - 25px);
+  }
+  pre + .pilcrow {
+    display: inline-block;
+    vertical-align: text-bottom;
+    padding-bottom: 8px;
+  }
+  table {
+    display: inline-block;
+    overflow-x: auto;
+  }
+}
+
+/* aside, blockquote */
+aside, blockquote {
+  margin-left: 0;
+  padding: 0 2em;
+  font-style: italic;
+}
+blockquote {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  margin: 1em 0;
+}
+cite {
+  display: block;
+  text-align: right;
+  font-style: italic;
+}
+
+/* tables */
+table {
+  width: 100%;
+  margin: 0 0 1em;
+  border-collapse: collapse;
+}
+thead, tbody {
+  border: 1px solid var(--line-color);
+}
+th, td {
+  text-align: left;
+  vertical-align: top;
+  padding: 5px 10px;
+}
+th {
+  text-align: left;
+  background-color: #eee;
+}
+tr:nth-child(2n) > td {
+  background-color: var(--background-color);
+}
+tr:nth-child(2n+1) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n+1) > td {
+  background-color: var(--background-color);
+}
+table caption {
+  margin: 0;
+  padding: 3px 1em;
+}
+table p {
+  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
+     be allowed within tables more generally, it would be far better to select on a class. */
+  margin: 0;
+}
+
+/* pilcrow */
+a.pilcrow {
+  margin-left: 3px;
+  visibility: hidden;
+  user-select: none;
+}
+a.pilcrow[href] { color: #ddd; }
+a.pilcrow[href]:hover { text-decoration: none; }
+@media screen {
+  :hover > a.pilcrow {
+    visibility: visible;
+  }
+  a.pilcrow:hover {
+    background-color: transparent;
+  }
+}
+
+/* misc */
+hr {
+  border: 0;
+  border-top: 1px solid var(--line-color);
+}
+.bcp14 {
+  font-variant: small-caps;
+}
+
+.role {
+  font-variant: all-small-caps;
+}
+
+/* info block */
+#identifiers {
+  margin: 0;
+  font-size: var(--small-font-size);
+  line-height: 18px;
+  --identifier-width: 8em;
+}
+#identifiers dt {
+  width: var(--identifier-width);
+  margin: 0;
+  clear: left;
+  float: left;
+  text-align: right;
+}
+#identifiers dd {
+  margin: 0 0 0 calc(1em + var(--identifier-width));
+  min-width: 5em;
+}
+#identifiers .authors .author {
+  display: inline-block;
+  margin-right: 1.5em;
+}
+#identifiers .authors .org {
+  font-style: italic;
+}
+
+/* The prepared/rendered info at the very bottom of the page */
+.docInfo {
+  color: #999;
+  font-size: 0.9em;
+  font-style: italic;
+  margin-top: 2em;
+}
+.docInfo .prepared {
+  float: left;
+}
+.docInfo .prepared {
+  float: right;
+}
+
+/* table of contents */
+#toc {
+  padding: 0.75em 0 2em 0;
+  margin-bottom: 1em;
+}
+#toc nav ul {
+  margin: 0 0.5em 0 0;
+  padding: 0;
+  list-style: none;
+}
+#toc nav li {
+  line-height: 1.3em;
+  margin: 0.75em 0;
+  padding-left: 1.2em;
+  text-indent: -1.2em;
+}
+#toc a.xref {
+  white-space: normal;
+}
+/* references */
+.references dt {
+  text-align: right;
+  font-weight: bold;
+  min-width: 7em;
+}
+.references dd {
+  margin-left: 8em;
+  overflow: auto;
+}
+
+.refInstance {
+  margin-bottom: 1.25em;
+}
+
+.references .ascii {
+  margin-bottom: 0.25em;
+}
+
+/* index */
+.index ul {
+  margin: 0 0 0 1em;
+  padding: 0;
+  list-style: none;
+}
+.index ul ul {
+  margin: 0;
+}
+.index li {
+  margin: 0;
+  text-indent: -2em;
+  padding-left: 2em;
+  padding-bottom: 5px;
+}
+.indexIndex {
+  margin: 0.5em 0 1em;
+}
+.index a {
+  font-weight: 700;
+}
+/* make the index two-column on all but the smallest screens */
+@media (min-width: 500px) {
+  .index ul {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  .index ul ul {
+    column-count: 1;
+    column-gap: 0;
+  }
+}
+
+/* authors */
+address.vcard {
+  font-style: normal;
+  margin: 1em 0;
+}
+address.vcard .nameRole {
+  font-weight: 700;
+  margin-left: 0;
+}
+address.vcard .label {
+  margin: 0.5em 0;
+}
+address.vcard .type {
+  display: none;
+}
+.alternative-contact {
+  margin: 1.5em 0 1em;
+}
+hr.addr {
+  border-top: 1px dashed;
+  margin: 0;
+  color: #ddd;
+  max-width: calc(100% - 16px);
+}
+@media (min-width: 500px) {
+  #authors-addresses > section {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  #authors-addresses > section > h2 {
+    column-span: all;
+  }
+  /* hack for break-inside: avoid-column */
+  #authors-addresses address {
+    display: inline-block;
+    break-inside: avoid-column;
+  }
+}
+
+.rfcEditorRemove p:first-of-type {
+  font-style: italic;
+}
+.cref {
+  background-color: rgba(249, 232, 105, 0.3);
+  padding: 2px 4px;
+}
+.crefSource {
+  font-style: italic;
+}
+/* alternative layout for smaller screens */
+@media screen and (max-width: 929px) {
+  #toc {
+    position: fixed;
+    z-index: 2;
+    top: 0;
+    right: 0;
+    padding: 0;
+    margin: 0;
+    border-bottom: 1px solid #ccc;
+    opacity: 0.6;
+  }
+  #toc.active {
+      opacity: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 2px 0 2px 6px;
+    padding-right: 1em;
+    font-size: 18px;
+    line-height: 24px;
+    min-width: 190px;
+    text-align: right;
+    background-color: #444;
+    color: white;
+    cursor: pointer;
+  }
+  #toc h2::before { /* css hamburger */
+    float: right;
+    position: relative;
+    width: 1em;
+    height: 1px;
+    left: -164px;
+    margin: 8px 0 0 0;
+    background: white none repeat scroll 0 0;
+    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
+    content: "";
+  }
+  #toc nav {
+    display: none;
+    background-color: var(--background-color);
+    padding: 0.5em 1em 1em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    height: calc(100vh - 48px);
+    border-left: 1px solid #ddd;
+  }
+  #toc.active nav {
+    display: block;
+  }
+  /* Make the collapsed ToC header render white on gray also when it's a link */
+  #toc h2 a,
+  #toc h2 a:link,
+  #toc h2 a:focus,
+  #toc h2 a:hover,
+  #toc a.toplink,
+  #toc a.toplink:hover {
+    color: white;
+    background-color: #444;
+    text-decoration: none;
+  }
+  #toc a.toplink {
+    margin-top: 2px;
+  }
+}
+
+/* alternative layout for wide screens */
+@media screen and (min-width: 930px) {
+  body {
+    padding-right: 360px;
+    padding-right: calc(min(180px + 20%, 500px));
+  }
+  #toc {
+    position: fixed;
+    bottom: 0;
+    right: 0;
+    right: calc(50vw - 480px);
+    width: 312px;
+    margin: 0;
+    padding: 0;
+    z-index: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 0.25em 1em 1em 0;
+  }
+  #toc nav {
+    display: block;
+    height: calc(90vh - 84px);
+    bottom: 0;
+    padding: 0.5em 0 2em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    scrollbar-width: thin;
+  }
+  #toc nav > ul  {
+    margin-bottom: 2em;
+  }
+  #toc ul {
+    margin: 0 0 0 4px;
+    font-size: var(--small-font-size);
+  }
+  #toc ul p, #toc ul li {
+    margin: 2px 0;
+    line-height: 22px;
+  }
+  img { /* future proofing */
+    max-width: 100%;
+    height: auto;
+  }
+}
+
+/* pagination */
+@media print {
+  body {
+    width: 100%;
+  }
+  p {
+    orphans: 3;
+    widows: 3;
+  }
+  #n-copyright-notice {
+    border-bottom: none;
+  }
+  #toc, #n-introduction {
+    page-break-before: always;
+  }
+  #toc {
+    border-top: none;
+    padding-top: 0;
+  }
+  figure, pre {
+    page-break-inside: avoid;
+  }
+  figure {
+    overflow: scroll;
+  }
+  h1, h2, h3, h4, h5, h6 {
+    page-break-after: avoid;
+  }
+  h2+*, h3+*, h4+*, h5+*, h6+* {
+    page-break-before: avoid;
+  }
+  pre {
+    white-space: pre-wrap;
+    word-wrap: break-word;
+    font-size: 10pt;
+  }
+  table {
+    border: 1px solid #ddd;
+  }
+  td {
+    border-top: 1px solid #ddd;
+  }
+}
+
+@page :first {
+  padding-top: 0;
+  @top-left {
+    content: normal;
+    border: none;
+  }
+  @top-center {
+    content: normal;
+    border: none;
+  }
+  @top-right {
+    content: normal;
+    border: none;
+  }
+}
+
+@page {
+  size: A4;
+  margin-bottom: 45mm;
+  padding-top: 20px;
+}
+
+/* Changes introduced to fix issues found during implementation */
+
+/* Separate body from document info even without intervening H1 */
+section {
+  clear: both;
+}
+
+/* Top align author divs, to avoid names without organization dropping level with org names */
+.author {
+  vertical-align: top;
+}
+
+/* Style section numbers with more space between number and title */
+.section-number {
+  padding-right: 0.5em;
+}
+
+/* Add styling for a link in the ToC that points to the top of the document */
+a.toplink {
+  float: right;
+  margin: 8px 0.5em 0;
+}
+
+/* Fix the dl styling to match the RFC 7992 attributes */
+dl > dt,
+dl.dlParallel > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl.dlNewline > dt {
+  float: none;
+}
+
+/* Provide styling for table cell text alignment */
+table .text-left, table .text-left {
+  text-align: left;
+}
+table .text-center, table .text-center {
+  text-align: center;
+}
+table .text-right, table .text-right {
+  text-align: right;
+}
+
+/* Make the alternative author contact information look less like just another
+   author, and group it closer with the primary author contact information */
+.alternative-contact {
+  margin: 0.5em 0 0.25em 0;
+}
+address .non-ascii {
+  margin: 0 0 0 2em;
+}
+
+/* With it being possible to set tables with alignment
+  left, center, and right, { width: 100%; } does not make sense */
+table {
+  width: auto;
+}
+
+/* Avoid reference text that sits in a block with very wide left margin,
+   because of a long floating dt label.*/
+.references dd {
+  overflow: visible;
+}
+
+/* Control caption placement */
+caption {
+  caption-side: bottom;
+}
+
+/* Limit the width of the author address vcard, so names in right-to-left
+   script don't end up on the other side of the page. */
+
+address.vcard {
+  max-width: 20em;
+  margin-right: auto;
+}
+
+/* For address alignment dependent on LTR or RTL scripts */
+address div.left {
+  text-align: left;
+}
+address div.right {
+  text-align: right;
+}
+
+/* Provide table alignment support.  We can't use the alignX classes above
+   since they do unwanted things with caption and other styling. */
+table.right {
+ margin-left: auto;
+ margin-right: 0;
+}
+table.center {
+ margin-left: auto;
+ margin-right: auto;
+}
+table.left {
+ margin-left: 0;
+ margin-right: auto;
+}
+
+/* Give the table caption label the same styling as the figcaption */
+
+@media print {
+  .toplink {
+    display: none;
+  }
+
+  /* avoid overwriting the top border line with the ToC header */
+  #toc {
+    padding-top: 1px;
+  }
+
+  /* Avoid page breaks inside dl and author address entries */
+  dd {
+    page-break-before: avoid;
+  }
+  .vcard {
+    page-break-inside: avoid;
+  }
+
+}
+/* Tweak the bcp14 keyword presentation */
+.bcp14 {
+  font-variant: small-caps;
+  font-weight: bold;
+  font-size: 0.9em;
+}
+</style>
+<link href="rfc-local.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<table class="ears">
+<thead><tr>
+<td class="left">Internet-Draft</td>
+<td class="center">QPACK</td>
+<td class="right">June 2020</td>
+</tr></thead>
+<tfoot><tr>
+<td class="left">Krasic, et al.</td>
+<td class="center">Expires 5 December 2020</td>
+<td class="right">[Page]</td>
+</tr></tfoot>
+</table>
+<div id="external-metadata" class="document-information"></div>
+<div id="internal-metadata" class="document-information">
+<dl id="identifiers">
+<dt class="label-workgroup">Workgroup:</dt>
+<dd class="workgroup">QUIC</dd>
+<dt class="label-internet-draft">Internet-Draft:</dt>
+<dd class="internet-draft">draft-ietf-quic-qpack-latest</dd>
+<dt class="label-published">Published:</dt>
+<dd class="published">
+<time datetime="2020-06-03" class="published">3 June 2020</time>
+    </dd>
+<dt class="label-intended-status">Intended Status:</dt>
+<dd class="intended-status">Standards Track</dd>
+<dt class="label-expires">Expires:</dt>
+<dd class="expires"><time datetime="2020-12-05">5 December 2020</time></dd>
+<dt class="label-authors">Authors:</dt>
+<dd class="authors">
+<div class="author">
+      <div class="author-name">C. Krasic</div>
+<div class="org">Netflix</div>
+</div>
+<div class="author">
+      <div class="author-name">M. Bishop</div>
+<div class="org">Akamai Technologies</div>
+</div>
+<div class="author">
+      <div class="author-name">A. Frindell, <span class="editor">Ed.</span>
+</div>
+<div class="org">Facebook</div>
+</div>
+</dd>
+</dl>
+</div>
+<h1 id="title">QPACK: Header Compression for HTTP/3</h1>
+<section id="section-abstract">
+      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
+<p id="section-abstract-1">This specification defines QPACK, a compression format for efficiently
+representing HTTP fields, to be used in HTTP/3. This is a variation of HPACK
+compression that seeks to reduce head-of-line blocking.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.1">
+      <h2 id="name-note-to-readers">
+<a href="#name-note-to-readers" class="section-name selfRef">Note to Readers</a>
+      </h2>
+<p id="section-note.1-1">Discussion of this draft takes place on the QUIC working group mailing list
+(<a href="mailto:quic@ietf.org">quic@ietf.org</a>), which is archived at
+<span><a href="https://mailarchive.ietf.org/arch/search/?email_list=quic">https://mailarchive.ietf.org/arch/search/?email_list=quic</a></span>.<a href="#section-note.1-1" class="pilcrow">¶</a></p>
+<p id="section-note.1-2">Working Group information can be found at <span><a href="https://github.com/quicwg">https://github.com/quicwg</a></span>; source
+code and issues list for this draft can be found at
+<span><a href="https://github.com/quicwg/base-drafts/labels/-qpack">https://github.com/quicwg/base-drafts/labels/-qpack</a></span>.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
+</section>
+<div id="status-of-memo">
+<section id="section-boilerplate.1">
+        <h2 id="name-status-of-this-memo">
+<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
+        </h2>
+<p id="section-boilerplate.1-1">
+        This Internet-Draft is submitted in full conformance with the
+        provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-2">
+        Internet-Drafts are working documents of the Internet Engineering Task
+        Force (IETF). Note that other groups may also distribute working
+        documents as Internet-Drafts. The list of current Internet-Drafts is
+        at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-3">
+        Internet-Drafts are draft documents valid for a maximum of six months
+        and may be updated, replaced, or obsoleted by other documents at any
+        time. It is inappropriate to use Internet-Drafts as reference
+        material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-4">
+        This Internet-Draft will expire on 5 December 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="copyright">
+<section id="section-boilerplate.2">
+        <h2 id="name-copyright-notice">
+<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
+        </h2>
+<p id="section-boilerplate.2-1">
+            Copyright (c) 2020 IETF Trust and the persons identified as the
+            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.2-2">
+            This document is subject to BCP 78 and the IETF Trust's Legal
+            Provisions Relating to IETF Documents
+            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
+            publication of this document. Please review these documents
+            carefully, as they describe your rights and restrictions with
+            respect to this document. Code Components extracted from this
+            document must include Simplified BSD License text as described in
+            Section 4.e of the Trust Legal Provisions and are provided without
+            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="toc">
+<section id="section-toc.1">
+        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
+<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
+        </h2>
+<nav class="toc"><ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.1.2.1">
+                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-conventions-and-definitions" class="xref">Conventions and Definitions</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.1.2.2">
+                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-notational-conventions" class="xref">Notational Conventions</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-compression-process-overvie" class="xref">Compression Process Overview</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.1">
+                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-encoder" class="xref">Encoder</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.1.2.1">
+                    <p id="section-toc.1-1.2.2.1.2.1.1"><a href="#section-2.1.1" class="xref">2.1.1</a>.  <a href="#name-limits-on-dynamic-table-ins" class="xref">Limits on Dynamic Table Insertions</a><a href="#section-toc.1-1.2.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.1.2.2">
+                    <p id="section-toc.1-1.2.2.1.2.2.1"><a href="#section-2.1.2" class="xref">2.1.2</a>.  <a href="#name-blocked-streams" class="xref">Blocked Streams</a><a href="#section-toc.1-1.2.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.1.2.3">
+                    <p id="section-toc.1-1.2.2.1.2.3.1"><a href="#section-2.1.3" class="xref">2.1.3</a>.  <a href="#name-avoiding-flow-control-deadl" class="xref">Avoiding Flow Control Deadlocks</a><a href="#section-toc.1-1.2.2.1.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.1.2.4">
+                    <p id="section-toc.1-1.2.2.1.2.4.1"><a href="#section-2.1.4" class="xref">2.1.4</a>.  <a href="#name-known-received-count" class="xref">Known Received Count</a><a href="#section-toc.1-1.2.2.1.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.2">
+                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-decoder" class="xref">Decoder</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.2.2.1">
+                    <p id="section-toc.1-1.2.2.2.2.1.1"><a href="#section-2.2.1" class="xref">2.2.1</a>.  <a href="#name-blocked-decoding" class="xref">Blocked Decoding</a><a href="#section-toc.1-1.2.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.2.2.2">
+                    <p id="section-toc.1-1.2.2.2.2.2.1"><a href="#section-2.2.2" class="xref">2.2.2</a>.  <a href="#name-state-synchronization" class="xref">State Synchronization</a><a href="#section-toc.1-1.2.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.2.2.3">
+                    <p id="section-toc.1-1.2.2.2.2.3.1"><a href="#section-2.2.3" class="xref">2.2.3</a>.  <a href="#name-invalid-references" class="xref">Invalid References</a><a href="#section-toc.1-1.2.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-reference-tables" class="xref">Reference Tables</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.1">
+                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-static-table" class="xref">Static Table</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2">
+                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-dynamic-table" class="xref">Dynamic Table</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.1">
+                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-dynamic-table-size" class="xref">Dynamic Table Size</a><a href="#section-toc.1-1.3.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.2">
+                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-dynamic-table-capacity-and-" class="xref">Dynamic Table Capacity and Eviction</a><a href="#section-toc.1-1.3.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.3">
+                    <p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="xref">3.2.3</a>.  <a href="#name-maximum-dynamic-table-capac" class="xref">Maximum Dynamic Table Capacity</a><a href="#section-toc.1-1.3.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.4">
+                    <p id="section-toc.1-1.3.2.2.2.4.1"><a href="#section-3.2.4" class="xref">3.2.4</a>.  <a href="#name-absolute-indexing" class="xref">Absolute Indexing</a><a href="#section-toc.1-1.3.2.2.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.5">
+                    <p id="section-toc.1-1.3.2.2.2.5.1"><a href="#section-3.2.5" class="xref">3.2.5</a>.  <a href="#name-relative-indexing" class="xref">Relative Indexing</a><a href="#section-toc.1-1.3.2.2.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.6">
+                    <p id="section-toc.1-1.3.2.2.2.6.1"><a href="#section-3.2.6" class="xref">3.2.6</a>.  <a href="#name-post-base-indexing" class="xref">Post-Base Indexing</a><a href="#section-toc.1-1.3.2.2.2.6.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-wire-format" class="xref">Wire Format</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1">
+                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-primitives" class="xref">Primitives</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1.2.1">
+                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-prefixed-integers" class="xref">Prefixed Integers</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1.2.2">
+                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-string-literals" class="xref">String Literals</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2">
+                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-encoder-and-decoder-streams" class="xref">Encoder and Decoder Streams</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.3">
+                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-encoder-instructions" class="xref">Encoder Instructions</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.3.2.1">
+                    <p id="section-toc.1-1.4.2.3.2.1.1"><a href="#section-4.3.1" class="xref">4.3.1</a>.  <a href="#name-set-dynamic-table-capacity" class="xref">Set Dynamic Table Capacity</a><a href="#section-toc.1-1.4.2.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.3.2.2">
+                    <p id="section-toc.1-1.4.2.3.2.2.1"><a href="#section-4.3.2" class="xref">4.3.2</a>.  <a href="#name-insert-with-name-reference" class="xref">Insert With Name Reference</a><a href="#section-toc.1-1.4.2.3.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.3.2.3">
+                    <p id="section-toc.1-1.4.2.3.2.3.1"><a href="#section-4.3.3" class="xref">4.3.3</a>.  <a href="#name-insert-without-name-referen" class="xref">Insert Without Name Reference</a><a href="#section-toc.1-1.4.2.3.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.3.2.4">
+                    <p id="section-toc.1-1.4.2.3.2.4.1"><a href="#section-4.3.4" class="xref">4.3.4</a>.  <a href="#name-duplicate" class="xref">Duplicate</a><a href="#section-toc.1-1.4.2.3.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.4">
+                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-decoder-instructions" class="xref">Decoder Instructions</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.4.2.1">
+                    <p id="section-toc.1-1.4.2.4.2.1.1"><a href="#section-4.4.1" class="xref">4.4.1</a>.  <a href="#name-section-acknowledgement" class="xref">Section Acknowledgement</a><a href="#section-toc.1-1.4.2.4.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.4.2.2">
+                    <p id="section-toc.1-1.4.2.4.2.2.1"><a href="#section-4.4.2" class="xref">4.4.2</a>.  <a href="#name-stream-cancellation" class="xref">Stream Cancellation</a><a href="#section-toc.1-1.4.2.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.4.2.3">
+                    <p id="section-toc.1-1.4.2.4.2.3.1"><a href="#section-4.4.3" class="xref">4.4.3</a>.  <a href="#name-insert-count-increment" class="xref">Insert Count Increment</a><a href="#section-toc.1-1.4.2.4.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.5">
+                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-field-line-representations" class="xref">Field Line Representations</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.5.2.1">
+                    <p id="section-toc.1-1.4.2.5.2.1.1"><a href="#section-4.5.1" class="xref">4.5.1</a>.  <a href="#name-encoded-field-section-prefi" class="xref">Encoded Field Section Prefix</a><a href="#section-toc.1-1.4.2.5.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.5.2.2">
+                    <p id="section-toc.1-1.4.2.5.2.2.1"><a href="#section-4.5.2" class="xref">4.5.2</a>.  <a href="#name-indexed-field-line" class="xref">Indexed Field Line</a><a href="#section-toc.1-1.4.2.5.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.5.2.3">
+                    <p id="section-toc.1-1.4.2.5.2.3.1"><a href="#section-4.5.3" class="xref">4.5.3</a>.  <a href="#name-indexed-field-line-with-pos" class="xref">Indexed Field Line With Post-Base Index</a><a href="#section-toc.1-1.4.2.5.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.5.2.4">
+                    <p id="section-toc.1-1.4.2.5.2.4.1"><a href="#section-4.5.4" class="xref">4.5.4</a>.  <a href="#name-literal-field-line-with-nam" class="xref">Literal Field Line With Name Reference</a><a href="#section-toc.1-1.4.2.5.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.5.2.5">
+                    <p id="section-toc.1-1.4.2.5.2.5.1"><a href="#section-4.5.5" class="xref">4.5.5</a>.  <a href="#name-literal-field-line-with-pos" class="xref">Literal Field Line With Post-Base Name Reference</a><a href="#section-toc.1-1.4.2.5.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.5.2.6">
+                    <p id="section-toc.1-1.4.2.5.2.6.1"><a href="#section-4.5.6" class="xref">4.5.6</a>.  <a href="#name-literal-field-line-without-" class="xref">Literal Field Line Without Name Reference</a><a href="#section-toc.1-1.4.2.5.2.6.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-configuration" class="xref">Configuration</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-error-handling" class="xref">Error Handling</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-probing-dynamic-table-state" class="xref">Probing Dynamic Table State</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-applicability-to-qpack-and-" class="xref">Applicability to QPACK and HTTP</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.3">
+                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-mitigation" class="xref">Mitigation</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.4">
+                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-never-indexed-literals" class="xref">Never Indexed Literals</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.5">
+                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-static-huffman-encoding" class="xref">Static Huffman Encoding</a><a href="#section-toc.1-1.7.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.6">
+                <p id="section-toc.1-1.7.2.6.1"><a href="#section-7.6" class="xref">7.6</a>.  <a href="#name-memory-consumption" class="xref">Memory Consumption</a><a href="#section-toc.1-1.7.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.7">
+                <p id="section-toc.1-1.7.2.7.1"><a href="#section-7.7" class="xref">7.7</a>.  <a href="#name-implementation-limits" class="xref">Implementation Limits</a><a href="#section-toc.1-1.7.2.7.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.1">
+                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-settings-registration" class="xref">Settings Registration</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.2">
+                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-stream-type-registration" class="xref">Stream Type Registration</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.3">
+                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-error-code-registration" class="xref">Error Code Registration</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1">
+                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2">
+                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-static-table-2" class="xref">Static Table</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-sample-one-pass-encoding-al" class="xref">Sample One Pass Encoding Algorithm</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12">
+            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref">Appendix C</a>.  <a href="#name-change-log" class="xref">Change Log</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.1">
+                <p id="section-toc.1-1.12.2.1.1"><a href="#section-c.1" class="xref">C.1</a>.  <a href="#name-since-draft-ietf-quic-qpack" class="xref">Since draft-ietf-quic-qpack-14</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.2">
+                <p id="section-toc.1-1.12.2.2.1"><a href="#section-c.2" class="xref">C.2</a>.  <a href="#name-since-draft-ietf-quic-qpack-" class="xref">Since draft-ietf-quic-qpack-13</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.3">
+                <p id="section-toc.1-1.12.2.3.1"><a href="#section-c.3" class="xref">C.3</a>.  <a href="#name-since-draft-ietf-quic-qpack-1" class="xref">Since draft-ietf-quic-qpack-12</a><a href="#section-toc.1-1.12.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.4">
+                <p id="section-toc.1-1.12.2.4.1"><a href="#section-c.4" class="xref">C.4</a>.  <a href="#name-since-draft-ietf-quic-qpack-11" class="xref">Since draft-ietf-quic-qpack-11</a><a href="#section-toc.1-1.12.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.5">
+                <p id="section-toc.1-1.12.2.5.1"><a href="#section-c.5" class="xref">C.5</a>.  <a href="#name-since-draft-ietf-quic-qpack-10" class="xref">Since draft-ietf-quic-qpack-10</a><a href="#section-toc.1-1.12.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.6">
+                <p id="section-toc.1-1.12.2.6.1"><a href="#section-c.6" class="xref">C.6</a>.  <a href="#name-since-draft-ietf-quic-qpack-0" class="xref">Since draft-ietf-quic-qpack-09</a><a href="#section-toc.1-1.12.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.7">
+                <p id="section-toc.1-1.12.2.7.1"><a href="#section-c.7" class="xref">C.7</a>.  <a href="#name-since-draft-ietf-quic-qpack-08" class="xref">Since draft-ietf-quic-qpack-08</a><a href="#section-toc.1-1.12.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.8">
+                <p id="section-toc.1-1.12.2.8.1"><a href="#section-c.8" class="xref">C.8</a>.  <a href="#name-since-draft-ietf-quic-qpack-06" class="xref">Since draft-ietf-quic-qpack-06</a><a href="#section-toc.1-1.12.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.9">
+                <p id="section-toc.1-1.12.2.9.1"><a href="#section-c.9" class="xref">C.9</a>.  <a href="#name-since-draft-ietf-quic-qpack-05" class="xref">Since draft-ietf-quic-qpack-05</a><a href="#section-toc.1-1.12.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.10">
+                <p id="section-toc.1-1.12.2.10.1"><a href="#section-c.10" class="xref">C.10</a>. <a href="#name-since-draft-ietf-quic-qpack-04" class="xref">Since draft-ietf-quic-qpack-04</a><a href="#section-toc.1-1.12.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.11">
+                <p id="section-toc.1-1.12.2.11.1"><a href="#section-c.11" class="xref">C.11</a>. <a href="#name-since-draft-ietf-quic-qpack-03" class="xref">Since draft-ietf-quic-qpack-03</a><a href="#section-toc.1-1.12.2.11.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.12">
+                <p id="section-toc.1-1.12.2.12.1"><a href="#section-c.12" class="xref">C.12</a>. <a href="#name-since-draft-ietf-quic-qpack-02" class="xref">Since draft-ietf-quic-qpack-02</a><a href="#section-toc.1-1.12.2.12.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.13">
+                <p id="section-toc.1-1.12.2.13.1"><a href="#section-c.13" class="xref">C.13</a>. <a href="#name-since-draft-ietf-quic-qpack-01" class="xref">Since draft-ietf-quic-qpack-01</a><a href="#section-toc.1-1.12.2.13.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.14">
+                <p id="section-toc.1-1.12.2.14.1"><a href="#section-c.14" class="xref">C.14</a>. <a href="#name-since-draft-ietf-quic-qpack-00" class="xref">Since draft-ietf-quic-qpack-00</a><a href="#section-toc.1-1.12.2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.15">
+                <p id="section-toc.1-1.12.2.15.1"><a href="#section-c.15" class="xref">C.15</a>. <a href="#name-since-draft-ietf-quic-qcram" class="xref">Since draft-ietf-quic-qcram-00</a><a href="#section-toc.1-1.12.2.15.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13">
+            <p id="section-toc.1-1.13.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.14">
+            <p id="section-toc.1-1.14.1"><a href="#section-appendix.e" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</nav>
+</section>
+</div>
+<div id="introduction">
+<section id="section-1">
+      <h2 id="name-introduction">
+<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
+      </h2>
+<p id="section-1-1">The QUIC transport protocol <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> is designed to support HTTP
+semantics, and its design subsumes many of the features of HTTP/2 <span>[<a href="#RFC7540" class="xref">RFC7540</a>]</span>.
+HTTP/2 uses HPACK <span>[<a href="#RFC7541" class="xref">RFC7541</a>]</span> for compression of the header and trailer
+sections.  If HPACK were used for HTTP/3 <span>[<a href="#HTTP3" class="xref">HTTP3</a>]</span>, it would induce head-of-line
+blocking for field sections due to built-in assumptions of a total ordering
+across frames on all streams.<a href="#section-1-1" class="pilcrow">¶</a></p>
+<p id="section-1-2">QPACK reuses core concepts from HPACK, but is redesigned to allow correctness in
+the presence of out-of-order delivery, with flexibility for implementations to
+balance between resilience against head-of-line blocking and optimal compression
+ratio.  The design goals are to closely approach the compression ratio of HPACK
+with substantially less head-of-line blocking under the same loss conditions.<a href="#section-1-2" class="pilcrow">¶</a></p>
+<div id="conventions-and-definitions">
+<section id="section-1.1">
+        <h3 id="name-conventions-and-definitions">
+<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-conventions-and-definitions" class="section-name selfRef">Conventions and Definitions</a>
+        </h3>
+<p id="section-1.1-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
+"MAY", and "OPTIONAL" in this document are to be interpreted as
+described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they
+appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
+<p id="section-1.1-2">Definitions of terms that are used in this document:<a href="#section-1.1-2" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-1.1-3">
+          <dt id="section-1.1-3.1">HTTP fields:</dt>
+<dd id="section-1.1-3.2">
+  Metadata sent as part of an HTTP message.  The term encompasses both header
+and trailer fields. Colloquially, the term "headers" has often been used to
+refer to HTTP header fields and trailer fields; this document uses "fields"
+for generality.<a href="#section-1.1-3.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.3">HTTP field line:</dt>
+<dd id="section-1.1-3.4">
+  A name-value pair sent as part of an HTTP field section.  See Section 4 of
+<span>[<a href="#SEMANTICS" class="xref">SEMANTICS</a>]</span>.<a href="#section-1.1-3.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.5">HTTP field value:</dt>
+<dd id="section-1.1-3.6">
+  Data associated with a field name, composed from all field line values with
+that field name in that section, concatenated together and separated with
+commas.<a href="#section-1.1-3.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.7">Field section:</dt>
+<dd id="section-1.1-3.8">
+  An ordered collection of HTTP field lines associated with an HTTP message.  A
+field section can contain multiple field lines with the same name.  It can
+also contain duplicate field lines.  An HTTP message can include both header
+field and trailer field sections.<a href="#section-1.1-3.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.9">Representation:</dt>
+<dd id="section-1.1-3.10">
+  An instruction which represents a field line, possibly by reference to the
+dynamic and static tables.<a href="#section-1.1-3.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.11">Encoder:</dt>
+<dd id="section-1.1-3.12">
+  An implementation which encodes field sections.<a href="#section-1.1-3.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.13">Decoder:</dt>
+<dd id="section-1.1-3.14">
+  An implementation which decodes encoded field sections.<a href="#section-1.1-3.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.15">Absolute Index:</dt>
+<dd id="section-1.1-3.16">
+  A unique index for each entry in the dynamic table.<a href="#section-1.1-3.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.17">Base:</dt>
+<dd id="section-1.1-3.18">
+  A reference point for relative and post-base indices.  Representations which
+reference dynamic table entries are relative to a Base.<a href="#section-1.1-3.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.1-3.19">Insert Count:</dt>
+<dd id="section-1.1-3.20">
+  The total number of entries inserted in the dynamic table.<a href="#section-1.1-3.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-1.1-4">QPACK is a name, not an acronym.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="notational-conventions">
+<section id="section-1.2">
+        <h3 id="name-notational-conventions">
+<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-notational-conventions" class="section-name selfRef">Notational Conventions</a>
+        </h3>
+<p id="section-1.2-1">Diagrams use the format described in Section 3.1 of <span>[<a href="#RFC2360" class="xref">RFC2360</a>]</span>, with the
+following additional conventions:<a href="#section-1.2-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-1.2-2">
+          <dt id="section-1.2-2.1">x (A)</dt>
+<dd id="section-1.2-2.2">
+  Indicates that x is A bits long<a href="#section-1.2-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-2.3">x (A+)</dt>
+<dd id="section-1.2-2.4">
+  Indicates that x uses the prefixed integer encoding defined in
+<a href="#prefixed-integers" class="xref">Section 4.1.1</a>, beginning with an A-bit prefix.<a href="#section-1.2-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-2.5">x ...</dt>
+<dd id="section-1.2-2.6">
+  Indicates that x is variable-length and extends to the end of the region.<a href="#section-1.2-2.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+</section>
+</div>
+<div id="compression-process-overview">
+<section id="section-2">
+      <h2 id="name-compression-process-overvie">
+<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-compression-process-overvie" class="section-name selfRef">Compression Process Overview</a>
+      </h2>
+<p id="section-2-1">Like HPACK, QPACK uses two tables for associating field lines ("headers") to
+indices.  The static table (<a href="#header-table-static" class="xref">Section 3.1</a>) is predefined and contains
+common header field lines (some of them with an empty value).  The dynamic table
+(<a href="#header-table-dynamic" class="xref">Section 3.2</a>) is built up over the course of the connection and can
+be used by the encoder to index both header and trailer field lines in the
+encoded field sections.<a href="#section-2-1" class="pilcrow">¶</a></p>
+<p id="section-2-2">QPACK defines unidirectional streams for sending instructions from encoder to
+decoder and vice versa.<a href="#section-2-2" class="pilcrow">¶</a></p>
+<div id="encoder">
+<section id="section-2.1">
+        <h3 id="name-encoder">
+<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-encoder" class="section-name selfRef">Encoder</a>
+        </h3>
+<p id="section-2.1-1">An encoder converts a header or trailer field section into a series of
+representations by emitting either an indexed or a literal representation for
+each field line in the list; see <a href="#field-line-representations" class="xref">Section 4.5</a>.  Indexed
+representations achieve high compression by replacing the literal name and
+possibly the value with an index to either the static or dynamic table.
+References to the static table and literal representations do not require any
+dynamic state and never risk head-of-line blocking.  References to the dynamic
+table risk head-of-line blocking if the encoder has not received an
+acknowledgement indicating the entry is available at the decoder.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
+<p id="section-2.1-2">An encoder MAY insert any entry in the dynamic table it chooses; it is not
+limited to field lines it is compressing.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
+<p id="section-2.1-3">QPACK preserves the ordering of field lines within each field section.  An
+encoder MUST emit field representations in the order they appear in the input
+field section.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
+<p id="section-2.1-4">QPACK is designed to contain the more complex state tracking to the encoder,
+while the decoder is relatively simple.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
+<div id="blocked-insertion">
+<section id="section-2.1.1">
+          <h4 id="name-limits-on-dynamic-table-ins">
+<a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-limits-on-dynamic-table-ins" class="section-name selfRef">Limits on Dynamic Table Insertions</a>
+          </h4>
+<p id="section-2.1.1-1">Inserting entries into the dynamic table might not be possible if the table
+contains entries which cannot be evicted.<a href="#section-2.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-2.1.1-2">A dynamic table entry cannot be evicted immediately after insertion, even if it
+has never been referenced. Once the insertion of a dynamic table entry has been
+acknowledged and there are no outstanding references to the entry in
+unacknowledged representations, the entry becomes evictable.  Note that
+references on the encoder stream never preclude the eviction of an entry,
+because those references are guaranteed to be processed before the instruction
+evicting the entry.<a href="#section-2.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-2.1.1-3">If the dynamic table does not contain enough room for a new entry without
+evicting other entries, and the entries which would be evicted are not
+evictable, the encoder MUST NOT insert that entry into the dynamic table
+(including duplicates of existing entries). In order to avoid this, an encoder
+that uses the dynamic table has to keep track of each dynamic table entry
+referenced by each field section until those representations are acknowledged by
+the decoder; see <a href="#header-acknowledgement" class="xref">Section 4.4.1</a>.<a href="#section-2.1.1-3" class="pilcrow">¶</a></p>
+<div id="avoiding-prohibited-insertions">
+<section id="section-2.1.1.1">
+            <h5 id="name-avoiding-prohibited-inserti">
+<a href="#section-2.1.1.1" class="section-number selfRef">2.1.1.1. </a><a href="#name-avoiding-prohibited-inserti" class="section-name selfRef">Avoiding Prohibited Insertions</a>
+            </h5>
+<p id="section-2.1.1.1-1">To ensure that the encoder is not prevented from adding new entries, the encoder
+can avoid referencing entries that are close to eviction.  Rather than
+reference such an entry, the encoder can emit a Duplicate instruction
+(<a href="#duplicate" class="xref">Section 4.3.4</a>), and reference the duplicate instead.<a href="#section-2.1.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-2.1.1.1-2">Determining which entries are too close to eviction to reference is an encoder
+preference.  One heuristic is to target a fixed amount of available space in the
+dynamic table: either unused space or space that can be reclaimed by evicting
+non-blocking entries.  To achieve this, the encoder can maintain a draining
+index, which is the smallest absolute index (<a href="#indexing" class="xref">Section 3.2.4</a>) in the dynamic table
+that it will emit a reference for.  As new entries are inserted, the encoder
+increases the draining index to maintain the section of the table that it will
+not reference.  If the encoder does not create new references to entries with an
+absolute index lower than the draining index, the number of unacknowledged
+references to those entries will eventually become zero, allowing them to be
+evicted.<a href="#section-2.1.1.1-2" class="pilcrow">¶</a></p>
+<span id="name-draining-dynamic-table-entr"></span><div id="fig-draining-index">
+<figure id="figure-1">
+              <div class="artwork art-text alignLeft art-drawing" id="section-2.1.1.1-3.1">
+<pre>
+   +--------+---------------------------------+----------+
+   | Unused |          Referenceable          | Draining |
+   | Space  |             Entries             | Entries  |
+   +--------+---------------------------------+----------+
+            ^                                 ^          ^
+            |                                 |          |
+      Insertion Point                 Draining Index  Dropping
+                                                       Point
+</pre>
+</div>
+<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
+<a href="#name-draining-dynamic-table-entr" class="selfRef">Draining Dynamic Table Entries</a>
+              </figcaption></figure>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="blocked-streams">
+<section id="section-2.1.2">
+          <h4 id="name-blocked-streams">
+<a href="#section-2.1.2" class="section-number selfRef">2.1.2. </a><a href="#name-blocked-streams" class="section-name selfRef">Blocked Streams</a>
+          </h4>
+<p id="section-2.1.2-1">Because QUIC does not guarantee order between data on different streams, a
+decoder might encounter a representation that references a dynamic table entry
+that it has not yet received.<a href="#section-2.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-2.1.2-2">Each encoded field section contains a Required Insert Count (<a href="#header-prefix" class="xref">Section 4.5.1</a>),
+the lowest possible value for the Insert Count with which the field section can
+be decoded. For a field section encoded using references to the dynamic table,
+the Required Insert Count is one larger than the largest absolute index of all
+referenced dynamic table entries. For a field section encoded with no references
+to the dynamic table, the Required Insert Count is zero.<a href="#section-2.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-2.1.2-3">When the decoder receives an encoded field section with a Required Insert Count
+greater than its own Insert Count, the stream cannot be processed immediately,
+and is considered "blocked"; see <a href="#blocked-decoding" class="xref">Section 2.2.1</a>.<a href="#section-2.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-2.1.2-4">The decoder specifies an upper bound on the number of streams which can be
+blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting; see <a href="#configuration" class="xref">Section 5</a>.
+An encoder MUST limit the number of streams which could become blocked to the
+value of SETTINGS_QPACK_BLOCKED_STREAMS at all times. If a decoder encounters
+more blocked streams than it promised to support, it MUST treat this as a
+connection error of type QPACK_DECOMPRESSION_FAILED.<a href="#section-2.1.2-4" class="pilcrow">¶</a></p>
+<p id="section-2.1.2-5">Note that the decoder might not become blocked on every stream which risks
+becoming blocked.<a href="#section-2.1.2-5" class="pilcrow">¶</a></p>
+<p id="section-2.1.2-6">An encoder can decide whether to risk having a stream become blocked. If
+permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS, compression efficiency
+can often be improved by referencing dynamic table entries that are still in
+transit, but if there is loss or reordering the stream can become blocked at the
+decoder.  An encoder can avoid the risk of blocking by only referencing dynamic
+table entries which have been acknowledged, but this could mean using literals.
+Since literals make the encoded field section larger, this can result in the
+encoder becoming blocked on congestion or flow control limits.<a href="#section-2.1.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="avoiding-flow-control-deadlocks">
+<section id="section-2.1.3">
+          <h4 id="name-avoiding-flow-control-deadl">
+<a href="#section-2.1.3" class="section-number selfRef">2.1.3. </a><a href="#name-avoiding-flow-control-deadl" class="section-name selfRef">Avoiding Flow Control Deadlocks</a>
+          </h4>
+<p id="section-2.1.3-1">Writing instructions on streams that are limited by flow control can produce
+deadlocks.<a href="#section-2.1.3-1" class="pilcrow">¶</a></p>
+<p id="section-2.1.3-2">A decoder might stop issuing flow control credit on the stream that carries an
+encoded field section until the necessary updates are received on the encoder
+stream. If the granting of flow control credit on the encoder stream (or the
+connection as a whole) depends on the consumption and release of data on the
+stream carrying the encoded field section, a deadlock might result.<a href="#section-2.1.3-2" class="pilcrow">¶</a></p>
+<p id="section-2.1.3-3">More generally, a stream containing a large instruction can become deadlocked if
+the decoder withholds flow control credit until the instruction is completely
+received.<a href="#section-2.1.3-3" class="pilcrow">¶</a></p>
+<p id="section-2.1.3-4">To avoid these deadlocks, an encoder SHOULD avoid writing an instruction unless
+sufficient stream and connection flow control credit is available for the entire
+instruction.<a href="#section-2.1.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="known-received-count">
+<section id="section-2.1.4">
+          <h4 id="name-known-received-count">
+<a href="#section-2.1.4" class="section-number selfRef">2.1.4. </a><a href="#name-known-received-count" class="section-name selfRef">Known Received Count</a>
+          </h4>
+<p id="section-2.1.4-1">The Known Received Count is the total number of dynamic table insertions and
+duplications acknowledged by the decoder.  The encoder tracks the Known Received
+Count in order to identify which dynamic table entries can be referenced without
+potentially blocking a stream.  The decoder tracks the Known Received Count in
+order to be able to send Insert Count Increment instructions.<a href="#section-2.1.4-1" class="pilcrow">¶</a></p>
+<p id="section-2.1.4-2">A Section Acknowledgement instruction (<a href="#header-acknowledgement" class="xref">Section 4.4.1</a>) implies that
+the decoder has received all dynamic table state necessary to decode the field
+section.  If the Required Insert Count of the acknowledged field section is
+greater than the current Known Received Count, Known Received Count is updated
+to the value of the Required Insert Count.<a href="#section-2.1.4-2" class="pilcrow">¶</a></p>
+<p id="section-2.1.4-3">An Insert Count Increment instruction <a href="#insert-count-increment" class="xref">Section 4.4.3</a> increases the
+Known Received Count by its Increment parameter.  See <a href="#new-table-entries" class="xref">Section 2.2.2.3</a> for
+guidance.<a href="#section-2.1.4-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="decoder">
+<section id="section-2.2">
+        <h3 id="name-decoder">
+<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-decoder" class="section-name selfRef">Decoder</a>
+        </h3>
+<p id="section-2.2-1">As in HPACK, the decoder processes a series of representations and emits the
+corresponding field sections. It also processes instructions received on the
+encoder stream that modify the dynamic table.  Note that encoded field sections
+and encoder stream instructions arrive on separate streams.  This is unlike
+HPACK, where encoded field sections (header blocks) can contain instructions
+that modify the dynamic table, and there is no dedicated stream of HPACK
+instructions.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
+<p id="section-2.2-2">The decoder MUST emit field lines in the order their representations appear in
+the encoded field section.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
+<div id="blocked-decoding">
+<section id="section-2.2.1">
+          <h4 id="name-blocked-decoding">
+<a href="#section-2.2.1" class="section-number selfRef">2.2.1. </a><a href="#name-blocked-decoding" class="section-name selfRef">Blocked Decoding</a>
+          </h4>
+<p id="section-2.2.1-1">Upon receipt of an encoded field section, the decoder examines the Required
+Insert Count. When the Required Insert Count is less than or equal to the
+decoder's Insert Count, the field section can be processed immediately.
+Otherwise, the stream on which the field section was received becomes blocked.<a href="#section-2.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-2.2.1-2">While blocked, encoded field section data SHOULD remain in the blocked stream's
+flow control window.  A stream becomes unblocked when the Insert Count becomes
+greater than or equal to the Required Insert Count for all encoded field
+sections the decoder has started reading from the stream.<a href="#section-2.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-2.2.1-3">When processing encoded field sections, the decoder expects the Required Insert
+Count to equal the lowest possible value for the Insert Count with which the
+field section can be decoded, as prescribed in <a href="#blocked-streams" class="xref">Section 2.1.2</a>. If it
+encounters a Required Insert Count smaller than expected, it MUST treat this as
+a connection error of type QPACK_DECOMPRESSION_FAILED; see
+<a href="#invalid-references" class="xref">Section 2.2.3</a>. If it encounters a Required Insert Count larger than
+expected, it MAY treat this as a connection error of type
+QPACK_DECOMPRESSION_FAILED.<a href="#section-2.2.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="state-synchronization">
+<section id="section-2.2.2">
+          <h4 id="name-state-synchronization">
+<a href="#section-2.2.2" class="section-number selfRef">2.2.2. </a><a href="#name-state-synchronization" class="section-name selfRef">State Synchronization</a>
+          </h4>
+<p id="section-2.2.2-1">The decoder signals the following events by emitting decoder instructions
+(<a href="#decoder-instructions" class="xref">Section 4.4</a>) on the decoder stream.<a href="#section-2.2.2-1" class="pilcrow">¶</a></p>
+<div id="completed-processing-of-a-field-section">
+<section id="section-2.2.2.1">
+            <h5 id="name-completed-processing-of-a-f">
+<a href="#section-2.2.2.1" class="section-number selfRef">2.2.2.1. </a><a href="#name-completed-processing-of-a-f" class="section-name selfRef">Completed Processing of a Field Section</a>
+            </h5>
+<p id="section-2.2.2.1-1">After the decoder finishes decoding a field section encoded using
+representations containing dynamic table references, it MUST emit a Section
+Acknowledgement instruction (<a href="#header-acknowledgement" class="xref">Section 4.4.1</a>).  A stream may carry
+multiple field sections in the case of intermediate responses, trailers, and
+pushed requests.  The encoder interprets each Section Acknowledgement
+instruction as acknowledging the earliest unacknowledged field section
+containing dynamic table references sent on the given stream.<a href="#section-2.2.2.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="abandonment-of-a-stream">
+<section id="section-2.2.2.2">
+            <h5 id="name-abandonment-of-a-stream">
+<a href="#section-2.2.2.2" class="section-number selfRef">2.2.2.2. </a><a href="#name-abandonment-of-a-stream" class="section-name selfRef">Abandonment of a Stream</a>
+            </h5>
+<p id="section-2.2.2.2-1">When an endpoint receives a stream reset before the end of a stream or before
+all encoded field sections are processed on that stream, or when it abandons
+reading of a stream, it generates a Stream Cancellation instruction; see
+<a href="#stream-cancellation" class="xref">Section 4.4.2</a>.  This signals to the encoder that all references to the
+dynamic table on that stream are no longer outstanding.  A decoder with a
+maximum dynamic table capacity (<a href="#maximum-dynamic-table-capacity" class="xref">Section 3.2.3</a>) equal to
+zero MAY omit sending Stream Cancellations, because the encoder cannot have any
+dynamic table references.  An encoder cannot infer from this instruction that
+any updates to the dynamic table have been received.<a href="#section-2.2.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-2.2.2.2-2">The Section Acknowledgement and Stream Cancellation instructions permit the
+encoder to remove references to entries in the dynamic table.  When an entry
+with absolute index lower than the Known Received Count has zero references,
+then it is considered evictable; see <a href="#blocked-insertion" class="xref">Section 2.1.1</a>.<a href="#section-2.2.2.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="new-table-entries">
+<section id="section-2.2.2.3">
+            <h5 id="name-new-table-entries">
+<a href="#section-2.2.2.3" class="section-number selfRef">2.2.2.3. </a><a href="#name-new-table-entries" class="section-name selfRef">New Table Entries</a>
+            </h5>
+<p id="section-2.2.2.3-1">After receiving new table entries on the encoder stream, the decoder chooses
+when to emit Insert Count Increment instructions; see
+<a href="#insert-count-increment" class="xref">Section 4.4.3</a>. Emitting this instruction after adding each new
+dynamic table entry will provide the timeliest feedback to the encoder, but
+could be redundant with other decoder feedback. By delaying an Insert Count
+Increment instruction, the decoder might be able to coalesce multiple Insert
+Count Increment instructions, or replace them entirely with Section
+Acknowledgements; see <a href="#header-acknowledgement" class="xref">Section 4.4.1</a>. However, delaying too long
+may lead to compression inefficiencies if the encoder waits for an entry to be
+acknowledged before using it.<a href="#section-2.2.2.3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="invalid-references">
+<section id="section-2.2.3">
+          <h4 id="name-invalid-references">
+<a href="#section-2.2.3" class="section-number selfRef">2.2.3. </a><a href="#name-invalid-references" class="section-name selfRef">Invalid References</a>
+          </h4>
+<p id="section-2.2.3-1">If the decoder encounters a reference in a field line representation to a
+dynamic table entry which has already been evicted or which has an absolute
+index greater than or equal to the declared Required Insert Count
+(<a href="#header-prefix" class="xref">Section 4.5.1</a>), it MUST treat this as a connection error of type
+QPACK_DECOMPRESSION_FAILED.<a href="#section-2.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-2.2.3-2">If the decoder encounters a reference in an encoder instruction to a dynamic
+table entry which has already been evicted, it MUST treat this as a connection
+error of type QPACK_ENCODER_STREAM_ERROR.<a href="#section-2.2.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="reference-tables">
+<section id="section-3">
+      <h2 id="name-reference-tables">
+<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-reference-tables" class="section-name selfRef">Reference Tables</a>
+      </h2>
+<p id="section-3-1">Unlike in HPACK, entries in the QPACK static and dynamic tables are addressed
+separately.  The following sections describe how entries in each table are
+addressed.<a href="#section-3-1" class="pilcrow">¶</a></p>
+<div id="header-table-static">
+<section id="section-3.1">
+        <h3 id="name-static-table">
+<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-static-table" class="section-name selfRef">Static Table</a>
+        </h3>
+<p id="section-3.1-1">The static table consists of a predefined static list of field lines, each of
+which has a fixed index over time.  Its entries are defined in <a href="#static-table" class="xref">Appendix A</a>.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+<p id="section-3.1-2">All entries in the static table have a name and a value.  However, values can be
+empty (that is, have a length of 0).  Each entry is identified by a unique
+index.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
+<p id="section-3.1-3">Note that the QPACK static table is indexed from 0, whereas the HPACK static
+table is indexed from 1.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
+<p id="section-3.1-4">When the decoder encounters an invalid static table index in a field line
+representation it MUST treat this as a connection error of type
+QPACK_DECOMPRESSION_FAILED.  If this index is received on the encoder stream,
+this MUST be treated as a connection error of type QPACK_ENCODER_STREAM_ERROR.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="header-table-dynamic">
+<section id="section-3.2">
+        <h3 id="name-dynamic-table">
+<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-dynamic-table" class="section-name selfRef">Dynamic Table</a>
+        </h3>
+<p id="section-3.2-1">The dynamic table consists of a list of field lines maintained in first-in,
+first-out order. Each HTTP/3 endpoint holds a dynamic table that is initially
+empty.  Entries are added by encoder instructions received on the encoder
+stream; see <a href="#encoder-instructions" class="xref">Section 4.3</a>.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
+<p id="section-3.2-2">The dynamic table can contain duplicate entries (i.e., entries with the same
+name and same value).  Therefore, duplicate entries MUST NOT be treated as an
+error by the decoder.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
+<p id="section-3.2-3">Dynamic table entries can have empty values.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
+<div id="dynamic-table-size">
+<section id="section-3.2.1">
+          <h4 id="name-dynamic-table-size">
+<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-dynamic-table-size" class="section-name selfRef">Dynamic Table Size</a>
+          </h4>
+<p id="section-3.2.1-1">The size of the dynamic table is the sum of the size of its entries.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-3.2.1-2">The size of an entry is the sum of its name's length in bytes, its value's
+length in bytes, and 32.  The size of an entry is calculated using the length of
+its name and value without Huffman encoding applied.<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="eviction">
+<section id="section-3.2.2">
+          <h4 id="name-dynamic-table-capacity-and-">
+<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-dynamic-table-capacity-and-" class="section-name selfRef">Dynamic Table Capacity and Eviction</a>
+          </h4>
+<p id="section-3.2.2-1">The encoder sets the capacity of the dynamic table, which serves as the upper
+limit on its size.  The initial capacity of the dynamic table is zero.  The
+encoder sends a Set Dynamic Table Capacity instruction
+(<a href="#set-dynamic-capacity" class="xref">Section 4.3.1</a>) with a non-zero capacity to begin using the dynamic
+table.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-3.2.2-2">Before a new entry is added to the dynamic table, entries are evicted from the
+end of the dynamic table until the size of the dynamic table is less than or
+equal to (table capacity - size of new entry). The encoder MUST NOT cause a
+dynamic table entry to be evicted unless that entry is evictable; see
+<a href="#blocked-insertion" class="xref">Section 2.1.1</a>.  The new entry is then added to the table.  It is an
+error if the encoder attempts to add an entry that is larger than the dynamic
+table capacity; the decoder MUST treat this as a connection error of type
+QPACK_ENCODER_STREAM_ERROR.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
+<p id="section-3.2.2-3">A new entry can reference an entry in the dynamic table that will be evicted
+when adding this new entry into the dynamic table.  Implementations are
+cautioned to avoid deleting the referenced name or value if the referenced entry
+is evicted from the dynamic table prior to inserting the new entry.<a href="#section-3.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-3.2.2-4">Whenever the dynamic table capacity is reduced by the encoder
+(<a href="#set-dynamic-capacity" class="xref">Section 4.3.1</a>), entries are evicted from the end of the dynamic
+table until the size of the dynamic table is less than or equal to the new table
+capacity.  This mechanism can be used to completely clear entries from the
+dynamic table by setting a capacity of 0, which can subsequently be restored.<a href="#section-3.2.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="maximum-dynamic-table-capacity">
+<section id="section-3.2.3">
+          <h4 id="name-maximum-dynamic-table-capac">
+<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-maximum-dynamic-table-capac" class="section-name selfRef">Maximum Dynamic Table Capacity</a>
+          </h4>
+<p id="section-3.2.3-1">To bound the memory requirements of the decoder, the decoder limits the maximum
+value the encoder is permitted to set for the dynamic table capacity.  In
+HTTP/3, this limit is determined by the value of
+SETTINGS_QPACK_MAX_TABLE_CAPACITY sent by the decoder; see <a href="#configuration" class="xref">Section 5</a>.
+The encoder MUST not set a dynamic table capacity that exceeds this maximum, but
+it can choose to use a lower dynamic table capacity; see
+<a href="#set-dynamic-capacity" class="xref">Section 4.3.1</a>.<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-3.2.3-2">For clients using 0-RTT data in HTTP/3, the server's maximum table capacity is
+the remembered value of the setting, or zero if the value was not previously
+sent.  When the client's 0-RTT value of the SETTING is zero, the server MAY set
+it to a non-zero value in its SETTINGS frame. If the remembered value is
+non-zero, the server MUST send the same non-zero value in its SETTINGS frame. If
+it specifies any other value, or omits SETTINGS_QPACK_MAX_TABLE_CAPACITY from
+SETTINGS, the encoder must treat this as a connection error of type
+QPACK_DECODER_STREAM_ERROR.<a href="#section-3.2.3-2" class="pilcrow">¶</a></p>
+<p id="section-3.2.3-3">For HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or is
+rejected, the maximum table capacity is 0 until the encoder processes a SETTINGS
+frame with a non-zero value of SETTINGS_QPACK_MAX_TABLE_CAPACITY.<a href="#section-3.2.3-3" class="pilcrow">¶</a></p>
+<p id="section-3.2.3-4">When the maximum table capacity is zero, the encoder MUST NOT insert entries
+into the dynamic table, and MUST NOT send any encoder instructions on the
+encoder stream.<a href="#section-3.2.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="indexing">
+<section id="section-3.2.4">
+          <h4 id="name-absolute-indexing">
+<a href="#section-3.2.4" class="section-number selfRef">3.2.4. </a><a href="#name-absolute-indexing" class="section-name selfRef">Absolute Indexing</a>
+          </h4>
+<p id="section-3.2.4-1">Each entry possesses an absolute index which is fixed for the lifetime of that
+entry. The first entry inserted has an absolute index of "0"; indices increase
+by one with each insertion.<a href="#section-3.2.4-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="relative-indexing">
+<section id="section-3.2.5">
+          <h4 id="name-relative-indexing">
+<a href="#section-3.2.5" class="section-number selfRef">3.2.5. </a><a href="#name-relative-indexing" class="section-name selfRef">Relative Indexing</a>
+          </h4>
+<p id="section-3.2.5-1">Relative indices begin at zero and increase in the opposite direction from the
+absolute index.  Determining which entry has a relative index of "0" depends on
+the context of the reference.<a href="#section-3.2.5-1" class="pilcrow">¶</a></p>
+<p id="section-3.2.5-2">In encoder instructions (<a href="#encoder-instructions" class="xref">Section 4.3</a>), a relative index of "0"
+refers to the most recently inserted value in the dynamic table.  Note that this
+means the entry referenced by a given relative index will change while
+interpreting instructions on the encoder stream.<a href="#section-3.2.5-2" class="pilcrow">¶</a></p>
+<span id="name-example-dynamic-table-index"></span><figure id="figure-2">
+            <div class="artwork art-text alignLeft art-drawing" id="section-3.2.5-3.1">
+<pre>
+      +-----+---------------+-------+
+      | n-1 |      ...      |   d   |  Absolute Index
+      + - - +---------------+ - - - +
+      |  0  |      ...      | n-d-1 |  Relative Index
+      +-----+---------------+-------+
+      ^                             |
+      |                             V
+Insertion Point               Dropping Point
+
+n = count of entries inserted
+d = count of entries dropped
+</pre>
+</div>
+<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
+<a href="#name-example-dynamic-table-index" class="selfRef">Example Dynamic Table Indexing - Encoder Stream</a>
+            </figcaption></figure>
+<p id="section-3.2.5-4">Unlike in encoder instructions, relative indices in field line representations
+are relative to the Base at the beginning of the encoded field section; see
+<a href="#header-prefix" class="xref">Section 4.5.1</a>. This ensures that references are stable even if encoded field
+sections and dynamic table updates are processed out of order.<a href="#section-3.2.5-4" class="pilcrow">¶</a></p>
+<p id="section-3.2.5-5">In a field line representation, a relative index of "0" refers to the entry with
+absolute index equal to Base - 1.<a href="#section-3.2.5-5" class="pilcrow">¶</a></p>
+<span id="name-example-dynamic-table-indexi"></span><figure id="figure-3">
+            <div class="artwork art-text alignLeft art-drawing" id="section-3.2.5-6.1">
+<pre>
+               Base
+                |
+                V
+    +-----+-----+-----+-----+-------+
+    | n-1 | n-2 | n-3 | ... |   d   |  Absolute Index
+    +-----+-----+  -  +-----+   -   +
+                |  0  | ... | n-d-3 |  Relative Index
+                +-----+-----+-------+
+
+n = count of entries inserted
+d = count of entries dropped
+In this example, Base = n - 2
+</pre>
+</div>
+<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
+<a href="#name-example-dynamic-table-indexi" class="selfRef">Example Dynamic Table Indexing - Relative Index in Representation</a>
+            </figcaption></figure>
+</section>
+</div>
+<div id="post-base">
+<section id="section-3.2.6">
+          <h4 id="name-post-base-indexing">
+<a href="#section-3.2.6" class="section-number selfRef">3.2.6. </a><a href="#name-post-base-indexing" class="section-name selfRef">Post-Base Indexing</a>
+          </h4>
+<p id="section-3.2.6-1">Post-Base indices are used in field line representations for entries with
+absolute indices greater than or equal to Base, starting at 0 for the entry with
+absolute index equal to Base, and increasing in the same direction as the
+absolute index.<a href="#section-3.2.6-1" class="pilcrow">¶</a></p>
+<p id="section-3.2.6-2">Post-Base indices allow an encoder to process a field section in a single pass
+and include references to entries added while processing this (or other) field
+sections.<a href="#section-3.2.6-2" class="pilcrow">¶</a></p>
+<span id="name-example-dynamic-table-indexin"></span><figure id="figure-4">
+            <div class="artwork art-text alignLeft art-drawing" id="section-3.2.6-3.1">
+<pre>
+               Base
+                |
+                V
+    +-----+-----+-----+-----+-----+
+    | n-1 | n-2 | n-3 | ... |  d  |  Absolute Index
+    +-----+-----+-----+-----+-----+
+    |  1  |  0  |                    Post-Base Index
+    +-----+-----+
+
+n = count of entries inserted
+d = count of entries dropped
+In this example, Base = n - 2
+</pre>
+</div>
+<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
+<a href="#name-example-dynamic-table-indexin" class="selfRef">Example Dynamic Table Indexing - Post-Base Index in Representation</a>
+            </figcaption></figure>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="wire-format">
+<section id="section-4">
+      <h2 id="name-wire-format">
+<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-wire-format" class="section-name selfRef">Wire Format</a>
+      </h2>
+<div id="primitives">
+<section id="section-4.1">
+        <h3 id="name-primitives">
+<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-primitives" class="section-name selfRef">Primitives</a>
+        </h3>
+<div id="prefixed-integers">
+<section id="section-4.1.1">
+          <h4 id="name-prefixed-integers">
+<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-prefixed-integers" class="section-name selfRef">Prefixed Integers</a>
+          </h4>
+<p id="section-4.1.1-1">The prefixed integer from Section 5.1 of <span>[<a href="#RFC7541" class="xref">RFC7541</a>]</span> is used heavily throughout
+this document.  The format from <span>[<a href="#RFC7541" class="xref">RFC7541</a>]</span> is used unmodified.  Note, however,
+that QPACK uses some prefix sizes not actually used in HPACK.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.1-2">QPACK implementations MUST be able to decode integers up to and including 62
+bits long.<a href="#section-4.1.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="string-literals">
+<section id="section-4.1.2">
+          <h4 id="name-string-literals">
+<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-string-literals" class="section-name selfRef">String Literals</a>
+          </h4>
+<p id="section-4.1.2-1">The string literal defined by Section 5.2 of <span>[<a href="#RFC7541" class="xref">RFC7541</a>]</span> is also used throughout.
+This string format includes optional Huffman encoding.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-2">HPACK defines string literals to begin on a byte boundary.  They begin with a
+single bit flag, denoted as 'H' in this document (indicating whether the string
+is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer,
+and finally Length bytes of data. When Huffman encoding is enabled, the Huffman
+table from Appendix B of <span>[<a href="#RFC7541" class="xref">RFC7541</a>]</span> is used without modification.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-3">This document expands the definition of string literals and permits them to
+begin other than on a byte boundary.  An "N-bit prefix string literal" begins
+with the same Huffman flag, followed by the length encoded as an (N-1)-bit
+prefix integer.  The prefix size, N, can have a value between 2 and 8 inclusive.
+The remainder of the string literal is unmodified.<a href="#section-4.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-4">A string literal without a prefix length noted is an 8-bit prefix string literal
+and follows the definitions in <span>[<a href="#RFC7541" class="xref">RFC7541</a>]</span> without modification.<a href="#section-4.1.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="enc-dec-stream-def">
+<section id="section-4.2">
+        <h3 id="name-encoder-and-decoder-streams">
+<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-encoder-and-decoder-streams" class="section-name selfRef">Encoder and Decoder Streams</a>
+        </h3>
+<p id="section-4.2-1">QPACK defines two unidirectional stream types:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.2-2.1">An encoder stream is a unidirectional stream of type 0x02.
+It carries an unframed sequence of encoder instructions from encoder
+to decoder.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.2-2.2">A decoder stream is a unidirectional stream of type 0x03.
+It carries an unframed sequence of decoder instructions from decoder
+to encoder.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.2-3">HTTP/3 endpoints contain a QPACK encoder and decoder. Each endpoint MUST
+initiate at most one encoder stream and at most one decoder stream. Receipt of a
+second instance of either stream type MUST be treated as a connection error of
+type H3_STREAM_CREATION_ERROR. These streams MUST NOT be closed. Closure of
+either unidirectional stream type MUST be treated as a connection error of type
+H3_CLOSED_CRITICAL_STREAM.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
+<p id="section-4.2-4">An endpoint MAY avoid creating an encoder stream if it's not going to be used
+(for example if its encoder doesn't wish to use the dynamic table, or if the
+maximum size of the dynamic table permitted by the peer is zero).<a href="#section-4.2-4" class="pilcrow">¶</a></p>
+<p id="section-4.2-5">An endpoint MAY avoid creating a decoder stream if its decoder sets the maximum
+capacity of the dynamic table to zero.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
+<p id="section-4.2-6">An endpoint MUST allow its peer to create an encoder stream and a decoder stream
+even if the connection's settings prevent their use.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="encoder-instructions">
+<section id="section-4.3">
+        <h3 id="name-encoder-instructions">
+<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-encoder-instructions" class="section-name selfRef">Encoder Instructions</a>
+        </h3>
+<p id="section-4.3-1">An encoder sends encoder instructions on the encoder stream to set the capacity
+of the dynamic table and add dynamic table entries.  Instructions adding table
+entries can use existing entries to avoid transmitting redundant information.
+The name can be transmitted as a reference to an existing entry in the static or
+the dynamic table or as a string literal.  For entries which already exist in
+the dynamic table, the full entry can also be used by reference, creating a
+duplicate entry.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+<p id="section-4.3-2">This section specifies the following encoder instructions.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
+<div id="set-dynamic-capacity">
+<section id="section-4.3.1">
+          <h4 id="name-set-dynamic-table-capacity">
+<a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-set-dynamic-table-capacity" class="section-name selfRef">Set Dynamic Table Capacity</a>
+          </h4>
+<p id="section-4.3.1-1">An encoder informs the decoder of a change to the dynamic table capacity using
+an instruction which begins with the '001' three-bit pattern.  This is followed
+by the new dynamic table capacity represented as an integer with a 5-bit prefix;
+see <a href="#prefixed-integers" class="xref">Section 4.1.1</a>.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
+<span id="name-set-dynamic-table-capacity-2"></span><div id="fig-set-capacity">
+<figure id="figure-5">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.3.1-2.1">
+<pre>
+  0   1   2   3   4   5   6   7
++---+---+---+---+---+---+---+---+
+| 0 | 0 | 1 |   Capacity (5+)   |
++---+---+---+-------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
+<a href="#name-set-dynamic-table-capacity-2" class="selfRef">Set Dynamic Table Capacity</a>
+            </figcaption></figure>
+</div>
+<p id="section-4.3.1-3">The new capacity MUST be lower than or equal to the limit described in
+<a href="#maximum-dynamic-table-capacity" class="xref">Section 3.2.3</a>.  In HTTP/3, this limit is the value of the
+SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter (<a href="#configuration" class="xref">Section 5</a>) received from
+the decoder.  The decoder MUST treat a new dynamic table capacity value that
+exceeds this limit as a connection error of type QPACK_ENCODER_STREAM_ERROR.<a href="#section-4.3.1-3" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-4">Reducing the dynamic table capacity can cause entries to be evicted; see
+<a href="#eviction" class="xref">Section 3.2.2</a>.  This MUST NOT cause the eviction of entries which are not
+evictable; see <a href="#blocked-insertion" class="xref">Section 2.1.1</a>.  Changing the capacity of the dynamic
+table is not acknowledged as this instruction does not insert an entry.<a href="#section-4.3.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="insert-with-name-reference">
+<section id="section-4.3.2">
+          <h4 id="name-insert-with-name-reference">
+<a href="#section-4.3.2" class="section-number selfRef">4.3.2. </a><a href="#name-insert-with-name-reference" class="section-name selfRef">Insert With Name Reference</a>
+          </h4>
+<p id="section-4.3.2-1">An encoder adds an entry to the dynamic table where the field name matches the
+field name of an entry stored in the static or the dynamic table using an
+instruction that starts with the '1' one-bit pattern.  The second ('T') bit
+indicates whether the reference is to the static or dynamic table. The 6-bit
+prefix integer (<a href="#prefixed-integers" class="xref">Section 4.1.1</a>) that follows is used to locate the table
+entry for the field name.  When T=1, the number represents the static table
+index; when T=0, the number is the relative index of the entry in the dynamic
+table.<a href="#section-4.3.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.3.2-2">The field name reference is followed by the field value represented as a string
+literal; see <a href="#string-literals" class="xref">Section 4.1.2</a>.<a href="#section-4.3.2-2" class="pilcrow">¶</a></p>
+<span id="name-insert-field-line-indexed-n"></span><figure id="figure-6">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.3.2-3.1">
+<pre>
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 1 | T |    Name Index (6+)    |
+   +---+---+-----------------------+
+   | H |     Value Length (7+)     |
+   +---+---------------------------+
+   |  Value String (Length bytes)  |
+   +-------------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
+<a href="#name-insert-field-line-indexed-n" class="selfRef">Insert Field Line -- Indexed Name</a>
+            </figcaption></figure>
+</section>
+</div>
+<div id="insert-without-name-reference">
+<section id="section-4.3.3">
+          <h4 id="name-insert-without-name-referen">
+<a href="#section-4.3.3" class="section-number selfRef">4.3.3. </a><a href="#name-insert-without-name-referen" class="section-name selfRef">Insert Without Name Reference</a>
+          </h4>
+<p id="section-4.3.3-1">An encoder adds an entry to the dynamic table where both the field name and the
+field value are represented as string literals using an instruction that starts
+with the '01' two-bit pattern.<a href="#section-4.3.3-1" class="pilcrow">¶</a></p>
+<p id="section-4.3.3-2">This is followed by the name represented as a 6-bit prefix string literal, and
+the value represented as an 8-bit prefix string literal; see
+<a href="#string-literals" class="xref">Section 4.1.2</a>.<a href="#section-4.3.3-2" class="pilcrow">¶</a></p>
+<span id="name-insert-field-line-new-name"></span><figure id="figure-7">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.3.3-3.1">
+<pre>
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 1 | H | Name Length (5+)  |
+   +---+---+---+-------------------+
+   |  Name String (Length bytes)   |
+   +---+---------------------------+
+   | H |     Value Length (7+)     |
+   +---+---------------------------+
+   |  Value String (Length bytes)  |
+   +-------------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
+<a href="#name-insert-field-line-new-name" class="selfRef">Insert Field Line -- New Name</a>
+            </figcaption></figure>
+</section>
+</div>
+<div id="duplicate">
+<section id="section-4.3.4">
+          <h4 id="name-duplicate">
+<a href="#section-4.3.4" class="section-number selfRef">4.3.4. </a><a href="#name-duplicate" class="section-name selfRef">Duplicate</a>
+          </h4>
+<p id="section-4.3.4-1">An encoder duplicates an existing entry in the dynamic table using an
+instruction that begins with the '000' three-bit pattern.  This is followed by
+the relative index of the existing entry represented as an integer with a 5-bit
+prefix; see <a href="#prefixed-integers" class="xref">Section 4.1.1</a>.<a href="#section-4.3.4-1" class="pilcrow">¶</a></p>
+<span id="name-duplicate-2"></span><div id="fig-index-with-duplication">
+<figure id="figure-8">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.3.4-2.1">
+<pre>
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 | 0 |    Index (5+)     |
+   +---+---+---+-------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
+<a href="#name-duplicate-2" class="selfRef">Duplicate</a>
+            </figcaption></figure>
+</div>
+<p id="section-4.3.4-3">The existing entry is re-inserted into the dynamic table without resending
+either the name or the value. This is useful to avoid adding a reference to an
+older entry, which might block inserting new entries.<a href="#section-4.3.4-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="decoder-instructions">
+<section id="section-4.4">
+        <h3 id="name-decoder-instructions">
+<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-decoder-instructions" class="section-name selfRef">Decoder Instructions</a>
+        </h3>
+<p id="section-4.4-1">A decoder sends decoder instructions on the decoder stream to inform the encoder
+about the processing of field sections and table updates to ensure consistency
+of the dynamic table.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
+<p id="section-4.4-2">This section specifies the following decoder instructions.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
+<div id="header-acknowledgement">
+<section id="section-4.4.1">
+          <h4 id="name-section-acknowledgement">
+<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-section-acknowledgement" class="section-name selfRef">Section Acknowledgement</a>
+          </h4>
+<p id="section-4.4.1-1">After processing an encoded field section whose declared Required Insert Count
+is not zero, the decoder emits a Section Acknowledgement instruction.  The
+instruction begins with the '1' one-bit pattern which is followed by the field
+section's associated stream ID encoded as a 7-bit prefix integer; see
+<a href="#prefixed-integers" class="xref">Section 4.1.1</a>.<a href="#section-4.4.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.4.1-2">This instruction is used as described in <a href="#known-received-count" class="xref">Section 2.1.4</a> and
+in <a href="#state-synchronization" class="xref">Section 2.2.2</a>.<a href="#section-4.4.1-2" class="pilcrow">¶</a></p>
+<span id="name-section-acknowledgement-2"></span><div id="fig-header-ack">
+<figure id="figure-9">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.4.1-3.1">
+<pre>
+  0   1   2   3   4   5   6   7
++---+---+---+---+---+---+---+---+
+| 1 |      Stream ID (7+)       |
++---+---------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
+<a href="#name-section-acknowledgement-2" class="selfRef">Section Acknowledgement</a>
+            </figcaption></figure>
+</div>
+<p id="section-4.4.1-4">If an encoder receives a Section Acknowledgement instruction referring to a
+stream on which every encoded field section with a non-zero Required Insert
+Count has already been acknowledged, that MUST be treated as a connection error
+of type QPACK_DECODER_STREAM_ERROR.<a href="#section-4.4.1-4" class="pilcrow">¶</a></p>
+<p id="section-4.4.1-5">The Section Acknowledgement instruction might increase the Known Received Count;
+see <a href="#known-received-count" class="xref">Section 2.1.4</a>.<a href="#section-4.4.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-cancellation">
+<section id="section-4.4.2">
+          <h4 id="name-stream-cancellation">
+<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-stream-cancellation" class="section-name selfRef">Stream Cancellation</a>
+          </h4>
+<p id="section-4.4.2-1">When a stream is reset or reading is abandoned, the decoder emits a Stream
+Cancellation instruction. The instruction begins with the '01' two-bit
+pattern, which is followed by the stream ID of the affected stream encoded as a
+6-bit prefix integer.<a href="#section-4.4.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.4.2-2">This instruction is used as described in <a href="#state-synchronization" class="xref">Section 2.2.2</a>.<a href="#section-4.4.2-2" class="pilcrow">¶</a></p>
+<span id="name-stream-cancellation-2"></span><div id="fig-stream-cancel">
+<figure id="figure-10">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.4.2-3.1">
+<pre>
+  0   1   2   3   4   5   6   7
++---+---+---+---+---+---+---+---+
+| 0 | 1 |     Stream ID (6+)    |
++---+---+-----------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
+<a href="#name-stream-cancellation-2" class="selfRef">Stream Cancellation</a>
+            </figcaption></figure>
+</div>
+</section>
+</div>
+<div id="insert-count-increment">
+<section id="section-4.4.3">
+          <h4 id="name-insert-count-increment">
+<a href="#section-4.4.3" class="section-number selfRef">4.4.3. </a><a href="#name-insert-count-increment" class="section-name selfRef">Insert Count Increment</a>
+          </h4>
+<p id="section-4.4.3-1">The Insert Count Increment instruction begins with the '00' two-bit pattern,
+followed by the Increment encoded as a 6-bit prefix integer.  This instruction
+increases the Known Received Count (<a href="#known-received-count" class="xref">Section 2.1.4</a>) by the value of
+the Increment parameter.  The decoder should send an Increment value that
+increases the Known Received Count to the total number of dynamic table
+insertions and duplications processed so far.<a href="#section-4.4.3-1" class="pilcrow">¶</a></p>
+<span id="name-insert-count-increment-2"></span><div id="fig-size-sync">
+<figure id="figure-11">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.4.3-2.1">
+<pre>
+  0   1   2   3   4   5   6   7
++---+---+---+---+---+---+---+---+
+| 0 | 0 |     Increment (6+)    |
++---+---+-----------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
+<a href="#name-insert-count-increment-2" class="selfRef">Insert Count Increment</a>
+            </figcaption></figure>
+</div>
+<p id="section-4.4.3-3">An encoder that receives an Increment field equal to zero, or one that increases
+the Known Received Count beyond what the encoder has sent MUST treat this as a
+connection error of type QPACK_DECODER_STREAM_ERROR.<a href="#section-4.4.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="field-line-representations">
+<section id="section-4.5">
+        <h3 id="name-field-line-representations">
+<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-field-line-representations" class="section-name selfRef">Field Line Representations</a>
+        </h3>
+<p id="section-4.5-1">An encoded field section consists of a prefix and a possibly empty sequence of
+representations defined in this section.  Each representation corresponds to a
+single field line.  These representations reference the static table or the
+dynamic table in a particular state, but do not modify that state.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
+<p id="section-4.5-2">Encoded field sections are carried in frames on streams defined by the enclosing
+protocol.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
+<div id="header-prefix">
+<section id="section-4.5.1">
+          <h4 id="name-encoded-field-section-prefi">
+<a href="#section-4.5.1" class="section-number selfRef">4.5.1. </a><a href="#name-encoded-field-section-prefi" class="section-name selfRef">Encoded Field Section Prefix</a>
+          </h4>
+<p id="section-4.5.1-1">Each encoded field section is prefixed with two integers.  The Required Insert
+Count is encoded as an integer with an 8-bit prefix after the encoding described
+in <a href="#ric" class="xref">Section 4.5.1.1</a>).  The Base is encoded as a sign bit ('S') and a Delta Base value
+with a 7-bit prefix; see <a href="#base" class="xref">Section 4.5.1.2</a>.<a href="#section-4.5.1-1" class="pilcrow">¶</a></p>
+<span id="name-encoded-field-section"></span><div id="fig-base-index">
+<figure id="figure-12">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.5.1-2.1">
+<pre>
+  0   1   2   3   4   5   6   7
++---+---+---+---+---+---+---+---+
+|   Required Insert Count (8+)  |
++---+---------------------------+
+| S |      Delta Base (7+)      |
++---+---------------------------+
+|      Encoded Field Lines    ...
++-------------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
+<a href="#name-encoded-field-section" class="selfRef">Encoded Field Section</a>
+            </figcaption></figure>
+</div>
+<div id="ric">
+<section id="section-4.5.1.1">
+            <h5 id="name-required-insert-count">
+<a href="#section-4.5.1.1" class="section-number selfRef">4.5.1.1. </a><a href="#name-required-insert-count" class="section-name selfRef">Required Insert Count</a>
+            </h5>
+<p id="section-4.5.1.1-1">Required Insert Count identifies the state of the dynamic table needed to
+process the encoded field section.  Blocking decoders use the Required Insert
+Count to determine when it is safe to process the rest of the field section.<a href="#section-4.5.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.1-2">The encoder transforms the Required Insert Count as follows before encoding:<a href="#section-4.5.1.1-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.5.1.1-3">
+<pre>
+   if ReqInsertCount == 0:
+      EncInsertCount = 0
+   else:
+      EncInsertCount = (ReqInsertCount mod (2 * MaxEntries)) + 1
+</pre><a href="#section-4.5.1.1-3" class="pilcrow">¶</a>
+</div>
+<p id="section-4.5.1.1-4">Here <code>MaxEntries</code> is the maximum number of entries that the dynamic table can
+have.  The smallest entry has empty name and value strings and has the size of
+32.  Hence <code>MaxEntries</code> is calculated as<a href="#section-4.5.1.1-4" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.5.1.1-5">
+<pre>
+   MaxEntries = floor( MaxTableCapacity / 32 )
+</pre><a href="#section-4.5.1.1-5" class="pilcrow">¶</a>
+</div>
+<p id="section-4.5.1.1-6"><code>MaxTableCapacity</code> is the maximum capacity of the dynamic table as specified by
+the decoder; see <a href="#maximum-dynamic-table-capacity" class="xref">Section 3.2.3</a>.<a href="#section-4.5.1.1-6" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.1-7">This encoding limits the length of the prefix on long-lived connections.<a href="#section-4.5.1.1-7" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.1-8">The decoder can reconstruct the Required Insert Count using an algorithm such as
+the following.  If the decoder encounters a value of EncodedInsertCount that
+could not have been produced by a conformant encoder, it MUST treat this as a
+connection error of type QPACK_DECOMPRESSION_FAILED.<a href="#section-4.5.1.1-8" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.1-9">TotalNumberOfInserts is the total number of inserts into the decoder's dynamic
+table.<a href="#section-4.5.1.1-9" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.5.1.1-10">
+<pre>
+   FullRange = 2 * MaxEntries
+   if EncodedInsertCount == 0:
+      ReqInsertCount = 0
+   else:
+      if EncodedInsertCount &gt; FullRange:
+         Error
+      MaxValue = TotalNumberOfInserts + MaxEntries
+
+      # MaxWrapped is the largest possible value of
+      # ReqInsertCount that is 0 mod 2*MaxEntries
+      MaxWrapped = floor(MaxValue / FullRange) * FullRange
+      ReqInsertCount = MaxWrapped + EncodedInsertCount - 1
+
+      # If ReqInsertCount exceeds MaxValue, the Encoder's value
+      # must have wrapped one fewer time
+      if ReqInsertCount &gt; MaxValue:
+         if ReqInsertCount &lt;= FullRange:
+            Error
+         ReqInsertCount -= FullRange
+
+      # Value of 0 must be encoded as 0.
+      if ReqInsertCount == 0:
+         Error
+</pre><a href="#section-4.5.1.1-10" class="pilcrow">¶</a>
+</div>
+<p id="section-4.5.1.1-11">For example, if the dynamic table is 100 bytes, then the Required Insert Count
+will be encoded modulo 6.  If a decoder has received 10 inserts, then an encoded
+value of 4 indicates that the Required Insert Count is 9 for the field section.<a href="#section-4.5.1.1-11" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="base">
+<section id="section-4.5.1.2">
+            <h5 id="name-base">
+<a href="#section-4.5.1.2" class="section-number selfRef">4.5.1.2. </a><a href="#name-base" class="section-name selfRef">Base</a>
+            </h5>
+<p id="section-4.5.1.2-1">The Base is used to resolve references in the dynamic table as described in
+<a href="#relative-indexing" class="xref">Section 3.2.5</a>.<a href="#section-4.5.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.2-2">To save space, the Base is encoded relative to the Required Insert Count using a
+one-bit sign ('S') and the Delta Base value.  A sign bit of 0 indicates that the
+Base is greater than or equal to the value of the Required Insert Count; the
+decoder adds the value of Delta Base to the Required Insert Count to determine
+the value of the Base.  A sign bit of 1 indicates that the Base is less than the
+Required Insert Count; the decoder subtracts the value of Delta Base from the
+Required Insert Count and also subtracts one to determine the value of the Base.
+That is:<a href="#section-4.5.1.2-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.5.1.2-3">
+<pre>
+   if S == 0:
+      Base = ReqInsertCount + DeltaBase
+   else:
+      Base = ReqInsertCount - DeltaBase - 1
+</pre><a href="#section-4.5.1.2-3" class="pilcrow">¶</a>
+</div>
+<p id="section-4.5.1.2-4">A single-pass encoder determines the Base before encoding a field section.  If
+the encoder inserted entries in the dynamic table while encoding the field
+section, Required Insert Count will be greater than the Base, so the encoded
+difference is negative and the sign bit is set to 1.  If the field section was
+not encoded using representations which reference the most recent entry in the
+table and did not insert any new entries, the Base will be greater than the
+Required Insert Count, so the delta will be positive and the sign bit is set to
+0.<a href="#section-4.5.1.2-4" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.2-5">An encoder that produces table updates before encoding a field section might set
+Base to the value of Required Insert Count.  In such case, both the sign bit and
+the Delta Base will be set to zero.<a href="#section-4.5.1.2-5" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.2-6">A field section that was encoded without references to the dynamic table can use
+any value for the Base; setting Delta Base to zero is one of the most efficient
+encodings.<a href="#section-4.5.1.2-6" class="pilcrow">¶</a></p>
+<p id="section-4.5.1.2-7">For example, with a Required Insert Count of 9, a decoder receives an S bit of 1
+and a Delta Base of 2.  This sets the Base to 6 and enables post-base indexing
+for three entries.  In this example, a relative index of 1 refers to the 5th
+entry that was added to the table; a post-base index of 1 refers to the 8th
+entry.<a href="#section-4.5.1.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="indexed-field-line">
+<section id="section-4.5.2">
+          <h4 id="name-indexed-field-line">
+<a href="#section-4.5.2" class="section-number selfRef">4.5.2. </a><a href="#name-indexed-field-line" class="section-name selfRef">Indexed Field Line</a>
+          </h4>
+<p id="section-4.5.2-1">An indexed field line representation identifies an entry in the static table,
+or an entry in the dynamic table with an absolute index less than the value of
+the Base.<a href="#section-4.5.2-1" class="pilcrow">¶</a></p>
+<span id="name-indexed-field-line-2"></span><figure id="figure-13">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.5.2-2.1">
+<pre>
+  0   1   2   3   4   5   6   7
++---+---+---+---+---+---+---+---+
+| 1 | T |      Index (6+)       |
++---+---+-----------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
+<a href="#name-indexed-field-line-2" class="selfRef">Indexed Field Line</a>
+            </figcaption></figure>
+<p id="section-4.5.2-3">This representation starts with the '1' 1-bit pattern, followed by the 'T' bit
+indicating whether the reference is into the static or dynamic table.  The 6-bit
+prefix integer (<a href="#prefixed-integers" class="xref">Section 4.1.1</a>) that follows is used to locate the
+table entry for the field line.  When T=1, the number represents the static
+table index; when T=0, the number is the relative index of the entry in the
+dynamic table.<a href="#section-4.5.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="indexed-field-line-with-post-base-index">
+<section id="section-4.5.3">
+          <h4 id="name-indexed-field-line-with-pos">
+<a href="#section-4.5.3" class="section-number selfRef">4.5.3. </a><a href="#name-indexed-field-line-with-pos" class="section-name selfRef">Indexed Field Line With Post-Base Index</a>
+          </h4>
+<p id="section-4.5.3-1">An indexed field line with post-base index representation identifies an entry
+in the dynamic table with an absolute index greater than or equal to the value
+of the Base.<a href="#section-4.5.3-1" class="pilcrow">¶</a></p>
+<span id="name-indexed-field-line-with-post"></span><figure id="figure-14">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.5.3-2.1">
+<pre>
+  0   1   2   3   4   5   6   7
++---+---+---+---+---+---+---+---+
+| 0 | 0 | 0 | 1 |  Index (4+)   |
++---+---+---+---+---------------+
+</pre>
+</div>
+<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
+<a href="#name-indexed-field-line-with-post" class="selfRef">Indexed Field Line with Post-Base Index</a>
+            </figcaption></figure>
+<p id="section-4.5.3-3">This representation starts with the '0001' 4-bit pattern.  This is followed by
+the post-base index (<a href="#post-base" class="xref">Section 3.2.6</a>) of the matching field line, represented as
+an integer with a 4-bit prefix; see <a href="#prefixed-integers" class="xref">Section 4.1.1</a>.<a href="#section-4.5.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="literal-name-reference">
+<section id="section-4.5.4">
+          <h4 id="name-literal-field-line-with-nam">
+<a href="#section-4.5.4" class="section-number selfRef">4.5.4. </a><a href="#name-literal-field-line-with-nam" class="section-name selfRef">Literal Field Line With Name Reference</a>
+          </h4>
+<p id="section-4.5.4-1">A literal field line with name reference representation encodes a field line
+where the field name matches the field name of an entry in the static table, or
+the field name of an entry in the dynamic table with an absolute index less than
+the value of the Base.<a href="#section-4.5.4-1" class="pilcrow">¶</a></p>
+<span id="name-literal-field-line-with-name"></span><figure id="figure-15">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.5.4-2.1">
+<pre>
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 1 | N | T |Name Index (4+)|
+   +---+---+---+---+---------------+
+   | H |     Value Length (7+)     |
+   +---+---------------------------+
+   |  Value String (Length bytes)  |
+   +-------------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
+<a href="#name-literal-field-line-with-name" class="selfRef">Literal Field Line With Name Reference</a>
+            </figcaption></figure>
+<p id="section-4.5.4-3">This representation starts with the '01' two-bit pattern.  The following bit,
+'N', indicates whether an intermediary is permitted to add this field line to
+the dynamic table on subsequent hops. When the 'N' bit is set, the encoded field
+line MUST always be encoded with a literal representation. In particular, when a
+peer sends a field line that it received represented as a literal field line
+with the 'N' bit set, it MUST use a literal representation to forward this field
+line.  This bit is intended for protecting field values that are not to be put
+at risk by compressing them; see <a href="#security-considerations" class="xref">Section 7</a> for more details.<a href="#section-4.5.4-3" class="pilcrow">¶</a></p>
+<p id="section-4.5.4-4">The fourth ('T') bit indicates whether the reference is to the static or dynamic
+table.  The 4-bit prefix integer (<a href="#prefixed-integers" class="xref">Section 4.1.1</a>) that follows is used to
+locate the table entry for the field name.  When T=1, the number represents the
+static table index; when T=0, the number is the relative index of the entry in
+the dynamic table.<a href="#section-4.5.4-4" class="pilcrow">¶</a></p>
+<p id="section-4.5.4-5">Only the field name is taken from the dynamic table entry; the field value is
+encoded as an 8-bit prefix string literal; see <a href="#string-literals" class="xref">Section 4.1.2</a>.<a href="#section-4.5.4-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="literal-field-line-with-post-base-name-reference">
+<section id="section-4.5.5">
+          <h4 id="name-literal-field-line-with-pos">
+<a href="#section-4.5.5" class="section-number selfRef">4.5.5. </a><a href="#name-literal-field-line-with-pos" class="section-name selfRef">Literal Field Line With Post-Base Name Reference</a>
+          </h4>
+<p id="section-4.5.5-1">A literal field line with post-base name reference representation encodes a
+field line where the field name matches the field name of a dynamic table entry
+with an absolute index greater than or equal to the value of the Base.<a href="#section-4.5.5-1" class="pilcrow">¶</a></p>
+<span id="name-literal-field-line-with-post"></span><figure id="figure-16">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.5.5-2.1">
+<pre>
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 | 0 | 0 | N |NameIdx(3+)|
+   +---+---+---+---+---+-----------+
+   | H |     Value Length (7+)     |
+   +---+---------------------------+
+   |  Value String (Length bytes)  |
+   +-------------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
+<a href="#name-literal-field-line-with-post" class="selfRef">Literal Field Line With Post-Base Name Reference</a>
+            </figcaption></figure>
+<p id="section-4.5.5-3">This representation starts with the '0000' four-bit pattern.  The fifth bit is
+the 'N' bit as described in <a href="#literal-name-reference" class="xref">Section 4.5.4</a>.  This is followed by a
+post-base index of the dynamic table entry (<a href="#post-base" class="xref">Section 3.2.6</a>) encoded as an
+integer with a 3-bit prefix; see <a href="#prefixed-integers" class="xref">Section 4.1.1</a>.<a href="#section-4.5.5-3" class="pilcrow">¶</a></p>
+<p id="section-4.5.5-4">Only the field name is taken from the dynamic table entry; the field value is
+encoded as an 8-bit prefix string literal; see <a href="#string-literals" class="xref">Section 4.1.2</a>.<a href="#section-4.5.5-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="literal-field-line-without-name-reference">
+<section id="section-4.5.6">
+          <h4 id="name-literal-field-line-without-">
+<a href="#section-4.5.6" class="section-number selfRef">4.5.6. </a><a href="#name-literal-field-line-without-" class="section-name selfRef">Literal Field Line Without Name Reference</a>
+          </h4>
+<p id="section-4.5.6-1">The literal field line without name reference representation encodes a
+field name and a field value as string literals.<a href="#section-4.5.6-1" class="pilcrow">¶</a></p>
+<span id="name-literal-field-line-without-n"></span><figure id="figure-17">
+            <div class="artwork art-text alignLeft art-drawing" id="section-4.5.6-2.1">
+<pre>
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 | 1 | N | H |NameLen(3+)|
+   +---+---+---+---+---+-----------+
+   |  Name String (Length bytes)   |
+   +---+---------------------------+
+   | H |     Value Length (7+)     |
+   +---+---------------------------+
+   |  Value String (Length bytes)  |
+   +-------------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
+<a href="#name-literal-field-line-without-n" class="selfRef">Literal Field Line Without Name Reference</a>
+            </figcaption></figure>
+<p id="section-4.5.6-3">This representation begins with the '001' three-bit pattern.  The fourth bit is
+the 'N' bit as described in <a href="#literal-name-reference" class="xref">Section 4.5.4</a>.  The name follows,
+represented as a 4-bit prefix string literal, then the value, represented as an
+8-bit prefix string literal; see <a href="#string-literals" class="xref">Section 4.1.2</a>.<a href="#section-4.5.6-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="configuration">
+<section id="section-5">
+      <h2 id="name-configuration">
+<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-configuration" class="section-name selfRef">Configuration</a>
+      </h2>
+<p id="section-5-1">QPACK defines two settings which are included in the HTTP/3 SETTINGS frame.<a href="#section-5-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-5-2">
+        <dt id="section-5-2.1">SETTINGS_QPACK_MAX_TABLE_CAPACITY (0x1):</dt>
+<dd id="section-5-2.2">
+  The default value is zero.  See <a href="#header-table-dynamic" class="xref">Section 3.2</a> for usage.  This is
+the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2.<a href="#section-5-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-5-2.3">SETTINGS_QPACK_BLOCKED_STREAMS (0x7):</dt>
+<dd id="section-5-2.4">
+  The default value is zero.  See <a href="#blocked-streams" class="xref">Section 2.1.2</a>.<a href="#section-5-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="error-handling">
+<section id="section-6">
+      <h2 id="name-error-handling">
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-error-handling" class="section-name selfRef">Error Handling</a>
+      </h2>
+<p id="section-6-1">The following error codes are defined for HTTP/3 to indicate failures of
+QPACK which prevent the connection from continuing:<a href="#section-6-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-6-2">
+        <dt id="section-6-2.1">QPACK_DECOMPRESSION_FAILED (0x200):</dt>
+<dd id="section-6-2.2">
+  The decoder failed to interpret an encoded field section and is not able to
+continue decoding that field section.<a href="#section-6-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-6-2.3">QPACK_ENCODER_STREAM_ERROR (0x201):</dt>
+<dd id="section-6-2.4">
+  The decoder failed to interpret an encoder instruction received on the
+encoder stream.<a href="#section-6-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-6-2.5">QPACK_DECODER_STREAM_ERROR (0x202):</dt>
+<dd id="section-6-2.6">
+  The encoder failed to interpret a decoder instruction received on the
+decoder stream.<a href="#section-6-2.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="security-considerations">
+<section id="section-7">
+      <h2 id="name-security-considerations">
+<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
+      </h2>
+<p id="section-7-1">This section describes potential areas of security concern with QPACK:<a href="#section-7-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-7-2.1">Use of compression as a length-based oracle for verifying guesses about
+secrets that are compressed into a shared compression context.<a href="#section-7-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7-2.2">Denial of service resulting from exhausting processing or memory capacity at
+a decoder.<a href="#section-7-2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<div id="probing-dynamic-table-state">
+<section id="section-7.1">
+        <h3 id="name-probing-dynamic-table-state">
+<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-probing-dynamic-table-state" class="section-name selfRef">Probing Dynamic Table State</a>
+        </h3>
+<p id="section-7.1-1">QPACK reduces the length of header field encodings by exploiting the redundancy
+inherent in protocols like HTTP. The ultimate goal of this is to reduce the
+amount of data that is required to send HTTP requests or responses.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
+<p id="section-7.1-2">The compression context used to encode header fields can be probed by an
+attacker who can both define header fields to be encoded and transmitted and
+observe the length of those fields once they are encoded. When an attacker can
+do both, they can adaptively modify requests in order to confirm guesses about
+the dynamic table state. If a guess is compressed into a shorter length, the
+attacker can observe the encoded length and infer that the guess was correct.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
+<p id="section-7.1-3">This is possible even over the Transport Layer Security Protocol (TLS, see
+<span>[<a href="#RFC5246" class="xref">RFC5246</a>]</span>), because while TLS provides confidentiality protection for
+content, it only provides a limited amount of protection for the length of that
+content.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7.1-4">
+          <dt id="section-7.1-4.1">Note:</dt>
+<dd id="section-7.1-4.2">
+  Padding schemes only provide limited protection against an attacker with these
+capabilities, potentially only forcing an increased number of guesses to learn
+the length associated with a given guess. Padding schemes also work directly
+against compression by increasing the number of bits that are transmitted.<a href="#section-7.1-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-7.1-5">Attacks like CRIME <span>[<a href="#CRIME" class="xref">CRIME</a>]</span> demonstrated the existence of these general attacker
+capabilities. The specific attack exploited the fact that DEFLATE <span>[<a href="#RFC1951" class="xref">RFC1951</a>]</span>
+removes redundancy based on prefix matching. This permitted the attacker to
+confirm guesses a character at a time, reducing an exponential-time attack into
+a linear-time attack.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="applicability-to-qpack-and-http">
+<section id="section-7.2">
+        <h3 id="name-applicability-to-qpack-and-">
+<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-applicability-to-qpack-and-" class="section-name selfRef">Applicability to QPACK and HTTP</a>
+        </h3>
+<p id="section-7.2-1">QPACK mitigates but does not completely prevent attacks modeled on CRIME <span>[<a href="#CRIME" class="xref">CRIME</a>]</span>
+by forcing a guess to match an entire header field value, rather than individual
+characters. An attacker can only learn whether a guess is correct or not, so is
+reduced to a brute force guess for the header field values.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
+<p id="section-7.2-2">The viability of recovering specific header field values therefore depends on
+the entropy of values. As a result, values with high entropy are unlikely to be
+recovered successfully. However, values with low entropy remain vulnerable.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
+<p id="section-7.2-3">Attacks of this nature are possible any time that two mutually distrustful
+entities control requests or responses that are placed onto a single HTTP/3
+connection. If the shared QPACK compressor permits one entity to add entries to
+the dynamic table, and the other to access those entries, then the state of the
+table can be learned.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
+<p id="section-7.2-4">Having requests or responses from mutually distrustful entities occurs when an
+intermediary either:<a href="#section-7.2-4" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-7.2-5.1">sends requests from multiple clients on a single connection toward an origin
+server, or<a href="#section-7.2-5.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.2-5.2">takes responses from multiple origin servers and places them on a shared
+connection toward a client.<a href="#section-7.2-5.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-7.2-6">Web browsers also need to assume that requests made on the same connection by
+different web origins <span>[<a href="#RFC6454" class="xref">RFC6454</a>]</span> are made by mutually distrustful entities.<a href="#section-7.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="mitigation">
+<section id="section-7.3">
+        <h3 id="name-mitigation">
+<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-mitigation" class="section-name selfRef">Mitigation</a>
+        </h3>
+<p id="section-7.3-1">Users of HTTP that require confidentiality for header fields can use values with
+entropy sufficient to make guessing infeasible. However, this is impractical as
+a general solution because it forces all users of HTTP to take steps to mitigate
+attacks. It would impose new constraints on how HTTP is used.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
+<p id="section-7.3-2">Rather than impose constraints on users of HTTP, an implementation of QPACK can
+instead constrain how compression is applied in order to limit the potential for
+dynamic table probing.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
+<p id="section-7.3-3">An ideal solution segregates access to the dynamic table based on the entity
+that is constructing header fields. Header field values that are added to the
+table are attributed to an entity, and only the entity that created a particular
+value can extract that value.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
+<p id="section-7.3-4">To improve compression performance of this option, certain entries might be
+tagged as being public. For example, a web browser might make the values of the
+Accept-Encoding header field available in all requests.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
+<p id="section-7.3-5">An encoder without good knowledge of the provenance of header fields might
+instead introduce a penalty for a header field with many different values, such
+that a large number of attempts to guess a header field value results in the
+header field not being compared to the dynamic table entries in future messages,
+effectively preventing further guesses.<a href="#section-7.3-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7.3-6">
+          <dt id="section-7.3-6.1">Note:</dt>
+<dd id="section-7.3-6.2">
+  Simply removing entries corresponding to the header field from the dynamic
+table can be ineffectual if the attacker has a reliable way of causing values to
+be reinstalled. For example, a request to load an image in a web browser
+typically includes the Cookie header field (a potentially highly valued target
+for this sort of attack), and web sites can easily force an image to be loaded,
+thereby refreshing the entry in the dynamic table.<a href="#section-7.3-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-7.3-7">This response might be made inversely proportional to the length of the header
+field value. Disabling access to the dynamic table for a header field might
+occur for shorter values more quickly or with higher probability than for longer
+values.<a href="#section-7.3-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="never-indexed-literals">
+<section id="section-7.4">
+        <h3 id="name-never-indexed-literals">
+<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-never-indexed-literals" class="section-name selfRef">Never Indexed Literals</a>
+        </h3>
+<p id="section-7.4-1">Implementations can also choose to protect sensitive header fields by not
+compressing them and instead encoding their value as literals.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
+<p id="section-7.4-2">Refusing to insert a header field into the dynamic table is only
+effective if doing so is avoided on all hops. The never indexed literal bit (see
+<a href="#literal-name-reference" class="xref">Section 4.5.4</a>) can be used to signal to intermediaries that a
+particular value was intentionally sent as a literal.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
+<p id="section-7.4-3">An intermediary MUST NOT re-encode a value that uses a literal representation
+with the 'N' bit set with another representation that would index it. If QPACK
+is used for re-encoding, a literal representation with the 'N' bit set MUST be
+used.  If HPACK is used for re-encoding, the never indexed literal
+representation (see Section 6.2.3 of <span>[<a href="#RFC7541" class="xref">RFC7541</a>]</span>) MUST be used.<a href="#section-7.4-3" class="pilcrow">¶</a></p>
+<p id="section-7.4-4">The choice to mark that a header field should never be indexed
+depends on several factors. Since QPACK doesn't protect against guessing an
+entire header field value, short or low-entropy values are more readily
+recovered by an adversary. Therefore, an encoder might choose not to index
+values with low entropy.<a href="#section-7.4-4" class="pilcrow">¶</a></p>
+<p id="section-7.4-5">An encoder might also choose not to index values for header fields that are
+considered to be highly valuable or sensitive to recovery, such as the Cookie or
+Authorization header fields.<a href="#section-7.4-5" class="pilcrow">¶</a></p>
+<p id="section-7.4-6">On the contrary, an encoder might prefer indexing values for header fields that
+have little or no value if they were exposed. For instance, a User-Agent header
+field does not commonly vary between requests and is sent to any server. In that
+case, confirmation that a particular User-Agent value has been used provides
+little value.<a href="#section-7.4-6" class="pilcrow">¶</a></p>
+<p id="section-7.4-7">Note that these criteria for deciding to use a never indexed literal
+representation will evolve over time as new attacks are discovered.<a href="#section-7.4-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="static-huffman-encoding">
+<section id="section-7.5">
+        <h3 id="name-static-huffman-encoding">
+<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-static-huffman-encoding" class="section-name selfRef">Static Huffman Encoding</a>
+        </h3>
+<p id="section-7.5-1">There is no currently known attack against a static Huffman encoding. A study
+has shown that using a static Huffman encoding table created an information
+leakage, however this same study concluded that an attacker could not take
+advantage of this information leakage to recover any meaningful amount of
+information (see <span>[<a href="#PETAL" class="xref">PETAL</a>]</span>).<a href="#section-7.5-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="memory-consumption">
+<section id="section-7.6">
+        <h3 id="name-memory-consumption">
+<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-memory-consumption" class="section-name selfRef">Memory Consumption</a>
+        </h3>
+<p id="section-7.6-1">An attacker can try to cause an endpoint to exhaust its memory. QPACK is
+designed to limit both the peak and stable amounts of memory allocated by an
+endpoint.<a href="#section-7.6-1" class="pilcrow">¶</a></p>
+<p id="section-7.6-2">The amount of memory used by the encoder is limited by the protocol using
+QPACK through the definition of the maximum size of the dynamic table, and the
+maximum number of blocking streams. In HTTP/3, these values are controlled by
+the decoder through the settings parameters SETTINGS_QPACK_MAX_TABLE_CAPACITY
+and SETTINGS_QPACK_BLOCKED_STREAMS, respectively (see
+<a href="#maximum-dynamic-table-capacity" class="xref">Section 3.2.3</a> and <a href="#blocked-streams" class="xref">Section 2.1.2</a>). The limit on the
+size of the dynamic table takes into account the size of the data stored in the
+dynamic table, plus a small allowance for overhead.  The limit on the number of
+blocked streams is only a proxy for the maximum amount of memory required by the
+decoder.  The actual maximum amount of memory will depend on how much memory the
+decoder uses to track each blocked stream.<a href="#section-7.6-2" class="pilcrow">¶</a></p>
+<p id="section-7.6-3">A decoder can limit the amount of state memory used for the dynamic table by
+setting an appropriate value for the maximum size of the dynamic table. In
+HTTP/3, this is realized by setting an appropriate value for the
+SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter. An encoder can limit the amount of
+state memory it uses by signaling a lower dynamic table size than the decoder
+allows (see <a href="#eviction" class="xref">Section 3.2.2</a>).<a href="#section-7.6-3" class="pilcrow">¶</a></p>
+<p id="section-7.6-4">A decoder can limit the amount of state memory used for blocked streams by
+setting an appropriate value for the maximum number of blocked streams.  In
+HTTP/3, this is realized by setting an appropriate value for the
+QPACK_BLOCKED_STREAMS parameter.  An encoder can limit the amount of state
+memory by only using as many blocked streams as it wishes to support; no
+signaling to the decoder is required.<a href="#section-7.6-4" class="pilcrow">¶</a></p>
+<p id="section-7.6-5">The amount of temporary memory consumed by an encoder or decoder can be limited
+by processing header fields sequentially. A decoder implementation does not need
+to retain a complete list of header fields while decoding a header block. An
+encoder implementation does not need to retain a complete list of header fields
+while encoding a header block if it is using a single-pass algorithm.  Note
+that it might be necessary for an application to retain a complete
+header list for other reasons; even if QPACK does not force this to occur,
+application constraints might make this necessary.<a href="#section-7.6-5" class="pilcrow">¶</a></p>
+<p id="section-7.6-6">While the negotiated limit on the dynamic table size accounts for much of the
+memory that can be consumed by a QPACK implementation, data which cannot be
+immediately sent due to flow control is not affected by this limit.
+Implementations should limit the size of unsent data, especially on the decoder
+stream where flexibility to choose what to send is limited.  Possible responses
+to an excess of unsent data might include limiting the ability of the peer to
+open new streams, reading only from the encoder stream, or closing the
+connection.<a href="#section-7.6-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="implementation-limits">
+<section id="section-7.7">
+        <h3 id="name-implementation-limits">
+<a href="#section-7.7" class="section-number selfRef">7.7. </a><a href="#name-implementation-limits" class="section-name selfRef">Implementation Limits</a>
+        </h3>
+<p id="section-7.7-1">An implementation of QPACK needs to ensure that large values for integers, long
+encoding for integers, or long string literals do not create security
+weaknesses.<a href="#section-7.7-1" class="pilcrow">¶</a></p>
+<p id="section-7.7-2">An implementation has to set a limit for the values it accepts for integers, as
+well as for the encoded length (see <a href="#prefixed-integers" class="xref">Section 4.1.1</a>). In the same way, it
+has to set a limit to the length it accepts for string literals (see
+<a href="#string-literals" class="xref">Section 4.1.2</a>).<a href="#section-7.7-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="iana-considerations">
+<section id="section-8">
+      <h2 id="name-iana-considerations">
+<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
+      </h2>
+<div id="settings-registration">
+<section id="section-8.1">
+        <h3 id="name-settings-registration">
+<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-settings-registration" class="section-name selfRef">Settings Registration</a>
+        </h3>
+<p id="section-8.1-1">This document specifies two settings. The entries in the following table are
+registered in the "HTTP/3 Settings" registry established in <span>[<a href="#HTTP3" class="xref">HTTP3</a>]</span>.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
+<table class="center" id="table-1">
+          <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Setting Name</th>
+              <th class="text-center" rowspan="1" colspan="1">Code</th>
+              <th class="text-left" rowspan="1" colspan="1">Specification</th>
+              <th class="text-left" rowspan="1" colspan="1">Default</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">QPACK_MAX_TABLE_CAPACITY</td>
+              <td class="text-center" rowspan="1" colspan="1">0x1</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#configuration" class="xref">Section 5</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">0</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">QPACK_BLOCKED_STREAMS</td>
+              <td class="text-center" rowspan="1" colspan="1">0x7</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#configuration" class="xref">Section 5</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">0</td>
+            </tr>
+          </tbody>
+        </table>
+</section>
+</div>
+<div id="stream-type-registration">
+<section id="section-8.2">
+        <h3 id="name-stream-type-registration">
+<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-stream-type-registration" class="section-name selfRef">Stream Type Registration</a>
+        </h3>
+<p id="section-8.2-1">This document specifies two stream types. The entries in the following table are
+registered in the "HTTP/3 Stream Type" registry established in <span>[<a href="#HTTP3" class="xref">HTTP3</a>]</span>.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
+<table class="center" id="table-2">
+          <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Stream Type</th>
+              <th class="text-center" rowspan="1" colspan="1">Code</th>
+              <th class="text-left" rowspan="1" colspan="1">Specification</th>
+              <th class="text-left" rowspan="1" colspan="1">Sender</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">QPACK Encoder Stream</td>
+              <td class="text-center" rowspan="1" colspan="1">0x02</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#enc-dec-stream-def" class="xref">Section 4.2</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">Both</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">QPACK Decoder Stream</td>
+              <td class="text-center" rowspan="1" colspan="1">0x03</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#enc-dec-stream-def" class="xref">Section 4.2</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">Both</td>
+            </tr>
+          </tbody>
+        </table>
+</section>
+</div>
+<div id="error-code-registration">
+<section id="section-8.3">
+        <h3 id="name-error-code-registration">
+<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-error-code-registration" class="section-name selfRef">Error Code Registration</a>
+        </h3>
+<p id="section-8.3-1">This document specifies three error codes. The entries in the following table
+are registered in the "HTTP/3 Error Code" registry established in <span>[<a href="#HTTP3" class="xref">HTTP3</a>]</span>.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
+<table class="center" id="table-3">
+          <caption><a href="#table-3" class="selfRef">Table 3</a></caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Name</th>
+              <th class="text-left" rowspan="1" colspan="1">Code</th>
+              <th class="text-left" rowspan="1" colspan="1">Description</th>
+              <th class="text-left" rowspan="1" colspan="1">Specification</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">QPACK_DECOMPRESSION_FAILED</td>
+              <td class="text-left" rowspan="1" colspan="1">0x200</td>
+              <td class="text-left" rowspan="1" colspan="1">Decoding of a field section failed</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-handling" class="xref">Section 6</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">QPACK_ENCODER_STREAM_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">0x201</td>
+              <td class="text-left" rowspan="1" colspan="1">Error on the encoder stream</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-handling" class="xref">Section 6</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">QPACK_DECODER_STREAM_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">0x202</td>
+              <td class="text-left" rowspan="1" colspan="1">Error on the decoder stream</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-handling" class="xref">Section 6</a>
+</td>
+            </tr>
+          </tbody>
+        </table>
+</section>
+</div>
+</section>
+</div>
+<section id="section-9">
+      <h2 id="name-references">
+<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
+      </h2>
+<section id="section-9.1">
+        <h3 id="name-normative-references">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
+        </h3>
+<dl class="references">
+<dt id="HTTP3">[HTTP3]</dt>
+<dd>
+<span class="refAuthor">Bishop, M., Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol Version 3 (HTTP/3)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-http-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-http-latest">https://tools.ietf.org/html/draft-ietf-quic-http-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-TRANSPORT">[QUIC-TRANSPORT]</dt>
+<dd>
+<span class="refAuthor">Iyengar, J., Ed.</span><span class="refAuthor"> and M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-transport-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-transport-latest">https://tools.ietf.org/html/draft-ietf-quic-transport-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2119">[RFC2119]</dt>
+<dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC7541">[RFC7541]</dt>
+<dd>
+<span class="refAuthor">Peon, R.</span><span class="refAuthor"> and H. Ruellan</span>, <span class="refTitle">"HPACK: Header Compression for HTTP/2"</span>, <span class="seriesInfo">RFC 7541</span>, <span class="seriesInfo">DOI 10.17487/RFC7541</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7541">https://www.rfc-editor.org/info/rfc7541</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8174">[RFC8174]</dt>
+<dd>
+<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="SEMANTICS">[SEMANTICS]</dt>
+<dd>
+<span class="refAuthor">Fielding, R.</span><span class="refAuthor">, Nottingham, M.</span><span class="refAuthor">, and J. Reschke</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-httpbis-semantics-08</span>, <time datetime="2020-05-26">26 May 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-semantics-08.txt">http://www.ietf.org/internet-drafts/draft-ietf-httpbis-semantics-08.txt</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+<section id="section-9.2">
+        <h3 id="name-informative-references">
+<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
+        </h3>
+<dl class="references">
+<dt id="CRIME">[CRIME]</dt>
+<dd>
+<span class="refAuthor">Wikipedia</span>, <span class="refTitle">"CRIME"</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="http://en.wikipedia.org/w/index.php?title=CRIME&amp;oldid=660948120">http://en.wikipedia.org/w/index.php?title=CRIME&amp;oldid=660948120</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="PETAL">[PETAL]</dt>
+<dd>
+<span class="refAuthor">Tan, J.</span><span class="refAuthor"> and J. Nahata</span>, <span class="refTitle">"PETAL: Preset Encoding Table Information Leakage"</span>, <time datetime="2013-04">April 2013</time>, <span>&lt;<a href="http://www.pdl.cmu.edu/PDL-FTP/associated/CMU-PDL-13-106.pdf">http://www.pdl.cmu.edu/PDL-FTP/associated/CMU-PDL-13-106.pdf</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC1951">[RFC1951]</dt>
+<dd>
+<span class="refAuthor">Deutsch, P.</span>, <span class="refTitle">"DEFLATE Compressed Data Format Specification version 1.3"</span>, <span class="seriesInfo">RFC 1951</span>, <span class="seriesInfo">DOI 10.17487/RFC1951</span>, <time datetime="1996-05">May 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1951">https://www.rfc-editor.org/info/rfc1951</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2360">[RFC2360]</dt>
+<dd>
+<span class="refAuthor">Scott, G.</span>, <span class="refTitle">"Guide for Internet Standards Writers"</span>, <span class="seriesInfo">BCP 22</span>, <span class="seriesInfo">RFC 2360</span>, <span class="seriesInfo">DOI 10.17487/RFC2360</span>, <time datetime="1998-06">June 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2360">https://www.rfc-editor.org/info/rfc2360</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5246">[RFC5246]</dt>
+<dd>
+<span class="refAuthor">Dierks, T.</span><span class="refAuthor"> and E. Rescorla</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.2"</span>, <span class="seriesInfo">RFC 5246</span>, <span class="seriesInfo">DOI 10.17487/RFC5246</span>, <time datetime="2008-08">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6454">[RFC6454]</dt>
+<dd>
+<span class="refAuthor">Barth, A.</span>, <span class="refTitle">"The Web Origin Concept"</span>, <span class="seriesInfo">RFC 6454</span>, <span class="seriesInfo">DOI 10.17487/RFC6454</span>, <time datetime="2011-12">December 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6454">https://www.rfc-editor.org/info/rfc6454</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC7540">[RFC7540]</dt>
+<dd>
+<span class="refAuthor">Belshe, M.</span><span class="refAuthor">, Peon, R.</span><span class="refAuthor">, and M. Thomson, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol Version 2 (HTTP/2)"</span>, <span class="seriesInfo">RFC 7540</span>, <span class="seriesInfo">DOI 10.17487/RFC7540</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7540">https://www.rfc-editor.org/info/rfc7540</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</section>
+<div id="static-table">
+<section id="section-appendix.a">
+      <h2 id="name-static-table-2">
+<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-static-table-2" class="section-name selfRef">Static Table</a>
+      </h2>
+<p id="section-appendix.a-1">This table was generated by analyzing actual internet traffic in 2018 and
+including the most common headers, after filtering out some unsupported and
+non-standard values. Due to this methodology, some of the entries may be
+inconsistent or appear multiple times with similar but not identical values.
+The order of the entries is optimized to encode the most common headers with the
+smallest number of bytes.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
+<table class="center" id="table-4">
+        <caption><a href="#table-4" class="selfRef">Table 4</a></caption>
+<thead>
+          <tr>
+            <th class="text-left" rowspan="1" colspan="1">Index</th>
+            <th class="text-left" rowspan="1" colspan="1">Name</th>
+            <th class="text-left" rowspan="1" colspan="1">Value</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">0</td>
+            <td class="text-left" rowspan="1" colspan="1">:authority</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">1</td>
+            <td class="text-left" rowspan="1" colspan="1">:path</td>
+            <td class="text-left" rowspan="1" colspan="1">/</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">2</td>
+            <td class="text-left" rowspan="1" colspan="1">age</td>
+            <td class="text-left" rowspan="1" colspan="1">0</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">3</td>
+            <td class="text-left" rowspan="1" colspan="1">content-disposition</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">4</td>
+            <td class="text-left" rowspan="1" colspan="1">content-length</td>
+            <td class="text-left" rowspan="1" colspan="1">0</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">5</td>
+            <td class="text-left" rowspan="1" colspan="1">cookie</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">6</td>
+            <td class="text-left" rowspan="1" colspan="1">date</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">7</td>
+            <td class="text-left" rowspan="1" colspan="1">etag</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">8</td>
+            <td class="text-left" rowspan="1" colspan="1">if-modified-since</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">9</td>
+            <td class="text-left" rowspan="1" colspan="1">if-none-match</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">10</td>
+            <td class="text-left" rowspan="1" colspan="1">last-modified</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">11</td>
+            <td class="text-left" rowspan="1" colspan="1">link</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">12</td>
+            <td class="text-left" rowspan="1" colspan="1">location</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">13</td>
+            <td class="text-left" rowspan="1" colspan="1">referer</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">14</td>
+            <td class="text-left" rowspan="1" colspan="1">set-cookie</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">15</td>
+            <td class="text-left" rowspan="1" colspan="1">:method</td>
+            <td class="text-left" rowspan="1" colspan="1">CONNECT</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">16</td>
+            <td class="text-left" rowspan="1" colspan="1">:method</td>
+            <td class="text-left" rowspan="1" colspan="1">DELETE</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">17</td>
+            <td class="text-left" rowspan="1" colspan="1">:method</td>
+            <td class="text-left" rowspan="1" colspan="1">GET</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">18</td>
+            <td class="text-left" rowspan="1" colspan="1">:method</td>
+            <td class="text-left" rowspan="1" colspan="1">HEAD</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">19</td>
+            <td class="text-left" rowspan="1" colspan="1">:method</td>
+            <td class="text-left" rowspan="1" colspan="1">OPTIONS</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">20</td>
+            <td class="text-left" rowspan="1" colspan="1">:method</td>
+            <td class="text-left" rowspan="1" colspan="1">POST</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">21</td>
+            <td class="text-left" rowspan="1" colspan="1">:method</td>
+            <td class="text-left" rowspan="1" colspan="1">PUT</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">22</td>
+            <td class="text-left" rowspan="1" colspan="1">:scheme</td>
+            <td class="text-left" rowspan="1" colspan="1">http</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">23</td>
+            <td class="text-left" rowspan="1" colspan="1">:scheme</td>
+            <td class="text-left" rowspan="1" colspan="1">https</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">24</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">103</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">25</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">200</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">26</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">304</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">27</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">404</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">28</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">503</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">29</td>
+            <td class="text-left" rowspan="1" colspan="1">accept</td>
+            <td class="text-left" rowspan="1" colspan="1">*/*</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">30</td>
+            <td class="text-left" rowspan="1" colspan="1">accept</td>
+            <td class="text-left" rowspan="1" colspan="1">application/dns-message</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">31</td>
+            <td class="text-left" rowspan="1" colspan="1">accept-encoding</td>
+            <td class="text-left" rowspan="1" colspan="1">gzip, deflate, br</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">32</td>
+            <td class="text-left" rowspan="1" colspan="1">accept-ranges</td>
+            <td class="text-left" rowspan="1" colspan="1">bytes</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">33</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-headers</td>
+            <td class="text-left" rowspan="1" colspan="1">cache-control</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">34</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-headers</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">35</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-origin</td>
+            <td class="text-left" rowspan="1" colspan="1">*</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">36</td>
+            <td class="text-left" rowspan="1" colspan="1">cache-control</td>
+            <td class="text-left" rowspan="1" colspan="1">max-age=0</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">37</td>
+            <td class="text-left" rowspan="1" colspan="1">cache-control</td>
+            <td class="text-left" rowspan="1" colspan="1">max-age=2592000</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">38</td>
+            <td class="text-left" rowspan="1" colspan="1">cache-control</td>
+            <td class="text-left" rowspan="1" colspan="1">max-age=604800</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">39</td>
+            <td class="text-left" rowspan="1" colspan="1">cache-control</td>
+            <td class="text-left" rowspan="1" colspan="1">no-cache</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">40</td>
+            <td class="text-left" rowspan="1" colspan="1">cache-control</td>
+            <td class="text-left" rowspan="1" colspan="1">no-store</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">41</td>
+            <td class="text-left" rowspan="1" colspan="1">cache-control</td>
+            <td class="text-left" rowspan="1" colspan="1">public, max-age=31536000</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">42</td>
+            <td class="text-left" rowspan="1" colspan="1">content-encoding</td>
+            <td class="text-left" rowspan="1" colspan="1">br</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">43</td>
+            <td class="text-left" rowspan="1" colspan="1">content-encoding</td>
+            <td class="text-left" rowspan="1" colspan="1">gzip</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">44</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">application/dns-message</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">45</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">application/javascript</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">46</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">application/json</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">47</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">application/x-www-form-urlencoded</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">48</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">image/gif</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">49</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">image/jpeg</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">50</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">image/png</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">51</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">text/css</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">52</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">text/html; charset=utf-8</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">53</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">text/plain</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">54</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+            <td class="text-left" rowspan="1" colspan="1">text/plain;charset=utf-8</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">55</td>
+            <td class="text-left" rowspan="1" colspan="1">range</td>
+            <td class="text-left" rowspan="1" colspan="1">bytes=0-</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">56</td>
+            <td class="text-left" rowspan="1" colspan="1">strict-transport-security</td>
+            <td class="text-left" rowspan="1" colspan="1">max-age=31536000</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">57</td>
+            <td class="text-left" rowspan="1" colspan="1">strict-transport-security</td>
+            <td class="text-left" rowspan="1" colspan="1">max-age=31536000; includesubdomains</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">58</td>
+            <td class="text-left" rowspan="1" colspan="1">strict-transport-security</td>
+            <td class="text-left" rowspan="1" colspan="1">max-age=31536000; includesubdomains; preload</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">59</td>
+            <td class="text-left" rowspan="1" colspan="1">vary</td>
+            <td class="text-left" rowspan="1" colspan="1">accept-encoding</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">60</td>
+            <td class="text-left" rowspan="1" colspan="1">vary</td>
+            <td class="text-left" rowspan="1" colspan="1">origin</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">61</td>
+            <td class="text-left" rowspan="1" colspan="1">x-content-type-options</td>
+            <td class="text-left" rowspan="1" colspan="1">nosniff</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">62</td>
+            <td class="text-left" rowspan="1" colspan="1">x-xss-protection</td>
+            <td class="text-left" rowspan="1" colspan="1">1; mode=block</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">63</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">100</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">64</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">204</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">65</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">206</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">66</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">302</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">67</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">400</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">68</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">403</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">69</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">421</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">70</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">425</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">71</td>
+            <td class="text-left" rowspan="1" colspan="1">:status</td>
+            <td class="text-left" rowspan="1" colspan="1">500</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">72</td>
+            <td class="text-left" rowspan="1" colspan="1">accept-language</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">73</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-credentials</td>
+            <td class="text-left" rowspan="1" colspan="1">FALSE</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">74</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-credentials</td>
+            <td class="text-left" rowspan="1" colspan="1">TRUE</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">75</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-headers</td>
+            <td class="text-left" rowspan="1" colspan="1">*</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">76</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-methods</td>
+            <td class="text-left" rowspan="1" colspan="1">get</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">77</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-methods</td>
+            <td class="text-left" rowspan="1" colspan="1">get, post, options</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">78</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-allow-methods</td>
+            <td class="text-left" rowspan="1" colspan="1">options</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">79</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-expose-headers</td>
+            <td class="text-left" rowspan="1" colspan="1">content-length</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">80</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-request-headers</td>
+            <td class="text-left" rowspan="1" colspan="1">content-type</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">81</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-request-method</td>
+            <td class="text-left" rowspan="1" colspan="1">get</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">82</td>
+            <td class="text-left" rowspan="1" colspan="1">access-control-request-method</td>
+            <td class="text-left" rowspan="1" colspan="1">post</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">83</td>
+            <td class="text-left" rowspan="1" colspan="1">alt-svc</td>
+            <td class="text-left" rowspan="1" colspan="1">clear</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">84</td>
+            <td class="text-left" rowspan="1" colspan="1">authorization</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">85</td>
+            <td class="text-left" rowspan="1" colspan="1">content-security-policy</td>
+            <td class="text-left" rowspan="1" colspan="1">script-src 'none'; object-src 'none'; base-uri 'none'</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">86</td>
+            <td class="text-left" rowspan="1" colspan="1">early-data</td>
+            <td class="text-left" rowspan="1" colspan="1">1</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">87</td>
+            <td class="text-left" rowspan="1" colspan="1">expect-ct</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">88</td>
+            <td class="text-left" rowspan="1" colspan="1">forwarded</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">89</td>
+            <td class="text-left" rowspan="1" colspan="1">if-range</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">90</td>
+            <td class="text-left" rowspan="1" colspan="1">origin</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">91</td>
+            <td class="text-left" rowspan="1" colspan="1">purpose</td>
+            <td class="text-left" rowspan="1" colspan="1">prefetch</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">92</td>
+            <td class="text-left" rowspan="1" colspan="1">server</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">93</td>
+            <td class="text-left" rowspan="1" colspan="1">timing-allow-origin</td>
+            <td class="text-left" rowspan="1" colspan="1">*</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">94</td>
+            <td class="text-left" rowspan="1" colspan="1">upgrade-insecure-requests</td>
+            <td class="text-left" rowspan="1" colspan="1">1</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">95</td>
+            <td class="text-left" rowspan="1" colspan="1">user-agent</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">96</td>
+            <td class="text-left" rowspan="1" colspan="1">x-forwarded-for</td>
+            <td class="text-left" rowspan="1" colspan="1"> </td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">97</td>
+            <td class="text-left" rowspan="1" colspan="1">x-frame-options</td>
+            <td class="text-left" rowspan="1" colspan="1">deny</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">98</td>
+            <td class="text-left" rowspan="1" colspan="1">x-frame-options</td>
+            <td class="text-left" rowspan="1" colspan="1">sameorigin</td>
+          </tr>
+        </tbody>
+      </table>
+</section>
+</div>
+<div id="sample-one-pass-encoding-algorithm">
+<section id="section-appendix.b">
+      <h2 id="name-sample-one-pass-encoding-al">
+<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-sample-one-pass-encoding-al" class="section-name selfRef">Sample One Pass Encoding Algorithm</a>
+      </h2>
+<p id="section-appendix.b-1">Pseudo-code for single pass encoding, excluding handling of duplicates,
+non-blocking mode, available encoder stream flow control and reference tracking.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-appendix.b-2">
+<pre>
+base = dynamicTable.getInsertCount()
+requiredInsertCount = 0
+for line in field_lines:
+  staticIndex = staticTable.findIndex(line)
+  if staticIndex is not None:
+    encodeIndexReference(streamBuffer, staticIndex)
+    continue
+
+  dynamicIndex = dynamicTable.findIndex(line)
+  if dynamicIndex is None:
+    # No matching entry.  Either insert+index or encode literal
+    staticNameIndex = staticTable.findName(line.name)
+    if staticNameIndex is None:
+       dynamicNameIndex = dynamicTable.findName(line.name)
+
+    if shouldIndex(line) and dynamicTable.canIndex(line):
+      encodeInsert(encoderBuffer, staticNameIndex,
+                   dynamicNameIndex, line)
+      dynamicIndex = dynamicTable.add(line)
+
+  if dynamicIndex is None:
+    # Couldn't index it, literal
+    if nameIndex is None or isStaticName:
+      # Encodes a literal with a static name or literal name
+      encodeLiteral(streamBuffer, nameIndex, line)
+    else:
+      # encode literal with dynamic name, possibly above base
+      encodeDynamicLiteral(streamBuffer, nameIndex, base, line)
+      requiredInsertCount = max(requiredInsertCount, nameIndex)
+  else:
+    # Dynamic index reference
+    assert(dynamicIndex is not None)
+    requiredInsertCount = max(requiredInsertCount, dynamicIndex)
+    # Encode dynamicIndex, possibly above base
+    encodeDynamicIndexReference(streamBuffer, dynamicIndex, base)
+
+# encode the prefix
+if requiredInsertCount == 0:
+  encodeIndexReference(prefixBuffer, 0, 0, 8)
+  encodeIndexReference(prefixBuffer, 0, 0, 7)
+else:
+  wireRIC = (
+    requiredInsertCount
+    % (2 * getMaxEntries(maxTableCapacity))
+  ) + 1;
+  encodeInteger(prefixBuffer, 0x00, wireRIC, 8)
+  if base &gt;= requiredInsertCount:
+    encodeInteger(prefixBuffer, 0, base - requiredInsertCount, 7)
+  else:
+    encodeInteger(prefixBuffer, 0x80,
+                  requiredInsertCount  - base - 1, 7)
+
+return encoderBuffer, prefixBuffer + streamBuffer
+</pre><a href="#section-appendix.b-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="change-log">
+<section id="section-appendix.c">
+      <h2 id="name-change-log">
+<a href="#section-appendix.c" class="section-number selfRef">Appendix C. </a><a href="#name-change-log" class="section-name selfRef">Change Log</a>
+      </h2>
+<ul class="ulEmpty normal">
+<li class="ulEmpty normal" id="section-appendix.c-1.1">
+          <strong>RFC Editor's Note:</strong> Please remove this section prior to publication of a
+final version of this document.<a href="#section-appendix.c-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+<div id="since-draft-ietf-quic-qpack-14">
+<section id="section-c.1">
+        <h2 id="name-since-draft-ietf-quic-qpack">
+<a href="#section-c.1" class="section-number selfRef">C.1. </a><a href="#name-since-draft-ietf-quic-qpack" class="section-name selfRef">Since draft-ietf-quic-qpack-14</a>
+        </h2>
+<p id="section-c.1-1">Added security considerations<a href="#section-c.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-13">
+<section id="section-c.2">
+        <h2 id="name-since-draft-ietf-quic-qpack-">
+<a href="#section-c.2" class="section-number selfRef">C.2. </a><a href="#name-since-draft-ietf-quic-qpack-" class="section-name selfRef">Since draft-ietf-quic-qpack-13</a>
+        </h2>
+<p id="section-c.2-1">No changes<a href="#section-c.2-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-12">
+<section id="section-c.3">
+        <h2 id="name-since-draft-ietf-quic-qpack-1">
+<a href="#section-c.3" class="section-number selfRef">C.3. </a><a href="#name-since-draft-ietf-quic-qpack-1" class="section-name selfRef">Since draft-ietf-quic-qpack-12</a>
+        </h2>
+<p id="section-c.3-1">Editorial changes only<a href="#section-c.3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-11">
+<section id="section-c.4">
+        <h2 id="name-since-draft-ietf-quic-qpack-11">
+<a href="#section-c.4" class="section-number selfRef">C.4. </a><a href="#name-since-draft-ietf-quic-qpack-11" class="section-name selfRef">Since draft-ietf-quic-qpack-11</a>
+        </h2>
+<p id="section-c.4-1">Editorial changes only<a href="#section-c.4-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-10">
+<section id="section-c.5">
+        <h2 id="name-since-draft-ietf-quic-qpack-10">
+<a href="#section-c.5" class="section-number selfRef">C.5. </a><a href="#name-since-draft-ietf-quic-qpack-10" class="section-name selfRef">Since draft-ietf-quic-qpack-10</a>
+        </h2>
+<p id="section-c.5-1">Editorial changes only<a href="#section-c.5-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-09">
+<section id="section-c.6">
+        <h2 id="name-since-draft-ietf-quic-qpack-0">
+<a href="#section-c.6" class="section-number selfRef">C.6. </a><a href="#name-since-draft-ietf-quic-qpack-0" class="section-name selfRef">Since draft-ietf-quic-qpack-09</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.6-1.1">Decoders MUST emit Header Acknowledgements (#2939)<a href="#section-c.6-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.2">Updated error code for multiple encoder or decoder streams (#2970)<a href="#section-c.6-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.3">Added explicit defaults for new SETTINGS (#2974)<a href="#section-c.6-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-08">
+<section id="section-c.7">
+        <h2 id="name-since-draft-ietf-quic-qpack-08">
+<a href="#section-c.7" class="section-number selfRef">C.7. </a><a href="#name-since-draft-ietf-quic-qpack-08" class="section-name selfRef">Since draft-ietf-quic-qpack-08</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.7-1.1">Endpoints are permitted to create encoder and decoder streams even if they
+can't use them (#2100, #2529)<a href="#section-c.7-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.7-1.2">Maximum values for settings removed (#2766, #2767)<a href="#section-c.7-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-06">
+<section id="section-c.8">
+        <h2 id="name-since-draft-ietf-quic-qpack-06">
+<a href="#section-c.8" class="section-number selfRef">C.8. </a><a href="#name-since-draft-ietf-quic-qpack-06" class="section-name selfRef">Since draft-ietf-quic-qpack-06</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.8-1.1">Clarify initial dynamic table capacity maximums (#2276, #2330, #2330)<a href="#section-c.8-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-05">
+<section id="section-c.9">
+        <h2 id="name-since-draft-ietf-quic-qpack-05">
+<a href="#section-c.9" class="section-number selfRef">C.9. </a><a href="#name-since-draft-ietf-quic-qpack-05" class="section-name selfRef">Since draft-ietf-quic-qpack-05</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.9-1.1">Introduced the terms dynamic table capacity and maximum dynamic table
+capacity.<a href="#section-c.9-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.2">Renamed SETTINGS_HEADER_TABLE_SIZE to SETTINGS_QPACK_MAX_TABLE_CAPACITY.<a href="#section-c.9-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-04">
+<section id="section-c.10">
+        <h2 id="name-since-draft-ietf-quic-qpack-04">
+<a href="#section-c.10" class="section-number selfRef">C.10. </a><a href="#name-since-draft-ietf-quic-qpack-04" class="section-name selfRef">Since draft-ietf-quic-qpack-04</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.10-1.1">Changed calculation of Delta Base Index to avoid an illegal value (#2002,
+#2005)<a href="#section-c.10-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-03">
+<section id="section-c.11">
+        <h2 id="name-since-draft-ietf-quic-qpack-03">
+<a href="#section-c.11" class="section-number selfRef">C.11. </a><a href="#name-since-draft-ietf-quic-qpack-03" class="section-name selfRef">Since draft-ietf-quic-qpack-03</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.11-1.1">Change HTTP settings defaults (#2038)<a href="#section-c.11-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.2">Substantial editorial reorganization<a href="#section-c.11-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-02">
+<section id="section-c.12">
+        <h2 id="name-since-draft-ietf-quic-qpack-02">
+<a href="#section-c.12" class="section-number selfRef">C.12. </a><a href="#name-since-draft-ietf-quic-qpack-02" class="section-name selfRef">Since draft-ietf-quic-qpack-02</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.12-1.1">Largest Reference encoded modulo MaxEntries (#1763)<a href="#section-c.12-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.2">New Static Table (#1355)<a href="#section-c.12-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.3">Table Size Update with Insert Count=0 is a connection error (#1762)<a href="#section-c.12-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.4">Stream Cancellations are optional when SETTINGS_HEADER_TABLE_SIZE=0 (#1761)<a href="#section-c.12-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.5">Implementations must handle 62 bit integers (#1760)<a href="#section-c.12-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.6">Different error types for each QPACK stream, other changes to error
+handling (#1726)<a href="#section-c.12-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.7">Preserve header field order (#1725)<a href="#section-c.12-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8">Initial table size is the maximum permitted when table is first usable (#1642)<a href="#section-c.12-1.8" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-01">
+<section id="section-c.13">
+        <h2 id="name-since-draft-ietf-quic-qpack-01">
+<a href="#section-c.13" class="section-number selfRef">C.13. </a><a href="#name-since-draft-ietf-quic-qpack-01" class="section-name selfRef">Since draft-ietf-quic-qpack-01</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.13-1.1">Only header blocks that reference the dynamic table are acknowledged (#1603,
+#1605)<a href="#section-c.13-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qpack-00">
+<section id="section-c.14">
+        <h2 id="name-since-draft-ietf-quic-qpack-00">
+<a href="#section-c.14" class="section-number selfRef">C.14. </a><a href="#name-since-draft-ietf-quic-qpack-00" class="section-name selfRef">Since draft-ietf-quic-qpack-00</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.14-1.1">Renumbered instructions for consistency (#1471, #1472)<a href="#section-c.14-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.2">Decoder is allowed to validate largest reference (#1404, #1469)<a href="#section-c.14-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.3">Header block acknowledgments also acknowledge the associated largest reference
+(#1370, #1400)<a href="#section-c.14-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.4">Added an acknowledgment for unread streams (#1371, #1400)<a href="#section-c.14-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.5">Removed framing from encoder stream (#1361,#1467)<a href="#section-c.14-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.6">Control streams use typed unidirectional streams rather than fixed stream IDs
+(#910,#1359)<a href="#section-c.14-1.6" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-qcram-00">
+<section id="section-c.15">
+        <h2 id="name-since-draft-ietf-quic-qcram">
+<a href="#section-c.15" class="section-number selfRef">C.15. </a><a href="#name-since-draft-ietf-quic-qcram" class="section-name selfRef">Since draft-ietf-quic-qcram-00</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.15-1.1">Separate instruction sets for table updates and header blocks (#1235, #1142,
+#1141)<a href="#section-c.15-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.2">Reworked indexing scheme (#1176, #1145, #1136, #1130, #1125, #1314)<a href="#section-c.15-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.3">Added mechanisms that support one-pass encoding (#1138, #1320)<a href="#section-c.15-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.4">Added a setting to control the number of blocked decoders (#238, #1140, #1143)<a href="#section-c.15-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.5">Moved table updates and acknowledgments to dedicated streams (#1121, #1122,
+#1238)<a href="#section-c.15-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+</section>
+</div>
+<div id="acknowledgments">
+<section id="section-appendix.d">
+      <h2 id="name-acknowledgments">
+<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
+      </h2>
+<p id="section-appendix.d-1">The IETF QUIC Working Group received an enormous amount of support from many
+people.<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
+<p id="section-appendix.d-2">The compression design team did substantial work exploring the problem space and
+influencing the initial draft.  The contributions of design team members Roberto
+Peon, Martin Thomson, and Dmitri Tikhonov are gratefully acknowledged.<a href="#section-appendix.d-2" class="pilcrow">¶</a></p>
+<p id="section-appendix.d-3">The following people also provided substantial contributions to this document:<a href="#section-appendix.d-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-appendix.d-4.1">Bence Beky<a href="#section-appendix.d-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-4.2">Alessandro Ghedini<a href="#section-appendix.d-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-4.3">Ryan Hamilton<a href="#section-appendix.d-4.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-4.4">Robin Marx<a href="#section-appendix.d-4.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-4.5">Patrick McManus<a href="#section-appendix.d-4.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-4.6">
+          <p id="section-appendix.d-4.6.1">        <span class="contact-name"><span class="non-ascii">奥 一穂</span> (<span class="ascii">Kazuho Oku</span>)</span><a href="#section-appendix.d-4.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="normal" id="section-appendix.d-4.7">Lucas Pardue<a href="#section-appendix.d-4.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-4.8">Biren Roy<a href="#section-appendix.d-4.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-4.9">Ian Swett<a href="#section-appendix.d-4.9" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-appendix.d-5">This draft draws heavily on the text of <span>[<a href="#RFC7541" class="xref">RFC7541</a>]</span>.  The indirect input of
+those authors is also gratefully acknowledged.<a href="#section-appendix.d-5" class="pilcrow">¶</a></p>
+<p id="section-appendix.d-6">Buck's contribution was supported by Google during his employment there.<a href="#section-appendix.d-6" class="pilcrow">¶</a></p>
+<p id="section-appendix.d-7">A portion of Mike's contribution was supported by Microsoft during his
+employment there.<a href="#section-appendix.d-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="authors-addresses">
+<section id="section-appendix.e">
+      <h2 id="name-authors-addresses">
+<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+      </h2>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Charles 'Buck' Krasic</span></div>
+<div dir="auto" class="left"><span class="org">Netflix</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:ckrasic@netflix.com" class="email">ckrasic@netflix.com</a>
+</div>
+</address>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Mike Bishop</span></div>
+<div dir="auto" class="left"><span class="org">Akamai Technologies</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:mbishop@evequefou.be" class="email">mbishop@evequefou.be</a>
+</div>
+</address>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Alan Frindell (<span class="role">editor</span>)</span></div>
+<div dir="auto" class="left"><span class="org">Facebook</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:afrind@fb.com" class="email">afrind@fb.com</a>
+</div>
+</address>
+</section>
+</div>
+<script>const toc = document.getElementById("toc");
+toc.querySelector("h2").addEventListener("click", e => {
+  toc.classList.toggle("active");
+});
+toc.querySelector("nav").addEventListener("click", e => {
+  toc.classList.remove("active");
+});
+</script>
+</body>
+</html>
diff --git a/jri/mustnot/draft-ietf-quic-qpack.txt b/jri/mustnot/draft-ietf-quic-qpack.txt
new file mode 100644
index 0000000000..29d8655d11
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-qpack.txt
@@ -0,0 +1,2464 @@
+
+
+
+
+QUIC                                                           C. Krasic
+Internet-Draft                                                   Netflix
+Intended status: Standards Track                               M. Bishop
+Expires: 5 December 2020                             Akamai Technologies
+                                                        A. Frindell, Ed.
+                                                                Facebook
+                                                             3 June 2020
+
+
+                  QPACK: Header Compression for HTTP/3
+                      draft-ietf-quic-qpack-latest
+
+Abstract
+
+   This specification defines QPACK, a compression format for
+   efficiently representing HTTP fields, to be used in HTTP/3.  This is
+   a variation of HPACK compression that seeks to reduce head-of-line
+   blocking.
+
+Note to Readers
+
+   Discussion of this draft takes place on the QUIC working group
+   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
+   archived at https://mailarchive.ietf.org/arch/
+   search/?email_list=quic.
+
+   Working Group information can be found at https://github.com/quicwg;
+   source code and issues list for this draft can be found at
+   https://github.com/quicwg/base-drafts/labels/-qpack.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at https://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on 5 December 2020.
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 1]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (https://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.  Code Components
+   extracted from this document must include Simplified BSD License text
+   as described in Section 4.e of the Trust Legal Provisions and are
+   provided without warranty as described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   4
+     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
+   2.  Compression Process Overview  . . . . . . . . . . . . . . . .   5
+     2.1.  Encoder . . . . . . . . . . . . . . . . . . . . . . . . .   5
+       2.1.1.  Limits on Dynamic Table Insertions  . . . . . . . . .   6
+       2.1.2.  Blocked Streams . . . . . . . . . . . . . . . . . . .   7
+       2.1.3.  Avoiding Flow Control Deadlocks . . . . . . . . . . .   8
+       2.1.4.  Known Received Count  . . . . . . . . . . . . . . . .   8
+     2.2.  Decoder . . . . . . . . . . . . . . . . . . . . . . . . .   9
+       2.2.1.  Blocked Decoding  . . . . . . . . . . . . . . . . . .   9
+       2.2.2.  State Synchronization . . . . . . . . . . . . . . . .   9
+       2.2.3.  Invalid References  . . . . . . . . . . . . . . . . .  11
+   3.  Reference Tables  . . . . . . . . . . . . . . . . . . . . . .  11
+     3.1.  Static Table  . . . . . . . . . . . . . . . . . . . . . .  11
+     3.2.  Dynamic Table . . . . . . . . . . . . . . . . . . . . . .  11
+       3.2.1.  Dynamic Table Size  . . . . . . . . . . . . . . . . .  12
+       3.2.2.  Dynamic Table Capacity and Eviction . . . . . . . . .  12
+       3.2.3.  Maximum Dynamic Table Capacity  . . . . . . . . . . .  13
+       3.2.4.  Absolute Indexing . . . . . . . . . . . . . . . . . .  13
+       3.2.5.  Relative Indexing . . . . . . . . . . . . . . . . . .  13
+       3.2.6.  Post-Base Indexing  . . . . . . . . . . . . . . . . .  14
+   4.  Wire Format . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     4.1.  Primitives  . . . . . . . . . . . . . . . . . . . . . . .  15
+       4.1.1.  Prefixed Integers . . . . . . . . . . . . . . . . . .  15
+       4.1.2.  String Literals . . . . . . . . . . . . . . . . . . .  15
+     4.2.  Encoder and Decoder Streams . . . . . . . . . . . . . . .  16
+     4.3.  Encoder Instructions  . . . . . . . . . . . . . . . . . .  17
+       4.3.1.  Set Dynamic Table Capacity  . . . . . . . . . . . . .  17
+       4.3.2.  Insert With Name Reference  . . . . . . . . . . . . .  17
+       4.3.3.  Insert Without Name Reference . . . . . . . . . . . .  18
+       4.3.4.  Duplicate . . . . . . . . . . . . . . . . . . . . . .  18
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 2]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+     4.4.  Decoder Instructions  . . . . . . . . . . . . . . . . . .  19
+       4.4.1.  Section Acknowledgement . . . . . . . . . . . . . . .  19
+       4.4.2.  Stream Cancellation . . . . . . . . . . . . . . . . .  20
+       4.4.3.  Insert Count Increment  . . . . . . . . . . . . . . .  20
+     4.5.  Field Line Representations  . . . . . . . . . . . . . . .  20
+       4.5.1.  Encoded Field Section Prefix  . . . . . . . . . . . .  21
+       4.5.2.  Indexed Field Line  . . . . . . . . . . . . . . . . .  23
+       4.5.3.  Indexed Field Line With Post-Base Index . . . . . . .  24
+       4.5.4.  Literal Field Line With Name Reference  . . . . . . .  24
+       4.5.5.  Literal Field Line With Post-Base Name Reference  . .  25
+       4.5.6.  Literal Field Line Without Name Reference . . . . . .  25
+   5.  Configuration . . . . . . . . . . . . . . . . . . . . . . . .  26
+   6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  26
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
+     7.1.  Probing Dynamic Table State . . . . . . . . . . . . . . .  27
+     7.2.  Applicability to QPACK and HTTP . . . . . . . . . . . . .  28
+     7.3.  Mitigation  . . . . . . . . . . . . . . . . . . . . . . .  28
+     7.4.  Never Indexed Literals  . . . . . . . . . . . . . . . . .  29
+     7.5.  Static Huffman Encoding . . . . . . . . . . . . . . . . .  30
+     7.6.  Memory Consumption  . . . . . . . . . . . . . . . . . . .  30
+     7.7.  Implementation Limits . . . . . . . . . . . . . . . . . .  31
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
+     8.1.  Settings Registration . . . . . . . . . . . . . . . . . .  31
+     8.2.  Stream Type Registration  . . . . . . . . . . . . . . . .  32
+     8.3.  Error Code Registration . . . . . . . . . . . . . . . . .  32
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  33
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  34
+   Appendix A.  Static Table . . . . . . . . . . . . . . . . . . . .  34
+   Appendix B.  Sample One Pass Encoding Algorithm . . . . . . . . .  39
+   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . .  40
+     C.1.  Since draft-ietf-quic-qpack-14  . . . . . . . . . . . . .  40
+     C.2.  Since draft-ietf-quic-qpack-13  . . . . . . . . . . . . .  41
+     C.3.  Since draft-ietf-quic-qpack-12  . . . . . . . . . . . . .  41
+     C.4.  Since draft-ietf-quic-qpack-11  . . . . . . . . . . . . .  41
+     C.5.  Since draft-ietf-quic-qpack-10  . . . . . . . . . . . . .  41
+     C.6.  Since draft-ietf-quic-qpack-09  . . . . . . . . . . . . .  41
+     C.7.  Since draft-ietf-quic-qpack-08  . . . . . . . . . . . . .  41
+     C.8.  Since draft-ietf-quic-qpack-06  . . . . . . . . . . . . .  41
+     C.9.  Since draft-ietf-quic-qpack-05  . . . . . . . . . . . . .  41
+     C.10. Since draft-ietf-quic-qpack-04  . . . . . . . . . . . . .  41
+     C.11. Since draft-ietf-quic-qpack-03  . . . . . . . . . . . . .  42
+     C.12. Since draft-ietf-quic-qpack-02  . . . . . . . . . . . . .  42
+     C.13. Since draft-ietf-quic-qpack-01  . . . . . . . . . . . . .  42
+     C.14. Since draft-ietf-quic-qpack-00  . . . . . . . . . . . . .  42
+     C.15. Since draft-ietf-quic-qcram-00  . . . . . . . . . . . . .  43
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  43
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 3]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+1.  Introduction
+
+   The QUIC transport protocol [QUIC-TRANSPORT] is designed to support
+   HTTP semantics, and its design subsumes many of the features of
+   HTTP/2 [RFC7540].  HTTP/2 uses HPACK [RFC7541] for compression of the
+   header and trailer sections.  If HPACK were used for HTTP/3 [HTTP3],
+   it would induce head-of-line blocking for field sections due to
+   built-in assumptions of a total ordering across frames on all
+   streams.
+
+   QPACK reuses core concepts from HPACK, but is redesigned to allow
+   correctness in the presence of out-of-order delivery, with
+   flexibility for implementations to balance between resilience against
+   head-of-line blocking and optimal compression ratio.  The design
+   goals are to closely approach the compression ratio of HPACK with
+   substantially less head-of-line blocking under the same loss
+   conditions.
+
+1.1.  Conventions and Definitions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Definitions of terms that are used in this document:
+
+   HTTP fields:  Metadata sent as part of an HTTP message.  The term
+      encompasses both header and trailer fields.  Colloquially, the
+      term "headers" has often been used to refer to HTTP header fields
+      and trailer fields; this document uses "fields" for generality.
+
+   HTTP field line:  A name-value pair sent as part of an HTTP field
+      section.  See Section 4 of [SEMANTICS].
+
+   HTTP field value:  Data associated with a field name, composed from
+      all field line values with that field name in that section,
+      concatenated together and separated with commas.
+
+   Field section:  An ordered collection of HTTP field lines associated
+      with an HTTP message.  A field section can contain multiple field
+      lines with the same name.  It can also contain duplicate field
+      lines.  An HTTP message can include both header field and trailer
+      field sections.
+
+   Representation:  An instruction which represents a field line,
+      possibly by reference to the dynamic and static tables.
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 4]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   Encoder:  An implementation which encodes field sections.
+
+   Decoder:  An implementation which decodes encoded field sections.
+
+   Absolute Index:  A unique index for each entry in the dynamic table.
+
+   Base:  A reference point for relative and post-base indices.
+      Representations which reference dynamic table entries are relative
+      to a Base.
+
+   Insert Count:  The total number of entries inserted in the dynamic
+      table.
+
+   QPACK is a name, not an acronym.
+
+1.2.  Notational Conventions
+
+   Diagrams use the format described in Section 3.1 of [RFC2360], with
+   the following additional conventions:
+
+   x (A)  Indicates that x is A bits long
+
+   x (A+)  Indicates that x uses the prefixed integer encoding defined
+      in Section 4.1.1, beginning with an A-bit prefix.
+
+   x ...  Indicates that x is variable-length and extends to the end of
+      the region.
+
+2.  Compression Process Overview
+
+   Like HPACK, QPACK uses two tables for associating field lines
+   ("headers") to indices.  The static table (Section 3.1) is predefined
+   and contains common header field lines (some of them with an empty
+   value).  The dynamic table (Section 3.2) is built up over the course
+   of the connection and can be used by the encoder to index both header
+   and trailer field lines in the encoded field sections.
+
+   QPACK defines unidirectional streams for sending instructions from
+   encoder to decoder and vice versa.
+
+2.1.  Encoder
+
+   An encoder converts a header or trailer field section into a series
+   of representations by emitting either an indexed or a literal
+   representation for each field line in the list; see Section 4.5.
+   Indexed representations achieve high compression by replacing the
+   literal name and possibly the value with an index to either the
+   static or dynamic table.  References to the static table and literal
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 5]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   representations do not require any dynamic state and never risk head-
+   of-line blocking.  References to the dynamic table risk head-of-line
+   blocking if the encoder has not received an acknowledgement
+   indicating the entry is available at the decoder.
+
+   An encoder MAY insert any entry in the dynamic table it chooses; it
+   is not limited to field lines it is compressing.
+
+   QPACK preserves the ordering of field lines within each field
+   section.  An encoder MUST emit field representations in the order
+   they appear in the input field section.
+
+   QPACK is designed to contain the more complex state tracking to the
+   encoder, while the decoder is relatively simple.
+
+2.1.1.  Limits on Dynamic Table Insertions
+
+   Inserting entries into the dynamic table might not be possible if the
+   table contains entries which cannot be evicted.
+
+   A dynamic table entry cannot be evicted immediately after insertion,
+   even if it has never been referenced.  Once the insertion of a
+   dynamic table entry has been acknowledged and there are no
+   outstanding references to the entry in unacknowledged
+   representations, the entry becomes evictable.  Note that references
+   on the encoder stream never preclude the eviction of an entry,
+   because those references are guaranteed to be processed before the
+   instruction evicting the entry.
+
+   If the dynamic table does not contain enough room for a new entry
+   without evicting other entries, and the entries which would be
+   evicted are not evictable, the encoder MUST NOT insert that entry
+   into the dynamic table (including duplicates of existing entries).
+   In order to avoid this, an encoder that uses the dynamic table has to
+   keep track of each dynamic table entry referenced by each field
+   section until those representations are acknowledged by the decoder;
+   see Section 4.4.1.
+
+2.1.1.1.  Avoiding Prohibited Insertions
+
+   To ensure that the encoder is not prevented from adding new entries,
+   the encoder can avoid referencing entries that are close to eviction.
+   Rather than reference such an entry, the encoder can emit a Duplicate
+   instruction (Section 4.3.4), and reference the duplicate instead.
+
+   Determining which entries are too close to eviction to reference is
+   an encoder preference.  One heuristic is to target a fixed amount of
+   available space in the dynamic table: either unused space or space
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 6]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   that can be reclaimed by evicting non-blocking entries.  To achieve
+   this, the encoder can maintain a draining index, which is the
+   smallest absolute index (Section 3.2.4) in the dynamic table that it
+   will emit a reference for.  As new entries are inserted, the encoder
+   increases the draining index to maintain the section of the table
+   that it will not reference.  If the encoder does not create new
+   references to entries with an absolute index lower than the draining
+   index, the number of unacknowledged references to those entries will
+   eventually become zero, allowing them to be evicted.
+
+      +--------+---------------------------------+----------+
+      | Unused |          Referenceable          | Draining |
+      | Space  |             Entries             | Entries  |
+      +--------+---------------------------------+----------+
+               ^                                 ^          ^
+               |                                 |          |
+         Insertion Point                 Draining Index  Dropping
+                                                          Point
+
+                  Figure 1: Draining Dynamic Table Entries
+
+2.1.2.  Blocked Streams
+
+   Because QUIC does not guarantee order between data on different
+   streams, a decoder might encounter a representation that references a
+   dynamic table entry that it has not yet received.
+
+   Each encoded field section contains a Required Insert Count
+   (Section 4.5.1), the lowest possible value for the Insert Count with
+   which the field section can be decoded.  For a field section encoded
+   using references to the dynamic table, the Required Insert Count is
+   one larger than the largest absolute index of all referenced dynamic
+   table entries.  For a field section encoded with no references to the
+   dynamic table, the Required Insert Count is zero.
+
+   When the decoder receives an encoded field section with a Required
+   Insert Count greater than its own Insert Count, the stream cannot be
+   processed immediately, and is considered "blocked"; see
+   Section 2.2.1.
+
+   The decoder specifies an upper bound on the number of streams which
+   can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting; see
+   Section 5.  An encoder MUST limit the number of streams which could
+   become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all
+   times.  If a decoder encounters more blocked streams than it promised
+   to support, it MUST treat this as a connection error of type
+   QPACK_DECOMPRESSION_FAILED.
+
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 7]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   Note that the decoder might not become blocked on every stream which
+   risks becoming blocked.
+
+   An encoder can decide whether to risk having a stream become blocked.
+   If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS,
+   compression efficiency can often be improved by referencing dynamic
+   table entries that are still in transit, but if there is loss or
+   reordering the stream can become blocked at the decoder.  An encoder
+   can avoid the risk of blocking by only referencing dynamic table
+   entries which have been acknowledged, but this could mean using
+   literals.  Since literals make the encoded field section larger, this
+   can result in the encoder becoming blocked on congestion or flow
+   control limits.
+
+2.1.3.  Avoiding Flow Control Deadlocks
+
+   Writing instructions on streams that are limited by flow control can
+   produce deadlocks.
+
+   A decoder might stop issuing flow control credit on the stream that
+   carries an encoded field section until the necessary updates are
+   received on the encoder stream.  If the granting of flow control
+   credit on the encoder stream (or the connection as a whole) depends
+   on the consumption and release of data on the stream carrying the
+   encoded field section, a deadlock might result.
+
+   More generally, a stream containing a large instruction can become
+   deadlocked if the decoder withholds flow control credit until the
+   instruction is completely received.
+
+   To avoid these deadlocks, an encoder SHOULD avoid writing an
+   instruction unless sufficient stream and connection flow control
+   credit is available for the entire instruction.
+
+2.1.4.  Known Received Count
+
+   The Known Received Count is the total number of dynamic table
+   insertions and duplications acknowledged by the decoder.  The encoder
+   tracks the Known Received Count in order to identify which dynamic
+   table entries can be referenced without potentially blocking a
+   stream.  The decoder tracks the Known Received Count in order to be
+   able to send Insert Count Increment instructions.
+
+   A Section Acknowledgement instruction (Section 4.4.1) implies that
+   the decoder has received all dynamic table state necessary to decode
+   the field section.  If the Required Insert Count of the acknowledged
+   field section is greater than the current Known Received Count, Known
+   Received Count is updated to the value of the Required Insert Count.
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 8]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   An Insert Count Increment instruction Section 4.4.3 increases the
+   Known Received Count by its Increment parameter.  See Section 2.2.2.3
+   for guidance.
+
+2.2.  Decoder
+
+   As in HPACK, the decoder processes a series of representations and
+   emits the corresponding field sections.  It also processes
+   instructions received on the encoder stream that modify the dynamic
+   table.  Note that encoded field sections and encoder stream
+   instructions arrive on separate streams.  This is unlike HPACK, where
+   encoded field sections (header blocks) can contain instructions that
+   modify the dynamic table, and there is no dedicated stream of HPACK
+   instructions.
+
+   The decoder MUST emit field lines in the order their representations
+   appear in the encoded field section.
+
+2.2.1.  Blocked Decoding
+
+   Upon receipt of an encoded field section, the decoder examines the
+   Required Insert Count.  When the Required Insert Count is less than
+   or equal to the decoder's Insert Count, the field section can be
+   processed immediately.  Otherwise, the stream on which the field
+   section was received becomes blocked.
+
+   While blocked, encoded field section data SHOULD remain in the
+   blocked stream's flow control window.  A stream becomes unblocked
+   when the Insert Count becomes greater than or equal to the Required
+   Insert Count for all encoded field sections the decoder has started
+   reading from the stream.
+
+   When processing encoded field sections, the decoder expects the
+   Required Insert Count to equal the lowest possible value for the
+   Insert Count with which the field section can be decoded, as
+   prescribed in Section 2.1.2.  If it encounters a Required Insert
+   Count smaller than expected, it MUST treat this as a connection error
+   of type QPACK_DECOMPRESSION_FAILED; see Section 2.2.3.  If it
+   encounters a Required Insert Count larger than expected, it MAY treat
+   this as a connection error of type QPACK_DECOMPRESSION_FAILED.
+
+2.2.2.  State Synchronization
+
+   The decoder signals the following events by emitting decoder
+   instructions (Section 4.4) on the decoder stream.
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020                [Page 9]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+2.2.2.1.  Completed Processing of a Field Section
+
+   After the decoder finishes decoding a field section encoded using
+   representations containing dynamic table references, it MUST emit a
+   Section Acknowledgement instruction (Section 4.4.1).  A stream may
+   carry multiple field sections in the case of intermediate responses,
+   trailers, and pushed requests.  The encoder interprets each
+   Section Acknowledgement instruction as acknowledging the earliest
+   unacknowledged field section containing dynamic table references sent
+   on the given stream.
+
+2.2.2.2.  Abandonment of a Stream
+
+   When an endpoint receives a stream reset before the end of a stream
+   or before all encoded field sections are processed on that stream, or
+   when it abandons reading of a stream, it generates a Stream
+   Cancellation instruction; see Section 4.4.2.  This signals to the
+   encoder that all references to the dynamic table on that stream are
+   no longer outstanding.  A decoder with a maximum dynamic table
+   capacity (Section 3.2.3) equal to zero MAY omit sending Stream
+   Cancellations, because the encoder cannot have any dynamic table
+   references.  An encoder cannot infer from this instruction that any
+   updates to the dynamic table have been received.
+
+   The Section Acknowledgement and Stream Cancellation instructions
+   permit the encoder to remove references to entries in the dynamic
+   table.  When an entry with absolute index lower than the Known
+   Received Count has zero references, then it is considered evictable;
+   see Section 2.1.1.
+
+2.2.2.3.  New Table Entries
+
+   After receiving new table entries on the encoder stream, the decoder
+   chooses when to emit Insert Count Increment instructions; see
+   Section 4.4.3.  Emitting this instruction after adding each new
+   dynamic table entry will provide the timeliest feedback to the
+   encoder, but could be redundant with other decoder feedback.  By
+   delaying an Insert Count Increment instruction, the decoder might be
+   able to coalesce multiple Insert Count Increment instructions, or
+   replace them entirely with Section Acknowledgements; see
+   Section 4.4.1.  However, delaying too long may lead to compression
+   inefficiencies if the encoder waits for an entry to be acknowledged
+   before using it.
+
+
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 10]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+2.2.3.  Invalid References
+
+   If the decoder encounters a reference in a field line representation
+   to a dynamic table entry which has already been evicted or which has
+   an absolute index greater than or equal to the declared Required
+   Insert Count (Section 4.5.1), it MUST treat this as a connection
+   error of type QPACK_DECOMPRESSION_FAILED.
+
+   If the decoder encounters a reference in an encoder instruction to a
+   dynamic table entry which has already been evicted, it MUST treat
+   this as a connection error of type QPACK_ENCODER_STREAM_ERROR.
+
+3.  Reference Tables
+
+   Unlike in HPACK, entries in the QPACK static and dynamic tables are
+   addressed separately.  The following sections describe how entries in
+   each table are addressed.
+
+3.1.  Static Table
+
+   The static table consists of a predefined static list of field lines,
+   each of which has a fixed index over time.  Its entries are defined
+   in Appendix A.
+
+   All entries in the static table have a name and a value.  However,
+   values can be empty (that is, have a length of 0).  Each entry is
+   identified by a unique index.
+
+   Note that the QPACK static table is indexed from 0, whereas the HPACK
+   static table is indexed from 1.
+
+   When the decoder encounters an invalid static table index in a field
+   line representation it MUST treat this as a connection error of type
+   QPACK_DECOMPRESSION_FAILED.  If this index is received on the encoder
+   stream, this MUST be treated as a connection error of type
+   QPACK_ENCODER_STREAM_ERROR.
+
+3.2.  Dynamic Table
+
+   The dynamic table consists of a list of field lines maintained in
+   first-in, first-out order.  Each HTTP/3 endpoint holds a dynamic
+   table that is initially empty.  Entries are added by encoder
+   instructions received on the encoder stream; see Section 4.3.
+
+   The dynamic table can contain duplicate entries (i.e., entries with
+   the same name and same value).  Therefore, duplicate entries MUST NOT
+   be treated as an error by the decoder.
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 11]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   Dynamic table entries can have empty values.
+
+3.2.1.  Dynamic Table Size
+
+   The size of the dynamic table is the sum of the size of its entries.
+
+   The size of an entry is the sum of its name's length in bytes, its
+   value's length in bytes, and 32.  The size of an entry is calculated
+   using the length of its name and value without Huffman encoding
+   applied.
+
+3.2.2.  Dynamic Table Capacity and Eviction
+
+   The encoder sets the capacity of the dynamic table, which serves as
+   the upper limit on its size.  The initial capacity of the dynamic
+   table is zero.  The encoder sends a Set Dynamic Table Capacity
+   instruction (Section 4.3.1) with a non-zero capacity to begin using
+   the dynamic table.
+
+   Before a new entry is added to the dynamic table, entries are evicted
+   from the end of the dynamic table until the size of the dynamic table
+   is less than or equal to (table capacity - size of new entry).  The
+   encoder MUST NOT cause a dynamic table entry to be evicted unless
+   that entry is evictable; see Section 2.1.1.  The new entry is then
+   added to the table.  It is an error if the encoder attempts to add an
+   entry that is larger than the dynamic table capacity; the decoder
+   MUST treat this as a connection error of type
+   QPACK_ENCODER_STREAM_ERROR.
+
+   A new entry can reference an entry in the dynamic table that will be
+   evicted when adding this new entry into the dynamic table.
+   Implementations are cautioned to avoid deleting the referenced name
+   or value if the referenced entry is evicted from the dynamic table
+   prior to inserting the new entry.
+
+   Whenever the dynamic table capacity is reduced by the encoder
+   (Section 4.3.1), entries are evicted from the end of the dynamic
+   table until the size of the dynamic table is less than or equal to
+   the new table capacity.  This mechanism can be used to completely
+   clear entries from the dynamic table by setting a capacity of 0,
+   which can subsequently be restored.
+
+
+
+
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 12]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+3.2.3.  Maximum Dynamic Table Capacity
+
+   To bound the memory requirements of the decoder, the decoder limits
+   the maximum value the encoder is permitted to set for the dynamic
+   table capacity.  In HTTP/3, this limit is determined by the value of
+   SETTINGS_QPACK_MAX_TABLE_CAPACITY sent by the decoder; see Section 5.
+   The encoder MUST not set a dynamic table capacity that exceeds this
+   maximum, but it can choose to use a lower dynamic table capacity; see
+   Section 4.3.1.
+
+   For clients using 0-RTT data in HTTP/3, the server's maximum table
+   capacity is the remembered value of the setting, or zero if the value
+   was not previously sent.  When the client's 0-RTT value of the
+   SETTING is zero, the server MAY set it to a non-zero value in its
+   SETTINGS frame.  If the remembered value is non-zero, the server MUST
+   send the same non-zero value in its SETTINGS frame.  If it specifies
+   any other value, or omits SETTINGS_QPACK_MAX_TABLE_CAPACITY from
+   SETTINGS, the encoder must treat this as a connection error of type
+   QPACK_DECODER_STREAM_ERROR.
+
+   For HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or
+   is rejected, the maximum table capacity is 0 until the encoder
+   processes a SETTINGS frame with a non-zero value of
+   SETTINGS_QPACK_MAX_TABLE_CAPACITY.
+
+   When the maximum table capacity is zero, the encoder MUST NOT insert
+   entries into the dynamic table, and MUST NOT send any encoder
+   instructions on the encoder stream.
+
+3.2.4.  Absolute Indexing
+
+   Each entry possesses an absolute index which is fixed for the
+   lifetime of that entry.  The first entry inserted has an absolute
+   index of "0"; indices increase by one with each insertion.
+
+3.2.5.  Relative Indexing
+
+   Relative indices begin at zero and increase in the opposite direction
+   from the absolute index.  Determining which entry has a relative
+   index of "0" depends on the context of the reference.
+
+   In encoder instructions (Section 4.3), a relative index of "0" refers
+   to the most recently inserted value in the dynamic table.  Note that
+   this means the entry referenced by a given relative index will change
+   while interpreting instructions on the encoder stream.
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 13]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+         +-----+---------------+-------+
+         | n-1 |      ...      |   d   |  Absolute Index
+         + - - +---------------+ - - - +
+         |  0  |      ...      | n-d-1 |  Relative Index
+         +-----+---------------+-------+
+         ^                             |
+         |                             V
+   Insertion Point               Dropping Point
+
+   n = count of entries inserted
+   d = count of entries dropped
+
+         Figure 2: Example Dynamic Table Indexing - Encoder Stream
+
+   Unlike in encoder instructions, relative indices in field line
+   representations are relative to the Base at the beginning of the
+   encoded field section; see Section 4.5.1.  This ensures that
+   references are stable even if encoded field sections and dynamic
+   table updates are processed out of order.
+
+   In a field line representation, a relative index of "0" refers to the
+   entry with absolute index equal to Base - 1.
+
+                  Base
+                   |
+                   V
+       +-----+-----+-----+-----+-------+
+       | n-1 | n-2 | n-3 | ... |   d   |  Absolute Index
+       +-----+-----+  -  +-----+   -   +
+                   |  0  | ... | n-d-3 |  Relative Index
+                   +-----+-----+-------+
+
+   n = count of entries inserted
+   d = count of entries dropped
+   In this example, Base = n - 2
+
+        Figure 3: Example Dynamic Table Indexing - Relative Index in
+                               Representation
+
+3.2.6.  Post-Base Indexing
+
+   Post-Base indices are used in field line representations for entries
+   with absolute indices greater than or equal to Base, starting at 0
+   for the entry with absolute index equal to Base, and increasing in
+   the same direction as the absolute index.
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 14]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   Post-Base indices allow an encoder to process a field section in a
+   single pass and include references to entries added while processing
+   this (or other) field sections.
+
+                  Base
+                   |
+                   V
+       +-----+-----+-----+-----+-----+
+       | n-1 | n-2 | n-3 | ... |  d  |  Absolute Index
+       +-----+-----+-----+-----+-----+
+       |  1  |  0  |                    Post-Base Index
+       +-----+-----+
+
+   n = count of entries inserted
+   d = count of entries dropped
+   In this example, Base = n - 2
+
+       Figure 4: Example Dynamic Table Indexing - Post-Base Index in
+                               Representation
+
+4.  Wire Format
+
+4.1.  Primitives
+
+4.1.1.  Prefixed Integers
+
+   The prefixed integer from Section 5.1 of [RFC7541] is used heavily
+   throughout this document.  The format from [RFC7541] is used
+   unmodified.  Note, however, that QPACK uses some prefix sizes not
+   actually used in HPACK.
+
+   QPACK implementations MUST be able to decode integers up to and
+   including 62 bits long.
+
+4.1.2.  String Literals
+
+   The string literal defined by Section 5.2 of [RFC7541] is also used
+   throughout.  This string format includes optional Huffman encoding.
+
+   HPACK defines string literals to begin on a byte boundary.  They
+   begin with a single bit flag, denoted as 'H' in this document
+   (indicating whether the string is Huffman-coded), followed by the
+   Length encoded as a 7-bit prefix integer, and finally Length bytes of
+   data.  When Huffman encoding is enabled, the Huffman table from
+   Appendix B of [RFC7541] is used without modification.
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 15]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   This document expands the definition of string literals and permits
+   them to begin other than on a byte boundary.  An "N-bit prefix string
+   literal" begins with the same Huffman flag, followed by the length
+   encoded as an (N-1)-bit prefix integer.  The prefix size, N, can have
+   a value between 2 and 8 inclusive.  The remainder of the string
+   literal is unmodified.
+
+   A string literal without a prefix length noted is an 8-bit prefix
+   string literal and follows the definitions in [RFC7541] without
+   modification.
+
+4.2.  Encoder and Decoder Streams
+
+   QPACK defines two unidirectional stream types:
+
+   *  An encoder stream is a unidirectional stream of type 0x02.  It
+      carries an unframed sequence of encoder instructions from encoder
+      to decoder.
+
+   *  A decoder stream is a unidirectional stream of type 0x03.  It
+      carries an unframed sequence of decoder instructions from decoder
+      to encoder.
+
+   HTTP/3 endpoints contain a QPACK encoder and decoder.  Each endpoint
+   MUST initiate at most one encoder stream and at most one decoder
+   stream.  Receipt of a second instance of either stream type MUST be
+   treated as a connection error of type H3_STREAM_CREATION_ERROR.
+   These streams MUST NOT be closed.  Closure of either unidirectional
+   stream type MUST be treated as a connection error of type
+   H3_CLOSED_CRITICAL_STREAM.
+
+   An endpoint MAY avoid creating an encoder stream if it's not going to
+   be used (for example if its encoder doesn't wish to use the dynamic
+   table, or if the maximum size of the dynamic table permitted by the
+   peer is zero).
+
+   An endpoint MAY avoid creating a decoder stream if its decoder sets
+   the maximum capacity of the dynamic table to zero.
+
+   An endpoint MUST allow its peer to create an encoder stream and a
+   decoder stream even if the connection's settings prevent their use.
+
+
+
+
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 16]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+4.3.  Encoder Instructions
+
+   An encoder sends encoder instructions on the encoder stream to set
+   the capacity of the dynamic table and add dynamic table entries.
+   Instructions adding table entries can use existing entries to avoid
+   transmitting redundant information.  The name can be transmitted as a
+   reference to an existing entry in the static or the dynamic table or
+   as a string literal.  For entries which already exist in the dynamic
+   table, the full entry can also be used by reference, creating a
+   duplicate entry.
+
+   This section specifies the following encoder instructions.
+
+4.3.1.  Set Dynamic Table Capacity
+
+   An encoder informs the decoder of a change to the dynamic table
+   capacity using an instruction which begins with the '001' three-bit
+   pattern.  This is followed by the new dynamic table capacity
+   represented as an integer with a 5-bit prefix; see Section 4.1.1.
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 | 1 |   Capacity (5+)   |
+   +---+---+---+-------------------+
+
+                    Figure 5: Set Dynamic Table Capacity
+
+   The new capacity MUST be lower than or equal to the limit described
+   in Section 3.2.3.  In HTTP/3, this limit is the value of the
+   SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter (Section 5) received from
+   the decoder.  The decoder MUST treat a new dynamic table capacity
+   value that exceeds this limit as a connection error of type
+   QPACK_ENCODER_STREAM_ERROR.
+
+   Reducing the dynamic table capacity can cause entries to be evicted;
+   see Section 3.2.2.  This MUST NOT cause the eviction of entries which
+   are not evictable; see Section 2.1.1.  Changing the capacity of the
+   dynamic table is not acknowledged as this instruction does not insert
+   an entry.
+
+4.3.2.  Insert With Name Reference
+
+   An encoder adds an entry to the dynamic table where the field name
+   matches the field name of an entry stored in the static or the
+   dynamic table using an instruction that starts with the '1' one-bit
+   pattern.  The second ('T') bit indicates whether the reference is to
+   the static or dynamic table.  The 6-bit prefix integer
+   (Section 4.1.1) that follows is used to locate the table entry for
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 17]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   the field name.  When T=1, the number represents the static table
+   index; when T=0, the number is the relative index of the entry in the
+   dynamic table.
+
+   The field name reference is followed by the field value represented
+   as a string literal; see Section 4.1.2.
+
+        0   1   2   3   4   5   6   7
+      +---+---+---+---+---+---+---+---+
+      | 1 | T |    Name Index (6+)    |
+      +---+---+-----------------------+
+      | H |     Value Length (7+)     |
+      +---+---------------------------+
+      |  Value String (Length bytes)  |
+      +-------------------------------+
+
+                Figure 6: Insert Field Line -- Indexed Name
+
+4.3.3.  Insert Without Name Reference
+
+   An encoder adds an entry to the dynamic table where both the field
+   name and the field value are represented as string literals using an
+   instruction that starts with the '01' two-bit pattern.
+
+   This is followed by the name represented as a 6-bit prefix string
+   literal, and the value represented as an 8-bit prefix string literal;
+   see Section 4.1.2.
+
+        0   1   2   3   4   5   6   7
+      +---+---+---+---+---+---+---+---+
+      | 0 | 1 | H | Name Length (5+)  |
+      +---+---+---+-------------------+
+      |  Name String (Length bytes)   |
+      +---+---------------------------+
+      | H |     Value Length (7+)     |
+      +---+---------------------------+
+      |  Value String (Length bytes)  |
+      +-------------------------------+
+
+                  Figure 7: Insert Field Line -- New Name
+
+4.3.4.  Duplicate
+
+   An encoder duplicates an existing entry in the dynamic table using an
+   instruction that begins with the '000' three-bit pattern.  This is
+   followed by the relative index of the existing entry represented as
+   an integer with a 5-bit prefix; see Section 4.1.1.
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 18]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+        0   1   2   3   4   5   6   7
+      +---+---+---+---+---+---+---+---+
+      | 0 | 0 | 0 |    Index (5+)     |
+      +---+---+---+-------------------+
+
+                            Figure 8: Duplicate
+
+   The existing entry is re-inserted into the dynamic table without
+   resending either the name or the value.  This is useful to avoid
+   adding a reference to an older entry, which might block inserting new
+   entries.
+
+4.4.  Decoder Instructions
+
+   A decoder sends decoder instructions on the decoder stream to inform
+   the encoder about the processing of field sections and table updates
+   to ensure consistency of the dynamic table.
+
+   This section specifies the following decoder instructions.
+
+4.4.1.  Section Acknowledgement
+
+   After processing an encoded field section whose declared Required
+   Insert Count is not zero, the decoder emits a Section Acknowledgement
+   instruction.  The instruction begins with the '1' one-bit pattern
+   which is followed by the field section's associated stream ID encoded
+   as a 7-bit prefix integer; see Section 4.1.1.
+
+   This instruction is used as described in Section 2.1.4 and in
+   Section 2.2.2.
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 1 |      Stream ID (7+)       |
+   +---+---------------------------+
+
+                     Figure 9: Section Acknowledgement
+
+   If an encoder receives a Section Acknowledgement instruction
+   referring to a stream on which every encoded field section with a
+   non-zero Required Insert Count has already been acknowledged, that
+   MUST be treated as a connection error of type
+   QPACK_DECODER_STREAM_ERROR.
+
+   The Section Acknowledgement instruction might increase the Known
+   Received Count; see Section 2.1.4.
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 19]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+4.4.2.  Stream Cancellation
+
+   When a stream is reset or reading is abandoned, the decoder emits a
+   Stream Cancellation instruction.  The instruction begins with the
+   '01' two-bit pattern, which is followed by the stream ID of the
+   affected stream encoded as a 6-bit prefix integer.
+
+   This instruction is used as described in Section 2.2.2.
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 1 |     Stream ID (6+)    |
+   +---+---+-----------------------+
+
+                       Figure 10: Stream Cancellation
+
+4.4.3.  Insert Count Increment
+
+   The Insert Count Increment instruction begins with the '00' two-bit
+   pattern, followed by the Increment encoded as a 6-bit prefix integer.
+   This instruction increases the Known Received Count (Section 2.1.4)
+   by the value of the Increment parameter.  The decoder should send an
+   Increment value that increases the Known Received Count to the total
+   number of dynamic table insertions and duplications processed so far.
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 |     Increment (6+)    |
+   +---+---+-----------------------+
+
+                     Figure 11: Insert Count Increment
+
+   An encoder that receives an Increment field equal to zero, or one
+   that increases the Known Received Count beyond what the encoder has
+   sent MUST treat this as a connection error of type
+   QPACK_DECODER_STREAM_ERROR.
+
+4.5.  Field Line Representations
+
+   An encoded field section consists of a prefix and a possibly empty
+   sequence of representations defined in this section.  Each
+   representation corresponds to a single field line.  These
+   representations reference the static table or the dynamic table in a
+   particular state, but do not modify that state.
+
+   Encoded field sections are carried in frames on streams defined by
+   the enclosing protocol.
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 20]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+4.5.1.  Encoded Field Section Prefix
+
+   Each encoded field section is prefixed with two integers.  The
+   Required Insert Count is encoded as an integer with an 8-bit prefix
+   after the encoding described in Section 4.5.1.1).  The Base is
+   encoded as a sign bit ('S') and a Delta Base value with a 7-bit
+   prefix; see Section 4.5.1.2.
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   |   Required Insert Count (8+)  |
+   +---+---------------------------+
+   | S |      Delta Base (7+)      |
+   +---+---------------------------+
+   |      Encoded Field Lines    ...
+   +-------------------------------+
+
+                      Figure 12: Encoded Field Section
+
+4.5.1.1.  Required Insert Count
+
+   Required Insert Count identifies the state of the dynamic table
+   needed to process the encoded field section.  Blocking decoders use
+   the Required Insert Count to determine when it is safe to process the
+   rest of the field section.
+
+   The encoder transforms the Required Insert Count as follows before
+   encoding:
+
+      if ReqInsertCount == 0:
+         EncInsertCount = 0
+      else:
+         EncInsertCount = (ReqInsertCount mod (2 * MaxEntries)) + 1
+
+   Here "MaxEntries" is the maximum number of entries that the dynamic
+   table can have.  The smallest entry has empty name and value strings
+   and has the size of 32.  Hence "MaxEntries" is calculated as
+
+      MaxEntries = floor( MaxTableCapacity / 32 )
+
+   "MaxTableCapacity" is the maximum capacity of the dynamic table as
+   specified by the decoder; see Section 3.2.3.
+
+   This encoding limits the length of the prefix on long-lived
+   connections.
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 21]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   The decoder can reconstruct the Required Insert Count using an
+   algorithm such as the following.  If the decoder encounters a value
+   of EncodedInsertCount that could not have been produced by a
+   conformant encoder, it MUST treat this as a connection error of type
+   QPACK_DECOMPRESSION_FAILED.
+
+   TotalNumberOfInserts is the total number of inserts into the
+   decoder's dynamic table.
+
+      FullRange = 2 * MaxEntries
+      if EncodedInsertCount == 0:
+         ReqInsertCount = 0
+      else:
+         if EncodedInsertCount > FullRange:
+            Error
+         MaxValue = TotalNumberOfInserts + MaxEntries
+
+         # MaxWrapped is the largest possible value of
+         # ReqInsertCount that is 0 mod 2*MaxEntries
+         MaxWrapped = floor(MaxValue / FullRange) * FullRange
+         ReqInsertCount = MaxWrapped + EncodedInsertCount - 1
+
+         # If ReqInsertCount exceeds MaxValue, the Encoder's value
+         # must have wrapped one fewer time
+         if ReqInsertCount > MaxValue:
+            if ReqInsertCount <= FullRange:
+               Error
+            ReqInsertCount -= FullRange
+
+         # Value of 0 must be encoded as 0.
+         if ReqInsertCount == 0:
+            Error
+
+   For example, if the dynamic table is 100 bytes, then the Required
+   Insert Count will be encoded modulo 6.  If a decoder has received 10
+   inserts, then an encoded value of 4 indicates that the Required
+   Insert Count is 9 for the field section.
+
+4.5.1.2.  Base
+
+   The Base is used to resolve references in the dynamic table as
+   described in Section 3.2.5.
+
+   To save space, the Base is encoded relative to the Required Insert
+   Count using a one-bit sign ('S') and the Delta Base value.  A sign
+   bit of 0 indicates that the Base is greater than or equal to the
+   value of the Required Insert Count; the decoder adds the value of
+   Delta Base to the Required Insert Count to determine the value of the
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 22]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   Base.  A sign bit of 1 indicates that the Base is less than the
+   Required Insert Count; the decoder subtracts the value of Delta Base
+   from the Required Insert Count and also subtracts one to determine
+   the value of the Base.  That is:
+
+      if S == 0:
+         Base = ReqInsertCount + DeltaBase
+      else:
+         Base = ReqInsertCount - DeltaBase - 1
+
+   A single-pass encoder determines the Base before encoding a field
+   section.  If the encoder inserted entries in the dynamic table while
+   encoding the field section, Required Insert Count will be greater
+   than the Base, so the encoded difference is negative and the sign bit
+   is set to 1.  If the field section was not encoded using
+   representations which reference the most recent entry in the table
+   and did not insert any new entries, the Base will be greater than the
+   Required Insert Count, so the delta will be positive and the sign bit
+   is set to 0.
+
+   An encoder that produces table updates before encoding a field
+   section might set Base to the value of Required Insert Count.  In
+   such case, both the sign bit and the Delta Base will be set to zero.
+
+   A field section that was encoded without references to the dynamic
+   table can use any value for the Base; setting Delta Base to zero is
+   one of the most efficient encodings.
+
+   For example, with a Required Insert Count of 9, a decoder receives an
+   S bit of 1 and a Delta Base of 2.  This sets the Base to 6 and
+   enables post-base indexing for three entries.  In this example, a
+   relative index of 1 refers to the 5th entry that was added to the
+   table; a post-base index of 1 refers to the 8th entry.
+
+4.5.2.  Indexed Field Line
+
+   An indexed field line representation identifies an entry in the
+   static table, or an entry in the dynamic table with an absolute index
+   less than the value of the Base.
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 1 | T |      Index (6+)       |
+   +---+---+-----------------------+
+
+                       Figure 13: Indexed Field Line
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 23]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   This representation starts with the '1' 1-bit pattern, followed by
+   the 'T' bit indicating whether the reference is into the static or
+   dynamic table.  The 6-bit prefix integer (Section 4.1.1) that follows
+   is used to locate the table entry for the field line.  When T=1, the
+   number represents the static table index; when T=0, the number is the
+   relative index of the entry in the dynamic table.
+
+4.5.3.  Indexed Field Line With Post-Base Index
+
+   An indexed field line with post-base index representation identifies
+   an entry in the dynamic table with an absolute index greater than or
+   equal to the value of the Base.
+
+     0   1   2   3   4   5   6   7
+   +---+---+---+---+---+---+---+---+
+   | 0 | 0 | 0 | 1 |  Index (4+)   |
+   +---+---+---+---+---------------+
+
+             Figure 14: Indexed Field Line with Post-Base Index
+
+   This representation starts with the '0001' 4-bit pattern.  This is
+   followed by the post-base index (Section 3.2.6) of the matching field
+   line, represented as an integer with a 4-bit prefix; see
+   Section 4.1.1.
+
+4.5.4.  Literal Field Line With Name Reference
+
+   A literal field line with name reference representation encodes a
+   field line where the field name matches the field name of an entry in
+   the static table, or the field name of an entry in the dynamic table
+   with an absolute index less than the value of the Base.
+
+        0   1   2   3   4   5   6   7
+      +---+---+---+---+---+---+---+---+
+      | 0 | 1 | N | T |Name Index (4+)|
+      +---+---+---+---+---------------+
+      | H |     Value Length (7+)     |
+      +---+---------------------------+
+      |  Value String (Length bytes)  |
+      +-------------------------------+
+
+             Figure 15: Literal Field Line With Name Reference
+
+   This representation starts with the '01' two-bit pattern.  The
+   following bit, 'N', indicates whether an intermediary is permitted to
+   add this field line to the dynamic table on subsequent hops.  When
+   the 'N' bit is set, the encoded field line MUST always be encoded
+   with a literal representation.  In particular, when a peer sends a
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 24]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   field line that it received represented as a literal field line with
+   the 'N' bit set, it MUST use a literal representation to forward this
+   field line.  This bit is intended for protecting field values that
+   are not to be put at risk by compressing them; see Section 7 for more
+   details.
+
+   The fourth ('T') bit indicates whether the reference is to the static
+   or dynamic table.  The 4-bit prefix integer (Section 4.1.1) that
+   follows is used to locate the table entry for the field name.  When
+   T=1, the number represents the static table index; when T=0, the
+   number is the relative index of the entry in the dynamic table.
+
+   Only the field name is taken from the dynamic table entry; the field
+   value is encoded as an 8-bit prefix string literal; see
+   Section 4.1.2.
+
+4.5.5.  Literal Field Line With Post-Base Name Reference
+
+   A literal field line with post-base name reference representation
+   encodes a field line where the field name matches the field name of a
+   dynamic table entry with an absolute index greater than or equal to
+   the value of the Base.
+
+        0   1   2   3   4   5   6   7
+      +---+---+---+---+---+---+---+---+
+      | 0 | 0 | 0 | 0 | N |NameIdx(3+)|
+      +---+---+---+---+---+-----------+
+      | H |     Value Length (7+)     |
+      +---+---------------------------+
+      |  Value String (Length bytes)  |
+      +-------------------------------+
+
+        Figure 16: Literal Field Line With Post-Base Name Reference
+
+   This representation starts with the '0000' four-bit pattern.  The
+   fifth bit is the 'N' bit as described in Section 4.5.4.  This is
+   followed by a post-base index of the dynamic table entry
+   (Section 3.2.6) encoded as an integer with a 3-bit prefix; see
+   Section 4.1.1.
+
+   Only the field name is taken from the dynamic table entry; the field
+   value is encoded as an 8-bit prefix string literal; see
+   Section 4.1.2.
+
+4.5.6.  Literal Field Line Without Name Reference
+
+   The literal field line without name reference representation encodes
+   a field name and a field value as string literals.
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 25]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+        0   1   2   3   4   5   6   7
+      +---+---+---+---+---+---+---+---+
+      | 0 | 0 | 1 | N | H |NameLen(3+)|
+      +---+---+---+---+---+-----------+
+      |  Name String (Length bytes)   |
+      +---+---------------------------+
+      | H |     Value Length (7+)     |
+      +---+---------------------------+
+      |  Value String (Length bytes)  |
+      +-------------------------------+
+
+            Figure 17: Literal Field Line Without Name Reference
+
+   This representation begins with the '001' three-bit pattern.  The
+   fourth bit is the 'N' bit as described in Section 4.5.4.  The name
+   follows, represented as a 4-bit prefix string literal, then the
+   value, represented as an 8-bit prefix string literal; see
+   Section 4.1.2.
+
+5.  Configuration
+
+   QPACK defines two settings which are included in the HTTP/3 SETTINGS
+   frame.
+
+   SETTINGS_QPACK_MAX_TABLE_CAPACITY (0x1):  The default value is zero.
+      See Section 3.2 for usage.  This is the equivalent of the
+      SETTINGS_HEADER_TABLE_SIZE from HTTP/2.
+
+   SETTINGS_QPACK_BLOCKED_STREAMS (0x7):  The default value is zero.
+      See Section 2.1.2.
+
+6.  Error Handling
+
+   The following error codes are defined for HTTP/3 to indicate failures
+   of QPACK which prevent the connection from continuing:
+
+   QPACK_DECOMPRESSION_FAILED (0x200):  The decoder failed to interpret
+      an encoded field section and is not able to continue decoding that
+      field section.
+
+   QPACK_ENCODER_STREAM_ERROR (0x201):  The decoder failed to interpret
+      an encoder instruction received on the encoder stream.
+
+   QPACK_DECODER_STREAM_ERROR (0x202):  The encoder failed to interpret
+      a decoder instruction received on the decoder stream.
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 26]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+7.  Security Considerations
+
+   This section describes potential areas of security concern with
+   QPACK:
+
+   *  Use of compression as a length-based oracle for verifying guesses
+      about secrets that are compressed into a shared compression
+      context.
+
+   *  Denial of service resulting from exhausting processing or memory
+      capacity at a decoder.
+
+7.1.  Probing Dynamic Table State
+
+   QPACK reduces the length of header field encodings by exploiting the
+   redundancy inherent in protocols like HTTP.  The ultimate goal of
+   this is to reduce the amount of data that is required to send HTTP
+   requests or responses.
+
+   The compression context used to encode header fields can be probed by
+   an attacker who can both define header fields to be encoded and
+   transmitted and observe the length of those fields once they are
+   encoded.  When an attacker can do both, they can adaptively modify
+   requests in order to confirm guesses about the dynamic table state.
+   If a guess is compressed into a shorter length, the attacker can
+   observe the encoded length and infer that the guess was correct.
+
+   This is possible even over the Transport Layer Security Protocol
+   (TLS, see [RFC5246]), because while TLS provides confidentiality
+   protection for content, it only provides a limited amount of
+   protection for the length of that content.
+
+   Note:  Padding schemes only provide limited protection against an
+      attacker with these capabilities, potentially only forcing an
+      increased number of guesses to learn the length associated with a
+      given guess.  Padding schemes also work directly against
+      compression by increasing the number of bits that are transmitted.
+
+   Attacks like CRIME [CRIME] demonstrated the existence of these
+   general attacker capabilities.  The specific attack exploited the
+   fact that DEFLATE [RFC1951] removes redundancy based on prefix
+   matching.  This permitted the attacker to confirm guesses a character
+   at a time, reducing an exponential-time attack into a linear-time
+   attack.
+
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 27]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+7.2.  Applicability to QPACK and HTTP
+
+   QPACK mitigates but does not completely prevent attacks modeled on
+   CRIME [CRIME] by forcing a guess to match an entire header field
+   value, rather than individual characters.  An attacker can only learn
+   whether a guess is correct or not, so is reduced to a brute force
+   guess for the header field values.
+
+   The viability of recovering specific header field values therefore
+   depends on the entropy of values.  As a result, values with high
+   entropy are unlikely to be recovered successfully.  However, values
+   with low entropy remain vulnerable.
+
+   Attacks of this nature are possible any time that two mutually
+   distrustful entities control requests or responses that are placed
+   onto a single HTTP/3 connection.  If the shared QPACK compressor
+   permits one entity to add entries to the dynamic table, and the other
+   to access those entries, then the state of the table can be learned.
+
+   Having requests or responses from mutually distrustful entities
+   occurs when an intermediary either:
+
+   *  sends requests from multiple clients on a single connection toward
+      an origin server, or
+
+   *  takes responses from multiple origin servers and places them on a
+      shared connection toward a client.
+
+   Web browsers also need to assume that requests made on the same
+   connection by different web origins [RFC6454] are made by mutually
+   distrustful entities.
+
+7.3.  Mitigation
+
+   Users of HTTP that require confidentiality for header fields can use
+   values with entropy sufficient to make guessing infeasible.  However,
+   this is impractical as a general solution because it forces all users
+   of HTTP to take steps to mitigate attacks.  It would impose new
+   constraints on how HTTP is used.
+
+   Rather than impose constraints on users of HTTP, an implementation of
+   QPACK can instead constrain how compression is applied in order to
+   limit the potential for dynamic table probing.
+
+   An ideal solution segregates access to the dynamic table based on the
+   entity that is constructing header fields.  Header field values that
+   are added to the table are attributed to an entity, and only the
+   entity that created a particular value can extract that value.
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 28]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   To improve compression performance of this option, certain entries
+   might be tagged as being public.  For example, a web browser might
+   make the values of the Accept-Encoding header field available in all
+   requests.
+
+   An encoder without good knowledge of the provenance of header fields
+   might instead introduce a penalty for a header field with many
+   different values, such that a large number of attempts to guess a
+   header field value results in the header field not being compared to
+   the dynamic table entries in future messages, effectively preventing
+   further guesses.
+
+   Note:  Simply removing entries corresponding to the header field from
+      the dynamic table can be ineffectual if the attacker has a
+      reliable way of causing values to be reinstalled.  For example, a
+      request to load an image in a web browser typically includes the
+      Cookie header field (a potentially highly valued target for this
+      sort of attack), and web sites can easily force an image to be
+      loaded, thereby refreshing the entry in the dynamic table.
+
+   This response might be made inversely proportional to the length of
+   the header field value.  Disabling access to the dynamic table for a
+   header field might occur for shorter values more quickly or with
+   higher probability than for longer values.
+
+7.4.  Never Indexed Literals
+
+   Implementations can also choose to protect sensitive header fields by
+   not compressing them and instead encoding their value as literals.
+
+   Refusing to insert a header field into the dynamic table is only
+   effective if doing so is avoided on all hops.  The never indexed
+   literal bit (see Section 4.5.4) can be used to signal to
+   intermediaries that a particular value was intentionally sent as a
+   literal.
+
+   An intermediary MUST NOT re-encode a value that uses a literal
+   representation with the 'N' bit set with another representation that
+   would index it.  If QPACK is used for re-encoding, a literal
+   representation with the 'N' bit set MUST be used.  If HPACK is used
+   for re-encoding, the never indexed literal representation (see
+   Section 6.2.3 of [RFC7541]) MUST be used.
+
+   The choice to mark that a header field should never be indexed
+   depends on several factors.  Since QPACK doesn't protect against
+   guessing an entire header field value, short or low-entropy values
+   are more readily recovered by an adversary.  Therefore, an encoder
+   might choose not to index values with low entropy.
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 29]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   An encoder might also choose not to index values for header fields
+   that are considered to be highly valuable or sensitive to recovery,
+   such as the Cookie or Authorization header fields.
+
+   On the contrary, an encoder might prefer indexing values for header
+   fields that have little or no value if they were exposed.  For
+   instance, a User-Agent header field does not commonly vary between
+   requests and is sent to any server.  In that case, confirmation that
+   a particular User-Agent value has been used provides little value.
+
+   Note that these criteria for deciding to use a never indexed literal
+   representation will evolve over time as new attacks are discovered.
+
+7.5.  Static Huffman Encoding
+
+   There is no currently known attack against a static Huffman encoding.
+   A study has shown that using a static Huffman encoding table created
+   an information leakage, however this same study concluded that an
+   attacker could not take advantage of this information leakage to
+   recover any meaningful amount of information (see [PETAL]).
+
+7.6.  Memory Consumption
+
+   An attacker can try to cause an endpoint to exhaust its memory.
+   QPACK is designed to limit both the peak and stable amounts of memory
+   allocated by an endpoint.
+
+   The amount of memory used by the encoder is limited by the protocol
+   using QPACK through the definition of the maximum size of the dynamic
+   table, and the maximum number of blocking streams.  In HTTP/3, these
+   values are controlled by the decoder through the settings parameters
+   SETTINGS_QPACK_MAX_TABLE_CAPACITY and SETTINGS_QPACK_BLOCKED_STREAMS,
+   respectively (see Section 3.2.3 and Section 2.1.2).  The limit on the
+   size of the dynamic table takes into account the size of the data
+   stored in the dynamic table, plus a small allowance for overhead.
+   The limit on the number of blocked streams is only a proxy for the
+   maximum amount of memory required by the decoder.  The actual maximum
+   amount of memory will depend on how much memory the decoder uses to
+   track each blocked stream.
+
+   A decoder can limit the amount of state memory used for the dynamic
+   table by setting an appropriate value for the maximum size of the
+   dynamic table.  In HTTP/3, this is realized by setting an appropriate
+   value for the SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter.  An
+   encoder can limit the amount of state memory it uses by signaling a
+   lower dynamic table size than the decoder allows (see Section 3.2.2).
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 30]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   A decoder can limit the amount of state memory used for blocked
+   streams by setting an appropriate value for the maximum number of
+   blocked streams.  In HTTP/3, this is realized by setting an
+   appropriate value for the QPACK_BLOCKED_STREAMS parameter.  An
+   encoder can limit the amount of state memory by only using as many
+   blocked streams as it wishes to support; no signaling to the decoder
+   is required.
+
+   The amount of temporary memory consumed by an encoder or decoder can
+   be limited by processing header fields sequentially.  A decoder
+   implementation does not need to retain a complete list of header
+   fields while decoding a header block.  An encoder implementation does
+   not need to retain a complete list of header fields while encoding a
+   header block if it is using a single-pass algorithm.  Note that it
+   might be necessary for an application to retain a complete header
+   list for other reasons; even if QPACK does not force this to occur,
+   application constraints might make this necessary.
+
+   While the negotiated limit on the dynamic table size accounts for
+   much of the memory that can be consumed by a QPACK implementation,
+   data which cannot be immediately sent due to flow control is not
+   affected by this limit.  Implementations should limit the size of
+   unsent data, especially on the decoder stream where flexibility to
+   choose what to send is limited.  Possible responses to an excess of
+   unsent data might include limiting the ability of the peer to open
+   new streams, reading only from the encoder stream, or closing the
+   connection.
+
+7.7.  Implementation Limits
+
+   An implementation of QPACK needs to ensure that large values for
+   integers, long encoding for integers, or long string literals do not
+   create security weaknesses.
+
+   An implementation has to set a limit for the values it accepts for
+   integers, as well as for the encoded length (see Section 4.1.1).  In
+   the same way, it has to set a limit to the length it accepts for
+   string literals (see Section 4.1.2).
+
+8.  IANA Considerations
+
+8.1.  Settings Registration
+
+   This document specifies two settings.  The entries in the following
+   table are registered in the "HTTP/3 Settings" registry established in
+   [HTTP3].
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 31]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+       +--------------------------+------+---------------+---------+
+       | Setting Name             | Code | Specification | Default |
+       +==========================+======+===============+=========+
+       | QPACK_MAX_TABLE_CAPACITY | 0x1  | Section 5     | 0       |
+       +--------------------------+------+---------------+---------+
+       | QPACK_BLOCKED_STREAMS    | 0x7  | Section 5     | 0       |
+       +--------------------------+------+---------------+---------+
+
+                                  Table 1
+
+8.2.  Stream Type Registration
+
+   This document specifies two stream types.  The entries in the
+   following table are registered in the "HTTP/3 Stream Type" registry
+   established in [HTTP3].
+
+         +----------------------+------+---------------+--------+
+         | Stream Type          | Code | Specification | Sender |
+         +======================+======+===============+========+
+         | QPACK Encoder Stream | 0x02 | Section 4.2   | Both   |
+         +----------------------+------+---------------+--------+
+         | QPACK Decoder Stream | 0x03 | Section 4.2   | Both   |
+         +----------------------+------+---------------+--------+
+
+                                 Table 2
+
+8.3.  Error Code Registration
+
+   This document specifies three error codes.  The entries in the
+   following table are registered in the "HTTP/3 Error Code" registry
+   established in [HTTP3].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 32]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   +----------------------------+-------+-------------+---------------+
+   | Name                       | Code  | Description | Specification |
+   +============================+=======+=============+===============+
+   | QPACK_DECOMPRESSION_FAILED | 0x200 | Decoding of | Section 6     |
+   |                            |       | a field     |               |
+   |                            |       | section     |               |
+   |                            |       | failed      |               |
+   +----------------------------+-------+-------------+---------------+
+   | QPACK_ENCODER_STREAM_ERROR | 0x201 | Error on    | Section 6     |
+   |                            |       | the encoder |               |
+   |                            |       | stream      |               |
+   +----------------------------+-------+-------------+---------------+
+   | QPACK_DECODER_STREAM_ERROR | 0x202 | Error on    | Section 6     |
+   |                            |       | the decoder |               |
+   |                            |       | stream      |               |
+   +----------------------------+-------+-------------+---------------+
+
+                                 Table 3
+
+9.  References
+
+9.1.  Normative References
+
+   [HTTP3]    Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
+              (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
+              quic-http-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-http-latest>.
+
+   [QUIC-TRANSPORT]
+              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", Work in Progress,
+              Internet-Draft, draft-ietf-quic-transport-latest, 3 June
+              2020, <https://tools.ietf.org/html/draft-ietf-quic-
+              transport-latest>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC7541]  Peon, R. and H. Ruellan, "HPACK: Header Compression for
+              HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
+              <https://www.rfc-editor.org/info/rfc7541>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 33]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   [SEMANTICS]
+              Fielding, R., Nottingham, M., and J. Reschke, "HTTP
+              Semantics", Work in Progress, Internet-Draft, draft-ietf-
+              httpbis-semantics-08, 26 May 2020, <http://www.ietf.org/
+              internet-drafts/draft-ietf-httpbis-semantics-08.txt>.
+
+9.2.  Informative References
+
+   [CRIME]    Wikipedia, "CRIME", May 2015, <http://en.wikipedia.org/w/
+              index.php?title=CRIME&oldid=660948120>.
+
+   [PETAL]    Tan, J. and J. Nahata, "PETAL: Preset Encoding
+              Table Information Leakage", April 2013,
+              <http://www.pdl.cmu.edu/PDL-FTP/associated/CMU-PDL-
+              13-106.pdf>.
+
+   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
+              version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
+              <https://www.rfc-editor.org/info/rfc1951>.
+
+   [RFC2360]  Scott, G., "Guide for Internet Standards Writers", BCP 22,
+              RFC 2360, DOI 10.17487/RFC2360, June 1998,
+              <https://www.rfc-editor.org/info/rfc2360>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
+              DOI 10.17487/RFC6454, December 2011,
+              <https://www.rfc-editor.org/info/rfc6454>.
+
+   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
+              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
+              DOI 10.17487/RFC7540, May 2015,
+              <https://www.rfc-editor.org/info/rfc7540>.
+
+Appendix A.  Static Table
+
+   This table was generated by analyzing actual internet traffic in 2018
+   and including the most common headers, after filtering out some
+   unsupported and non-standard values.  Due to this methodology, some
+   of the entries may be inconsistent or appear multiple times with
+   similar but not identical values.  The order of the entries is
+   optimized to encode the most common headers with the smallest number
+   of bytes.
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 34]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   +-------+----------------------------------+-----------------------+
+   | Index | Name                             | Value                 |
+   +=======+==================================+=======================+
+   | 0     | :authority                       |                       |
+   +-------+----------------------------------+-----------------------+
+   | 1     | :path                            | /                     |
+   +-------+----------------------------------+-----------------------+
+   | 2     | age                              | 0                     |
+   +-------+----------------------------------+-----------------------+
+   | 3     | content-disposition              |                       |
+   +-------+----------------------------------+-----------------------+
+   | 4     | content-length                   | 0                     |
+   +-------+----------------------------------+-----------------------+
+   | 5     | cookie                           |                       |
+   +-------+----------------------------------+-----------------------+
+   | 6     | date                             |                       |
+   +-------+----------------------------------+-----------------------+
+   | 7     | etag                             |                       |
+   +-------+----------------------------------+-----------------------+
+   | 8     | if-modified-since                |                       |
+   +-------+----------------------------------+-----------------------+
+   | 9     | if-none-match                    |                       |
+   +-------+----------------------------------+-----------------------+
+   | 10    | last-modified                    |                       |
+   +-------+----------------------------------+-----------------------+
+   | 11    | link                             |                       |
+   +-------+----------------------------------+-----------------------+
+   | 12    | location                         |                       |
+   +-------+----------------------------------+-----------------------+
+   | 13    | referer                          |                       |
+   +-------+----------------------------------+-----------------------+
+   | 14    | set-cookie                       |                       |
+   +-------+----------------------------------+-----------------------+
+   | 15    | :method                          | CONNECT               |
+   +-------+----------------------------------+-----------------------+
+   | 16    | :method                          | DELETE                |
+   +-------+----------------------------------+-----------------------+
+   | 17    | :method                          | GET                   |
+   +-------+----------------------------------+-----------------------+
+   | 18    | :method                          | HEAD                  |
+   +-------+----------------------------------+-----------------------+
+   | 19    | :method                          | OPTIONS               |
+   +-------+----------------------------------+-----------------------+
+   | 20    | :method                          | POST                  |
+   +-------+----------------------------------+-----------------------+
+   | 21    | :method                          | PUT                   |
+   +-------+----------------------------------+-----------------------+
+   | 22    | :scheme                          | http                  |
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 35]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   +-------+----------------------------------+-----------------------+
+   | 23    | :scheme                          | https                 |
+   +-------+----------------------------------+-----------------------+
+   | 24    | :status                          | 103                   |
+   +-------+----------------------------------+-----------------------+
+   | 25    | :status                          | 200                   |
+   +-------+----------------------------------+-----------------------+
+   | 26    | :status                          | 304                   |
+   +-------+----------------------------------+-----------------------+
+   | 27    | :status                          | 404                   |
+   +-------+----------------------------------+-----------------------+
+   | 28    | :status                          | 503                   |
+   +-------+----------------------------------+-----------------------+
+   | 29    | accept                           | */*                   |
+   +-------+----------------------------------+-----------------------+
+   | 30    | accept                           | application/dns-      |
+   |       |                                  | message               |
+   +-------+----------------------------------+-----------------------+
+   | 31    | accept-encoding                  | gzip, deflate, br     |
+   +-------+----------------------------------+-----------------------+
+   | 32    | accept-ranges                    | bytes                 |
+   +-------+----------------------------------+-----------------------+
+   | 33    | access-control-allow-headers     | cache-control         |
+   +-------+----------------------------------+-----------------------+
+   | 34    | access-control-allow-headers     | content-type          |
+   +-------+----------------------------------+-----------------------+
+   | 35    | access-control-allow-origin      | *                     |
+   +-------+----------------------------------+-----------------------+
+   | 36    | cache-control                    | max-age=0             |
+   +-------+----------------------------------+-----------------------+
+   | 37    | cache-control                    | max-age=2592000       |
+   +-------+----------------------------------+-----------------------+
+   | 38    | cache-control                    | max-age=604800        |
+   +-------+----------------------------------+-----------------------+
+   | 39    | cache-control                    | no-cache              |
+   +-------+----------------------------------+-----------------------+
+   | 40    | cache-control                    | no-store              |
+   +-------+----------------------------------+-----------------------+
+   | 41    | cache-control                    | public, max-          |
+   |       |                                  | age=31536000          |
+   +-------+----------------------------------+-----------------------+
+   | 42    | content-encoding                 | br                    |
+   +-------+----------------------------------+-----------------------+
+   | 43    | content-encoding                 | gzip                  |
+   +-------+----------------------------------+-----------------------+
+   | 44    | content-type                     | application/dns-      |
+   |       |                                  | message               |
+   +-------+----------------------------------+-----------------------+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 36]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   | 45    | content-type                     | application/          |
+   |       |                                  | javascript            |
+   +-------+----------------------------------+-----------------------+
+   | 46    | content-type                     | application/json      |
+   +-------+----------------------------------+-----------------------+
+   | 47    | content-type                     | application/x-www-    |
+   |       |                                  | form-urlencoded       |
+   +-------+----------------------------------+-----------------------+
+   | 48    | content-type                     | image/gif             |
+   +-------+----------------------------------+-----------------------+
+   | 49    | content-type                     | image/jpeg            |
+   +-------+----------------------------------+-----------------------+
+   | 50    | content-type                     | image/png             |
+   +-------+----------------------------------+-----------------------+
+   | 51    | content-type                     | text/css              |
+   +-------+----------------------------------+-----------------------+
+   | 52    | content-type                     | text/html;            |
+   |       |                                  | charset=utf-8         |
+   +-------+----------------------------------+-----------------------+
+   | 53    | content-type                     | text/plain            |
+   +-------+----------------------------------+-----------------------+
+   | 54    | content-type                     | text/                 |
+   |       |                                  | plain;charset=utf-8   |
+   +-------+----------------------------------+-----------------------+
+   | 55    | range                            | bytes=0-              |
+   +-------+----------------------------------+-----------------------+
+   | 56    | strict-transport-security        | max-age=31536000      |
+   +-------+----------------------------------+-----------------------+
+   | 57    | strict-transport-security        | max-age=31536000;     |
+   |       |                                  | includesubdomains     |
+   +-------+----------------------------------+-----------------------+
+   | 58    | strict-transport-security        | max-age=31536000;     |
+   |       |                                  | includesubdomains;    |
+   |       |                                  | preload               |
+   +-------+----------------------------------+-----------------------+
+   | 59    | vary                             | accept-encoding       |
+   +-------+----------------------------------+-----------------------+
+   | 60    | vary                             | origin                |
+   +-------+----------------------------------+-----------------------+
+   | 61    | x-content-type-options           | nosniff               |
+   +-------+----------------------------------+-----------------------+
+   | 62    | x-xss-protection                 | 1; mode=block         |
+   +-------+----------------------------------+-----------------------+
+   | 63    | :status                          | 100                   |
+   +-------+----------------------------------+-----------------------+
+   | 64    | :status                          | 204                   |
+   +-------+----------------------------------+-----------------------+
+   | 65    | :status                          | 206                   |
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 37]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   +-------+----------------------------------+-----------------------+
+   | 66    | :status                          | 302                   |
+   +-------+----------------------------------+-----------------------+
+   | 67    | :status                          | 400                   |
+   +-------+----------------------------------+-----------------------+
+   | 68    | :status                          | 403                   |
+   +-------+----------------------------------+-----------------------+
+   | 69    | :status                          | 421                   |
+   +-------+----------------------------------+-----------------------+
+   | 70    | :status                          | 425                   |
+   +-------+----------------------------------+-----------------------+
+   | 71    | :status                          | 500                   |
+   +-------+----------------------------------+-----------------------+
+   | 72    | accept-language                  |                       |
+   +-------+----------------------------------+-----------------------+
+   | 73    | access-control-allow-credentials | FALSE                 |
+   +-------+----------------------------------+-----------------------+
+   | 74    | access-control-allow-credentials | TRUE                  |
+   +-------+----------------------------------+-----------------------+
+   | 75    | access-control-allow-headers     | *                     |
+   +-------+----------------------------------+-----------------------+
+   | 76    | access-control-allow-methods     | get                   |
+   +-------+----------------------------------+-----------------------+
+   | 77    | access-control-allow-methods     | get, post, options    |
+   +-------+----------------------------------+-----------------------+
+   | 78    | access-control-allow-methods     | options               |
+   +-------+----------------------------------+-----------------------+
+   | 79    | access-control-expose-headers    | content-length        |
+   +-------+----------------------------------+-----------------------+
+   | 80    | access-control-request-headers   | content-type          |
+   +-------+----------------------------------+-----------------------+
+   | 81    | access-control-request-method    | get                   |
+   +-------+----------------------------------+-----------------------+
+   | 82    | access-control-request-method    | post                  |
+   +-------+----------------------------------+-----------------------+
+   | 83    | alt-svc                          | clear                 |
+   +-------+----------------------------------+-----------------------+
+   | 84    | authorization                    |                       |
+   +-------+----------------------------------+-----------------------+
+   | 85    | content-security-policy          | script-src 'none';    |
+   |       |                                  | object-src 'none';    |
+   |       |                                  | base-uri 'none'       |
+   +-------+----------------------------------+-----------------------+
+   | 86    | early-data                       | 1                     |
+   +-------+----------------------------------+-----------------------+
+   | 87    | expect-ct                        |                       |
+   +-------+----------------------------------+-----------------------+
+   | 88    | forwarded                        |                       |
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 38]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   +-------+----------------------------------+-----------------------+
+   | 89    | if-range                         |                       |
+   +-------+----------------------------------+-----------------------+
+   | 90    | origin                           |                       |
+   +-------+----------------------------------+-----------------------+
+   | 91    | purpose                          | prefetch              |
+   +-------+----------------------------------+-----------------------+
+   | 92    | server                           |                       |
+   +-------+----------------------------------+-----------------------+
+   | 93    | timing-allow-origin              | *                     |
+   +-------+----------------------------------+-----------------------+
+   | 94    | upgrade-insecure-requests        | 1                     |
+   +-------+----------------------------------+-----------------------+
+   | 95    | user-agent                       |                       |
+   +-------+----------------------------------+-----------------------+
+   | 96    | x-forwarded-for                  |                       |
+   +-------+----------------------------------+-----------------------+
+   | 97    | x-frame-options                  | deny                  |
+   +-------+----------------------------------+-----------------------+
+   | 98    | x-frame-options                  | sameorigin            |
+   +-------+----------------------------------+-----------------------+
+
+                                 Table 4
+
+Appendix B.  Sample One Pass Encoding Algorithm
+
+   Pseudo-code for single pass encoding, excluding handling of
+   duplicates, non-blocking mode, available encoder stream flow control
+   and reference tracking.
+
+   base = dynamicTable.getInsertCount()
+   requiredInsertCount = 0
+   for line in field_lines:
+     staticIndex = staticTable.findIndex(line)
+     if staticIndex is not None:
+       encodeIndexReference(streamBuffer, staticIndex)
+       continue
+
+     dynamicIndex = dynamicTable.findIndex(line)
+     if dynamicIndex is None:
+       # No matching entry.  Either insert+index or encode literal
+       staticNameIndex = staticTable.findName(line.name)
+       if staticNameIndex is None:
+          dynamicNameIndex = dynamicTable.findName(line.name)
+
+       if shouldIndex(line) and dynamicTable.canIndex(line):
+         encodeInsert(encoderBuffer, staticNameIndex,
+                      dynamicNameIndex, line)
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 39]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+         dynamicIndex = dynamicTable.add(line)
+
+     if dynamicIndex is None:
+       # Couldn't index it, literal
+       if nameIndex is None or isStaticName:
+         # Encodes a literal with a static name or literal name
+         encodeLiteral(streamBuffer, nameIndex, line)
+       else:
+         # encode literal with dynamic name, possibly above base
+         encodeDynamicLiteral(streamBuffer, nameIndex, base, line)
+         requiredInsertCount = max(requiredInsertCount, nameIndex)
+     else:
+       # Dynamic index reference
+       assert(dynamicIndex is not None)
+       requiredInsertCount = max(requiredInsertCount, dynamicIndex)
+       # Encode dynamicIndex, possibly above base
+       encodeDynamicIndexReference(streamBuffer, dynamicIndex, base)
+
+   # encode the prefix
+   if requiredInsertCount == 0:
+     encodeIndexReference(prefixBuffer, 0, 0, 8)
+     encodeIndexReference(prefixBuffer, 0, 0, 7)
+   else:
+     wireRIC = (
+       requiredInsertCount
+       % (2 * getMaxEntries(maxTableCapacity))
+     ) + 1;
+     encodeInteger(prefixBuffer, 0x00, wireRIC, 8)
+     if base >= requiredInsertCount:
+       encodeInteger(prefixBuffer, 0, base - requiredInsertCount, 7)
+     else:
+       encodeInteger(prefixBuffer, 0x80,
+                     requiredInsertCount  - base - 1, 7)
+
+   return encoderBuffer, prefixBuffer + streamBuffer
+
+Appendix C.  Change Log
+
+      *RFC Editor's Note:* Please remove this section prior to
+      publication of a final version of this document.
+
+C.1.  Since draft-ietf-quic-qpack-14
+
+   Added security considerations
+
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 40]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+C.2.  Since draft-ietf-quic-qpack-13
+
+   No changes
+
+C.3.  Since draft-ietf-quic-qpack-12
+
+   Editorial changes only
+
+C.4.  Since draft-ietf-quic-qpack-11
+
+   Editorial changes only
+
+C.5.  Since draft-ietf-quic-qpack-10
+
+   Editorial changes only
+
+C.6.  Since draft-ietf-quic-qpack-09
+
+   *  Decoders MUST emit Header Acknowledgements (#2939)
+
+   *  Updated error code for multiple encoder or decoder streams (#2970)
+
+   *  Added explicit defaults for new SETTINGS (#2974)
+
+C.7.  Since draft-ietf-quic-qpack-08
+
+   *  Endpoints are permitted to create encoder and decoder streams even
+      if they can't use them (#2100, #2529)
+
+   *  Maximum values for settings removed (#2766, #2767)
+
+C.8.  Since draft-ietf-quic-qpack-06
+
+   *  Clarify initial dynamic table capacity maximums (#2276, #2330,
+      #2330)
+
+C.9.  Since draft-ietf-quic-qpack-05
+
+   *  Introduced the terms dynamic table capacity and maximum dynamic
+      table capacity.
+
+   *  Renamed SETTINGS_HEADER_TABLE_SIZE to
+      SETTINGS_QPACK_MAX_TABLE_CAPACITY.
+
+C.10.  Since draft-ietf-quic-qpack-04
+
+   *  Changed calculation of Delta Base Index to avoid an illegal value
+      (#2002, #2005)
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 41]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+C.11.  Since draft-ietf-quic-qpack-03
+
+   *  Change HTTP settings defaults (#2038)
+
+   *  Substantial editorial reorganization
+
+C.12.  Since draft-ietf-quic-qpack-02
+
+   *  Largest Reference encoded modulo MaxEntries (#1763)
+
+   *  New Static Table (#1355)
+
+   *  Table Size Update with Insert Count=0 is a connection error
+      (#1762)
+
+   *  Stream Cancellations are optional when
+      SETTINGS_HEADER_TABLE_SIZE=0 (#1761)
+
+   *  Implementations must handle 62 bit integers (#1760)
+
+   *  Different error types for each QPACK stream, other changes to
+      error handling (#1726)
+
+   *  Preserve header field order (#1725)
+
+   *  Initial table size is the maximum permitted when table is first
+      usable (#1642)
+
+C.13.  Since draft-ietf-quic-qpack-01
+
+   *  Only header blocks that reference the dynamic table are
+      acknowledged (#1603, #1605)
+
+C.14.  Since draft-ietf-quic-qpack-00
+
+   *  Renumbered instructions for consistency (#1471, #1472)
+
+   *  Decoder is allowed to validate largest reference (#1404, #1469)
+
+   *  Header block acknowledgments also acknowledge the associated
+      largest reference (#1370, #1400)
+
+   *  Added an acknowledgment for unread streams (#1371, #1400)
+
+   *  Removed framing from encoder stream (#1361,#1467)
+
+   *  Control streams use typed unidirectional streams rather than fixed
+      stream IDs (#910,#1359)
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 42]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+C.15.  Since draft-ietf-quic-qcram-00
+
+   *  Separate instruction sets for table updates and header blocks
+      (#1235, #1142, #1141)
+
+   *  Reworked indexing scheme (#1176, #1145, #1136, #1130, #1125,
+      #1314)
+
+   *  Added mechanisms that support one-pass encoding (#1138, #1320)
+
+   *  Added a setting to control the number of blocked decoders (#238,
+      #1140, #1143)
+
+   *  Moved table updates and acknowledgments to dedicated streams
+      (#1121, #1122, #1238)
+
+Acknowledgments
+
+   The IETF QUIC Working Group received an enormous amount of support
+   from many people.
+
+   The compression design team did substantial work exploring the
+   problem space and influencing the initial draft.  The contributions
+   of design team members Roberto Peon, Martin Thomson, and Dmitri
+   Tikhonov are gratefully acknowledged.
+
+   The following people also provided substantial contributions to this
+   document:
+
+   *  Bence Beky
+
+   *  Alessandro Ghedini
+
+   *  Ryan Hamilton
+
+   *  Robin Marx
+
+   *  Patrick McManus
+
+   *  奥 一穂 (Kazuho Oku)
+
+   *  Lucas Pardue
+
+   *  Biren Roy
+
+   *  Ian Swett
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 43]
+
+Internet-Draft                    QPACK                        June 2020
+
+
+   This draft draws heavily on the text of [RFC7541].  The indirect
+   input of those authors is also gratefully acknowledged.
+
+   Buck's contribution was supported by Google during his employment
+   there.
+
+   A portion of Mike's contribution was supported by Microsoft during
+   his employment there.
+
+Authors' Addresses
+
+   Charles 'Buck' Krasic
+   Netflix
+
+   Email: ckrasic@netflix.com
+
+
+   Mike Bishop
+   Akamai Technologies
+
+   Email: mbishop@evequefou.be
+
+
+   Alan Frindell (editor)
+   Facebook
+
+   Email: afrind@fb.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krasic, et al.           Expires 5 December 2020               [Page 44]
diff --git a/jri/mustnot/draft-ietf-quic-recovery.html b/jri/mustnot/draft-ietf-quic-recovery.html
new file mode 100644
index 0000000000..5527589c50
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-recovery.html
@@ -0,0 +1,3680 @@
+<!DOCTYPE html>
+<html lang="en" class="Internet-Draft">
+<head>
+<meta charset="utf-8">
+<meta content="Common,Latin" name="scripts">
+<meta content="initial-scale=1.0" name="viewport">
+<title>QUIC Loss Detection and Congestion Control</title>
+<meta content="Jana Iyengar" name="author">
+<meta content="Ian Swett" name="author">
+<meta content="
+       This document describes loss detection and congestion control mechanisms for
+QUIC. 
+    " name="description">
+<meta content="xml2rfc 2.45.2" name="generator">
+<meta content="draft-ietf-quic-recovery-latest" name="ietf.draft">
+<link href="draft-ietf-quic-recovery.xml" rel="alternate" type="application/rfc+xml">
+<link href="#copyright" rel="license">
+<style type="text/css">@import url('https://martinthomson.github.io/i-d-template/fonts.css');
+
+html {
+  --background-color: #fff;
+  --text-color: #222;
+  --title-color: #191919;
+  --link-color: #2a6496;
+  --highlight-color: #f9f9f9;
+  --line-color: #eee;
+  --small-font-size: 14.5px;
+}
+body {
+  max-width: 600px;
+  margin: 75px auto;
+  padding: 0 5px;
+  color: var(--text-color);
+  background-color: var(--background-color);
+  font: 16px/22px "Lora", serif;
+  scroll-behavior: smooth;
+}
+
+.ears {
+  display: none;
+}
+
+/* headings */
+#title, h1, h2, h3, h4, h5, h6 {
+  font-family: "Cabin Condensed", sans-serif;
+  font-weight: 600;
+  margin: 0.8em 0 0.3em;
+  font-size-adjust: 0.5;
+  color: var(--title-color);
+}
+#title {
+  padding: 1em 0 0.2em;
+  font-size: 32px;
+  line-height: 40px;
+  clear: both;
+}
+h1, h2, h3 {
+  font-size: 22px;
+  line-height: 26px;
+}
+h4, h5, h6 {
+  font-size: 18px;
+  line-height: 22px;
+}
+
+/* general structure */
+.author {
+  padding-bottom: 0.3em;
+}
+#abstract+p, #abstract+p code, #abstract+p samp, #abstract+p tt {
+  font-size: 18px;
+  line-height: 24px;
+}
+p {
+  padding: 0;
+  margin: 0.5em 0;
+  text-align: left;
+}
+div, span {
+  position: relative;
+}
+div {
+  margin: 0;
+}
+.alignRight.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignRight.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignRight {
+  margin: 1em 0;
+}
+.alignRight > *:first-child {
+  border: none;
+  margin: 0;
+  float: right;
+  clear: both;
+}
+.alignRight > *:nth-child(2) {
+  clear: both;
+  display: block;
+  border: none;
+}
+svg {
+  display: block;
+}
+.alignCenter.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignCenter.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignCenter {
+  margin: 1em 0;
+}
+.alignCenter > *:first-child {
+  border: none;
+  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
+     support flexbox yet.
+  */
+  display: table;
+  margin: 0 auto;
+}
+
+/* lists */
+ol, ul {
+  padding: 0;
+  margin: 0 0 1em 2em;
+}
+ol ol, ul ul, ol ul, ul ol {
+  margin-left: 1em;
+}
+li {
+  margin: 0 0 0.25em 0;
+}
+.ulCompact li {
+  margin: 0;
+}
+ul.empty, .ulEmpty {
+  list-style-type: none;
+}
+ul.empty li, .ulEmpty li {
+  margin-top: 0.5em;
+}
+ul.compact, .ulCompact,
+ol.compact, .olCompact {
+  line-height: 100%;
+  margin: 0 0 0 2em;
+}
+
+/* definition lists */
+dl {
+}
+dl > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl > dd {
+  margin-bottom: .8em;
+  min-height: 1.3em;
+}
+dl.compact > dd, .dlCompact > dd {
+  margin-bottom: 0em;
+}
+dl > dd > dl {
+  margin-top: 0.5em;
+  margin-bottom: 0em;
+}
+dd.break {
+  display: none;
+}
+
+/* links */
+a, a[href].selfRef:hover {
+  text-decoration: none;
+}
+a[href].selfRef {
+  color: var(--text-color);
+}
+a[href] {
+  color: var(--link-color);
+}
+a[href]:hover {
+  text-decoration: underline;
+}
+a[href].selfRef:hover {
+  background-color: var(--highlight-color);
+}
+a.xref {
+  white-space: nowrap;
+}
+
+/* Figures */
+tt, code, pre {
+  background-color: var(--highlight-color);
+  font: 14px/22px 'Oxygen Mono', monospace;
+}
+pre {
+  border: 1px solid var(--line-color);
+  font-size: 13.5px;
+  line-height: 16px;
+  letter-spacing: -0.2px;
+  margin: 5px;
+  padding: 5px;
+}
+img {
+  max-width: 100%;
+}
+figure {
+  margin: 0.5em 0;
+}
+figure blockquote {
+  margin: 0.8em 0.4em 0.4em;
+}
+figcaption, caption {
+  font-style: italic;
+  margin: 0.5em 1.5em;
+  text-align: left;
+}
+@media screen {
+  pre {
+    display: inline-block;
+    overflow-x: auto;
+    max-width: 100%;
+    width: calc(100% - 22px - 1em);
+  }
+  figure pre {
+    display: block;
+    width: calc(100% - 25px);
+  }
+  pre + .pilcrow {
+    display: inline-block;
+    vertical-align: text-bottom;
+    padding-bottom: 8px;
+  }
+  table {
+    display: inline-block;
+    overflow-x: auto;
+  }
+}
+
+/* aside, blockquote */
+aside, blockquote {
+  margin-left: 0;
+  padding: 0 2em;
+  font-style: italic;
+}
+blockquote {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  margin: 1em 0;
+}
+cite {
+  display: block;
+  text-align: right;
+  font-style: italic;
+}
+
+/* tables */
+table {
+  width: 100%;
+  margin: 0 0 1em;
+  border-collapse: collapse;
+}
+thead, tbody {
+  border: 1px solid var(--line-color);
+}
+th, td {
+  text-align: left;
+  vertical-align: top;
+  padding: 5px 10px;
+}
+th {
+  text-align: left;
+  background-color: #eee;
+}
+tr:nth-child(2n) > td {
+  background-color: var(--background-color);
+}
+tr:nth-child(2n+1) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n+1) > td {
+  background-color: var(--background-color);
+}
+table caption {
+  margin: 0;
+  padding: 3px 1em;
+}
+table p {
+  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
+     be allowed within tables more generally, it would be far better to select on a class. */
+  margin: 0;
+}
+
+/* pilcrow */
+a.pilcrow {
+  margin-left: 3px;
+  visibility: hidden;
+  user-select: none;
+}
+a.pilcrow[href] { color: #ddd; }
+a.pilcrow[href]:hover { text-decoration: none; }
+@media screen {
+  :hover > a.pilcrow {
+    visibility: visible;
+  }
+  a.pilcrow:hover {
+    background-color: transparent;
+  }
+}
+
+/* misc */
+hr {
+  border: 0;
+  border-top: 1px solid var(--line-color);
+}
+.bcp14 {
+  font-variant: small-caps;
+}
+
+.role {
+  font-variant: all-small-caps;
+}
+
+/* info block */
+#identifiers {
+  margin: 0;
+  font-size: var(--small-font-size);
+  line-height: 18px;
+  --identifier-width: 8em;
+}
+#identifiers dt {
+  width: var(--identifier-width);
+  margin: 0;
+  clear: left;
+  float: left;
+  text-align: right;
+}
+#identifiers dd {
+  margin: 0 0 0 calc(1em + var(--identifier-width));
+  min-width: 5em;
+}
+#identifiers .authors .author {
+  display: inline-block;
+  margin-right: 1.5em;
+}
+#identifiers .authors .org {
+  font-style: italic;
+}
+
+/* The prepared/rendered info at the very bottom of the page */
+.docInfo {
+  color: #999;
+  font-size: 0.9em;
+  font-style: italic;
+  margin-top: 2em;
+}
+.docInfo .prepared {
+  float: left;
+}
+.docInfo .prepared {
+  float: right;
+}
+
+/* table of contents */
+#toc {
+  padding: 0.75em 0 2em 0;
+  margin-bottom: 1em;
+}
+#toc nav ul {
+  margin: 0 0.5em 0 0;
+  padding: 0;
+  list-style: none;
+}
+#toc nav li {
+  line-height: 1.3em;
+  margin: 0.75em 0;
+  padding-left: 1.2em;
+  text-indent: -1.2em;
+}
+#toc a.xref {
+  white-space: normal;
+}
+/* references */
+.references dt {
+  text-align: right;
+  font-weight: bold;
+  min-width: 7em;
+}
+.references dd {
+  margin-left: 8em;
+  overflow: auto;
+}
+
+.refInstance {
+  margin-bottom: 1.25em;
+}
+
+.references .ascii {
+  margin-bottom: 0.25em;
+}
+
+/* index */
+.index ul {
+  margin: 0 0 0 1em;
+  padding: 0;
+  list-style: none;
+}
+.index ul ul {
+  margin: 0;
+}
+.index li {
+  margin: 0;
+  text-indent: -2em;
+  padding-left: 2em;
+  padding-bottom: 5px;
+}
+.indexIndex {
+  margin: 0.5em 0 1em;
+}
+.index a {
+  font-weight: 700;
+}
+/* make the index two-column on all but the smallest screens */
+@media (min-width: 500px) {
+  .index ul {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  .index ul ul {
+    column-count: 1;
+    column-gap: 0;
+  }
+}
+
+/* authors */
+address.vcard {
+  font-style: normal;
+  margin: 1em 0;
+}
+address.vcard .nameRole {
+  font-weight: 700;
+  margin-left: 0;
+}
+address.vcard .label {
+  margin: 0.5em 0;
+}
+address.vcard .type {
+  display: none;
+}
+.alternative-contact {
+  margin: 1.5em 0 1em;
+}
+hr.addr {
+  border-top: 1px dashed;
+  margin: 0;
+  color: #ddd;
+  max-width: calc(100% - 16px);
+}
+@media (min-width: 500px) {
+  #authors-addresses > section {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  #authors-addresses > section > h2 {
+    column-span: all;
+  }
+  /* hack for break-inside: avoid-column */
+  #authors-addresses address {
+    display: inline-block;
+    break-inside: avoid-column;
+  }
+}
+
+.rfcEditorRemove p:first-of-type {
+  font-style: italic;
+}
+.cref {
+  background-color: rgba(249, 232, 105, 0.3);
+  padding: 2px 4px;
+}
+.crefSource {
+  font-style: italic;
+}
+/* alternative layout for smaller screens */
+@media screen and (max-width: 929px) {
+  #toc {
+    position: fixed;
+    z-index: 2;
+    top: 0;
+    right: 0;
+    padding: 0;
+    margin: 0;
+    border-bottom: 1px solid #ccc;
+    opacity: 0.6;
+  }
+  #toc.active {
+      opacity: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 2px 0 2px 6px;
+    padding-right: 1em;
+    font-size: 18px;
+    line-height: 24px;
+    min-width: 190px;
+    text-align: right;
+    background-color: #444;
+    color: white;
+    cursor: pointer;
+  }
+  #toc h2::before { /* css hamburger */
+    float: right;
+    position: relative;
+    width: 1em;
+    height: 1px;
+    left: -164px;
+    margin: 8px 0 0 0;
+    background: white none repeat scroll 0 0;
+    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
+    content: "";
+  }
+  #toc nav {
+    display: none;
+    background-color: var(--background-color);
+    padding: 0.5em 1em 1em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    height: calc(100vh - 48px);
+    border-left: 1px solid #ddd;
+  }
+  #toc.active nav {
+    display: block;
+  }
+  /* Make the collapsed ToC header render white on gray also when it's a link */
+  #toc h2 a,
+  #toc h2 a:link,
+  #toc h2 a:focus,
+  #toc h2 a:hover,
+  #toc a.toplink,
+  #toc a.toplink:hover {
+    color: white;
+    background-color: #444;
+    text-decoration: none;
+  }
+  #toc a.toplink {
+    margin-top: 2px;
+  }
+}
+
+/* alternative layout for wide screens */
+@media screen and (min-width: 930px) {
+  body {
+    padding-right: 360px;
+    padding-right: calc(min(180px + 20%, 500px));
+  }
+  #toc {
+    position: fixed;
+    bottom: 0;
+    right: 0;
+    right: calc(50vw - 480px);
+    width: 312px;
+    margin: 0;
+    padding: 0;
+    z-index: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 0.25em 1em 1em 0;
+  }
+  #toc nav {
+    display: block;
+    height: calc(90vh - 84px);
+    bottom: 0;
+    padding: 0.5em 0 2em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    scrollbar-width: thin;
+  }
+  #toc nav > ul  {
+    margin-bottom: 2em;
+  }
+  #toc ul {
+    margin: 0 0 0 4px;
+    font-size: var(--small-font-size);
+  }
+  #toc ul p, #toc ul li {
+    margin: 2px 0;
+    line-height: 22px;
+  }
+  img { /* future proofing */
+    max-width: 100%;
+    height: auto;
+  }
+}
+
+/* pagination */
+@media print {
+  body {
+    width: 100%;
+  }
+  p {
+    orphans: 3;
+    widows: 3;
+  }
+  #n-copyright-notice {
+    border-bottom: none;
+  }
+  #toc, #n-introduction {
+    page-break-before: always;
+  }
+  #toc {
+    border-top: none;
+    padding-top: 0;
+  }
+  figure, pre {
+    page-break-inside: avoid;
+  }
+  figure {
+    overflow: scroll;
+  }
+  h1, h2, h3, h4, h5, h6 {
+    page-break-after: avoid;
+  }
+  h2+*, h3+*, h4+*, h5+*, h6+* {
+    page-break-before: avoid;
+  }
+  pre {
+    white-space: pre-wrap;
+    word-wrap: break-word;
+    font-size: 10pt;
+  }
+  table {
+    border: 1px solid #ddd;
+  }
+  td {
+    border-top: 1px solid #ddd;
+  }
+}
+
+@page :first {
+  padding-top: 0;
+  @top-left {
+    content: normal;
+    border: none;
+  }
+  @top-center {
+    content: normal;
+    border: none;
+  }
+  @top-right {
+    content: normal;
+    border: none;
+  }
+}
+
+@page {
+  size: A4;
+  margin-bottom: 45mm;
+  padding-top: 20px;
+}
+
+/* Changes introduced to fix issues found during implementation */
+
+/* Separate body from document info even without intervening H1 */
+section {
+  clear: both;
+}
+
+/* Top align author divs, to avoid names without organization dropping level with org names */
+.author {
+  vertical-align: top;
+}
+
+/* Style section numbers with more space between number and title */
+.section-number {
+  padding-right: 0.5em;
+}
+
+/* Add styling for a link in the ToC that points to the top of the document */
+a.toplink {
+  float: right;
+  margin: 8px 0.5em 0;
+}
+
+/* Fix the dl styling to match the RFC 7992 attributes */
+dl > dt,
+dl.dlParallel > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl.dlNewline > dt {
+  float: none;
+}
+
+/* Provide styling for table cell text alignment */
+table .text-left, table .text-left {
+  text-align: left;
+}
+table .text-center, table .text-center {
+  text-align: center;
+}
+table .text-right, table .text-right {
+  text-align: right;
+}
+
+/* Make the alternative author contact information look less like just another
+   author, and group it closer with the primary author contact information */
+.alternative-contact {
+  margin: 0.5em 0 0.25em 0;
+}
+address .non-ascii {
+  margin: 0 0 0 2em;
+}
+
+/* With it being possible to set tables with alignment
+  left, center, and right, { width: 100%; } does not make sense */
+table {
+  width: auto;
+}
+
+/* Avoid reference text that sits in a block with very wide left margin,
+   because of a long floating dt label.*/
+.references dd {
+  overflow: visible;
+}
+
+/* Control caption placement */
+caption {
+  caption-side: bottom;
+}
+
+/* Limit the width of the author address vcard, so names in right-to-left
+   script don't end up on the other side of the page. */
+
+address.vcard {
+  max-width: 20em;
+  margin-right: auto;
+}
+
+/* For address alignment dependent on LTR or RTL scripts */
+address div.left {
+  text-align: left;
+}
+address div.right {
+  text-align: right;
+}
+
+/* Provide table alignment support.  We can't use the alignX classes above
+   since they do unwanted things with caption and other styling. */
+table.right {
+ margin-left: auto;
+ margin-right: 0;
+}
+table.center {
+ margin-left: auto;
+ margin-right: auto;
+}
+table.left {
+ margin-left: 0;
+ margin-right: auto;
+}
+
+/* Give the table caption label the same styling as the figcaption */
+
+@media print {
+  .toplink {
+    display: none;
+  }
+
+  /* avoid overwriting the top border line with the ToC header */
+  #toc {
+    padding-top: 1px;
+  }
+
+  /* Avoid page breaks inside dl and author address entries */
+  dd {
+    page-break-before: avoid;
+  }
+  .vcard {
+    page-break-inside: avoid;
+  }
+
+}
+/* Tweak the bcp14 keyword presentation */
+.bcp14 {
+  font-variant: small-caps;
+  font-weight: bold;
+  font-size: 0.9em;
+}
+</style>
+<link href="rfc-local.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<table class="ears">
+<thead><tr>
+<td class="left">Internet-Draft</td>
+<td class="center">QUIC Loss Detection</td>
+<td class="right">June 2020</td>
+</tr></thead>
+<tfoot><tr>
+<td class="left">Iyengar &amp; Swett</td>
+<td class="center">Expires 5 December 2020</td>
+<td class="right">[Page]</td>
+</tr></tfoot>
+</table>
+<div id="external-metadata" class="document-information"></div>
+<div id="internal-metadata" class="document-information">
+<dl id="identifiers">
+<dt class="label-workgroup">Workgroup:</dt>
+<dd class="workgroup">QUIC</dd>
+<dt class="label-internet-draft">Internet-Draft:</dt>
+<dd class="internet-draft">draft-ietf-quic-recovery-latest</dd>
+<dt class="label-published">Published:</dt>
+<dd class="published">
+<time datetime="2020-06-03" class="published">3 June 2020</time>
+    </dd>
+<dt class="label-intended-status">Intended Status:</dt>
+<dd class="intended-status">Standards Track</dd>
+<dt class="label-expires">Expires:</dt>
+<dd class="expires"><time datetime="2020-12-05">5 December 2020</time></dd>
+<dt class="label-authors">Authors:</dt>
+<dd class="authors">
+<div class="author">
+      <div class="author-name">J. Iyengar, <span class="editor">Ed.</span>
+</div>
+<div class="org">Fastly</div>
+</div>
+<div class="author">
+      <div class="author-name">I. Swett, <span class="editor">Ed.</span>
+</div>
+<div class="org">Google</div>
+</div>
+</dd>
+</dl>
+</div>
+<h1 id="title">QUIC Loss Detection and Congestion Control</h1>
+<section id="section-abstract">
+      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
+<p id="section-abstract-1">This document describes loss detection and congestion control mechanisms for
+QUIC.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.1">
+      <h2 id="name-note-to-readers">
+<a href="#name-note-to-readers" class="section-name selfRef">Note to Readers</a>
+      </h2>
+<p id="section-note.1-1">Discussion of this draft takes place on the QUIC working group mailing list
+(<a href="mailto:quic@ietf.org">quic@ietf.org</a>), which is archived at
+<span><a href="https://mailarchive.ietf.org/arch/search/?email_list=quic">https://mailarchive.ietf.org/arch/search/?email_list=quic</a></span>.<a href="#section-note.1-1" class="pilcrow">¶</a></p>
+<p id="section-note.1-2">Working Group information can be found at <span><a href="https://github.com/quicwg">https://github.com/quicwg</a></span>; source
+code and issues list for this draft can be found at
+<span><a href="https://github.com/quicwg/base-drafts/labels/-recovery">https://github.com/quicwg/base-drafts/labels/-recovery</a></span>.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
+</section>
+<div id="status-of-memo">
+<section id="section-boilerplate.1">
+        <h2 id="name-status-of-this-memo">
+<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
+        </h2>
+<p id="section-boilerplate.1-1">
+        This Internet-Draft is submitted in full conformance with the
+        provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-2">
+        Internet-Drafts are working documents of the Internet Engineering Task
+        Force (IETF). Note that other groups may also distribute working
+        documents as Internet-Drafts. The list of current Internet-Drafts is
+        at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-3">
+        Internet-Drafts are draft documents valid for a maximum of six months
+        and may be updated, replaced, or obsoleted by other documents at any
+        time. It is inappropriate to use Internet-Drafts as reference
+        material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-4">
+        This Internet-Draft will expire on 5 December 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="copyright">
+<section id="section-boilerplate.2">
+        <h2 id="name-copyright-notice">
+<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
+        </h2>
+<p id="section-boilerplate.2-1">
+            Copyright (c) 2020 IETF Trust and the persons identified as the
+            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.2-2">
+            This document is subject to BCP 78 and the IETF Trust's Legal
+            Provisions Relating to IETF Documents
+            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
+            publication of this document. Please review these documents
+            carefully, as they describe your rights and restrictions with
+            respect to this document. Code Components extracted from this
+            document must include Simplified BSD License text as described in
+            Section 4.e of the Trust Legal Provisions and are provided without
+            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="toc">
+<section id="section-toc.1">
+        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
+<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
+        </h2>
+<nav class="toc"><ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-definitions" class="xref">Conventions and Definitions</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-design-of-the-quic-transmis" class="xref">Design of the QUIC Transmission Machinery</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1">
+                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-relevant-differences-betwee" class="xref">Relevant Differences Between QUIC and TCP</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.1">
+                    <p id="section-toc.1-1.3.2.1.2.1.1" class="keepWithNext"><a href="#section-3.1.1" class="xref">3.1.1</a>.  <a href="#name-separate-packet-number-spac" class="xref">Separate Packet Number Spaces</a><a href="#section-toc.1-1.3.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.2">
+                    <p id="section-toc.1-1.3.2.1.2.2.1"><a href="#section-3.1.2" class="xref">3.1.2</a>.  <a href="#name-monotonically-increasing-pa" class="xref">Monotonically Increasing Packet Numbers</a><a href="#section-toc.1-1.3.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.3">
+                    <p id="section-toc.1-1.3.2.1.2.3.1"><a href="#section-3.1.3" class="xref">3.1.3</a>.  <a href="#name-clearer-loss-epoch" class="xref">Clearer Loss Epoch</a><a href="#section-toc.1-1.3.2.1.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.4">
+                    <p id="section-toc.1-1.3.2.1.2.4.1"><a href="#section-3.1.4" class="xref">3.1.4</a>.  <a href="#name-no-reneging" class="xref">No Reneging</a><a href="#section-toc.1-1.3.2.1.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.5">
+                    <p id="section-toc.1-1.3.2.1.2.5.1"><a href="#section-3.1.5" class="xref">3.1.5</a>.  <a href="#name-more-ack-ranges" class="xref">More ACK Ranges</a><a href="#section-toc.1-1.3.2.1.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.6">
+                    <p id="section-toc.1-1.3.2.1.2.6.1"><a href="#section-3.1.6" class="xref">3.1.6</a>.  <a href="#name-explicit-correction-for-del" class="xref">Explicit Correction For Delayed Acknowledgements</a><a href="#section-toc.1-1.3.2.1.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.7">
+                    <p id="section-toc.1-1.3.2.1.2.7.1"><a href="#section-3.1.7" class="xref">3.1.7</a>.  <a href="#name-probe-timeout-replaces-rto-" class="xref">Probe Timeout Replaces RTO and TLP</a><a href="#section-toc.1-1.3.2.1.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.8">
+                    <p id="section-toc.1-1.3.2.1.2.8.1"><a href="#section-3.1.8" class="xref">3.1.8</a>.  <a href="#name-the-minimum-congestion-wind" class="xref">The Minimum Congestion Window is Two Packets</a><a href="#section-toc.1-1.3.2.1.2.8.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-estimating-the-round-trip-t" class="xref">Estimating the Round-Trip Time</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1">
+                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-generating-rtt-samples" class="xref">Generating RTT samples</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.2">
+                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-estimating-min_rtt" class="xref">Estimating min_rtt</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3">
+                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-estimating-smoothed_rtt-and" class="xref">Estimating smoothed_rtt and rttvar</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-loss-detection" class="xref">Loss Detection</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1">
+                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-acknowledgement-based-detec" class="xref">Acknowledgement-based Detection</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1.2.1">
+                    <p id="section-toc.1-1.5.2.1.2.1.1"><a href="#section-5.1.1" class="xref">5.1.1</a>.  <a href="#name-packet-threshold" class="xref">Packet Threshold</a><a href="#section-toc.1-1.5.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1.2.2">
+                    <p id="section-toc.1-1.5.2.1.2.2.1"><a href="#section-5.1.2" class="xref">5.1.2</a>.  <a href="#name-time-threshold" class="xref">Time Threshold</a><a href="#section-toc.1-1.5.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2">
+                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-probe-timeout" class="xref">Probe Timeout</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2.2.1">
+                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-computing-pto" class="xref">Computing PTO</a><a href="#section-toc.1-1.5.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2.2.2">
+                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-handshakes-and-new-paths" class="xref">Handshakes and New Paths</a><a href="#section-toc.1-1.5.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2.2.3">
+                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-speeding-up-handshake-compl" class="xref">Speeding Up Handshake Completion</a><a href="#section-toc.1-1.5.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2.2.4">
+                    <p id="section-toc.1-1.5.2.2.2.4.1"><a href="#section-5.2.4" class="xref">5.2.4</a>.  <a href="#name-sending-probe-packets" class="xref">Sending Probe Packets</a><a href="#section-toc.1-1.5.2.2.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.3">
+                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-handling-retry-packets" class="xref">Handling Retry Packets</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4">
+                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-discarding-keys-and-packet-" class="xref">Discarding Keys and Packet State</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-congestion-control" class="xref">Congestion Control</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-explicit-congestion-notific" class="xref">Explicit Congestion Notification</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2">
+                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-initial-and-minimum-congest" class="xref">Initial and Minimum Congestion Window</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.3">
+                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-slow-start" class="xref">Slow Start</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.4">
+                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-congestion-avoidance" class="xref">Congestion Avoidance</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.5">
+                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-recovery-period" class="xref">Recovery Period</a><a href="#section-toc.1-1.6.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.6">
+                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-ignoring-loss-of-undecrypta" class="xref">Ignoring Loss of Undecryptable Packets</a><a href="#section-toc.1-1.6.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.7">
+                <p id="section-toc.1-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-probe-timeout-2" class="xref">Probe Timeout</a><a href="#section-toc.1-1.6.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.8">
+                <p id="section-toc.1-1.6.2.8.1"><a href="#section-6.8" class="xref">6.8</a>.  <a href="#name-persistent-congestion" class="xref">Persistent Congestion</a><a href="#section-toc.1-1.6.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.9">
+                <p id="section-toc.1-1.6.2.9.1"><a href="#section-6.9" class="xref">6.9</a>.  <a href="#name-pacing" class="xref">Pacing</a><a href="#section-toc.1-1.6.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.10">
+                <p id="section-toc.1-1.6.2.10.1"><a href="#section-6.10" class="xref">6.10</a>. <a href="#name-under-utilizing-the-congest" class="xref">Under-utilizing the Congestion Window</a><a href="#section-toc.1-1.6.2.10.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-congestion-signals" class="xref">Congestion Signals</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-traffic-analysis" class="xref">Traffic Analysis</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3">
+                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-misreporting-ecn-markings" class="xref">Misreporting ECN Markings</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.1">
+                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.2">
+                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-loss-recovery-pseudocode" class="xref">Loss Recovery Pseudocode</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1">
+                <p id="section-toc.1-1.10.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-tracking-sent-packets" class="xref">Tracking Sent Packets</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1.2.1">
+                    <p id="section-toc.1-1.10.2.1.2.1.1"><a href="#section-a.1.1" class="xref">A.1.1</a>.  <a href="#name-sent-packet-fields" class="xref">Sent Packet Fields</a><a href="#section-toc.1-1.10.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2">
+                <p id="section-toc.1-1.10.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-constants-of-interest" class="xref">Constants of Interest</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3">
+                <p id="section-toc.1-1.10.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-variables-of-interest" class="xref">Variables of interest</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.4">
+                <p id="section-toc.1-1.10.2.4.1"><a href="#section-a.4" class="xref">A.4</a>.  <a href="#name-initialization" class="xref">Initialization</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5">
+                <p id="section-toc.1-1.10.2.5.1"><a href="#section-a.5" class="xref">A.5</a>.  <a href="#name-on-sending-a-packet" class="xref">On Sending a Packet</a><a href="#section-toc.1-1.10.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.6">
+                <p id="section-toc.1-1.10.2.6.1"><a href="#section-a.6" class="xref">A.6</a>.  <a href="#name-on-receiving-a-datagram" class="xref">On Receiving a Datagram</a><a href="#section-toc.1-1.10.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.7">
+                <p id="section-toc.1-1.10.2.7.1"><a href="#section-a.7" class="xref">A.7</a>.  <a href="#name-on-receiving-an-acknowledgm" class="xref">On Receiving an Acknowledgment</a><a href="#section-toc.1-1.10.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.8">
+                <p id="section-toc.1-1.10.2.8.1"><a href="#section-a.8" class="xref">A.8</a>.  <a href="#name-setting-the-loss-detection-" class="xref">Setting the Loss Detection Timer</a><a href="#section-toc.1-1.10.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.9">
+                <p id="section-toc.1-1.10.2.9.1"><a href="#section-a.9" class="xref">A.9</a>.  <a href="#name-on-timeout" class="xref">On Timeout</a><a href="#section-toc.1-1.10.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.10">
+                <p id="section-toc.1-1.10.2.10.1"><a href="#section-a.10" class="xref">A.10</a>. <a href="#name-detecting-lost-packets" class="xref">Detecting Lost Packets</a><a href="#section-toc.1-1.10.2.10.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-congestion-control-pseudoco" class="xref">Congestion Control Pseudocode</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.1">
+                <p id="section-toc.1-1.11.2.1.1"><a href="#section-b.1" class="xref">B.1</a>.  <a href="#name-constants-of-interest-2" class="xref">Constants of interest</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.2">
+                <p id="section-toc.1-1.11.2.2.1"><a href="#section-b.2" class="xref">B.2</a>.  <a href="#name-variables-of-interest-2" class="xref">Variables of interest</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.3">
+                <p id="section-toc.1-1.11.2.3.1"><a href="#section-b.3" class="xref">B.3</a>.  <a href="#name-initialization-2" class="xref">Initialization</a><a href="#section-toc.1-1.11.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.4">
+                <p id="section-toc.1-1.11.2.4.1"><a href="#section-b.4" class="xref">B.4</a>.  <a href="#name-on-packet-sent" class="xref">On Packet Sent</a><a href="#section-toc.1-1.11.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.5">
+                <p id="section-toc.1-1.11.2.5.1"><a href="#section-b.5" class="xref">B.5</a>.  <a href="#name-on-packet-acknowledgement" class="xref">On Packet Acknowledgement</a><a href="#section-toc.1-1.11.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.6">
+                <p id="section-toc.1-1.11.2.6.1"><a href="#section-b.6" class="xref">B.6</a>.  <a href="#name-on-new-congestion-event" class="xref">On New Congestion Event</a><a href="#section-toc.1-1.11.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.7">
+                <p id="section-toc.1-1.11.2.7.1"><a href="#section-b.7" class="xref">B.7</a>.  <a href="#name-process-ecn-information" class="xref">Process ECN Information</a><a href="#section-toc.1-1.11.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.8">
+                <p id="section-toc.1-1.11.2.8.1"><a href="#section-b.8" class="xref">B.8</a>.  <a href="#name-on-packets-lost" class="xref">On Packets Lost</a><a href="#section-toc.1-1.11.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.9">
+                <p id="section-toc.1-1.11.2.9.1"><a href="#section-b.9" class="xref">B.9</a>.  <a href="#name-upon-dropping-initial-or-ha" class="xref">Upon dropping Initial or Handshake keys</a><a href="#section-toc.1-1.11.2.9.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12">
+            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref">Appendix C</a>.  <a href="#name-change-log" class="xref">Change Log</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
+<ul class="compact toc ulEmpty">
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.1">
+                <p id="section-toc.1-1.12.2.1.1"><a href="#section-c.1" class="xref">C.1</a>.  <a href="#name-since-draft-ietf-quic-recov" class="xref">Since draft-ietf-quic-recovery-27</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.2">
+                <p id="section-toc.1-1.12.2.2.1"><a href="#section-c.2" class="xref">C.2</a>.  <a href="#name-since-draft-ietf-quic-recove" class="xref">Since draft-ietf-quic-recovery-26</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.3">
+                <p id="section-toc.1-1.12.2.3.1"><a href="#section-c.3" class="xref">C.3</a>.  <a href="#name-since-draft-ietf-quic-recover" class="xref">Since draft-ietf-quic-recovery-25</a><a href="#section-toc.1-1.12.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.4">
+                <p id="section-toc.1-1.12.2.4.1"><a href="#section-c.4" class="xref">C.4</a>.  <a href="#name-since-draft-ietf-quic-recovery" class="xref">Since draft-ietf-quic-recovery-24</a><a href="#section-toc.1-1.12.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.5">
+                <p id="section-toc.1-1.12.2.5.1"><a href="#section-c.5" class="xref">C.5</a>.  <a href="#name-since-draft-ietf-quic-recovery-" class="xref">Since draft-ietf-quic-recovery-23</a><a href="#section-toc.1-1.12.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.6">
+                <p id="section-toc.1-1.12.2.6.1"><a href="#section-c.6" class="xref">C.6</a>.  <a href="#name-since-draft-ietf-quic-recovery-2" class="xref">Since draft-ietf-quic-recovery-22</a><a href="#section-toc.1-1.12.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.7">
+                <p id="section-toc.1-1.12.2.7.1"><a href="#section-c.7" class="xref">C.7</a>.  <a href="#name-since-draft-ietf-quic-recovery-21" class="xref">Since draft-ietf-quic-recovery-21</a><a href="#section-toc.1-1.12.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.8">
+                <p id="section-toc.1-1.12.2.8.1"><a href="#section-c.8" class="xref">C.8</a>.  <a href="#name-since-draft-ietf-quic-recovery-20" class="xref">Since draft-ietf-quic-recovery-20</a><a href="#section-toc.1-1.12.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.9">
+                <p id="section-toc.1-1.12.2.9.1"><a href="#section-c.9" class="xref">C.9</a>.  <a href="#name-since-draft-ietf-quic-recovery-1" class="xref">Since draft-ietf-quic-recovery-19</a><a href="#section-toc.1-1.12.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.10">
+                <p id="section-toc.1-1.12.2.10.1"><a href="#section-c.10" class="xref">C.10</a>. <a href="#name-since-draft-ietf-quic-recovery-18" class="xref">Since draft-ietf-quic-recovery-18</a><a href="#section-toc.1-1.12.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.11">
+                <p id="section-toc.1-1.12.2.11.1"><a href="#section-c.11" class="xref">C.11</a>. <a href="#name-since-draft-ietf-quic-recovery-17" class="xref">Since draft-ietf-quic-recovery-17</a><a href="#section-toc.1-1.12.2.11.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.12">
+                <p id="section-toc.1-1.12.2.12.1"><a href="#section-c.12" class="xref">C.12</a>. <a href="#name-since-draft-ietf-quic-recovery-16" class="xref">Since draft-ietf-quic-recovery-16</a><a href="#section-toc.1-1.12.2.12.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.13">
+                <p id="section-toc.1-1.12.2.13.1"><a href="#section-c.13" class="xref">C.13</a>. <a href="#name-since-draft-ietf-quic-recovery-14" class="xref">Since draft-ietf-quic-recovery-14</a><a href="#section-toc.1-1.12.2.13.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.14">
+                <p id="section-toc.1-1.12.2.14.1"><a href="#section-c.14" class="xref">C.14</a>. <a href="#name-since-draft-ietf-quic-recovery-13" class="xref">Since draft-ietf-quic-recovery-13</a><a href="#section-toc.1-1.12.2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.15">
+                <p id="section-toc.1-1.12.2.15.1"><a href="#section-c.15" class="xref">C.15</a>. <a href="#name-since-draft-ietf-quic-recovery-12" class="xref">Since draft-ietf-quic-recovery-12</a><a href="#section-toc.1-1.12.2.15.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.16">
+                <p id="section-toc.1-1.12.2.16.1"><a href="#section-c.16" class="xref">C.16</a>. <a href="#name-since-draft-ietf-quic-recovery-11" class="xref">Since draft-ietf-quic-recovery-11</a><a href="#section-toc.1-1.12.2.16.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.17">
+                <p id="section-toc.1-1.12.2.17.1"><a href="#section-c.17" class="xref">C.17</a>. <a href="#name-since-draft-ietf-quic-recovery-10" class="xref">Since draft-ietf-quic-recovery-10</a><a href="#section-toc.1-1.12.2.17.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.18">
+                <p id="section-toc.1-1.12.2.18.1"><a href="#section-c.18" class="xref">C.18</a>. <a href="#name-since-draft-ietf-quic-recovery-0" class="xref">Since draft-ietf-quic-recovery-09</a><a href="#section-toc.1-1.12.2.18.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.19">
+                <p id="section-toc.1-1.12.2.19.1"><a href="#section-c.19" class="xref">C.19</a>. <a href="#name-since-draft-ietf-quic-recovery-08" class="xref">Since draft-ietf-quic-recovery-08</a><a href="#section-toc.1-1.12.2.19.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.20">
+                <p id="section-toc.1-1.12.2.20.1"><a href="#section-c.20" class="xref">C.20</a>. <a href="#name-since-draft-ietf-quic-recovery-07" class="xref">Since draft-ietf-quic-recovery-07</a><a href="#section-toc.1-1.12.2.20.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.21">
+                <p id="section-toc.1-1.12.2.21.1"><a href="#section-c.21" class="xref">C.21</a>. <a href="#name-since-draft-ietf-quic-recovery-06" class="xref">Since draft-ietf-quic-recovery-06</a><a href="#section-toc.1-1.12.2.21.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.22">
+                <p id="section-toc.1-1.12.2.22.1"><a href="#section-c.22" class="xref">C.22</a>. <a href="#name-since-draft-ietf-quic-recovery-05" class="xref">Since draft-ietf-quic-recovery-05</a><a href="#section-toc.1-1.12.2.22.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.23">
+                <p id="section-toc.1-1.12.2.23.1"><a href="#section-c.23" class="xref">C.23</a>. <a href="#name-since-draft-ietf-quic-recovery-04" class="xref">Since draft-ietf-quic-recovery-04</a><a href="#section-toc.1-1.12.2.23.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.24">
+                <p id="section-toc.1-1.12.2.24.1"><a href="#section-c.24" class="xref">C.24</a>. <a href="#name-since-draft-ietf-quic-recovery-03" class="xref">Since draft-ietf-quic-recovery-03</a><a href="#section-toc.1-1.12.2.24.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.25">
+                <p id="section-toc.1-1.12.2.25.1"><a href="#section-c.25" class="xref">C.25</a>. <a href="#name-since-draft-ietf-quic-recovery-02" class="xref">Since draft-ietf-quic-recovery-02</a><a href="#section-toc.1-1.12.2.25.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.26">
+                <p id="section-toc.1-1.12.2.26.1"><a href="#section-c.26" class="xref">C.26</a>. <a href="#name-since-draft-ietf-quic-recovery-01" class="xref">Since draft-ietf-quic-recovery-01</a><a href="#section-toc.1-1.12.2.26.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.27">
+                <p id="section-toc.1-1.12.2.27.1"><a href="#section-c.27" class="xref">C.27</a>. <a href="#name-since-draft-ietf-quic-recovery-00" class="xref">Since draft-ietf-quic-recovery-00</a><a href="#section-toc.1-1.12.2.27.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.28">
+                <p id="section-toc.1-1.12.2.28.1"><a href="#section-c.28" class="xref">C.28</a>. <a href="#name-since-draft-iyengar-quic-lo" class="xref">Since draft-iyengar-quic-loss-recovery-01</a><a href="#section-toc.1-1.12.2.28.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.13">
+            <p id="section-toc.1-1.13.1"><a href="#section-appendix.d" class="xref">Appendix D</a>.  <a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.14">
+            <p id="section-toc.1-1.14.1"><a href="#section-appendix.e" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact toc ulEmpty" id="section-toc.1-1.15">
+            <p id="section-toc.1-1.15.1"><a href="#section-appendix.f" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</nav>
+</section>
+</div>
+<div id="introduction">
+<section id="section-1">
+      <h2 id="name-introduction">
+<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
+      </h2>
+<p id="section-1-1">QUIC is a new multiplexed and secure transport protocol atop UDP, specified in
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>. This document describes congestion control and loss
+recovery for QUIC. Mechanisms described in this document follow the spirit
+of existing TCP congestion control and loss recovery mechanisms, described in
+RFCs, various Internet-drafts, or academic papers, and also those prevalent in
+TCP implementations.<a href="#section-1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="conventions-and-definitions">
+<section id="section-2">
+      <h2 id="name-conventions-and-definitions">
+<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-definitions" class="section-name selfRef">Conventions and Definitions</a>
+      </h2>
+<p id="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
+"MAY", and "OPTIONAL" in this document are to be interpreted as
+described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they
+appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
+<p id="section-2-2">Definitions of terms that are used in this document:<a href="#section-2-2" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-2-3">
+        <dt id="section-2-3.1">Ack-eliciting Frames:</dt>
+<dd id="section-2-3.2">
+  All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered
+ack-eliciting.<a href="#section-2-3.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2-3.3">Ack-eliciting Packets:</dt>
+<dd id="section-2-3.4">
+  Packets that contain ack-eliciting frames elicit an ACK from the receiver
+within the maximum ack delay and are called ack-eliciting packets.<a href="#section-2-3.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-2-3.5">In-flight:</dt>
+<dd id="section-2-3.6">
+  Packets are considered in-flight when they are ack-eliciting or contain a
+PADDING frame, and they have been sent but are not acknowledged, declared
+lost, or abandoned along with old keys.<a href="#section-2-3.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="design-of-the-quic-transmission-machinery">
+<section id="section-3">
+      <h2 id="name-design-of-the-quic-transmis">
+<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-design-of-the-quic-transmis" class="section-name selfRef">Design of the QUIC Transmission Machinery</a>
+      </h2>
+<p id="section-3-1">All transmissions in QUIC are sent with a packet-level header, which indicates
+the encryption level and includes a packet sequence number (referred to below as
+a packet number).  The encryption level indicates the packet number space, as
+described in <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.  Packet numbers never repeat within a packet
+number space for the lifetime of a connection.  Packet numbers are sent in
+monotonically increasing order within a space, preventing ambiguity.<a href="#section-3-1" class="pilcrow">¶</a></p>
+<p id="section-3-2">This design obviates the need for disambiguating between transmissions and
+retransmissions and eliminates significant complexity from QUIC's interpretation
+of TCP loss detection mechanisms.<a href="#section-3-2" class="pilcrow">¶</a></p>
+<p id="section-3-3">QUIC packets can contain multiple frames of different types. The recovery
+mechanisms ensure that data and frames that need reliable delivery are
+acknowledged or declared lost and sent in new packets as necessary. The types
+of frames contained in a packet affect recovery and congestion control logic:<a href="#section-3-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-3-4.1">All packets are acknowledged, though packets that contain no
+ack-eliciting frames are only acknowledged along with ack-eliciting
+packets.<a href="#section-3-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-3-4.2">Long header packets that contain CRYPTO frames are critical to the
+performance of the QUIC handshake and use shorter timers for
+acknowledgement.<a href="#section-3-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-3-4.3">Packets containing frames besides ACK or CONNECTION_CLOSE frames count toward
+congestion control limits and are considered in-flight.<a href="#section-3-4.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-3-4.4">PADDING frames cause packets to contribute toward bytes in flight without
+directly causing an acknowledgment to be sent.<a href="#section-3-4.4" class="pilcrow">¶</a>
+</li>
+</ul>
+<div id="relevant-differences-between-quic-and-tcp">
+<section id="section-3.1">
+        <h3 id="name-relevant-differences-betwee">
+<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-relevant-differences-betwee" class="section-name selfRef">Relevant Differences Between QUIC and TCP</a>
+        </h3>
+<p id="section-3.1-1">Readers familiar with TCP's loss detection and congestion control will find
+algorithms here that parallel well-known TCP ones. Protocol differences between
+QUIC and TCP however contribute to algorithmic differences. We briefly describe
+these protocol differences below.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+<div id="separate-packet-number-spaces">
+<section id="section-3.1.1">
+          <h4 id="name-separate-packet-number-spac">
+<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-separate-packet-number-spac" class="section-name selfRef">Separate Packet Number Spaces</a>
+          </h4>
+<p id="section-3.1.1-1">QUIC uses separate packet number spaces for each encryption level, except 0-RTT
+and all generations of 1-RTT keys use the same packet number space.  Separate
+packet number spaces ensures acknowledgement of packets sent with one level of
+encryption will not cause spurious retransmission of packets sent with a
+different encryption level.  Congestion control and round-trip time (RTT)
+measurement are unified across packet number spaces.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="monotonically-increasing-packet-numbers">
+<section id="section-3.1.2">
+          <h4 id="name-monotonically-increasing-pa">
+<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-monotonically-increasing-pa" class="section-name selfRef">Monotonically Increasing Packet Numbers</a>
+          </h4>
+<p id="section-3.1.2-1">TCP conflates transmission order at the sender with delivery order at the
+receiver, which results in retransmissions of the same data carrying the same
+sequence number, and consequently leads to "retransmission ambiguity".  QUIC
+separates the two. QUIC uses a packet number to indicate transmission order.
+Application data is sent in one or more streams and delivery order is
+determined by stream offsets encoded within STREAM frames.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-3.1.2-2">QUIC's packet number is strictly increasing within a packet number space,
+and directly encodes transmission order.  A higher packet number signifies
+that the packet was sent later, and a lower packet number signifies that
+the packet was sent earlier.  When a packet containing ack-eliciting
+frames is detected lost, QUIC rebundles necessary frames in a new packet
+with a new packet number, removing ambiguity about which packet is
+acknowledged when an ACK is received.  Consequently, more accurate RTT
+measurements can be made, spurious retransmissions are trivially detected, and
+mechanisms such as Fast Retransmit can be applied universally, based only on
+packet number.<a href="#section-3.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-3.1.2-3">This design point significantly simplifies loss detection mechanisms for QUIC.
+Most TCP mechanisms implicitly attempt to infer transmission ordering based on
+TCP sequence numbers - a non-trivial task, especially when TCP timestamps are
+not available.<a href="#section-3.1.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="clearer-loss-epoch">
+<section id="section-3.1.3">
+          <h4 id="name-clearer-loss-epoch">
+<a href="#section-3.1.3" class="section-number selfRef">3.1.3. </a><a href="#name-clearer-loss-epoch" class="section-name selfRef">Clearer Loss Epoch</a>
+          </h4>
+<p id="section-3.1.3-1">QUIC starts a loss epoch when a packet is lost and ends one when any packet
+sent after the epoch starts is acknowledged.  TCP waits for the gap in the
+sequence number space to be filled, and so if a segment is lost multiple times
+in a row, the loss epoch may not end for several round trips. Because both
+should reduce their congestion windows only once per epoch, QUIC will do it
+once for every round trip that experiences loss, while TCP may only do it
+once across multiple round trips.<a href="#section-3.1.3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="no-reneging">
+<section id="section-3.1.4">
+          <h4 id="name-no-reneging">
+<a href="#section-3.1.4" class="section-number selfRef">3.1.4. </a><a href="#name-no-reneging" class="section-name selfRef">No Reneging</a>
+          </h4>
+<p id="section-3.1.4-1">QUIC ACKs contain information that is similar to TCP SACK, but QUIC does not
+allow any acked packet to be reneged, greatly simplifying implementations on
+both sides and reducing memory pressure on the sender.<a href="#section-3.1.4-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="more-ack-ranges">
+<section id="section-3.1.5">
+          <h4 id="name-more-ack-ranges">
+<a href="#section-3.1.5" class="section-number selfRef">3.1.5. </a><a href="#name-more-ack-ranges" class="section-name selfRef">More ACK Ranges</a>
+          </h4>
+<p id="section-3.1.5-1">QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges.  In high loss
+environments, this speeds recovery, reduces spurious retransmits, and ensures
+forward progress without relying on timeouts.<a href="#section-3.1.5-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="explicit-correction-for-delayed-acknowledgements">
+<section id="section-3.1.6">
+          <h4 id="name-explicit-correction-for-del">
+<a href="#section-3.1.6" class="section-number selfRef">3.1.6. </a><a href="#name-explicit-correction-for-del" class="section-name selfRef">Explicit Correction For Delayed Acknowledgements</a>
+          </h4>
+<p id="section-3.1.6-1">QUIC endpoints measure the delay incurred between when a packet is received and
+when the corresponding acknowledgment is sent, allowing a peer to maintain a
+more accurate round-trip time estimate; see Section 13.2 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-3.1.6-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="probe-timeout-replaces-rto-and-tlp">
+<section id="section-3.1.7">
+          <h4 id="name-probe-timeout-replaces-rto-">
+<a href="#section-3.1.7" class="section-number selfRef">3.1.7. </a><a href="#name-probe-timeout-replaces-rto-" class="section-name selfRef">Probe Timeout Replaces RTO and TLP</a>
+          </h4>
+<p id="section-3.1.7-1">QUIC uses a probe timeout (see <a href="#pto" class="xref">Section 5.2</a>), with a timer based on TCP's RTO
+computation.  QUIC's PTO includes the peer's maximum expected acknowledgement
+delay instead of using a fixed minimum timeout. QUIC does not collapse the
+congestion window until persistent congestion (<a href="#persistent-congestion" class="xref">Section 6.8</a>) is
+declared, unlike TCP, which collapses the congestion window upon expiry of an
+RTO.  Instead of collapsing the congestion window and declaring everything
+in-flight lost, QUIC allows probe packets to temporarily exceed the congestion
+window whenever the timer expires.<a href="#section-3.1.7-1" class="pilcrow">¶</a></p>
+<p id="section-3.1.7-2">In doing this, QUIC avoids unnecessary congestion window reductions, obviating
+the need for correcting mechanisms such as F-RTO <span>[<a href="#RFC5682" class="xref">RFC5682</a>]</span>. Since QUIC does
+not collapse the congestion window on a PTO expiration, a QUIC sender is not
+limited from sending more in-flight packets after a PTO expiration if it still
+has available congestion window. This occurs when a sender is
+application-limited and the PTO timer expires. This is more aggressive than
+TCP's RTO mechanism when application-limited, but identical when not
+application-limited.<a href="#section-3.1.7-2" class="pilcrow">¶</a></p>
+<p id="section-3.1.7-3">A single packet loss at the tail does not indicate persistent congestion, so
+QUIC specifies a time-based definition to ensure one or more packets are sent
+prior to a dramatic decrease in congestion window; see
+<a href="#persistent-congestion" class="xref">Section 6.8</a>.<a href="#section-3.1.7-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="the-minimum-congestion-window-is-two-packets">
+<section id="section-3.1.8">
+          <h4 id="name-the-minimum-congestion-wind">
+<a href="#section-3.1.8" class="section-number selfRef">3.1.8. </a><a href="#name-the-minimum-congestion-wind" class="section-name selfRef">The Minimum Congestion Window is Two Packets</a>
+          </h4>
+<p id="section-3.1.8-1">TCP uses a minimum congestion window of one packet. However, loss of
+that single packet means that the sender needs to waiting for a PTO
+(<a href="#pto" class="xref">Section 5.2</a>) to recover, which can be much longer than a round-trip time.
+Sending a single ack-eliciting packet also increases the chances of incurring
+additional latency when a receiver delays its acknowledgement.<a href="#section-3.1.8-1" class="pilcrow">¶</a></p>
+<p id="section-3.1.8-2">QUIC therefore recommends that the minimum congestion window be two
+packets. While this increases network load, it is considered safe, since the
+sender will still reduce its sending rate exponentially under persistent
+congestion (<a href="#pto" class="xref">Section 5.2</a>).<a href="#section-3.1.8-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="compute-rtt">
+<section id="section-4">
+      <h2 id="name-estimating-the-round-trip-t">
+<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-estimating-the-round-trip-t" class="section-name selfRef">Estimating the Round-Trip Time</a>
+      </h2>
+<p id="section-4-1">At a high level, an endpoint measures the time from when a packet was sent to
+when it is acknowledged as a round-trip time (RTT) sample.  The endpoint uses
+RTT samples and peer-reported host delays (see Section 13.2 of
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>) to generate a statistical description of the network
+path's RTT. An endpoint computes the following three values for each path:
+the minimum value observed over the lifetime of the path (min_rtt), an
+exponentially-weighted moving average (smoothed_rtt), and the mean deviation
+(referred to as "variation" in the rest of this document) in the observed RTT
+samples (rttvar).<a href="#section-4-1" class="pilcrow">¶</a></p>
+<div id="latest-rtt">
+<section id="section-4.1">
+        <h3 id="name-generating-rtt-samples">
+<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-generating-rtt-samples" class="section-name selfRef">Generating RTT samples</a>
+        </h3>
+<p id="section-4.1-1">An endpoint generates an RTT sample on receiving an ACK frame that meets the
+following two conditions:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.1-2.1">the largest acknowledged packet number is newly acknowledged, and<a href="#section-4.1-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1-2.2">at least one of the newly acknowledged packets was ack-eliciting.<a href="#section-4.1-2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.1-3">The RTT sample, latest_rtt, is generated as the time elapsed since the largest
+acknowledged packet was sent:<a href="#section-4.1-3" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.1-4">
+<pre>
+latest_rtt = ack_time - send_time_of_largest_acked
+</pre><a href="#section-4.1-4" class="pilcrow">¶</a>
+</div>
+<p id="section-4.1-5">An RTT sample is generated using only the largest acknowledged packet in the
+received ACK frame.  This is because a peer reports ACK delays for only the
+largest acknowledged packet in an ACK frame.  While the reported ACK delay is
+not used by the RTT sample measurement, it is used to adjust the RTT sample in
+subsequent computations of smoothed_rtt and rttvar <a href="#smoothed-rtt" class="xref">Section 4.3</a>.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
+<p id="section-4.1-6">To avoid generating multiple RTT samples for a single packet, an ACK frame
+SHOULD NOT be used to update RTT estimates if it does not newly acknowledge the
+largest acknowledged packet.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
+<p id="section-4.1-7">An RTT sample MUST NOT be generated on receiving an ACK frame that does not
+newly acknowledge at least one ack-eliciting packet. A peer usually does not
+send an ACK frame when only non-ack-eliciting packets are received. Therefore
+an ACK frame that contains acknowledgements for only non-ack-eliciting packets
+could include an arbitrarily large Ack Delay value.  Ignoring
+such ACK frames avoids complications in subsequent smoothed_rtt and rttvar
+computations.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
+<p id="section-4.1-8">A sender might generate multiple RTT samples per RTT when multiple ACK frames
+are received within an RTT.  As suggested in <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>, doing so might result
+in inadequate history in smoothed_rtt and rttvar.  Ensuring that RTT estimates
+retain sufficient history is an open research question.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="min-rtt">
+<section id="section-4.2">
+        <h3 id="name-estimating-min_rtt">
+<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-estimating-min_rtt" class="section-name selfRef">Estimating min_rtt</a>
+        </h3>
+<p id="section-4.2-1">min_rtt is the minimum RTT observed for a given network path.  min_rtt is set
+to the latest_rtt on the first RTT sample, and to the lesser of min_rtt and
+latest_rtt on subsequent samples.  In this document, min_rtt is used by loss
+detection to reject implausibly small rtt samples.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.2-2">An endpoint uses only locally observed times in computing the min_rtt and does
+not adjust for ACK delays reported by the peer.  Doing so allows the endpoint
+to set a lower bound for the smoothed_rtt based entirely on what it observes
+(see <a href="#smoothed-rtt" class="xref">Section 4.3</a>), and limits potential underestimation due to
+erroneously-reported delays by the peer.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
+<p id="section-4.2-3">The RTT for a network path may change over time.  If a path's actual RTT
+decreases, the min_rtt will adapt immediately on the first low sample.  If
+the path's actual RTT increases, the min_rtt will not adapt to it, allowing
+future RTT samples that are smaller than the new RTT be included in
+smoothed_rtt.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="smoothed-rtt">
+<section id="section-4.3">
+        <h3 id="name-estimating-smoothed_rtt-and">
+<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-estimating-smoothed_rtt-and" class="section-name selfRef">Estimating smoothed_rtt and rttvar</a>
+        </h3>
+<p id="section-4.3-1">smoothed_rtt is an exponentially-weighted moving average of an endpoint's RTT
+samples, and rttvar is the variation in the RTT samples, estimated using a
+mean variation.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+<p id="section-4.3-2">The calculation of smoothed_rtt uses path latency after adjusting RTT samples
+for acknowledgement delays. These delays are computed using the ACK Delay
+field of the ACK frame as described in Section 19.3 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.
+For packets sent in the ApplicationData packet number space, a peer limits
+any delay in sending an acknowledgement for an ack-eliciting packet to no
+greater than the value it advertised in the max_ack_delay transport parameter.
+Consequently, when a peer reports an Ack Delay that is greater than its
+max_ack_delay, the delay is attributed to reasons out of the peer's control,
+such as scheduler latency at the peer or loss of previous ACK frames.  Any
+delays beyond the peer's max_ack_delay are therefore considered effectively
+part of path delay and incorporated into the smoothed_rtt estimate.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
+<p id="section-4.3-3">When adjusting an RTT sample using peer-reported acknowledgement delays, an
+endpoint:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.3-4.1">MUST ignore the Ack Delay field of the ACK frame for packets sent in the
+Initial and Handshake packet number space.<a href="#section-4.3-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.3-4.2">MUST use the lesser of the value reported in Ack Delay field of the ACK frame
+and the peer's max_ack_delay transport parameter.<a href="#section-4.3-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.3-4.3">MUST NOT apply the adjustment if the resulting RTT sample is smaller than the
+min_rtt.  This limits the underestimation that a misreporting peer can cause
+to the smoothed_rtt.<a href="#section-4.3-4.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.3-5">smoothed_rtt and rttvar are computed as follows, similar to <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
+<p id="section-4.3-6">When there are no samples for a network path, and on the first RTT sample for
+the network path:<a href="#section-4.3-6" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.3-7">
+<pre>
+smoothed_rtt = rtt_sample
+rttvar = rtt_sample / 2
+</pre><a href="#section-4.3-7" class="pilcrow">¶</a>
+</div>
+<p id="section-4.3-8">Before any RTT samples are available, the initial RTT is used as rtt_sample.  On
+the first RTT sample for the network path, that sample is used as rtt_sample.
+This ensures that the first measurement erases the history of any persisted or
+default values.<a href="#section-4.3-8" class="pilcrow">¶</a></p>
+<p id="section-4.3-9">On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:<a href="#section-4.3-9" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.3-10">
+<pre>
+ack_delay = min(Ack Delay in ACK Frame, max_ack_delay)
+adjusted_rtt = latest_rtt
+if (min_rtt + ack_delay &lt; latest_rtt):
+  adjusted_rtt = latest_rtt - ack_delay
+smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
+rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
+rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
+</pre><a href="#section-4.3-10" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="loss-detection">
+<section id="section-5">
+      <h2 id="name-loss-detection">
+<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-loss-detection" class="section-name selfRef">Loss Detection</a>
+      </h2>
+<p id="section-5-1">QUIC senders use acknowledgements to detect lost packets, and a probe
+time out (see <a href="#pto" class="xref">Section 5.2</a>) to ensure acknowledgements are received. This section
+provides a description of these algorithms.<a href="#section-5-1" class="pilcrow">¶</a></p>
+<p id="section-5-2">If a packet is lost, the QUIC transport needs to recover from that loss, such
+as by retransmitting the data, sending an updated frame, or abandoning the
+frame.  For more information, see Section 13.3 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-5-2" class="pilcrow">¶</a></p>
+<div id="ack-loss-detection">
+<section id="section-5.1">
+        <h3 id="name-acknowledgement-based-detec">
+<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-acknowledgement-based-detec" class="section-name selfRef">Acknowledgement-based Detection</a>
+        </h3>
+<p id="section-5.1-1">Acknowledgement-based loss detection implements the spirit of TCP's Fast
+Retransmit <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>, Early Retransmit <span>[<a href="#RFC5827" class="xref">RFC5827</a>]</span>, FACK <span>[<a href="#FACK" class="xref">FACK</a>]</span>, SACK loss
+recovery <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>, and RACK <span>[<a href="#RACK" class="xref">RACK</a>]</span>. This section
+provides an overview of how these algorithms are implemented in QUIC.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.1-2">A packet is declared lost if it meets all the following conditions:<a href="#section-5.1-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.1-3.1">The packet is unacknowledged, in-flight, and was sent prior to an
+acknowledged packet.<a href="#section-5.1-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.1-3.2">Either its packet number is kPacketThreshold smaller than an acknowledged
+packet (<a href="#packet-threshold" class="xref">Section 5.1.1</a>), or it was sent long enough in the past
+(<a href="#time-threshold" class="xref">Section 5.1.2</a>).<a href="#section-5.1-3.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-5.1-4">The acknowledgement indicates that a packet sent later was delivered, and the
+packet and time thresholds provide some tolerance for packet reordering.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
+<p id="section-5.1-5">Spuriously declaring packets as lost leads to unnecessary retransmissions and
+may result in degraded performance due to the actions of the congestion
+controller upon detecting loss.  Implementations can detect spurious
+retransmissions and increase the reordering threshold in packets or time to
+reduce future spurious retransmissions and loss events. Implementations with
+adaptive time thresholds MAY choose to start with smaller initial reordering
+thresholds to minimize recovery latency.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
+<div id="packet-threshold">
+<section id="section-5.1.1">
+          <h4 id="name-packet-threshold">
+<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-packet-threshold" class="section-name selfRef">Packet Threshold</a>
+          </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>.  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.  Algorithms that increase the reordering threshold after
+spuriously detecting losses, such as TCP-NCR <span>[<a href="#RFC4653" class="xref">RFC4653</a>]</span>, have proven to be
+useful in TCP and are expected to at least as useful in QUIC.  Re-ordering
+could be more common with QUIC than TCP, because network elements cannot observe
+and fix the order of out-of-order packets.<a href="#section-5.1.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="time-threshold">
+<section id="section-5.1.2">
+          <h4 id="name-time-threshold">
+<a href="#section-5.1.2" class="section-number selfRef">5.1.2. </a><a href="#name-time-threshold" class="section-name selfRef">Time Threshold</a>
+          </h4>
+<p id="section-5.1.2-1">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 the local timer granularity, as
+indicated by the kGranularity constant.  The time threshold is:<a href="#section-5.1.2-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-5.1.2-2">
+<pre>
+max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)
+</pre><a href="#section-5.1.2-2" class="pilcrow">¶</a>
+</div>
+<p id="section-5.1.2-3">If packets sent prior to the largest acknowledged packet cannot yet be declared
+lost, then a timer SHOULD be set for the remaining time.<a href="#section-5.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.1.2-4">Using max(smoothed_rtt, latest_rtt) protects from the two following cases:<a href="#section-5.1.2-4" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.1.2-5.1">the latest RTT sample is lower than the smoothed RTT, perhaps due to
+reordering where the acknowledgement encountered a shorter path;<a href="#section-5.1.2-5.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.1.2-5.2">the latest RTT sample is higher than the smoothed RTT, perhaps due to a
+sustained increase in the actual RTT, but the smoothed RTT has not yet caught
+up.<a href="#section-5.1.2-5.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-5.1.2-6">The RECOMMENDED time threshold (kTimeThreshold), expressed as a round-trip time
+multiplier, is 9/8. The RECOMMENDED value of the timer granularity
+(kGranularity) is 1ms.<a href="#section-5.1.2-6" class="pilcrow">¶</a></p>
+<p id="section-5.1.2-7">Implementations MAY experiment with absolute thresholds, thresholds from
+previous connections, adaptive thresholds, or including RTT variation.  Smaller
+thresholds reduce reordering resilience and increase spurious retransmissions,
+and larger thresholds increase loss detection delay.<a href="#section-5.1.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="pto">
+<section id="section-5.2">
+        <h3 id="name-probe-timeout">
+<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-probe-timeout" class="section-name selfRef">Probe Timeout</a>
+        </h3>
+<p id="section-5.2-1">A Probe Timeout (PTO) triggers sending one or two probe datagrams when
+ack-eliciting packets are not acknowledged within the expected period of
+time or the server may not have validated the client's address.  A PTO enables
+a connection to recover from loss of tail packets or acknowledgements.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.2-2">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 <a href="#ack-loss-detection" class="xref">Section 5.1</a>.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
+<p id="section-5.2-3">As with loss detection, the probe timeout is per packet number space.
+The PTO algorithm used in QUIC implements the reliability functions of
+Tail Loss Probe <span>[<a href="#RACK" class="xref">RACK</a>]</span>, RTO <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>, and F-RTO algorithms for
+TCP <span>[<a href="#RFC5682" class="xref">RFC5682</a>]</span>. The timeout computation is based on TCP's retransmission
+timeout period <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
+<div id="computing-pto">
+<section id="section-5.2.1">
+          <h4 id="name-computing-pto">
+<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-computing-pto" class="section-name selfRef">Computing PTO</a>
+          </h4>
+<p id="section-5.2.1-1">When an ack-eliciting packet is transmitted, the sender schedules a timer for
+the PTO period as follows:<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-5.2.1-2">
+<pre>
+PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay
+</pre><a href="#section-5.2.1-2" class="pilcrow">¶</a>
+</div>
+<p id="section-5.2.1-3">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 variation in the estimate (4*rttvar),
+and max_ack_delay, to account for the maximum time by which a receiver might
+delay sending an acknowledgement.  When the PTO is armed for Initial or
+Handshake packet number spaces, the max_ack_delay is 0, as specified in
+13.2.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-4">The PTO value MUST be set to at least kGranularity, to avoid the timer expiring
+immediately.<a href="#section-5.2.1-4" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-5">A sender recomputes and may need to reset its PTO timer every time an
+ack-eliciting packet is sent or acknowledged, when the handshake is confirmed,
+or when Initial or Handshake keys are discarded. This ensures the PTO is always
+set based on the latest RTT information and for the last sent packet in the
+correct packet number space.<a href="#section-5.2.1-5" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-6">When ack-eliciting packets in multiple packet number spaces are in flight,
+the timer MUST be set for the packet number space with the earliest timeout,
+with one exception. The ApplicationData packet number space (Section 4.1.1
+of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>) MUST be ignored until the handshake completes. Not arming
+the PTO for ApplicationData prevents a client from retransmitting a 0-RTT
+packet on a PTO expiration before confirming that the server is able to
+decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on
+a PTO expiration before it has the keys to process an acknowledgement.<a href="#section-5.2.1-6" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-7">When a PTO timer expires, the PTO backoff MUST be increased, resulting in the
+PTO period being set to twice its current value. The PTO backoff factor is reset
+when an acknowledgement is received, except in the following case. A server
+might take longer to respond to packets during the handshake than otherwise.  To
+protect such a server from repeated client probes, the PTO backoff is not reset
+at a client that is not yet certain that the server has finished validating the
+client's address. That is, a client does not reset the PTO backoff factor on
+receiving acknowledgements until it receives a HANDSHAKE_DONE frame or an
+acknowledgement for one of its Handshake or 1-RTT packets.<a href="#section-5.2.1-7" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-8">This exponential reduction in the sender's rate is important because
+consecutive PTOs might be caused by loss of packets or acknowledgements due to
+severe congestion.  Even when there are ack-eliciting packets in-flight in
+multiple packet number spaces, the exponential increase in probe timeout
+occurs across all spaces to prevent excess load on the network.  For example,
+a timeout in the Initial packet number space doubles the length of the timeout
+in the Handshake packet number space.<a href="#section-5.2.1-8" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-9">The life of a connection that is experiencing consecutive PTOs is limited by
+the endpoint's idle timeout.<a href="#section-5.2.1-9" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-10">The probe timer MUST NOT be set if the time threshold <a href="#time-threshold" class="xref">Section 5.1.2</a> loss
+detection timer is set.  The time threshold loss detection timer is expected
+to both expire earlier than the PTO and be less likely to spuriously retransmit
+data.<a href="#section-5.2.1-10" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="pto-handshake">
+<section id="section-5.2.2">
+          <h4 id="name-handshakes-and-new-paths">
+<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-handshakes-and-new-paths" class="section-name selfRef">Handshakes and New Paths</a>
+          </h4>
+<p id="section-5.2.2-1">Resumed connections over the same network MAY use the previous connection's
+final smoothed RTT value as the resumed connection's initial RTT.  When no
+previous RTT is available, the initial RTT SHOULD be set to 333ms, resulting in
+a 1 second initial timeout, as recommended in <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-2">A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a
+PATH_RESPONSE to set the initial RTT (see kInitialRtt in
+<a href="#constants-of-interest" class="xref">Appendix A.2</a>) for a new path, but the delay SHOULD NOT be
+considered an RTT sample.<a href="#section-5.2.2-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-3">Prior to handshake completion, when few to none RTT samples have been
+generated, it is possible that the probe timer expiration is due to an
+incorrect RTT estimate at the client. To allow the client to improve its RTT
+estimate, the new packet that it sends MUST be ack-eliciting.<a href="#section-5.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-4">Initial packets and Handshake packets could be never acknowledged, but they are
+removed from bytes in flight when the Initial and Handshake keys are discarded,
+as described below in Section <a href="#discarding-packets" class="xref">Section 5.4</a>. When Initial or Handshake
+keys are discarded, the PTO and loss detection timers MUST be reset, because
+discarding keys indicates forward progress and the loss detection timer might
+have been set for a now discarded packet number space.<a href="#section-5.2.2-4" class="pilcrow">¶</a></p>
+<div id="before-address-validation">
+<section id="section-5.2.2.1">
+            <h5 id="name-before-address-validation">
+<a href="#section-5.2.2.1" class="section-number selfRef">5.2.2.1. </a><a href="#name-before-address-validation" class="section-name selfRef">Before Address Validation</a>
+            </h5>
+<p id="section-5.2.2.1-1">Until the server has validated the client's address on the path, the amount of
+data it can send is limited to three times the amount of data received,
+as specified in Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>. If no additional data can be
+sent, the server's PTO timer MUST NOT be armed until datagrams have been
+received from the client, because packets sent on PTO count against the
+anti-amplification limit. Note that the server could fail to validate the
+client's address even if 0-RTT is accepted.<a href="#section-5.2.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.2.2.1-2">Since the server could be blocked until more packets are received from the
+client, it is the client's responsibility to send packets to unblock the server
+until it is certain that the server has finished its address validation
+(see Section 8 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>).  That is, the client MUST set the
+probe timer if the client has not received an acknowledgement for one of its
+Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame.
+If Handshake keys are available to the client, it MUST send a Handshake
+packet, and otherwise it MUST send an Initial packet in a UDP datagram of
+at least 1200 bytes.<a href="#section-5.2.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.2.1-3">A client could have received and acknowledged a Handshake packet, causing it to
+discard state for the Initial packet number space, but not sent any
+ack-eliciting Handshake packets.  In this case, the PTO is set from the current
+time.<a href="#section-5.2.2.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="speeding-up-handshake-completion">
+<section id="section-5.2.3">
+          <h4 id="name-speeding-up-handshake-compl">
+<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-speeding-up-handshake-compl" class="section-name selfRef">Speeding Up Handshake Completion</a>
+          </h4>
+<p id="section-5.2.3-1">When a server receives an Initial packet containing duplicate CRYPTO data,
+it can assume the client did not receive all of the server's CRYPTO data sent
+in Initial packets, or the client's estimated RTT is too small. When a
+client receives Handshake or 1-RTT packets prior to obtaining Handshake keys,
+it may assume some or all of the server's Initial packets were lost.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-5.2.3-2">To speed up handshake completion under these conditions, an endpoint MAY send
+a packet containing unacknowledged CRYPTO data earlier than the PTO expiry,
+subject to address validation limits; see Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-5.2.3-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.3-3">Peers can also use coalesced packets to ensure that each datagram elicits at
+least one acknowledgement.  For example, clients can coalesce an Initial packet
+containing PING and PADDING frames with a 0-RTT data packet and a server can
+coalesce an Initial packet containing a PING frame with one or more packets in
+its first flight.<a href="#section-5.2.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="sending-probe-packets">
+<section id="section-5.2.4">
+          <h4 id="name-sending-probe-packets">
+<a href="#section-5.2.4" class="section-number selfRef">5.2.4. </a><a href="#name-sending-probe-packets" class="section-name selfRef">Sending Probe Packets</a>
+          </h4>
+<p id="section-5.2.4-1">When a PTO timer expires, a sender MUST send at least one ack-eliciting packet
+in the packet number space as a probe, unless there is no data available to
+send.  An endpoint MAY send up to two full-sized datagrams containing
+ack-eliciting packets, to avoid an expensive consecutive PTO expiration due
+to a single lost datagram or transmit data from multiple packet number spaces.
+All probe packets sent on a PTO MUST be ack-eliciting.<a href="#section-5.2.4-1" class="pilcrow">¶</a></p>
+<p id="section-5.2.4-2">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.  This is
+particularly valuable when the server has both Initial and Handshake data
+in-flight or the client has both Handshake and ApplicationData in-flight,
+because the peer might only have receive keys for one of the two packet number
+spaces.<a href="#section-5.2.4-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.4-3">If the sender wants to elicit a faster acknowledgement on PTO, it can skip a
+packet number to eliminate the ack delay.<a href="#section-5.2.4-3" class="pilcrow">¶</a></p>
+<p id="section-5.2.4-4">When the PTO timer expires, and there is new or previously sent unacknowledged
+data, it MUST be sent. A probe packet SHOULD carry new data when possible.
+A probe packet MAY carry retransmitted unacknowledged data when new data is
+unavailable, when flow control does not permit new data to be sent, or to
+opportunistically reduce loss recovery delay.  Implementations MAY use
+alternative strategies for determining the content of probe packets,
+including sending new or retransmitted data based on the application's
+priorities.<a href="#section-5.2.4-4" class="pilcrow">¶</a></p>
+<p id="section-5.2.4-5">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 retransmitted in a new packet,
+and then the original transmission is acknowledged.  When there is no data to
+send, the sender SHOULD send a PING or other ack-eliciting frame in a single
+packet, re-arming the PTO timer.<a href="#section-5.2.4-5" class="pilcrow">¶</a></p>
+<p id="section-5.2.4-6">Alternatively, instead of sending an ack-eliciting packet, the sender MAY mark
+any packets still in flight as lost.  Doing so avoids sending an additional
+packet, but increases the risk that loss is declared too aggressively, resulting
+in an unnecessary rate reduction by the congestion controller.<a href="#section-5.2.4-6" class="pilcrow">¶</a></p>
+<p id="section-5.2.4-7">Consecutive PTO periods increase exponentially, and as a result, connection
+recovery latency increases exponentially as packets continue to be dropped in
+the network.  Sending two packets on PTO expiration increases resilience to
+packet drops, thus reducing the probability of consecutive PTO events.<a href="#section-5.2.4-7" class="pilcrow">¶</a></p>
+<p id="section-5.2.4-8">When the PTO timer expires multiple times and new data cannot be sent,
+implementations must choose between sending the same payload every time
+or sending different payloads.  Sending the same payload may be simpler
+and ensures the highest priority frames arrive first.  Sending different
+payloads each time reduces the chances of spurious retransmission.<a href="#section-5.2.4-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="handling-retry-packets">
+<section id="section-5.3">
+        <h3 id="name-handling-retry-packets">
+<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-handling-retry-packets" class="section-name selfRef">Handling Retry Packets</a>
+        </h3>
+<p id="section-5.3-1">A Retry packet causes a client to send another Initial packet, effectively
+restarting the connection process.  A Retry packet indicates that the Initial
+was received, but not processed.  A Retry packet cannot be treated as an
+acknowledgment, because it does not indicate that a packet was processed or
+specify the packet number.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
+<p id="section-5.3-2">Clients that receive a Retry packet reset congestion control and loss recovery
+state, including resetting any pending timers.  Other connection state, in
+particular cryptographic handshake messages, is retained; see Section 17.2.5 of
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
+<p id="section-5.3-3">The client MAY compute an RTT estimate to the server as the time period from
+when the first Initial was sent to when a Retry or a Version Negotiation packet
+is received.  The client MAY use this value in place of its default for the
+initial RTT estimate.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="discarding-packets">
+<section id="section-5.4">
+        <h3 id="name-discarding-keys-and-packet-">
+<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-discarding-keys-and-packet-" class="section-name selfRef">Discarding Keys and Packet State</a>
+        </h3>
+<p id="section-5.4-1">When packet protection keys are discarded (see Section 4.10 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>),
+all packets that were sent with those keys can no longer be acknowledged because
+their acknowledgements cannot be processed anymore. The sender MUST discard
+all recovery state associated with those packets and MUST remove them from
+the count of bytes in flight.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
+<p id="section-5.4-2">Endpoints stop sending and receiving Initial packets once they start exchanging
+Handshake packets; see Section 17.2.2.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>. At this point,
+recovery state for all in-flight Initial packets is discarded.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
+<p id="section-5.4-3">When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
+discarded.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
+<p id="section-5.4-4">If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
+before Initial packets, early 0-RTT packets will be declared lost, but that
+is expected to be infrequent.<a href="#section-5.4-4" class="pilcrow">¶</a></p>
+<p id="section-5.4-5">It is expected that keys are discarded after packets encrypted with them would
+be acknowledged or declared lost.  Initial secrets however might be destroyed
+sooner, as soon as handshake keys are available; see Section 4.11.1 of
+<span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-5.4-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="congestion-control">
+<section id="section-6">
+      <h2 id="name-congestion-control">
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-congestion-control" class="section-name selfRef">Congestion Control</a>
+      </h2>
+<p id="section-6-1">This document specifies a congestion controller for QUIC similar to
+TCP NewReno <span>[<a href="#RFC6582" class="xref">RFC6582</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
+<p id="section-6-2">The signals QUIC provides for congestion control are generic and are designed to
+support different algorithms. Endpoints can unilaterally choose a different
+algorithm to use, such as Cubic <span>[<a href="#RFC8312" class="xref">RFC8312</a>]</span>.<a href="#section-6-2" class="pilcrow">¶</a></p>
+<p id="section-6-3">If an endpoint uses a different controller than that specified in this document,
+the chosen controller MUST conform to the congestion control guidelines
+specified in Section 3.1 of <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>.<a href="#section-6-3" class="pilcrow">¶</a></p>
+<p id="section-6-4">Similar to TCP, packets containing only ACK frames do not count towards bytes
+in flight and are not congestion controlled.  Unlike TCP, QUIC can detect the
+loss of these packets and MAY use that information to adjust the congestion
+controller or the rate of ACK-only packets being sent, but this document does
+not describe a mechanism for doing so.<a href="#section-6-4" class="pilcrow">¶</a></p>
+<p id="section-6-5">The algorithm in this document specifies and uses the controller's congestion
+window in bytes.<a href="#section-6-5" class="pilcrow">¶</a></p>
+<p id="section-6-6">An endpoint MUST NOT send a packet if it would cause bytes_in_flight (see
+<a href="#vars-of-interest" class="xref">Appendix B.2</a>) to be larger than the congestion window, unless the packet
+is sent on a PTO timer expiration; see <a href="#pto" class="xref">Section 5.2</a>.<a href="#section-6-6" class="pilcrow">¶</a></p>
+<div id="congestion-ecn">
+<section id="section-6.1">
+        <h3 id="name-explicit-congestion-notific">
+<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-explicit-congestion-notific" class="section-name selfRef">Explicit Congestion Notification</a>
+        </h3>
+<p id="section-6.1-1">If a path has been verified to support ECN <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span> <span>[<a href="#RFC8311" class="xref">RFC8311</a>]</span>, QUIC
+treats a Congestion Experienced (CE) codepoint in the IP header as a signal of
+congestion. This document specifies an endpoint's response when its peer
+receives packets with the ECN-CE codepoint.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="initial-cwnd">
+<section id="section-6.2">
+        <h3 id="name-initial-and-minimum-congest">
+<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-initial-and-minimum-congest" class="section-name selfRef">Initial and Minimum Congestion Window</a>
+        </h3>
+<p id="section-6.2-1">QUIC begins every connection in slow start with the congestion window set to
+an initial value.  Endpoints SHOULD use an initial congestion window of 10 times
+the maximum datagram size (max_datagram_size), limited to the larger of 14720 or
+twice the maximum datagram size. This follows the analysis and recommendations
+in <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span>, increasing the byte limit to account for the smaller 8 byte
+overhead of UDP compared to the 20 byte overhead for TCP.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
+<p id="section-6.2-2">Prior to validating the client's address, the server can be further limited by
+the anti-amplification limit as specified in Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.
+Though the anti-amplification limit can prevent the congestion window from
+being fully utilized and therefore slow down the increase in congestion window,
+it does not directly affect the congestion window.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.2-3">The minimum congestion window is the smallest value the congestion window can
+decrease to as a response to loss, ECN-CE, or persistent congestion.
+The RECOMMENDED value is 2 * max_datagram_size.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="slow-start">
+<section id="section-6.3">
+        <h3 id="name-slow-start">
+<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-slow-start" class="section-name selfRef">Slow Start</a>
+        </h3>
+<p id="section-6.3-1">While in slow start, QUIC increases the congestion window by the
+number of bytes acknowledged when each acknowledgment is processed, resulting
+in exponential growth of the congestion window.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
+<p id="section-6.3-2">QUIC exits slow start upon loss or upon increase in the ECN-CE counter.
+When slow start is exited, the congestion window halves and the slow start
+threshold is set to the new congestion window.  QUIC re-enters slow start
+any time the congestion window is less than the slow start threshold,
+which only occurs after persistent congestion is declared.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="congestion-avoidance">
+<section id="section-6.4">
+        <h3 id="name-congestion-avoidance">
+<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-congestion-avoidance" class="section-name selfRef">Congestion Avoidance</a>
+        </h3>
+<p id="section-6.4-1">Slow start exits to congestion avoidance.  Congestion avoidance uses an
+Additive Increase Multiplicative Decrease (AIMD) approach that increases
+the congestion window by one maximum packet size per congestion window
+acknowledged.  When a loss or ECN-CE marking is detected, NewReno halves
+the congestion window, sets the slow start threshold to the new
+congestion window, and then enters the recovery period.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="recovery-period">
+<section id="section-6.5">
+        <h3 id="name-recovery-period">
+<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-recovery-period" class="section-name selfRef">Recovery Period</a>
+        </h3>
+<p id="section-6.5-1">A recovery period is entered when loss or ECN-CE marking of a packet is
+detected in congestion avoidance after the congestion window and slow start
+threshold have been decreased.  A recovery period ends when a packet sent
+during the recovery period is acknowledged.  This is slightly different from
+TCP's definition of recovery, which ends when the lost packet that started
+recovery is acknowledged.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
+<p id="section-6.5-2">The recovery period aims to limit congestion window reduction to once per round
+trip. Therefore during recovery, the congestion window remains unchanged
+irrespective of new losses or increases in the ECN-CE counter.<a href="#section-6.5-2" class="pilcrow">¶</a></p>
+<p id="section-6.5-3">When entering recovery, a single packet MAY be sent even if bytes in flight
+now exceeds the recently reduced congestion window.  This speeds up loss
+recovery if the data in the lost packet is retransmitted and is similar to TCP
+as described in Section 5 of <span>[<a href="#RFC6675" class="xref">RFC6675</a>]</span>.  If further packets are lost while
+the sender is in recovery, sending any packets in response MUST obey the
+congestion window limit.<a href="#section-6.5-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="ignoring-loss-of-undecryptable-packets">
+<section id="section-6.6">
+        <h3 id="name-ignoring-loss-of-undecrypta">
+<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-ignoring-loss-of-undecrypta" class="section-name selfRef">Ignoring Loss of Undecryptable Packets</a>
+        </h3>
+<p id="section-6.6-1">During the handshake, some packet protection keys might not be available when
+a packet arrives and the receiver can choose to drop the packet. In particular,
+Handshake and 0-RTT packets cannot be processed until the Initial packets
+arrive and 1-RTT packets cannot be processed until the handshake completes.
+Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might
+have arrived before the peer had packet protection keys to process those
+packets. Endpoints MUST NOT ignore the loss of packets that were sent after
+the earliest acknowledged packet in a given packet number space.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="probe-timeout">
+<section id="section-6.7">
+        <h3 id="name-probe-timeout-2">
+<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-probe-timeout-2" class="section-name selfRef">Probe Timeout</a>
+        </h3>
+<p id="section-6.7-1">Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST
+however count these packets as being additionally in flight, since these packets
+add network load without establishing packet loss.  Note that sending probe
+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.<a href="#section-6.7-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="persistent-congestion">
+<section id="section-6.8">
+        <h3 id="name-persistent-congestion">
+<a href="#section-6.8" class="section-number selfRef">6.8. </a><a href="#name-persistent-congestion" class="section-name selfRef">Persistent Congestion</a>
+        </h3>
+<p id="section-6.8-1">When an ACK frame is received that establishes loss of all in-flight packets
+sent over a long enough period of time, the network is considered to be
+experiencing persistent congestion.  Commonly, this can be established by
+consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting
+packet is sent, an explicit duration must be used to account for those cases
+where PTOs do not occur or are substantially delayed. 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) <span>[<a href="#RACK" class="xref">RACK</a>]</span>, before establishing persistent
+congestion, as TCP does with a Retransmission Timeout (RTO) <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>.
+The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is
+approximately equivalent to two TLPs before an RTO in TCP.<a href="#section-6.8-1" class="pilcrow">¶</a></p>
+<p id="section-6.8-2">This duration is computed as follows:<a href="#section-6.8-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-6.8-3">
+<pre>
+(smoothed_rtt + 4 * rttvar + max_ack_delay) *
+    kPersistentCongestionThreshold
+</pre><a href="#section-6.8-3" class="pilcrow">¶</a>
+</div>
+<p id="section-6.8-4">For example, assume:<a href="#section-6.8-4" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-6.8-5">
+<pre>
+smoothed_rtt = 1
+rttvar = 0
+max_ack_delay = 0
+kPersistentCongestionThreshold = 3
+</pre><a href="#section-6.8-5" class="pilcrow">¶</a>
+</div>
+<p id="section-6.8-6">If an ack-eliciting packet is sent at time t = 0, the following scenario would
+illustrate persistent congestion:<a href="#section-6.8-6" class="pilcrow">¶</a></p>
+<table class="center" id="table-1">
+          <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Time</th>
+              <th class="text-left" rowspan="1" colspan="1">Action</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">t=0</td>
+              <td class="text-left" rowspan="1" colspan="1">Send Pkt #1 (App Data)</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">t=1</td>
+              <td class="text-left" rowspan="1" colspan="1">Send Pkt #2 (PTO 1)</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">t=3</td>
+              <td class="text-left" rowspan="1" colspan="1">Send Pkt #3 (PTO 2)</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">t=7</td>
+              <td class="text-left" rowspan="1" colspan="1">Send Pkt #4 (PTO 3)</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">t=8</td>
+              <td class="text-left" rowspan="1" colspan="1">Recv ACK of Pkt #4</td>
+            </tr>
+          </tbody>
+        </table>
+<p id="section-6.8-8">The first three packets are determined to be lost when the acknowledgement of
+packet 4 is received at t = 8.  The congestion period is calculated as the time
+between the oldest and newest lost packets: (3 - 0) = 3.  The duration for
+persistent congestion is equal to: (1 * kPersistentCongestionThreshold) = 3.
+Because the threshold was reached and because none of the packets between the
+oldest and the newest packets are acknowledged, the network is considered to
+have experienced persistent congestion.<a href="#section-6.8-8" class="pilcrow">¶</a></p>
+<p id="section-6.8-9">When persistent congestion is established, the sender's congestion 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
+<span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span> after Tail Loss Probes (TLP) <span>[<a href="#RACK" class="xref">RACK</a>]</span>.<a href="#section-6.8-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="pacing">
+<section id="section-6.9">
+        <h3 id="name-pacing">
+<a href="#section-6.9" class="section-number selfRef">6.9. </a><a href="#name-pacing" class="section-name selfRef">Pacing</a>
+        </h3>
+<p id="section-6.9-1">This document does not specify a pacer, but it is RECOMMENDED that a sender pace
+sending of all in-flight packets based on input from the congestion
+controller.  Sending multiple packets into the network without any delay between
+them creates a packet burst that might cause short-term congestion and losses.
+Implementations MUST either use pacing or another method to limit such bursts
+to the initial congestion window; see <a href="#initial-cwnd" class="xref">Section 6.2</a>.<a href="#section-6.9-1" class="pilcrow">¶</a></p>
+<p id="section-6.9-2">An implementation should take care to architect its congestion controller to
+work well with a pacer.  For instance, a pacer might wrap the congestion
+controller and control the availability of the congestion window, or a pacer
+might pace out packets handed to it by the congestion controller.<a href="#section-6.9-2" class="pilcrow">¶</a></p>
+<p id="section-6.9-3">Timely delivery of ACK frames is important for efficient loss recovery. Packets
+containing only ACK frames SHOULD therefore not be paced, to avoid delaying
+their delivery to the peer.<a href="#section-6.9-3" class="pilcrow">¶</a></p>
+<p id="section-6.9-4">Endpoints can implement pacing as they choose. A perfectly paced sender spreads
+packets exactly evenly over time. For a window-based congestion controller, such
+as the one in this document, that rate can be computed by averaging the
+congestion window over the round-trip time. Expressed as a rate in bytes:<a href="#section-6.9-4" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-6.9-5">
+<pre>
+rate = N * congestion_window / smoothed_rtt
+</pre><a href="#section-6.9-5" class="pilcrow">¶</a>
+</div>
+<p id="section-6.9-6">Or, expressed as an inter-packet interval:<a href="#section-6.9-6" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-6.9-7">
+<pre>
+interval = smoothed_rtt * packet_size / congestion_window / N
+</pre><a href="#section-6.9-7" class="pilcrow">¶</a>
+</div>
+<p id="section-6.9-8">Using a value for <code>N</code> that is small, but at least 1 (for example, 1.25) ensures
+that variations in round-trip time don't result in under-utilization of the
+congestion window.  Values of 'N' larger than 1 ultimately result in sending
+packets as acknowledgments are received rather than when timers fire, provided
+the congestion window is fully utilized and acknowledgments arrive at regular
+intervals.<a href="#section-6.9-8" class="pilcrow">¶</a></p>
+<p id="section-6.9-9">Practical considerations, such as packetization, scheduling delays, and
+computational efficiency, can cause a sender to deviate from this rate over time
+periods that are much shorter than a round-trip time.<a href="#section-6.9-9" class="pilcrow">¶</a></p>
+<p id="section-6.9-10">One possible implementation strategy for pacing uses a leaky bucket algorithm,
+where the capacity of the "bucket" is limited to the maximum burst size and the
+rate the "bucket" fills is determined by the above function.<a href="#section-6.9-10" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="under-utilizing-the-congestion-window">
+<section id="section-6.10">
+        <h3 id="name-under-utilizing-the-congest">
+<a href="#section-6.10" class="section-number selfRef">6.10. </a><a href="#name-under-utilizing-the-congest" class="section-name selfRef">Under-utilizing the Congestion Window</a>
+        </h3>
+<p id="section-6.10-1">When bytes in flight is smaller than the congestion window and sending is not
+pacing limited, the congestion window is under-utilized.  When this occurs,
+the congestion window SHOULD NOT be increased in either slow start or
+congestion avoidance. This can happen due to insufficient application data
+or flow control limits.<a href="#section-6.10-1" class="pilcrow">¶</a></p>
+<p id="section-6.10-2">A sender MAY use the pipeACK method described in Section 4.3 of <span>[<a href="#RFC7661" class="xref">RFC7661</a>]</span>
+to determine if the congestion window is sufficiently utilized.<a href="#section-6.10-2" class="pilcrow">¶</a></p>
+<p id="section-6.10-3">A sender that paces packets (see <a href="#pacing" class="xref">Section 6.9</a>) might delay sending packets
+and not fully utilize the congestion window due to this delay. A sender
+SHOULD NOT consider itself application limited if it would have fully
+utilized the congestion window without pacing delay.<a href="#section-6.10-3" class="pilcrow">¶</a></p>
+<p id="section-6.10-4">A sender MAY implement alternative mechanisms to update its congestion window
+after periods of under-utilization, such as those proposed for TCP in
+<span>[<a href="#RFC7661" class="xref">RFC7661</a>]</span>.<a href="#section-6.10-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="security-considerations">
+<section id="section-7">
+      <h2 id="name-security-considerations">
+<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
+      </h2>
+<div id="congestion-signals">
+<section id="section-7.1">
+        <h3 id="name-congestion-signals">
+<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-congestion-signals" class="section-name selfRef">Congestion Signals</a>
+        </h3>
+<p id="section-7.1-1">Congestion control fundamentally involves the consumption of signals - both
+loss and ECN codepoints - from unauthenticated entities.  On-path attackers can
+spoof or alter these signals.  An attacker can cause endpoints to reduce their
+sending rate by dropping packets, or alter send rate by changing ECN codepoints.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="traffic-analysis">
+<section id="section-7.2">
+        <h3 id="name-traffic-analysis">
+<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-traffic-analysis" class="section-name selfRef">Traffic Analysis</a>
+        </h3>
+<p id="section-7.2-1">Packets that carry only ACK frames can be heuristically identified by observing
+packet size.  Acknowledgement patterns may expose information about link
+characteristics or application behavior.  Endpoints can use PADDING frames or
+bundle acknowledgments with other frames to reduce leaked information.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="misreporting-ecn-markings">
+<section id="section-7.3">
+        <h3 id="name-misreporting-ecn-markings">
+<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-misreporting-ecn-markings" class="section-name selfRef">Misreporting ECN Markings</a>
+        </h3>
+<p id="section-7.3-1">A receiver can misreport ECN markings to alter the congestion response of a
+sender.  Suppressing reports of ECN-CE markings could cause a sender to
+increase their send rate.  This increase could result in congestion and loss.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
+<p id="section-7.3-2">A sender MAY attempt to detect suppression of reports by marking occasional
+packets that they send with ECN-CE.  If a packet sent with ECN-CE is not
+reported as having been CE marked when the packet is acknowledged, then the
+sender SHOULD disable ECN for that path.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
+<p id="section-7.3-3">Reporting additional ECN-CE markings will cause a sender to reduce their sending
+rate, which is similar in effect to advertising reduced connection flow control
+limits and so no advantage is gained by doing so.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
+<p id="section-7.3-4">Endpoints choose the congestion controller that they use.  Though congestion
+controllers generally treat reports of ECN-CE markings as equivalent to loss
+<span>[<a href="#RFC8311" class="xref">RFC8311</a>]</span>, the exact response for each controller could be different.  Failure
+to correctly respond to information about ECN markings is therefore difficult to
+detect.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="iana-considerations">
+<section id="section-8">
+      <h2 id="name-iana-considerations">
+<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
+      </h2>
+<p id="section-8-1">This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<section id="section-9">
+      <h2 id="name-references">
+<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
+      </h2>
+<section id="section-9.1">
+        <h3 id="name-normative-references">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
+        </h3>
+<dl class="references">
+<dt id="QUIC-TLS">[QUIC-TLS]</dt>
+<dd>
+<span class="refAuthor">Thomson, M., Ed.</span><span class="refAuthor"> and S. Turner, Ed.</span>, <span class="refTitle">"Using TLS to Secure QUIC"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-tls-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-tls-latest">https://tools.ietf.org/html/draft-ietf-quic-tls-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-TRANSPORT">[QUIC-TRANSPORT]</dt>
+<dd>
+<span class="refAuthor">Iyengar, J., Ed.</span><span class="refAuthor"> and M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-transport-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-transport-latest">https://tools.ietf.org/html/draft-ietf-quic-transport-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2119">[RFC2119]</dt>
+<dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8085">[RFC8085]</dt>
+<dd>
+<span class="refAuthor">Eggert, L.</span><span class="refAuthor">, Fairhurst, G.</span><span class="refAuthor">, and G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8174">[RFC8174]</dt>
+<dd>
+<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+<section id="section-9.2">
+        <h3 id="name-informative-references">
+<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
+        </h3>
+<dl class="references">
+<dt id="FACK">[FACK]</dt>
+<dd>
+<span class="refAuthor">Mathis, M.</span><span class="refAuthor"> and J. Mahdavi</span>, <span class="refTitle">"Forward Acknowledgement: Refining TCP Congestion Control"</span>, <span class="seriesInfo">ACM SIGCOMM </span>, <time datetime="1996-08">August 1996</time>. </dd>
+<dd class="break"></dd>
+<dt id="RACK">[RACK]</dt>
+<dd>
+<span class="refAuthor">Cheng, Y.</span><span class="refAuthor">, Cardwell, N.</span><span class="refAuthor">, Dukkipati, N.</span><span class="refAuthor">, and P. Jha</span>, <span class="refTitle">"RACK: a time-based fast loss detection algorithm for TCP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tcpm-rack-08</span>, <time datetime="2020-03-09">9 March 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-08.txt">http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-08.txt</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC3168">[RFC3168]</dt>
+<dd>
+<span class="refAuthor">Ramakrishnan, K.</span><span class="refAuthor">, Floyd, S.</span><span class="refAuthor">, and D. Black</span>, <span class="refTitle">"The Addition of Explicit Congestion Notification (ECN) to IP"</span>, <span class="seriesInfo">RFC 3168</span>, <span class="seriesInfo">DOI 10.17487/RFC3168</span>, <time datetime="2001-09">September 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3168">https://www.rfc-editor.org/info/rfc3168</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC4653">[RFC4653]</dt>
+<dd>
+<span class="refAuthor">Bhandarkar, S.</span><span class="refAuthor">, Reddy, A. L. N.</span><span class="refAuthor">, Allman, M.</span><span class="refAuthor">, and E. Blanton</span>, <span class="refTitle">"Improving the Robustness of TCP to Non-Congestion Events"</span>, <span class="seriesInfo">RFC 4653</span>, <span class="seriesInfo">DOI 10.17487/RFC4653</span>, <time datetime="2006-08">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4653">https://www.rfc-editor.org/info/rfc4653</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5681">[RFC5681]</dt>
+<dd>
+<span class="refAuthor">Allman, M.</span><span class="refAuthor">, Paxson, V.</span><span class="refAuthor">, and E. Blanton</span>, <span class="refTitle">"TCP Congestion Control"</span>, <span class="seriesInfo">RFC 5681</span>, <span class="seriesInfo">DOI 10.17487/RFC5681</span>, <time datetime="2009-09">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5681">https://www.rfc-editor.org/info/rfc5681</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5682">[RFC5682]</dt>
+<dd>
+<span class="refAuthor">Sarolahti, P.</span><span class="refAuthor">, Kojo, M.</span><span class="refAuthor">, Yamamoto, K.</span><span class="refAuthor">, and M. Hata</span>, <span class="refTitle">"Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP"</span>, <span class="seriesInfo">RFC 5682</span>, <span class="seriesInfo">DOI 10.17487/RFC5682</span>, <time datetime="2009-09">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5682">https://www.rfc-editor.org/info/rfc5682</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5827">[RFC5827]</dt>
+<dd>
+<span class="refAuthor">Allman, M.</span><span class="refAuthor">, Avrachenkov, K.</span><span class="refAuthor">, Ayesta, U.</span><span class="refAuthor">, Blanton, J.</span><span class="refAuthor">, and P. Hurtig</span>, <span class="refTitle">"Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)"</span>, <span class="seriesInfo">RFC 5827</span>, <span class="seriesInfo">DOI 10.17487/RFC5827</span>, <time datetime="2010-05">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5827">https://www.rfc-editor.org/info/rfc5827</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6298">[RFC6298]</dt>
+<dd>
+<span class="refAuthor">Paxson, V.</span><span class="refAuthor">, Allman, M.</span><span class="refAuthor">, Chu, J.</span><span class="refAuthor">, and M. Sargent</span>, <span class="refTitle">"Computing TCP's Retransmission Timer"</span>, <span class="seriesInfo">RFC 6298</span>, <span class="seriesInfo">DOI 10.17487/RFC6298</span>, <time datetime="2011-06">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6298">https://www.rfc-editor.org/info/rfc6298</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6582">[RFC6582]</dt>
+<dd>
+<span class="refAuthor">Henderson, T.</span><span class="refAuthor">, Floyd, S.</span><span class="refAuthor">, Gurtov, A.</span><span class="refAuthor">, and Y. Nishida</span>, <span class="refTitle">"The NewReno Modification to TCP's Fast Recovery Algorithm"</span>, <span class="seriesInfo">RFC 6582</span>, <span class="seriesInfo">DOI 10.17487/RFC6582</span>, <time datetime="2012-04">April 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6582">https://www.rfc-editor.org/info/rfc6582</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6675">[RFC6675]</dt>
+<dd>
+<span class="refAuthor">Blanton, E.</span><span class="refAuthor">, Allman, M.</span><span class="refAuthor">, Wang, L.</span><span class="refAuthor">, Jarvinen, I.</span><span class="refAuthor">, Kojo, M.</span><span class="refAuthor">, and Y. Nishida</span>, <span class="refTitle">"A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP"</span>, <span class="seriesInfo">RFC 6675</span>, <span class="seriesInfo">DOI 10.17487/RFC6675</span>, <time datetime="2012-08">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6675">https://www.rfc-editor.org/info/rfc6675</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6928">[RFC6928]</dt>
+<dd>
+<span class="refAuthor">Chu, J.</span><span class="refAuthor">, Dukkipati, N.</span><span class="refAuthor">, Cheng, Y.</span><span class="refAuthor">, and M. Mathis</span>, <span class="refTitle">"Increasing TCP's Initial Window"</span>, <span class="seriesInfo">RFC 6928</span>, <span class="seriesInfo">DOI 10.17487/RFC6928</span>, <time datetime="2013-04">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6928">https://www.rfc-editor.org/info/rfc6928</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC7661">[RFC7661]</dt>
+<dd>
+<span class="refAuthor">Fairhurst, G.</span><span class="refAuthor">, Sathiaseelan, A.</span><span class="refAuthor">, and R. Secchi</span>, <span class="refTitle">"Updating TCP to Support Rate-Limited Traffic"</span>, <span class="seriesInfo">RFC 7661</span>, <span class="seriesInfo">DOI 10.17487/RFC7661</span>, <time datetime="2015-10">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7661">https://www.rfc-editor.org/info/rfc7661</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8311">[RFC8311]</dt>
+<dd>
+<span class="refAuthor">Black, D.</span>, <span class="refTitle">"Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation"</span>, <span class="seriesInfo">RFC 8311</span>, <span class="seriesInfo">DOI 10.17487/RFC8311</span>, <time datetime="2018-01">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8311">https://www.rfc-editor.org/info/rfc8311</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8312">[RFC8312]</dt>
+<dd>
+<span class="refAuthor">Rhee, I.</span><span class="refAuthor">, Xu, L.</span><span class="refAuthor">, Ha, S.</span><span class="refAuthor">, Zimmermann, A.</span><span class="refAuthor">, Eggert, L.</span><span class="refAuthor">, and R. Scheffenegger</span>, <span class="refTitle">"CUBIC for Fast Long-Distance Networks"</span>, <span class="seriesInfo">RFC 8312</span>, <span class="seriesInfo">DOI 10.17487/RFC8312</span>, <time datetime="2018-02">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8312">https://www.rfc-editor.org/info/rfc8312</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</section>
+<div id="loss-recovery-pseudocode">
+<section id="section-appendix.a">
+      <h2 id="name-loss-recovery-pseudocode">
+<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-loss-recovery-pseudocode" class="section-name selfRef">Loss Recovery Pseudocode</a>
+      </h2>
+<p id="section-appendix.a-1">We now describe an example implementation of the loss detection mechanisms
+described in <a href="#loss-detection" class="xref">Section 5</a>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
+<div id="tracking-sent-packets">
+<section id="section-a.1">
+        <h2 id="name-tracking-sent-packets">
+<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-tracking-sent-packets" class="section-name selfRef">Tracking Sent Packets</a>
+        </h2>
+<p id="section-a.1-1">To correctly implement congestion control, a QUIC sender tracks every
+ack-eliciting packet until the packet is acknowledged or lost.
+It is expected that implementations will be able to access this information by
+packet number and crypto context and store the per-packet fields
+(<a href="#sent-packets-fields" class="xref">Appendix A.1.1</a>) for loss recovery and congestion control.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
+<p id="section-a.1-2">After a packet is declared lost, the endpoint can track it for an amount of
+time comparable to the maximum expected packet reordering, such as 1 RTT.
+This allows for detection of spurious retransmissions.<a href="#section-a.1-2" class="pilcrow">¶</a></p>
+<p id="section-a.1-3">Sent packets are tracked for each packet number space, and ACK
+processing only applies to a single space.<a href="#section-a.1-3" class="pilcrow">¶</a></p>
+<div id="sent-packets-fields">
+<section id="section-a.1.1">
+          <h3 id="name-sent-packet-fields">
+<a href="#section-a.1.1" class="section-number selfRef">A.1.1. </a><a href="#name-sent-packet-fields" class="section-name selfRef">Sent Packet Fields</a>
+          </h3>
+<dl class="dlParallel" id="section-a.1.1-1">
+            <dt id="section-a.1.1-1.1">packet_number:</dt>
+<dd id="section-a.1.1-1.2">
+  The packet number of the sent packet.<a href="#section-a.1.1-1.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.1.1-1.3">ack_eliciting:</dt>
+<dd id="section-a.1.1-1.4">
+  A boolean that indicates whether a packet is ack-eliciting.
+If true, it is expected that an acknowledgement will be received,
+though the peer could delay sending the ACK frame containing it
+by up to the MaxAckDelay.<a href="#section-a.1.1-1.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.1.1-1.5">in_flight:</dt>
+<dd id="section-a.1.1-1.6">
+  A boolean that indicates whether the packet counts towards bytes in
+flight.<a href="#section-a.1.1-1.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.1.1-1.7">sent_bytes:</dt>
+<dd id="section-a.1.1-1.8">
+  The number of bytes sent in the packet, not including UDP or IP
+overhead, but including QUIC framing overhead.<a href="#section-a.1.1-1.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.1.1-1.9">time_sent:</dt>
+<dd id="section-a.1.1-1.10">
+  The time the packet was sent.<a href="#section-a.1.1-1.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+</section>
+</div>
+<div id="constants-of-interest">
+<section id="section-a.2">
+        <h2 id="name-constants-of-interest">
+<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-constants-of-interest" class="section-name selfRef">Constants of Interest</a>
+        </h2>
+<p id="section-a.2-1">Constants used in loss recovery are based on a combination of RFCs, papers, and
+common practice.<a href="#section-a.2-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-a.2-2">
+          <dt id="section-a.2-2.1">kPacketThreshold:</dt>
+<dd id="section-a.2-2.2">
+  Maximum reordering in packets before packet threshold loss detection
+considers a packet lost. The value recommended in <a href="#packet-threshold" class="xref">Section 5.1.1</a> is 3.<a href="#section-a.2-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2-2.3">kTimeThreshold:</dt>
+<dd id="section-a.2-2.4">
+  Maximum reordering in time before time threshold loss detection
+considers a packet lost. Specified as an RTT multiplier. The value
+recommended in <a href="#time-threshold" class="xref">Section 5.1.2</a> is 9/8.<a href="#section-a.2-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2-2.5">kGranularity:</dt>
+<dd id="section-a.2-2.6">
+  Timer granularity. This is a system-dependent value, and <a href="#time-threshold" class="xref">Section 5.1.2</a>
+recommends a value of 1ms.<a href="#section-a.2-2.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2-2.7">kInitialRtt:</dt>
+<dd id="section-a.2-2.8">
+  The RTT used before an RTT sample is taken. The value recommended in
+<a href="#pto-handshake" class="xref">Section 5.2.2</a> is 500ms.<a href="#section-a.2-2.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.2-2.9">kPacketNumberSpace:</dt>
+<dd id="section-a.2-2.10">
+  An enum to enumerate the three packet number spaces.<a href="#section-a.2-2.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<div class="artwork art-text alignLeft" id="section-a.2-3">
+<pre>
+  enum kPacketNumberSpace {
+    Initial,
+    Handshake,
+    ApplicationData,
+  }
+</pre><a href="#section-a.2-3" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="ld-vars-of-interest">
+<section id="section-a.3">
+        <h2 id="name-variables-of-interest">
+<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-variables-of-interest" class="section-name selfRef">Variables of interest</a>
+        </h2>
+<p id="section-a.3-1">Variables required to implement the congestion control mechanisms
+are described in this section.<a href="#section-a.3-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-a.3-2">
+          <dt id="section-a.3-2.1">latest_rtt:</dt>
+<dd id="section-a.3-2.2">
+  The most recent RTT measurement made when receiving an ack for
+a previously unacked packet.<a href="#section-a.3-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.3">smoothed_rtt:</dt>
+<dd id="section-a.3-2.4">
+  The smoothed RTT of the connection, computed as described in
+<a href="#smoothed-rtt" class="xref">Section 4.3</a>.<a href="#section-a.3-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.5">rttvar:</dt>
+<dd id="section-a.3-2.6">
+  The RTT variation, computed as described in <a href="#smoothed-rtt" class="xref">Section 4.3</a>.<a href="#section-a.3-2.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.7">min_rtt:</dt>
+<dd id="section-a.3-2.8">
+  The minimum RTT seen in the connection, ignoring ack delay, as described
+in <a href="#min-rtt" class="xref">Section 4.2</a>.<a href="#section-a.3-2.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.9">max_ack_delay:</dt>
+<dd id="section-a.3-2.10">
+  The maximum amount of time by which the receiver intends to delay
+acknowledgments for packets in the ApplicationData packet number space. The
+actual ack_delay in a received ACK frame may be larger due to late timers,
+reordering, or lost ACK frames.<a href="#section-a.3-2.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.11">loss_detection_timer:</dt>
+<dd id="section-a.3-2.12">
+  Multi-modal timer used for loss detection.<a href="#section-a.3-2.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.13">pto_count:</dt>
+<dd id="section-a.3-2.14">
+  The number of times a PTO has been sent without receiving an ack.<a href="#section-a.3-2.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.15">time_of_last_ack_eliciting_packet[kPacketNumberSpace]:</dt>
+<dd id="section-a.3-2.16">
+  The time the most recent ack-eliciting packet was sent.<a href="#section-a.3-2.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.17">largest_acked_packet[kPacketNumberSpace]:</dt>
+<dd id="section-a.3-2.18">
+  The largest packet number acknowledged in the packet number space so far.<a href="#section-a.3-2.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.19">loss_time[kPacketNumberSpace]:</dt>
+<dd id="section-a.3-2.20">
+  The time at which the next packet in that packet number space will be
+considered lost based on exceeding the reordering window in time.<a href="#section-a.3-2.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.3-2.21">sent_packets[kPacketNumberSpace]:</dt>
+<dd id="section-a.3-2.22">
+  An association of packet numbers in a packet number space to information
+about them.  Described in detail above in <a href="#tracking-sent-packets" class="xref">Appendix A.1</a>.<a href="#section-a.3-2.22" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="initialization">
+<section id="section-a.4">
+        <h2 id="name-initialization">
+<a href="#section-a.4" class="section-number selfRef">A.4. </a><a href="#name-initialization" class="section-name selfRef">Initialization</a>
+        </h2>
+<p id="section-a.4-1">At the beginning of the connection, initialize the loss detection variables as
+follows:<a href="#section-a.4-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.4-2">
+<pre>
+   loss_detection_timer.reset()
+   pto_count = 0
+   latest_rtt = 0
+   smoothed_rtt = initial_rtt
+   rttvar = initial_rtt / 2
+   min_rtt = 0
+   max_ack_delay = 0
+   for pn_space in [ Initial, Handshake, ApplicationData ]:
+     largest_acked_packet[pn_space] = infinite
+     time_of_last_ack_eliciting_packet[pn_space] = 0
+     loss_time[pn_space] = 0
+</pre><a href="#section-a.4-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="on-sending-a-packet">
+<section id="section-a.5">
+        <h2 id="name-on-sending-a-packet">
+<a href="#section-a.5" class="section-number selfRef">A.5. </a><a href="#name-on-sending-a-packet" class="section-name selfRef">On Sending a Packet</a>
+        </h2>
+<p id="section-a.5-1">After a packet is sent, information about the packet is stored.  The parameters
+to OnPacketSent are described in detail above in <a href="#sent-packets-fields" class="xref">Appendix A.1.1</a>.<a href="#section-a.5-1" class="pilcrow">¶</a></p>
+<p id="section-a.5-2">Pseudocode for OnPacketSent follows:<a href="#section-a.5-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.5-3">
+<pre>
+ OnPacketSent(packet_number, pn_space, ack_eliciting,
+              in_flight, sent_bytes):
+   sent_packets[pn_space][packet_number].packet_number =
+                                            packet_number
+   sent_packets[pn_space][packet_number].time_sent = now()
+   sent_packets[pn_space][packet_number].ack_eliciting =
+                                            ack_eliciting
+   sent_packets[pn_space][packet_number].in_flight = in_flight
+   if (in_flight):
+     if (ack_eliciting):
+       time_of_last_ack_eliciting_packet[pn_space] = now()
+     OnPacketSentCC(sent_bytes)
+     sent_packets[pn_space][packet_number].size = sent_bytes
+     SetLossDetectionTimer()
+</pre><a href="#section-a.5-3" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="on-receiving-a-datagram">
+<section id="section-a.6">
+        <h2 id="name-on-receiving-a-datagram">
+<a href="#section-a.6" class="section-number selfRef">A.6. </a><a href="#name-on-receiving-a-datagram" class="section-name selfRef">On Receiving a Datagram</a>
+        </h2>
+<p id="section-a.6-1">When a server is blocked by anti-amplification limits, receiving
+a datagram unblocks it, even if none of the packets in the
+datagram are successfully processed. In such a case, the PTO
+timer will need to be re-armed.<a href="#section-a.6-1" class="pilcrow">¶</a></p>
+<p id="section-a.6-2">Pseudocode for OnDatagramReceived follows:<a href="#section-a.6-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.6-3">
+<pre>
+OnDatagramReceived(datagram):
+  // If this datagram unblocks the server, arm the
+  // PTO timer to avoid deadlock.
+  if (server was at anti-amplification limit):
+    SetLossDetectionTimer()
+</pre><a href="#section-a.6-3" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="on-receiving-an-acknowledgment">
+<section id="section-a.7">
+        <h2 id="name-on-receiving-an-acknowledgm">
+<a href="#section-a.7" class="section-number selfRef">A.7. </a><a href="#name-on-receiving-an-acknowledgm" class="section-name selfRef">On Receiving an Acknowledgment</a>
+        </h2>
+<p id="section-a.7-1">When an ACK frame is received, it may newly acknowledge any number of packets.<a href="#section-a.7-1" class="pilcrow">¶</a></p>
+<p id="section-a.7-2">Pseudocode for OnAckReceived and UpdateRtt follow:<a href="#section-a.7-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.7-3">
+<pre>
+OnAckReceived(ack, pn_space):
+  if (largest_acked_packet[pn_space] == infinite):
+    largest_acked_packet[pn_space] = ack.largest_acked
+  else:
+    largest_acked_packet[pn_space] =
+        max(largest_acked_packet[pn_space], ack.largest_acked)
+
+  // DetectNewlyAckedPackets finds packets that are newly
+  // acknowledged and removes them from sent_packets.
+  newly_acked_packets =
+      DetectAndRemoveAckedPackets(ack, pn_space)
+  // Nothing to do if there are no newly acked packets.
+  if (newly_acked_packets.empty()):
+    return
+
+  // If the largest acknowledged is newly acked and
+  // at least one ack-eliciting was newly acked, update the RTT.
+  if (newly_acked_packets.largest().packet_number ==
+          ack.largest_acked &amp;&amp;
+      IncludesAckEliciting(newly_acked_packets)):
+    latest_rtt =
+      now - sent_packets[pn_space][ack.largest_acked].time_sent
+    ack_delay = 0
+    if (pn_space == ApplicationData):
+      ack_delay = ack.ack_delay
+    UpdateRtt(ack_delay)
+
+  // Process ECN information if present.
+  if (ACK frame contains ECN information):
+      ProcessECN(ack, pn_space)
+
+  lost_packets = DetectAndRemoveLostPackets(pn_space)
+  if (!lost_packets.empty()):
+    OnPacketsLost(lost_packets)
+  OnPacketsAcked(newly_acked_packets)
+
+  // Reset pto_count unless the client is unsure if
+  // the server has validated the client's address.
+  if (PeerCompletedAddressValidation()):
+    pto_count = 0
+  SetLossDetectionTimer()
+
+
+UpdateRtt(ack_delay):
+  if (is first RTT sample):
+    min_rtt = latest_rtt
+    smoothed_rtt = latest_rtt
+    rttvar = latest_rtt / 2
+    return
+
+  // min_rtt ignores ack delay.
+  min_rtt = min(min_rtt, latest_rtt)
+  // Limit ack_delay by max_ack_delay
+  ack_delay = min(ack_delay, max_ack_delay)
+  // Adjust for ack delay if plausible.
+  adjusted_rtt = latest_rtt
+  if (latest_rtt &gt; min_rtt + ack_delay):
+    adjusted_rtt = latest_rtt - ack_delay
+
+  rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)
+  smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
+</pre><a href="#section-a.7-3" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="setting-the-loss-detection-timer">
+<section id="section-a.8">
+        <h2 id="name-setting-the-loss-detection-">
+<a href="#section-a.8" class="section-number selfRef">A.8. </a><a href="#name-setting-the-loss-detection-" class="section-name selfRef">Setting the Loss Detection Timer</a>
+        </h2>
+<p id="section-a.8-1">QUIC loss detection uses a single timer for all timeout loss detection.  The
+duration of the timer is based on the timer's mode, which is set in the packet
+and timer events further below.  The function SetLossDetectionTimer defined
+below shows how the single timer is set.<a href="#section-a.8-1" class="pilcrow">¶</a></p>
+<p id="section-a.8-2">This algorithm may result in the timer being set in the past, particularly if
+timers wake up late. Timers set in the past fire immediately.<a href="#section-a.8-2" class="pilcrow">¶</a></p>
+<p id="section-a.8-3">Pseudocode for SetLossDetectionTimer follows:<a href="#section-a.8-3" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.8-4">
+<pre>
+GetLossTimeAndSpace():
+  time = loss_time[Initial]
+  space = Initial
+  for pn_space in [ Handshake, ApplicationData ]:
+    if (time == 0 || loss_time[pn_space] &lt; time):
+      time = loss_time[pn_space];
+      space = pn_space
+  return time, space
+
+GetPtoTimeAndSpace():
+  duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
+      * (2 ^ pto_count)
+  // Arm PTO from now when there are no inflight packets.
+  if (no in-flight packets):
+    assert(!PeerCompletedAddressValidation())
+    if (has handshake keys):
+      return (now() + duration), Handshake
+    else:
+      return (now() + duration), Initial
+  pto_timeout = infinite
+  pto_space = Initial
+  for space in [ Initial, Handshake, ApplicationData ]:
+    if (no in-flight packets in space):
+        continue;
+    if (space == ApplicationData):
+      // Skip ApplicationData until handshake complete.
+      if (handshake is not complete):
+        return pto_timeout, pto_space
+      // Include max_ack_delay and backoff for ApplicationData.
+      duration += max_ack_delay * (2 ^ pto_count)
+
+    t = time_of_last_ack_eliciting_packet[space] + duration
+    if (t &lt; pto_timeout):
+      pto_timeout = t
+      pto_space = space
+  return pto_timeout, pto_space
+
+PeerCompletedAddressValidation():
+  # Assume clients validate the server's address implicitly.
+  if (endpoint is server):
+    return true
+  # Servers complete address validation when a
+  # protected packet is received.
+  return has received Handshake ACK ||
+       has received 1-RTT ACK ||
+       has received HANDSHAKE_DONE
+
+SetLossDetectionTimer():
+  earliest_loss_time, _ = GetLossTimeAndSpace()
+  if (earliest_loss_time != 0):
+    // Time threshold loss detection.
+    loss_detection_timer.update(earliest_loss_time)
+    return
+
+  if (server is at anti-amplification limit):
+    // The server's timer is not set if nothing can be sent.
+    loss_detection_timer.cancel()
+    return
+
+  if (no ack-eliciting packets in flight &amp;&amp;
+      PeerCompletedAddressValidation()):
+    // There is nothing to detect lost, so no timer is set.
+    // However, the client needs to arm the timer if the
+    // server might be blocked by the anti-amplification limit.
+    loss_detection_timer.cancel()
+    return
+
+  // Determine which PN space to arm PTO for.
+  timeout, _ = GetPtoTimeAndSpace()
+  loss_detection_timer.update(timeout)
+</pre><a href="#section-a.8-4" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="on-timeout">
+<section id="section-a.9">
+        <h2 id="name-on-timeout">
+<a href="#section-a.9" class="section-number selfRef">A.9. </a><a href="#name-on-timeout" class="section-name selfRef">On Timeout</a>
+        </h2>
+<p id="section-a.9-1">When the loss detection timer expires, the timer's mode determines the action
+to be performed.<a href="#section-a.9-1" class="pilcrow">¶</a></p>
+<p id="section-a.9-2">Pseudocode for OnLossDetectionTimeout follows:<a href="#section-a.9-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.9-3">
+<pre>
+OnLossDetectionTimeout():
+  earliest_loss_time, pn_space = GetLossTimeAndSpace()
+  if (earliest_loss_time != 0):
+    // Time threshold loss Detection
+    lost_packets = DetectLostPackets(pn_space)
+    assert(!lost_packets.empty())
+    OnPacketsLost(lost_packets)
+    SetLossDetectionTimer()
+    return
+
+  if (bytes_in_flight &gt; 0):
+    // PTO. Send new data if available, else retransmit old data.
+    // If neither is available, send a single PING frame.
+    _, pn_space = GetPtoTimeAndSpace()
+    SendOneOrTwoAckElicitingPackets(pn_space)
+  else:
+    assert(endpoint is client without 1-RTT keys)
+    // Client sends an anti-deadlock packet: Initial is padded
+    // to earn more anti-amplification credit,
+    // a Handshake packet proves address ownership.
+    if (has Handshake keys):
+      SendOneAckElicitingHandshakePacket()
+    else:
+      SendOneAckElicitingPaddedInitialPacket()
+
+  pto_count++
+  SetLossDetectionTimer()
+</pre><a href="#section-a.9-3" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="detecting-lost-packets">
+<section id="section-a.10">
+        <h2 id="name-detecting-lost-packets">
+<a href="#section-a.10" class="section-number selfRef">A.10. </a><a href="#name-detecting-lost-packets" class="section-name selfRef">Detecting Lost Packets</a>
+        </h2>
+<p id="section-a.10-1">DetectAndRemoveLostPackets is called every time an ACK is received or the time
+threshold loss detection timer expires. This function operates on the
+sent_packets for that packet number space and returns a list of packets newly
+detected as lost.<a href="#section-a.10-1" class="pilcrow">¶</a></p>
+<p id="section-a.10-2">Pseudocode for DetectAndRemoveLostPackets follows:<a href="#section-a.10-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.10-3">
+<pre>
+DetectAndRemoveLostPackets(pn_space):
+  assert(largest_acked_packet[pn_space] != infinite)
+  loss_time[pn_space] = 0
+  lost_packets = {}
+  loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)
+
+  // Minimum time of kGranularity before packets are deemed lost.
+  loss_delay = max(loss_delay, kGranularity)
+
+  // Packets sent before this time are deemed lost.
+  lost_send_time = now() - loss_delay
+
+  foreach unacked in sent_packets[pn_space]:
+    if (unacked.packet_number &gt; largest_acked_packet[pn_space]):
+      continue
+
+    // Mark packet as lost, or set time when it should be marked.
+    if (unacked.time_sent &lt;= lost_send_time ||
+        largest_acked_packet[pn_space] &gt;=
+          unacked.packet_number + kPacketThreshold):
+      sent_packets[pn_space].remove(unacked.packet_number)
+      if (unacked.in_flight):
+        lost_packets.insert(unacked)
+    else:
+      if (loss_time[pn_space] == 0):
+        loss_time[pn_space] = unacked.time_sent + loss_delay
+      else:
+        loss_time[pn_space] = min(loss_time[pn_space],
+                                  unacked.time_sent + loss_delay)
+  return lost_packets
+</pre><a href="#section-a.10-3" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="congestion-control-pseudocode">
+<section id="section-appendix.b">
+      <h2 id="name-congestion-control-pseudoco">
+<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-congestion-control-pseudoco" class="section-name selfRef">Congestion Control Pseudocode</a>
+      </h2>
+<p id="section-appendix.b-1">We now describe an example implementation of the congestion controller described
+in <a href="#congestion-control" class="xref">Section 6</a>.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
+<div id="cc-consts-of-interest">
+<section id="section-b.1">
+        <h2 id="name-constants-of-interest-2">
+<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-constants-of-interest-2" class="section-name selfRef">Constants of interest</a>
+        </h2>
+<p id="section-b.1-1">Constants used in congestion control are based on a combination of RFCs, papers,
+and common practice.<a href="#section-b.1-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-b.1-2">
+          <dt id="section-b.1-2.1">kInitialWindow:</dt>
+<dd id="section-b.1-2.2">
+  Default limit on the initial bytes in flight as described in <a href="#initial-cwnd" class="xref">Section 6.2</a>.<a href="#section-b.1-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-b.1-2.3">kMinimumWindow:</dt>
+<dd id="section-b.1-2.4">
+  Minimum congestion window in bytes as described in <a href="#initial-cwnd" class="xref">Section 6.2</a>.<a href="#section-b.1-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-b.1-2.5">kLossReductionFactor:</dt>
+<dd id="section-b.1-2.6">
+  Reduction in congestion window when a new loss event is detected.
+The <a href="#congestion-control" class="xref">Section 6</a> section recommends a value is 0.5.<a href="#section-b.1-2.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-b.1-2.7">kPersistentCongestionThreshold:</dt>
+<dd id="section-b.1-2.8">
+  Period of time for persistent congestion to be established, specified
+as a PTO multiplier. The <a href="#persistent-congestion" class="xref">Section 6.8</a> section recommends a
+value of 3.<a href="#section-b.1-2.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="vars-of-interest">
+<section id="section-b.2">
+        <h2 id="name-variables-of-interest-2">
+<a href="#section-b.2" class="section-number selfRef">B.2. </a><a href="#name-variables-of-interest-2" class="section-name selfRef">Variables of interest</a>
+        </h2>
+<p id="section-b.2-1">Variables required to implement the congestion control mechanisms
+are described in this section.<a href="#section-b.2-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-b.2-2">
+          <dt id="section-b.2-2.1">max_datagram_size:</dt>
+<dd id="section-b.2-2.2">
+  The sender's current maximum payload size. Does not include UDP or IP
+overhead.  The max datagram size is used for congestion window
+computations. An endpoint sets the value of this variable based on its
+PMTU (see Section 14.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>), with a minimum value of
+1200 bytes.<a href="#section-b.2-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-b.2-2.3">ecn_ce_counters[kPacketNumberSpace]:</dt>
+<dd id="section-b.2-2.4">
+  The highest value reported for the ECN-CE counter in the packet number space
+by the peer in an ACK frame. This value is used to detect increases in the
+reported ECN-CE counter.<a href="#section-b.2-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-b.2-2.5">bytes_in_flight:</dt>
+<dd id="section-b.2-2.6">
+  The sum of the size in bytes of all sent packets that contain at least one
+ack-eliciting or PADDING frame, and have not been acked or declared
+lost. The size does not include IP or UDP overhead, but does include the QUIC
+header and AEAD overhead.  Packets only containing ACK frames do not count
+towards bytes_in_flight to ensure congestion control does not impede
+congestion feedback.<a href="#section-b.2-2.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-b.2-2.7">congestion_window:</dt>
+<dd id="section-b.2-2.8">
+  Maximum number of bytes-in-flight that may be sent.<a href="#section-b.2-2.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-b.2-2.9">congestion_recovery_start_time:</dt>
+<dd id="section-b.2-2.10">
+  The time when QUIC first detects congestion due to loss or ECN, causing
+it to enter congestion recovery. When a packet sent after this time is
+acknowledged, QUIC exits congestion recovery.<a href="#section-b.2-2.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-b.2-2.11">ssthresh:</dt>
+<dd id="section-b.2-2.12">
+  Slow start threshold in bytes.  When the congestion window is below ssthresh,
+the mode is slow start and the window grows by the number of bytes
+acknowledged.<a href="#section-b.2-2.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="initialization-1">
+<section id="section-b.3">
+        <h2 id="name-initialization-2">
+<a href="#section-b.3" class="section-number selfRef">B.3. </a><a href="#name-initialization-2" class="section-name selfRef">Initialization</a>
+        </h2>
+<p id="section-b.3-1">At the beginning of the connection, initialize the congestion control
+variables as follows:<a href="#section-b.3-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-b.3-2">
+<pre>
+   congestion_window = kInitialWindow
+   bytes_in_flight = 0
+   congestion_recovery_start_time = 0
+   ssthresh = infinite
+   for pn_space in [ Initial, Handshake, ApplicationData ]:
+     ecn_ce_counters[pn_space] = 0
+</pre><a href="#section-b.3-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="on-packet-sent">
+<section id="section-b.4">
+        <h2 id="name-on-packet-sent">
+<a href="#section-b.4" class="section-number selfRef">B.4. </a><a href="#name-on-packet-sent" class="section-name selfRef">On Packet Sent</a>
+        </h2>
+<p id="section-b.4-1">Whenever a packet is sent, and it contains non-ACK frames, the packet
+increases bytes_in_flight.<a href="#section-b.4-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-b.4-2">
+<pre>
+   OnPacketSentCC(bytes_sent):
+     bytes_in_flight += bytes_sent
+</pre><a href="#section-b.4-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="on-packet-acknowledgement">
+<section id="section-b.5">
+        <h2 id="name-on-packet-acknowledgement">
+<a href="#section-b.5" class="section-number selfRef">B.5. </a><a href="#name-on-packet-acknowledgement" class="section-name selfRef">On Packet Acknowledgement</a>
+        </h2>
+<p id="section-b.5-1">Invoked from loss detection's OnAckReceived and is supplied with the
+newly acked_packets from sent_packets.<a href="#section-b.5-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-b.5-2">
+<pre>
+   InCongestionRecovery(sent_time):
+     return sent_time &lt;= congestion_recovery_start_time
+
+   OnPacketsAcked(acked_packets):
+     for (packet in acked_packets):
+       // Remove from bytes_in_flight.
+       bytes_in_flight -= packet.size
+       if (InCongestionRecovery(packet.time_sent)):
+         // Do not increase congestion window in recovery period.
+         return
+       if (IsAppOrFlowControlLimited()):
+         // Do not increase congestion_window if application
+         // limited or flow control limited.
+         return
+       if (congestion_window &lt; ssthresh):
+         // Slow start.
+         congestion_window += packet.size
+         return
+       // Congestion avoidance.
+       congestion_window += max_datagram_size * acked_packet.size
+           / congestion_window
+</pre><a href="#section-b.5-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="on-new-congestion-event">
+<section id="section-b.6">
+        <h2 id="name-on-new-congestion-event">
+<a href="#section-b.6" class="section-number selfRef">B.6. </a><a href="#name-on-new-congestion-event" class="section-name selfRef">On New Congestion Event</a>
+        </h2>
+<p id="section-b.6-1">Invoked from ProcessECN and OnPacketsLost when a new congestion event is
+detected. May start a new recovery period and reduces the congestion
+window.<a href="#section-b.6-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-b.6-2">
+<pre>
+   CongestionEvent(sent_time):
+     // Start a new congestion event if packet was sent after the
+     // start of the previous congestion recovery period.
+     if (!InCongestionRecovery(sent_time)):
+       congestion_recovery_start_time = now()
+       congestion_window *= kLossReductionFactor
+       congestion_window = max(congestion_window, kMinimumWindow)
+       ssthresh = congestion_window
+       // A packet can be sent to speed up loss recovery.
+       MaybeSendOnePacket()
+</pre><a href="#section-b.6-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="process-ecn-information">
+<section id="section-b.7">
+        <h2 id="name-process-ecn-information">
+<a href="#section-b.7" class="section-number selfRef">B.7. </a><a href="#name-process-ecn-information" class="section-name selfRef">Process ECN Information</a>
+        </h2>
+<p id="section-b.7-1">Invoked when an ACK frame with an ECN section is received from the peer.<a href="#section-b.7-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-b.7-2">
+<pre>
+   ProcessECN(ack, pn_space):
+     // If the ECN-CE counter reported by the peer has increased,
+     // this could be a new congestion event.
+     if (ack.ce_counter &gt; ecn_ce_counters[pn_space]):
+       ecn_ce_counters[pn_space] = ack.ce_counter
+       CongestionEvent(sent_packets[ack.largest_acked].time_sent)
+</pre><a href="#section-b.7-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="on-packets-lost">
+<section id="section-b.8">
+        <h2 id="name-on-packets-lost">
+<a href="#section-b.8" class="section-number selfRef">B.8. </a><a href="#name-on-packets-lost" class="section-name selfRef">On Packets Lost</a>
+        </h2>
+<p id="section-b.8-1">Invoked from DetectLostPackets when packets are deemed lost.<a href="#section-b.8-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-b.8-2">
+<pre>
+   InPersistentCongestion(lost_packets):
+     pto = smoothed_rtt + max(4 * rttvar, kGranularity) +
+       max_ack_delay
+     congestion_period = pto * kPersistentCongestionThreshold
+     // Determine if all packets in the time period before the
+     // largest newly lost packet, including the edges, are
+     // marked lost
+     return AreAllPacketsLost(lost_packets, congestion_period)
+
+   OnPacketsLost(lost_packets):
+     // Remove lost packets from bytes_in_flight.
+     for (lost_packet : lost_packets):
+       bytes_in_flight -= lost_packet.size
+     CongestionEvent(lost_packets.largest().time_sent)
+
+     // Collapse congestion window if persistent congestion
+     if (InPersistentCongestion(lost_packets)):
+       congestion_window = kMinimumWindow
+</pre><a href="#section-b.8-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="upon-dropping-initial-or-handshake-keys">
+<section id="section-b.9">
+        <h2 id="name-upon-dropping-initial-or-ha">
+<a href="#section-b.9" class="section-number selfRef">B.9. </a><a href="#name-upon-dropping-initial-or-ha" class="section-name selfRef">Upon dropping Initial or Handshake keys</a>
+        </h2>
+<p id="section-b.9-1">When Initial or Handshake keys are discarded, packets from the space
+are discarded and loss detection state is updated.<a href="#section-b.9-1" class="pilcrow">¶</a></p>
+<p id="section-b.9-2">Pseudocode for OnPacketNumberSpaceDiscarded follows:<a href="#section-b.9-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-b.9-3">
+<pre>
+OnPacketNumberSpaceDiscarded(pn_space):
+  assert(pn_space != ApplicationData)
+  // Remove any unacknowledged packets from flight.
+  foreach packet in sent_packets[pn_space]:
+    if packet.in_flight
+      bytes_in_flight -= size
+  sent_packets[pn_space].clear()
+  // Reset the loss detection and PTO timer
+  time_of_last_ack_eliciting_packet[pn_space] = 0
+  loss_time[pn_space] = 0
+  pto_count = 0
+  SetLossDetectionTimer()
+</pre><a href="#section-b.9-3" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="change-log">
+<section id="section-appendix.c">
+      <h2 id="name-change-log">
+<a href="#section-appendix.c" class="section-number selfRef">Appendix C. </a><a href="#name-change-log" class="section-name selfRef">Change Log</a>
+      </h2>
+<ul class="normal ulEmpty">
+<li class="normal ulEmpty" id="section-appendix.c-1.1">
+          <strong>RFC Editor's Note:</strong>  Please remove this section prior to
+publication of a final version of this document.<a href="#section-appendix.c-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-appendix.c-2">Issue and pull request numbers are listed with a leading octothorp.<a href="#section-appendix.c-2" class="pilcrow">¶</a></p>
+<div id="since-draft-ietf-quic-recovery-27">
+<section id="section-c.1">
+        <h2 id="name-since-draft-ietf-quic-recov">
+<a href="#section-c.1" class="section-number selfRef">C.1. </a><a href="#name-since-draft-ietf-quic-recov" class="section-name selfRef">Since draft-ietf-quic-recovery-27</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.1-1.1">Added recommendations for speeding up handshake under some loss conditions
+(#3078, #3080)<a href="#section-c.1-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.2">PTO count is reset when handshake progress is made (#3272, #3415)<a href="#section-c.1-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.3">PTO count is not reset by a client when the server might be awaiting
+address validation (#3546, #3551)<a href="#section-c.1-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.4">Recommend repairing losses immediately after entering the recovery period
+(#3335, #3443)<a href="#section-c.1-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.5">Clarified what loss conditions can be ignored during the handshake (#3456,
+#3450)<a href="#section-c.1-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.6">Allow, but don't recommend, using RTT from previous connection to seed RTT
+(#3464, #3496)<a href="#section-c.1-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.7">Recommend use of adaptive loss detection thresholds (#3571, #3572)<a href="#section-c.1-1.7" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-26">
+<section id="section-c.2">
+        <h2 id="name-since-draft-ietf-quic-recove">
+<a href="#section-c.2" class="section-number selfRef">C.2. </a><a href="#name-since-draft-ietf-quic-recove" class="section-name selfRef">Since draft-ietf-quic-recovery-26</a>
+        </h2>
+<p id="section-c.2-1">No changes.<a href="#section-c.2-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-25">
+<section id="section-c.3">
+        <h2 id="name-since-draft-ietf-quic-recover">
+<a href="#section-c.3" class="section-number selfRef">C.3. </a><a href="#name-since-draft-ietf-quic-recover" class="section-name selfRef">Since draft-ietf-quic-recovery-25</a>
+        </h2>
+<p id="section-c.3-1">No significant changes.<a href="#section-c.3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-24">
+<section id="section-c.4">
+        <h2 id="name-since-draft-ietf-quic-recovery">
+<a href="#section-c.4" class="section-number selfRef">C.4. </a><a href="#name-since-draft-ietf-quic-recovery" class="section-name selfRef">Since draft-ietf-quic-recovery-24</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.4-1.1">Require congestion control of some sort (#3247, #3244, #3248)<a href="#section-c.4-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.2">Set a minimum reordering threshold (#3256, #3240)<a href="#section-c.4-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.3">PTO is specific to a packet number space (#3067, #3074, #3066)<a href="#section-c.4-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-23">
+<section id="section-c.5">
+        <h2 id="name-since-draft-ietf-quic-recovery-">
+<a href="#section-c.5" class="section-number selfRef">C.5. </a><a href="#name-since-draft-ietf-quic-recovery-" class="section-name selfRef">Since draft-ietf-quic-recovery-23</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.5-1.1">Define under-utilizing the congestion window (#2630, #2686, #2675)<a href="#section-c.5-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.2">PTO MUST send data if possible (#3056, #3057)<a href="#section-c.5-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.3">Connection Close is not ack-eliciting (#3097, #3098)<a href="#section-c.5-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.4">MUST limit bursts to the initial congestion window (#3160)<a href="#section-c.5-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.5">Define the current max_datagram_size for congestion control
+(#3041, #3167)<a href="#section-c.5-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-22">
+<section id="section-c.6">
+        <h2 id="name-since-draft-ietf-quic-recovery-2">
+<a href="#section-c.6" class="section-number selfRef">C.6. </a><a href="#name-since-draft-ietf-quic-recovery-2" class="section-name selfRef">Since draft-ietf-quic-recovery-22</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.6-1.1">PTO should always send an ack-eliciting packet (#2895)<a href="#section-c.6-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.2">Unify the Handshake Timer with the PTO timer (#2648, #2658, #2886)<a href="#section-c.6-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.3">Move ACK generation text to transport draft (#1860, #2916)<a href="#section-c.6-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-21">
+<section id="section-c.7">
+        <h2 id="name-since-draft-ietf-quic-recovery-21">
+<a href="#section-c.7" class="section-number selfRef">C.7. </a><a href="#name-since-draft-ietf-quic-recovery-21" class="section-name selfRef">Since draft-ietf-quic-recovery-21</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.7-1.1">No changes<a href="#section-c.7-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-20">
+<section id="section-c.8">
+        <h2 id="name-since-draft-ietf-quic-recovery-20">
+<a href="#section-c.8" class="section-number selfRef">C.8. </a><a href="#name-since-draft-ietf-quic-recovery-20" class="section-name selfRef">Since draft-ietf-quic-recovery-20</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.8-1.1">Path validation can be used as initial RTT value (#2644, #2687)<a href="#section-c.8-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.2">max_ack_delay transport parameter defaults to 0 (#2638, #2646)<a href="#section-c.8-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.3">Ack Delay only measures intentional delays induced by the implementation
+(#2596, #2786)<a href="#section-c.8-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-19">
+<section id="section-c.9">
+        <h2 id="name-since-draft-ietf-quic-recovery-1">
+<a href="#section-c.9" class="section-number selfRef">C.9. </a><a href="#name-since-draft-ietf-quic-recovery-1" class="section-name selfRef">Since draft-ietf-quic-recovery-19</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.9-1.1">Change kPersistentThreshold from an exponent to a multiplier (#2557)<a href="#section-c.9-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.2">Send a PING if the PTO timer fires and there's nothing to send (#2624)<a href="#section-c.9-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.3">Set loss delay to at least kGranularity (#2617)<a href="#section-c.9-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.4">Merge application limited and sending after idle sections. Always limit
+burst size instead of requiring resetting CWND to initial CWND after
+idle (#2605)<a href="#section-c.9-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.5">Rewrite RTT estimation, allow RTT samples where a newly acked packet is
+ack-eliciting but the largest_acked is not (#2592)<a href="#section-c.9-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.6">Don't arm the handshake timer if there is no handshake data (#2590)<a href="#section-c.9-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.7">Clarify that the time threshold loss alarm takes precedence over the
+crypto handshake timer (#2590, #2620)<a href="#section-c.9-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.8">Change initial RTT to 500ms to align with RFC6298 (#2184)<a href="#section-c.9-1.8" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-18">
+<section id="section-c.10">
+        <h2 id="name-since-draft-ietf-quic-recovery-18">
+<a href="#section-c.10" class="section-number selfRef">C.10. </a><a href="#name-since-draft-ietf-quic-recovery-18" class="section-name selfRef">Since draft-ietf-quic-recovery-18</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.10-1.1">Change IW byte limit to 14720 from 14600 (#2494)<a href="#section-c.10-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.2">Update PTO calculation to match RFC6298 (#2480, #2489, #2490)<a href="#section-c.10-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.3">Improve loss detection's description of multiple packet number spaces and
+pseudocode (#2485, #2451, #2417)<a href="#section-c.10-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.4">Declare persistent congestion even if non-probe packets are sent and don't
+make persistent congestion more aggressive than RTO verified was (#2365,
+#2244)<a href="#section-c.10-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.5">Move pseudocode to the appendices (#2408)<a href="#section-c.10-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.6">What to send on multiple PTOs (#2380)<a href="#section-c.10-1.6" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-17">
+<section id="section-c.11">
+        <h2 id="name-since-draft-ietf-quic-recovery-17">
+<a href="#section-c.11" class="section-number selfRef">C.11. </a><a href="#name-since-draft-ietf-quic-recovery-17" class="section-name selfRef">Since draft-ietf-quic-recovery-17</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.11-1.1">After Probe Timeout discard in-flight packets or send another (#2212, #1965)<a href="#section-c.11-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.2">Endpoints discard initial keys as soon as handshake keys are available (#1951,
+#2045)<a href="#section-c.11-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.3">0-RTT state is discarded when 0-RTT is rejected (#2300)<a href="#section-c.11-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.4">Loss detection timer is cancelled when ack-eliciting frames are in flight
+(#2117, #2093)<a href="#section-c.11-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.5">Packets are declared lost if they are in flight (#2104)<a href="#section-c.11-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.6">After becoming idle, either pace packets or reset the congestion controller
+(#2138, 2187)<a href="#section-c.11-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.7">Process ECN counts before marking packets lost (#2142)<a href="#section-c.11-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.8">Mark packets lost before resetting crypto_count and pto_count (#2208, #2209)<a href="#section-c.11-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.9">Congestion and loss recovery state are discarded when keys are discarded
+(#2327)<a href="#section-c.11-1.9" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-16">
+<section id="section-c.12">
+        <h2 id="name-since-draft-ietf-quic-recovery-16">
+<a href="#section-c.12" class="section-number selfRef">C.12. </a><a href="#name-since-draft-ietf-quic-recovery-16" class="section-name selfRef">Since draft-ietf-quic-recovery-16</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.12-1.1">Unify TLP and RTO into a single PTO; eliminate min RTO, min TLP and min crypto
+timeouts; eliminate timeout validation (#2114, #2166, #2168, #1017)<a href="#section-c.12-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.2">Redefine how congestion avoidance in terms of when the period starts (#1928,
+#1930)<a href="#section-c.12-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.3">Document what needs to be tracked for packets that are in flight (#765, #1724,
+#1939)<a href="#section-c.12-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.4">Integrate both time and packet thresholds into loss detection (#1969, #1212,
+#934, #1974)<a href="#section-c.12-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.5">Reduce congestion window after idle, unless pacing is used (#2007, #2023)<a href="#section-c.12-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.6">Disable RTT calculation for packets that don't elicit acknowledgment (#2060,
+#2078)<a href="#section-c.12-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.7">Limit ack_delay by max_ack_delay (#2060, #2099)<a href="#section-c.12-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8">Initial keys are discarded once Handshake keys are available (#1951, #2045)<a href="#section-c.12-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.9">Reorder ECN and loss detection in pseudocode (#2142)<a href="#section-c.12-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.10">Only cancel loss detection timer if ack-eliciting packets are in flight
+(#2093, #2117)<a href="#section-c.12-1.10" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-14">
+<section id="section-c.13">
+        <h2 id="name-since-draft-ietf-quic-recovery-14">
+<a href="#section-c.13" class="section-number selfRef">C.13. </a><a href="#name-since-draft-ietf-quic-recovery-14" class="section-name selfRef">Since draft-ietf-quic-recovery-14</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.13-1.1">Used max_ack_delay from transport params (#1796, #1782)<a href="#section-c.13-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.13-1.2">Merge ACK and ACK_ECN (#1783)<a href="#section-c.13-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-13">
+<section id="section-c.14">
+        <h2 id="name-since-draft-ietf-quic-recovery-13">
+<a href="#section-c.14" class="section-number selfRef">C.14. </a><a href="#name-since-draft-ietf-quic-recovery-13" class="section-name selfRef">Since draft-ietf-quic-recovery-13</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.14-1.1">Corrected the lack of ssthresh reduction in CongestionEvent pseudocode (#1598)<a href="#section-c.14-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.2">Considerations for ECN spoofing (#1426, #1626)<a href="#section-c.14-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.3">Clarifications for PADDING and congestion control (#837, #838, #1517, #1531,
+#1540)<a href="#section-c.14-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.4">Reduce early retransmission timer to RTT/8 (#945, #1581)<a href="#section-c.14-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.5">Packets are declared lost after an RTO is verified (#935, #1582)<a href="#section-c.14-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-12">
+<section id="section-c.15">
+        <h2 id="name-since-draft-ietf-quic-recovery-12">
+<a href="#section-c.15" class="section-number selfRef">C.15. </a><a href="#name-since-draft-ietf-quic-recovery-12" class="section-name selfRef">Since draft-ietf-quic-recovery-12</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.15-1.1">Changes to manage separate packet number spaces and encryption levels (#1190,
+#1242, #1413, #1450)<a href="#section-c.15-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.2">Added ECN feedback mechanisms and handling; new ACK_ECN frame (#804, #805,
+#1372)<a href="#section-c.15-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-11">
+<section id="section-c.16">
+        <h2 id="name-since-draft-ietf-quic-recovery-11">
+<a href="#section-c.16" class="section-number selfRef">C.16. </a><a href="#name-since-draft-ietf-quic-recovery-11" class="section-name selfRef">Since draft-ietf-quic-recovery-11</a>
+        </h2>
+<p id="section-c.16-1">No significant changes.<a href="#section-c.16-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-10">
+<section id="section-c.17">
+        <h2 id="name-since-draft-ietf-quic-recovery-10">
+<a href="#section-c.17" class="section-number selfRef">C.17. </a><a href="#name-since-draft-ietf-quic-recovery-10" class="section-name selfRef">Since draft-ietf-quic-recovery-10</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.17-1.1">Improved text on ack generation (#1139, #1159)<a href="#section-c.17-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.17-1.2">Make references to TCP recovery mechanisms informational (#1195)<a href="#section-c.17-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.17-1.3">Define time_of_last_sent_handshake_packet (#1171)<a href="#section-c.17-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.17-1.4">Added signal from TLS the data it includes needs to be sent in a Retry packet
+(#1061, #1199)<a href="#section-c.17-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.17-1.5">Minimum RTT (min_rtt) is initialized with an infinite value (#1169)<a href="#section-c.17-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-09">
+<section id="section-c.18">
+        <h2 id="name-since-draft-ietf-quic-recovery-0">
+<a href="#section-c.18" class="section-number selfRef">C.18. </a><a href="#name-since-draft-ietf-quic-recovery-0" class="section-name selfRef">Since draft-ietf-quic-recovery-09</a>
+        </h2>
+<p id="section-c.18-1">No significant changes.<a href="#section-c.18-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-08">
+<section id="section-c.19">
+        <h2 id="name-since-draft-ietf-quic-recovery-08">
+<a href="#section-c.19" class="section-number selfRef">C.19. </a><a href="#name-since-draft-ietf-quic-recovery-08" class="section-name selfRef">Since draft-ietf-quic-recovery-08</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.19-1.1">Clarified pacing and RTO (#967, #977)<a href="#section-c.19-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-07">
+<section id="section-c.20">
+        <h2 id="name-since-draft-ietf-quic-recovery-07">
+<a href="#section-c.20" class="section-number selfRef">C.20. </a><a href="#name-since-draft-ietf-quic-recovery-07" class="section-name selfRef">Since draft-ietf-quic-recovery-07</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.20-1.1">Include Ack Delay in RTO(and TLP) computations (#981)<a href="#section-c.20-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.2">Ack Delay in SRTT computation (#961)<a href="#section-c.20-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.3">Default RTT and Slow Start (#590)<a href="#section-c.20-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.4">Many editorial fixes.<a href="#section-c.20-1.4" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-06">
+<section id="section-c.21">
+        <h2 id="name-since-draft-ietf-quic-recovery-06">
+<a href="#section-c.21" class="section-number selfRef">C.21. </a><a href="#name-since-draft-ietf-quic-recovery-06" class="section-name selfRef">Since draft-ietf-quic-recovery-06</a>
+        </h2>
+<p id="section-c.21-1">No significant changes.<a href="#section-c.21-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-05">
+<section id="section-c.22">
+        <h2 id="name-since-draft-ietf-quic-recovery-05">
+<a href="#section-c.22" class="section-number selfRef">C.22. </a><a href="#name-since-draft-ietf-quic-recovery-05" class="section-name selfRef">Since draft-ietf-quic-recovery-05</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.22-1.1">Add more congestion control text (#776)<a href="#section-c.22-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-04">
+<section id="section-c.23">
+        <h2 id="name-since-draft-ietf-quic-recovery-04">
+<a href="#section-c.23" class="section-number selfRef">C.23. </a><a href="#name-since-draft-ietf-quic-recovery-04" class="section-name selfRef">Since draft-ietf-quic-recovery-04</a>
+        </h2>
+<p id="section-c.23-1">No significant changes.<a href="#section-c.23-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-03">
+<section id="section-c.24">
+        <h2 id="name-since-draft-ietf-quic-recovery-03">
+<a href="#section-c.24" class="section-number selfRef">C.24. </a><a href="#name-since-draft-ietf-quic-recovery-03" class="section-name selfRef">Since draft-ietf-quic-recovery-03</a>
+        </h2>
+<p id="section-c.24-1">No significant changes.<a href="#section-c.24-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-02">
+<section id="section-c.25">
+        <h2 id="name-since-draft-ietf-quic-recovery-02">
+<a href="#section-c.25" class="section-number selfRef">C.25. </a><a href="#name-since-draft-ietf-quic-recovery-02" class="section-name selfRef">Since draft-ietf-quic-recovery-02</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.25-1.1">Integrate F-RTO (#544, #409)<a href="#section-c.25-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.25-1.2">Add congestion control (#545, #395)<a href="#section-c.25-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.25-1.3">Require connection abort if a skipped packet was acknowledged (#415)<a href="#section-c.25-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.25-1.4">Simplify RTO calculations (#142, #417)<a href="#section-c.25-1.4" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-01">
+<section id="section-c.26">
+        <h2 id="name-since-draft-ietf-quic-recovery-01">
+<a href="#section-c.26" class="section-number selfRef">C.26. </a><a href="#name-since-draft-ietf-quic-recovery-01" class="section-name selfRef">Since draft-ietf-quic-recovery-01</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.26-1.1">Overview added to loss detection<a href="#section-c.26-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.2">Changes initial default RTT to 100ms<a href="#section-c.26-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.3">Added time-based loss detection and fixes early retransmit<a href="#section-c.26-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.4">Clarified loss recovery for handshake packets<a href="#section-c.26-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.5">Fixed references and made TCP references informative<a href="#section-c.26-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-recovery-00">
+<section id="section-c.27">
+        <h2 id="name-since-draft-ietf-quic-recovery-00">
+<a href="#section-c.27" class="section-number selfRef">C.27. </a><a href="#name-since-draft-ietf-quic-recovery-00" class="section-name selfRef">Since draft-ietf-quic-recovery-00</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.27-1.1">Improved description of constants and ACK behavior<a href="#section-c.27-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-iyengar-quic-loss-recovery-01">
+<section id="section-c.28">
+        <h2 id="name-since-draft-iyengar-quic-lo">
+<a href="#section-c.28" class="section-number selfRef">C.28. </a><a href="#name-since-draft-iyengar-quic-lo" class="section-name selfRef">Since draft-iyengar-quic-loss-recovery-01</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.28-1.1">Adopted as base for draft-ietf-quic-recovery<a href="#section-c.28-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.28-1.2">Updated authors/editors list<a href="#section-c.28-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.28-1.3">Added table of contents<a href="#section-c.28-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+</section>
+</div>
+<div id="contributors">
+<section id="section-appendix.d">
+      <h2 id="name-contributors">
+<a href="#section-appendix.d" class="section-number selfRef">Appendix D. </a><a href="#name-contributors" class="section-name selfRef">Contributors</a>
+      </h2>
+<p id="section-appendix.d-1">The IETF QUIC Working Group received an enormous amount of support from many
+people. The following people provided substantive contributions to this
+document:
+Alessandro Ghedini,
+Benjamin Saunders,
+Gorry Fairhurst, <span class="contact-name"><span class="non-ascii">奥 一穂</span> (<span class="ascii">Kazuho Oku</span>)</span>,
+Lars Eggert,
+Magnus Westerlund,
+Marten Seemann,
+Martin Duke,
+Martin Thomson,
+Nick Banks,
+Praveen Balasubramaniam.<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="acknowledgments">
+<section id="section-appendix.e">
+      <h2 id="name-acknowledgments">
+<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
+    </h2>
+</section>
+</div>
+<div id="authors-addresses">
+<section id="section-appendix.f">
+      <h2 id="name-authors-addresses">
+<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+      </h2>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Jana Iyengar (<span class="role">editor</span>)</span></div>
+<div dir="auto" class="left"><span class="org">Fastly</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:jri.ietf@gmail.com" class="email">jri.ietf@gmail.com</a>
+</div>
+</address>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Ian Swett (<span class="role">editor</span>)</span></div>
+<div dir="auto" class="left"><span class="org">Google</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:ianswett@google.com" class="email">ianswett@google.com</a>
+</div>
+</address>
+</section>
+</div>
+<script>const toc = document.getElementById("toc");
+toc.querySelector("h2").addEventListener("click", e => {
+  toc.classList.toggle("active");
+});
+toc.querySelector("nav").addEventListener("click", e => {
+  toc.classList.remove("active");
+});
+</script>
+</body>
+</html>
diff --git a/jri/mustnot/draft-ietf-quic-recovery.txt b/jri/mustnot/draft-ietf-quic-recovery.txt
new file mode 100644
index 0000000000..d3477682ed
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-recovery.txt
@@ -0,0 +1,2576 @@
+
+
+
+
+QUIC                                                     J. Iyengar, Ed.
+Internet-Draft                                                    Fastly
+Intended status: Standards Track                           I. Swett, Ed.
+Expires: 5 December 2020                                          Google
+                                                             3 June 2020
+
+
+               QUIC Loss Detection and Congestion Control
+                    draft-ietf-quic-recovery-latest
+
+Abstract
+
+   This document describes loss detection and congestion control
+   mechanisms for QUIC.
+
+Note to Readers
+
+   Discussion of this draft takes place on the QUIC working group
+   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
+   archived at https://mailarchive.ietf.org/arch/
+   search/?email_list=quic.
+
+   Working Group information can be found at https://github.com/quicwg;
+   source code and issues list for this draft can be found at
+   https://github.com/quicwg/base-drafts/labels/-recovery.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at https://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on 5 December 2020.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 1]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (https://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.  Code Components
+   extracted from this document must include Simplified BSD License text
+   as described in Section 4.e of the Trust Legal Provisions and are
+   provided without warranty as described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
+   3.  Design of the QUIC Transmission Machinery . . . . . . . . . .   5
+     3.1.  Relevant Differences Between QUIC and TCP . . . . . . . .   5
+       3.1.1.  Separate Packet Number Spaces . . . . . . . . . . . .   6
+       3.1.2.  Monotonically Increasing Packet Numbers . . . . . . .   6
+       3.1.3.  Clearer Loss Epoch  . . . . . . . . . . . . . . . . .   6
+       3.1.4.  No Reneging . . . . . . . . . . . . . . . . . . . . .   7
+       3.1.5.  More ACK Ranges . . . . . . . . . . . . . . . . . . .   7
+       3.1.6.  Explicit Correction For Delayed Acknowledgements  . .   7
+       3.1.7.  Probe Timeout Replaces RTO and TLP  . . . . . . . . .   7
+       3.1.8.  The Minimum Congestion Window is Two Packets  . . . .   8
+   4.  Estimating the Round-Trip Time  . . . . . . . . . . . . . . .   8
+     4.1.  Generating RTT samples  . . . . . . . . . . . . . . . . .   8
+     4.2.  Estimating min_rtt  . . . . . . . . . . . . . . . . . . .   9
+     4.3.  Estimating smoothed_rtt and rttvar  . . . . . . . . . . .   9
+   5.  Loss Detection  . . . . . . . . . . . . . . . . . . . . . . .  11
+     5.1.  Acknowledgement-based Detection . . . . . . . . . . . . .  11
+       5.1.1.  Packet Threshold  . . . . . . . . . . . . . . . . . .  11
+       5.1.2.  Time Threshold  . . . . . . . . . . . . . . . . . . .  12
+     5.2.  Probe Timeout . . . . . . . . . . . . . . . . . . . . . .  13
+       5.2.1.  Computing PTO . . . . . . . . . . . . . . . . . . . .  13
+       5.2.2.  Handshakes and New Paths  . . . . . . . . . . . . . .  14
+       5.2.3.  Speeding Up Handshake Completion  . . . . . . . . . .  15
+       5.2.4.  Sending Probe Packets . . . . . . . . . . . . . . . .  16
+     5.3.  Handling Retry Packets  . . . . . . . . . . . . . . . . .  17
+     5.4.  Discarding Keys and Packet State  . . . . . . . . . . . .  17
+   6.  Congestion Control  . . . . . . . . . . . . . . . . . . . . .  18
+     6.1.  Explicit Congestion Notification  . . . . . . . . . . . .  19
+     6.2.  Initial and Minimum Congestion Window . . . . . . . . . .  19
+     6.3.  Slow Start  . . . . . . . . . . . . . . . . . . . . . . .  19
+     6.4.  Congestion Avoidance  . . . . . . . . . . . . . . . . . .  20
+     6.5.  Recovery Period . . . . . . . . . . . . . . . . . . . . .  20
+     6.6.  Ignoring Loss of Undecryptable Packets  . . . . . . . . .  20
+     6.7.  Probe Timeout . . . . . . . . . . . . . . . . . . . . . .  21
+     6.8.  Persistent Congestion . . . . . . . . . . . . . . . . . .  21
+     6.9.  Pacing  . . . . . . . . . . . . . . . . . . . . . . . . .  22
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 2]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+     6.10. Under-utilizing the Congestion Window . . . . . . . . . .  23
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
+     7.1.  Congestion Signals  . . . . . . . . . . . . . . . . . . .  24
+     7.2.  Traffic Analysis  . . . . . . . . . . . . . . . . . . . .  24
+     7.3.  Misreporting ECN Markings . . . . . . . . . . . . . . . .  24
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  25
+   Appendix A.  Loss Recovery Pseudocode . . . . . . . . . . . . . .  27
+     A.1.  Tracking Sent Packets . . . . . . . . . . . . . . . . . .  27
+       A.1.1.  Sent Packet Fields  . . . . . . . . . . . . . . . . .  27
+     A.2.  Constants of Interest . . . . . . . . . . . . . . . . . .  28
+     A.3.  Variables of interest . . . . . . . . . . . . . . . . . .  28
+     A.4.  Initialization  . . . . . . . . . . . . . . . . . . . . .  29
+     A.5.  On Sending a Packet . . . . . . . . . . . . . . . . . . .  29
+     A.6.  On Receiving a Datagram . . . . . . . . . . . . . . . . .  30
+     A.7.  On Receiving an Acknowledgment  . . . . . . . . . . . . .  30
+     A.8.  Setting the Loss Detection Timer  . . . . . . . . . . . .  32
+     A.9.  On Timeout  . . . . . . . . . . . . . . . . . . . . . . .  33
+     A.10. Detecting Lost Packets  . . . . . . . . . . . . . . . . .  34
+   Appendix B.  Congestion Control Pseudocode  . . . . . . . . . . .  35
+     B.1.  Constants of interest . . . . . . . . . . . . . . . . . .  35
+     B.2.  Variables of interest . . . . . . . . . . . . . . . . . .  36
+     B.3.  Initialization  . . . . . . . . . . . . . . . . . . . . .  36
+     B.4.  On Packet Sent  . . . . . . . . . . . . . . . . . . . . .  37
+     B.5.  On Packet Acknowledgement . . . . . . . . . . . . . . . .  37
+     B.6.  On New Congestion Event . . . . . . . . . . . . . . . . .  37
+     B.7.  Process ECN Information . . . . . . . . . . . . . . . . .  38
+     B.8.  On Packets Lost . . . . . . . . . . . . . . . . . . . . .  38
+     B.9.  Upon dropping Initial or Handshake keys . . . . . . . . .  39
+   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . .  39
+     C.1.  Since draft-ietf-quic-recovery-27 . . . . . . . . . . . .  39
+     C.2.  Since draft-ietf-quic-recovery-26 . . . . . . . . . . . .  40
+     C.3.  Since draft-ietf-quic-recovery-25 . . . . . . . . . . . .  40
+     C.4.  Since draft-ietf-quic-recovery-24 . . . . . . . . . . . .  40
+     C.5.  Since draft-ietf-quic-recovery-23 . . . . . . . . . . . .  40
+     C.6.  Since draft-ietf-quic-recovery-22 . . . . . . . . . . . .  40
+     C.7.  Since draft-ietf-quic-recovery-21 . . . . . . . . . . . .  40
+     C.8.  Since draft-ietf-quic-recovery-20 . . . . . . . . . . . .  40
+     C.9.  Since draft-ietf-quic-recovery-19 . . . . . . . . . . . .  41
+     C.10. Since draft-ietf-quic-recovery-18 . . . . . . . . . . . .  41
+     C.11. Since draft-ietf-quic-recovery-17 . . . . . . . . . . . .  41
+     C.12. Since draft-ietf-quic-recovery-16 . . . . . . . . . . . .  42
+     C.13. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . .  43
+     C.14. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . .  43
+     C.15. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . .  43
+     C.16. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . .  43
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 3]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+     C.17. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . .  43
+     C.18. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . .  44
+     C.19. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . .  44
+     C.20. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . .  44
+     C.21. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . .  44
+     C.22. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . .  44
+     C.23. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . .  44
+     C.24. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . .  44
+     C.25. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . .  44
+     C.26. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . .  45
+     C.27. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . .  45
+     C.28. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . .  45
+   Appendix D.  Contributors . . . . . . . . . . . . . . . . . . . .  45
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  45
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  45
+
+1.  Introduction
+
+   QUIC is a new multiplexed and secure transport protocol atop UDP,
+   specified in [QUIC-TRANSPORT].  This document describes congestion
+   control and loss recovery for QUIC.  Mechanisms described in this
+   document follow the spirit of existing TCP congestion control and
+   loss recovery mechanisms, described in RFCs, various Internet-drafts,
+   or academic papers, and also those prevalent in TCP implementations.
+
+2.  Conventions and Definitions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Definitions of terms that are used in this document:
+
+   Ack-eliciting Frames:  All frames other than ACK, PADDING, and
+      CONNECTION_CLOSE are considered ack-eliciting.
+
+   Ack-eliciting Packets:  Packets that contain ack-eliciting frames
+      elicit an ACK from the receiver within the maximum ack delay and
+      are called ack-eliciting packets.
+
+   In-flight:  Packets are considered in-flight when they are ack-
+      eliciting or contain a PADDING frame, and they have been sent but
+      are not acknowledged, declared lost, or abandoned along with old
+      keys.
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 4]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+3.  Design of the QUIC Transmission Machinery
+
+   All transmissions in QUIC are sent with a packet-level header, which
+   indicates the encryption level and includes a packet sequence number
+   (referred to below as a packet number).  The encryption level
+   indicates the packet number space, as described in [QUIC-TRANSPORT].
+   Packet numbers never repeat within a packet number space for the
+   lifetime of a connection.  Packet numbers are sent in monotonically
+   increasing order within a space, preventing ambiguity.
+
+   This design obviates the need for disambiguating between
+   transmissions and retransmissions and eliminates significant
+   complexity from QUIC's interpretation of TCP loss detection
+   mechanisms.
+
+   QUIC packets can contain multiple frames of different types.  The
+   recovery mechanisms ensure that data and frames that need reliable
+   delivery are acknowledged or declared lost and sent in new packets as
+   necessary.  The types of frames contained in a packet affect recovery
+   and congestion control logic:
+
+   *  All packets are acknowledged, though packets that contain no ack-
+      eliciting frames are only acknowledged along with ack-eliciting
+      packets.
+
+   *  Long header packets that contain CRYPTO frames are critical to the
+      performance of the QUIC handshake and use shorter timers for
+      acknowledgement.
+
+   *  Packets containing frames besides ACK or CONNECTION_CLOSE frames
+      count toward congestion control limits and are considered in-
+      flight.
+
+   *  PADDING frames cause packets to contribute toward bytes in flight
+      without directly causing an acknowledgment to be sent.
+
+3.1.  Relevant Differences Between QUIC and TCP
+
+   Readers familiar with TCP's loss detection and congestion control
+   will find algorithms here that parallel well-known TCP ones.
+   Protocol differences between QUIC and TCP however contribute to
+   algorithmic differences.  We briefly describe these protocol
+   differences below.
+
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 5]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+3.1.1.  Separate Packet Number Spaces
+
+   QUIC uses separate packet number spaces for each encryption level,
+   except 0-RTT and all generations of 1-RTT keys use the same packet
+   number space.  Separate packet number spaces ensures acknowledgement
+   of packets sent with one level of encryption will not cause spurious
+   retransmission of packets sent with a different encryption level.
+   Congestion control and round-trip time (RTT) measurement are unified
+   across packet number spaces.
+
+3.1.2.  Monotonically Increasing Packet Numbers
+
+   TCP conflates transmission order at the sender with delivery order at
+   the receiver, which results in retransmissions of the same data
+   carrying the same sequence number, and consequently leads to
+   "retransmission ambiguity".  QUIC separates the two.  QUIC uses a
+   packet number to indicate transmission order.  Application data is
+   sent in one or more streams and delivery order is determined by
+   stream offsets encoded within STREAM frames.
+
+   QUIC's packet number is strictly increasing within a packet number
+   space, and directly encodes transmission order.  A higher packet
+   number signifies that the packet was sent later, and a lower packet
+   number signifies that the packet was sent earlier.  When a packet
+   containing ack-eliciting frames is detected lost, QUIC rebundles
+   necessary frames in a new packet with a new packet number, removing
+   ambiguity about which packet is acknowledged when an ACK is received.
+   Consequently, more accurate RTT measurements can be made, spurious
+   retransmissions are trivially detected, and mechanisms such as Fast
+   Retransmit can be applied universally, based only on packet number.
+
+   This design point significantly simplifies loss detection mechanisms
+   for QUIC.  Most TCP mechanisms implicitly attempt to infer
+   transmission ordering based on TCP sequence numbers - a non-trivial
+   task, especially when TCP timestamps are not available.
+
+3.1.3.  Clearer Loss Epoch
+
+   QUIC starts a loss epoch when a packet is lost and ends one when any
+   packet sent after the epoch starts is acknowledged.  TCP waits for
+   the gap in the sequence number space to be filled, and so if a
+   segment is lost multiple times in a row, the loss epoch may not end
+   for several round trips.  Because both should reduce their congestion
+   windows only once per epoch, QUIC will do it once for every round
+   trip that experiences loss, while TCP may only do it once across
+   multiple round trips.
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 6]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+3.1.4.  No Reneging
+
+   QUIC ACKs contain information that is similar to TCP SACK, but QUIC
+   does not allow any acked packet to be reneged, greatly simplifying
+   implementations on both sides and reducing memory pressure on the
+   sender.
+
+3.1.5.  More ACK Ranges
+
+   QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges.  In
+   high loss environments, this speeds recovery, reduces spurious
+   retransmits, and ensures forward progress without relying on
+   timeouts.
+
+3.1.6.  Explicit Correction For Delayed Acknowledgements
+
+   QUIC endpoints measure the delay incurred between when a packet is
+   received and when the corresponding acknowledgment is sent, allowing
+   a peer to maintain a more accurate round-trip time estimate; see
+   Section 13.2 of [QUIC-TRANSPORT].
+
+3.1.7.  Probe Timeout Replaces RTO and TLP
+
+   QUIC uses a probe timeout (see Section 5.2), with a timer based on
+   TCP's RTO computation.  QUIC's PTO includes the peer's maximum
+   expected acknowledgement delay instead of using a fixed minimum
+   timeout.  QUIC does not collapse the congestion window until
+   persistent congestion (Section 6.8) is declared, unlike TCP, which
+   collapses the congestion window upon expiry of an RTO.  Instead of
+   collapsing the congestion window and declaring everything in-flight
+   lost, QUIC allows probe packets to temporarily exceed the congestion
+   window whenever the timer expires.
+
+   In doing this, QUIC avoids unnecessary congestion window reductions,
+   obviating the need for correcting mechanisms such as F-RTO [RFC5682].
+   Since QUIC does not collapse the congestion window on a PTO
+   expiration, a QUIC sender is not limited from sending more in-flight
+   packets after a PTO expiration if it still has available congestion
+   window.  This occurs when a sender is application-limited and the PTO
+   timer expires.  This is more aggressive than TCP's RTO mechanism when
+   application-limited, but identical when not application-limited.
+
+   A single packet loss at the tail does not indicate persistent
+   congestion, so QUIC specifies a time-based definition to ensure one
+   or more packets are sent prior to a dramatic decrease in congestion
+   window; see Section 6.8.
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 7]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+3.1.8.  The Minimum Congestion Window is Two Packets
+
+   TCP uses a minimum congestion window of one packet.  However, loss of
+   that single packet means that the sender needs to waiting for a PTO
+   (Section 5.2) to recover, which can be much longer than a round-trip
+   time.  Sending a single ack-eliciting packet also increases the
+   chances of incurring additional latency when a receiver delays its
+   acknowledgement.
+
+   QUIC therefore recommends that the minimum congestion window be two
+   packets.  While this increases network load, it is considered safe,
+   since the sender will still reduce its sending rate exponentially
+   under persistent congestion (Section 5.2).
+
+4.  Estimating the Round-Trip Time
+
+   At a high level, an endpoint measures the time from when a packet was
+   sent to when it is acknowledged as a round-trip time (RTT) sample.
+   The endpoint uses RTT samples and peer-reported host delays (see
+   Section 13.2 of [QUIC-TRANSPORT]) to generate a statistical
+   description of the network path's RTT.  An endpoint computes the
+   following three values for each path: the minimum value observed over
+   the lifetime of the path (min_rtt), an exponentially-weighted moving
+   average (smoothed_rtt), and the mean deviation (referred to as
+   "variation" in the rest of this document) in the observed RTT samples
+   (rttvar).
+
+4.1.  Generating RTT samples
+
+   An endpoint generates an RTT sample on receiving an ACK frame that
+   meets the following two conditions:
+
+   *  the largest acknowledged packet number is newly acknowledged, and
+
+   *  at least one of the newly acknowledged packets was ack-eliciting.
+
+   The RTT sample, latest_rtt, is generated as the time elapsed since
+   the largest acknowledged packet was sent:
+
+   latest_rtt = ack_time - send_time_of_largest_acked
+
+   An RTT sample is generated using only the largest acknowledged packet
+   in the received ACK frame.  This is because a peer reports ACK delays
+   for only the largest acknowledged packet in an ACK frame.  While the
+   reported ACK delay is not used by the RTT sample measurement, it is
+   used to adjust the RTT sample in subsequent computations of
+   smoothed_rtt and rttvar Section 4.3.
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 8]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   To avoid generating multiple RTT samples for a single packet, an ACK
+   frame SHOULD NOT be used to update RTT estimates if it does not newly
+   acknowledge the largest acknowledged packet.
+
+   An RTT sample MUST NOT be generated on receiving an ACK frame that
+   does not newly acknowledge at least one ack-eliciting packet.  A peer
+   usually does not send an ACK frame when only non-ack-eliciting
+   packets are received.  Therefore an ACK frame that contains
+   acknowledgements for only non-ack-eliciting packets could include an
+   arbitrarily large Ack Delay value.  Ignoring such ACK frames avoids
+   complications in subsequent smoothed_rtt and rttvar computations.
+
+   A sender might generate multiple RTT samples per RTT when multiple
+   ACK frames are received within an RTT.  As suggested in [RFC6298],
+   doing so might result in inadequate history in smoothed_rtt and
+   rttvar.  Ensuring that RTT estimates retain sufficient history is an
+   open research question.
+
+4.2.  Estimating min_rtt
+
+   min_rtt is the minimum RTT observed for a given network path.
+   min_rtt is set to the latest_rtt on the first RTT sample, and to the
+   lesser of min_rtt and latest_rtt on subsequent samples.  In this
+   document, min_rtt is used by loss detection to reject implausibly
+   small rtt samples.
+
+   An endpoint uses only locally observed times in computing the min_rtt
+   and does not adjust for ACK delays reported by the peer.  Doing so
+   allows the endpoint to set a lower bound for the smoothed_rtt based
+   entirely on what it observes (see Section 4.3), and limits potential
+   underestimation due to erroneously-reported delays by the peer.
+
+   The RTT for a network path may change over time.  If a path's actual
+   RTT decreases, the min_rtt will adapt immediately on the first low
+   sample.  If the path's actual RTT increases, the min_rtt will not
+   adapt to it, allowing future RTT samples that are smaller than the
+   new RTT be included in smoothed_rtt.
+
+4.3.  Estimating smoothed_rtt and rttvar
+
+   smoothed_rtt is an exponentially-weighted moving average of an
+   endpoint's RTT samples, and rttvar is the variation in the RTT
+   samples, estimated using a mean variation.
+
+   The calculation of smoothed_rtt uses path latency after adjusting RTT
+   samples for acknowledgement delays.  These delays are computed using
+   the ACK Delay field of the ACK frame as described in Section 19.3 of
+   [QUIC-TRANSPORT].  For packets sent in the ApplicationData packet
+
+
+
+Iyengar & Swett          Expires 5 December 2020                [Page 9]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   number space, a peer limits any delay in sending an acknowledgement
+   for an ack-eliciting packet to no greater than the value it
+   advertised in the max_ack_delay transport parameter.  Consequently,
+   when a peer reports an Ack Delay that is greater than its
+   max_ack_delay, the delay is attributed to reasons out of the peer's
+   control, such as scheduler latency at the peer or loss of previous
+   ACK frames.  Any delays beyond the peer's max_ack_delay are therefore
+   considered effectively part of path delay and incorporated into the
+   smoothed_rtt estimate.
+
+   When adjusting an RTT sample using peer-reported acknowledgement
+   delays, an endpoint:
+
+   *  MUST ignore the Ack Delay field of the ACK frame for packets sent
+      in the Initial and Handshake packet number space.
+
+   *  MUST use the lesser of the value reported in Ack Delay field of
+      the ACK frame and the peer's max_ack_delay transport parameter.
+
+   *  MUST NOT apply the adjustment if the resulting RTT sample is
+      smaller than the min_rtt.  This limits the underestimation that a
+      misreporting peer can cause to the smoothed_rtt.
+
+   smoothed_rtt and rttvar are computed as follows, similar to
+   [RFC6298].
+
+   When there are no samples for a network path, and on the first RTT
+   sample for the network path:
+
+   smoothed_rtt = rtt_sample
+   rttvar = rtt_sample / 2
+
+   Before any RTT samples are available, the initial RTT is used as
+   rtt_sample.  On the first RTT sample for the network path, that
+   sample is used as rtt_sample.  This ensures that the first
+   measurement erases the history of any persisted or default values.
+
+   On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:
+
+   ack_delay = min(Ack Delay in ACK Frame, max_ack_delay)
+   adjusted_rtt = latest_rtt
+   if (min_rtt + ack_delay < latest_rtt):
+     adjusted_rtt = latest_rtt - ack_delay
+   smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
+   rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
+   rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 10]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+5.  Loss Detection
+
+   QUIC senders use acknowledgements to detect lost packets, and a probe
+   time out (see Section 5.2) to ensure acknowledgements are received.
+   This section provides a description of these algorithms.
+
+   If a packet is lost, the QUIC transport needs to recover from that
+   loss, such as by retransmitting the data, sending an updated frame,
+   or abandoning the frame.  For more information, see Section 13.3 of
+   [QUIC-TRANSPORT].
+
+5.1.  Acknowledgement-based Detection
+
+   Acknowledgement-based loss detection implements the spirit of TCP's
+   Fast Retransmit [RFC5681], Early Retransmit [RFC5827], FACK [FACK],
+   SACK loss recovery [RFC6675], and RACK [RACK].  This section provides
+   an overview of how these algorithms are implemented in QUIC.
+
+   A packet is declared lost if it meets all the following conditions:
+
+   *  The packet is unacknowledged, in-flight, and was sent prior to an
+      acknowledged packet.
+
+   *  Either its packet number is kPacketThreshold smaller than an
+      acknowledged packet (Section 5.1.1), or it was sent long enough in
+      the past (Section 5.1.2).
+
+   The acknowledgement indicates that a packet sent later was delivered,
+   and the packet and time thresholds provide some tolerance for packet
+   reordering.
+
+   Spuriously declaring packets as lost leads to unnecessary
+   retransmissions and may result in degraded performance due to the
+   actions of the congestion controller upon detecting loss.
+   Implementations can detect spurious retransmissions and increase the
+   reordering threshold in packets or time to reduce future spurious
+   retransmissions and loss events.  Implementations with adaptive time
+   thresholds MAY choose to start with smaller initial reordering
+   thresholds to minimize recovery latency.
+
+5.1.1.  Packet Threshold
+
+   The RECOMMENDED initial value for the packet reordering threshold
+   (kPacketThreshold) is 3, based on best practices for TCP loss
+   detection [RFC5681] [RFC6675].  Implementations SHOULD NOT use a
+   packet threshold less than 3, to keep in line with TCP [RFC5681].
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 11]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   Some networks may exhibit higher degrees of reordering, causing a
+   sender to detect spurious losses.  Algorithms that increase the
+   reordering threshold after spuriously detecting losses, such as TCP-
+   NCR [RFC4653], have proven to be useful in TCP and are expected to at
+   least as useful in QUIC.  Re-ordering could be more common with QUIC
+   than TCP, because network elements cannot observe and fix the order
+   of out-of-order packets.
+
+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 the local timer granularity, as indicated by the kGranularity
+   constant.  The time threshold is:
+
+   max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)
+
+   If packets sent prior to the largest acknowledged packet cannot yet
+   be declared lost, then a timer SHOULD be set for the remaining time.
+
+   Using max(smoothed_rtt, latest_rtt) protects from the two following
+   cases:
+
+   *  the latest RTT sample is lower than the smoothed RTT, perhaps due
+      to reordering where the acknowledgement encountered a shorter
+      path;
+
+   *  the latest RTT sample is higher than the smoothed RTT, perhaps due
+      to a sustained increase in the actual RTT, but the smoothed RTT
+      has not yet caught up.
+
+   The RECOMMENDED time threshold (kTimeThreshold), expressed as a
+   round-trip time multiplier, is 9/8.  The RECOMMENDED value of the
+   timer granularity (kGranularity) is 1ms.
+
+   Implementations MAY experiment with absolute thresholds, thresholds
+   from previous connections, adaptive thresholds, or including RTT
+   variation.  Smaller thresholds reduce reordering resilience and
+   increase spurious retransmissions, and larger thresholds increase
+   loss detection delay.
+
+
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 12]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+5.2.  Probe Timeout
+
+   A Probe Timeout (PTO) triggers sending one or two probe datagrams
+   when ack-eliciting packets are not acknowledged within the expected
+   period of time or the server may not have validated the client's
+   address.  A PTO enables a connection to recover from loss of tail
+   packets or acknowledgements.
+
+   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.
+
+   As with loss detection, the probe timeout is per packet number space.
+   The PTO algorithm used in QUIC implements the reliability functions
+   of Tail Loss Probe [RACK], RTO [RFC5681], and F-RTO algorithms for
+   TCP [RFC5682].  The timeout computation is based on TCP's
+   retransmission timeout period [RFC6298].
+
+5.2.1.  Computing PTO
+
+   When an ack-eliciting packet is transmitted, the sender schedules a
+   timer for the PTO period as follows:
+
+   PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay
+
+   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 variation in the
+   estimate (4*rttvar), and max_ack_delay, to account for the maximum
+   time by which a receiver might delay sending an acknowledgement.
+   When the PTO is armed for Initial or Handshake packet number spaces,
+   the max_ack_delay is 0, as specified in 13.2.1 of [QUIC-TRANSPORT].
+
+   The PTO value MUST be set to at least kGranularity, to avoid the
+   timer expiring immediately.
+
+   A sender recomputes and may need to reset its PTO timer every time an
+   ack-eliciting packet is sent or acknowledged, when the handshake is
+   confirmed, or when Initial or Handshake keys are discarded.  This
+   ensures the PTO is always set based on the latest RTT information and
+   for the last sent packet in the correct packet number space.
+
+   When ack-eliciting packets in multiple packet number spaces are in
+   flight, the timer MUST be set for the packet number space with the
+   earliest timeout, with one exception.  The ApplicationData packet
+   number space (Section 4.1.1 of [QUIC-TLS]) MUST be ignored until the
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 13]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   handshake completes.  Not arming the PTO for ApplicationData prevents
+   a client from retransmitting a 0-RTT packet on a PTO expiration
+   before confirming that the server is able to decrypt 0-RTT packets,
+   and prevents a server from sending a 1-RTT packet on a PTO expiration
+   before it has the keys to process an acknowledgement.
+
+   When a PTO timer expires, the PTO backoff MUST be increased,
+   resulting in the PTO period being set to twice its current value.
+   The PTO backoff factor is reset when an acknowledgement is received,
+   except in the following case.  A server might take longer to respond
+   to packets during the handshake than otherwise.  To protect such a
+   server from repeated client probes, the PTO backoff is not reset at a
+   client that is not yet certain that the server has finished
+   validating the client's address.  That is, a client does not reset
+   the PTO backoff factor on receiving acknowledgements until it
+   receives a HANDSHAKE_DONE frame or an acknowledgement for one of its
+   Handshake or 1-RTT packets.
+
+   This exponential reduction in the sender's rate is important because
+   consecutive PTOs might be caused by loss of packets or
+   acknowledgements due to severe congestion.  Even when there are ack-
+   eliciting packets in-flight in multiple packet number spaces, the
+   exponential increase in probe timeout occurs across all spaces to
+   prevent excess load on the network.  For example, a timeout in the
+   Initial packet number space doubles the length of the timeout in the
+   Handshake packet number space.
+
+   The life of a connection that is experiencing consecutive PTOs is
+   limited by the endpoint's idle timeout.
+
+   The probe timer MUST NOT be set if the time threshold Section 5.1.2
+   loss detection timer is set.  The time threshold loss detection timer
+   is expected to both expire earlier than the PTO and be less likely to
+   spuriously retransmit data.
+
+5.2.2.  Handshakes and New Paths
+
+   Resumed connections over the same network MAY use the previous
+   connection's final smoothed RTT value as the resumed connection's
+   initial RTT.  When no previous RTT is available, the initial RTT
+   SHOULD be set to 333ms, resulting in a 1 second initial timeout, as
+   recommended in [RFC6298].
+
+   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
+   an RTT sample.
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 14]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   Prior to handshake completion, when few to none RTT samples have been
+   generated, it is possible that the probe timer expiration is due to
+   an incorrect RTT estimate at the client.  To allow the client to
+   improve its RTT estimate, the new packet that it sends MUST be ack-
+   eliciting.
+
+   Initial packets and Handshake packets could be never acknowledged,
+   but they are removed from bytes in flight when the Initial and
+   Handshake keys are discarded, as described below in
+   Section Section 5.4.  When Initial or Handshake keys are discarded,
+   the PTO and loss detection timers MUST be reset, because discarding
+   keys indicates forward progress and the loss detection timer might
+   have been set for a now discarded packet number space.
+
+5.2.2.1.  Before Address Validation
+
+   Until the server has validated the client's address on the path, the
+   amount of data it can send is limited to three times the amount of
+   data received, as specified in Section 8.1 of [QUIC-TRANSPORT].  If
+   no additional data can be sent, the server's PTO timer MUST NOT be
+   armed until datagrams have been received from the client, because
+   packets sent on PTO count against the anti-amplification limit.  Note
+   that the server could fail to validate the client's address even if
+   0-RTT is accepted.
+
+   Since the server could be blocked until more packets are received
+   from the client, it is the client's responsibility to send packets to
+   unblock the server until it is certain that the server has finished
+   its address validation (see Section 8 of [QUIC-TRANSPORT]).  That is,
+   the client MUST set the probe timer if the client has not received an
+   acknowledgement for one of its Handshake or 1-RTT packets, and has
+   not received a HANDSHAKE_DONE frame.  If Handshake keys are available
+   to the client, it MUST send a Handshake packet, and otherwise it MUST
+   send an Initial packet in a UDP datagram of at least 1200 bytes.
+
+   A client could have received and acknowledged a Handshake packet,
+   causing it to discard state for the Initial packet number space, but
+   not sent any ack-eliciting Handshake packets.  In this case, the PTO
+   is set from the current time.
+
+5.2.3.  Speeding Up Handshake Completion
+
+   When a server receives an Initial packet containing duplicate CRYPTO
+   data, it can assume the client did not receive all of the server's
+   CRYPTO data sent in Initial packets, or the client's estimated RTT is
+   too small.  When a client receives Handshake or 1-RTT packets prior
+   to obtaining Handshake keys, it may assume some or all of the
+   server's Initial packets were lost.
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 15]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   To speed up handshake completion under these conditions, an endpoint
+   MAY send a packet containing unacknowledged CRYPTO data earlier than
+   the PTO expiry, subject to address validation limits; see Section 8.1
+   of [QUIC-TRANSPORT].
+
+   Peers can also use coalesced packets to ensure that each datagram
+   elicits at least one acknowledgement.  For example, clients can
+   coalesce an Initial packet containing PING and PADDING frames with a
+   0-RTT data packet and a server can coalesce an Initial packet
+   containing a PING frame with one or more packets in its first flight.
+
+5.2.4.  Sending Probe Packets
+
+   When a PTO timer expires, a sender MUST send at least one ack-
+   eliciting packet in the packet number space as a probe, unless there
+   is no data available to send.  An endpoint MAY send up to two full-
+   sized datagrams containing ack-eliciting packets, to avoid an
+   expensive consecutive PTO expiration due to a single lost datagram or
+   transmit data from multiple packet number spaces.  All probe packets
+   sent on a PTO MUST be ack-eliciting.
+
+   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.  This is particularly valuable when the server has both
+   Initial and Handshake data in-flight or the client has both Handshake
+   and ApplicationData in-flight, because the peer might only have
+   receive keys for one of the two packet number spaces.
+
+   If the sender wants to elicit a faster acknowledgement on PTO, it can
+   skip a packet number to eliminate the ack delay.
+
+   When the PTO timer expires, and there is new or previously sent
+   unacknowledged data, it MUST be sent.  A probe packet SHOULD carry
+   new data when possible.  A probe packet MAY carry retransmitted
+   unacknowledged data when new data is unavailable, when flow control
+   does not permit new data to be sent, or to opportunistically reduce
+   loss recovery delay.  Implementations MAY use alternative strategies
+   for determining the content of probe packets, including sending new
+   or retransmitted data based on the application's priorities.
+
+   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
+   retransmitted in a new packet, and then the original transmission is
+   acknowledged.  When there is no data to send, the sender SHOULD send
+   a PING or other ack-eliciting frame in a single packet, re-arming the
+   PTO timer.
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 16]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   Alternatively, instead of sending an ack-eliciting packet, the sender
+   MAY mark any packets still in flight as lost.  Doing so avoids
+   sending an additional packet, but increases the risk that loss is
+   declared too aggressively, resulting in an unnecessary rate reduction
+   by the congestion controller.
+
+   Consecutive PTO periods increase exponentially, and as a result,
+   connection recovery latency increases exponentially as packets
+   continue to be dropped in the network.  Sending two packets on PTO
+   expiration increases resilience to packet drops, thus reducing the
+   probability of consecutive PTO events.
+
+   When the PTO timer expires multiple times and new data cannot be
+   sent, implementations must choose between sending the same payload
+   every time or sending different payloads.  Sending the same payload
+   may be simpler and ensures the highest priority frames arrive first.
+   Sending different payloads each time reduces the chances of spurious
+   retransmission.
+
+5.3.  Handling Retry Packets
+
+   A Retry packet causes a client to send another Initial packet,
+   effectively restarting the connection process.  A Retry packet
+   indicates that the Initial was received, but not processed.  A Retry
+   packet cannot be treated as an acknowledgment, because it does not
+   indicate that a packet was processed or specify the packet number.
+
+   Clients that receive a Retry packet reset congestion control and loss
+   recovery state, including resetting any pending timers.  Other
+   connection state, in particular cryptographic handshake messages, is
+   retained; see Section 17.2.5 of [QUIC-TRANSPORT].
+
+   The client MAY compute an RTT estimate to the server as the time
+   period from when the first Initial was sent to when a Retry or a
+   Version Negotiation packet is received.  The client MAY use this
+   value in place of its default for the initial RTT estimate.
+
+5.4.  Discarding Keys and Packet State
+
+   When packet protection keys are discarded (see Section 4.10 of
+   [QUIC-TLS]), all packets that were sent with those keys can no longer
+   be acknowledged because their acknowledgements cannot be processed
+   anymore.  The sender MUST discard all recovery state associated with
+   those packets and MUST remove them from the count of bytes in flight.
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 17]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   Endpoints stop sending and receiving Initial packets once they start
+   exchanging Handshake packets; see Section 17.2.2.1 of
+   [QUIC-TRANSPORT].  At this point, recovery state for all in-flight
+   Initial packets is discarded.
+
+   When 0-RTT is rejected, recovery state for all in-flight 0-RTT
+   packets is discarded.
+
+   If a server accepts 0-RTT, but does not buffer 0-RTT packets that
+   arrive before Initial packets, early 0-RTT packets will be declared
+   lost, but that is expected to be infrequent.
+
+   It is expected that keys are discarded after packets encrypted with
+   them would be acknowledged or declared lost.  Initial secrets however
+   might be destroyed sooner, as soon as handshake keys are available;
+   see Section 4.11.1 of [QUIC-TLS].
+
+6.  Congestion Control
+
+   This document specifies a congestion controller for QUIC similar to
+   TCP NewReno [RFC6582].
+
+   The signals QUIC provides for congestion control are generic and are
+   designed to support different algorithms.  Endpoints can unilaterally
+   choose a different algorithm to use, such as Cubic [RFC8312].
+
+   If an endpoint uses a different controller than that specified in
+   this document, the chosen controller MUST conform to the congestion
+   control guidelines specified in Section 3.1 of [RFC8085].
+
+   Similar to TCP, packets containing only ACK frames do not count
+   towards bytes in flight and are not congestion controlled.  Unlike
+   TCP, QUIC can detect the loss of these packets and MAY use that
+   information to adjust the congestion controller or the rate of ACK-
+   only packets being sent, but this document does not describe a
+   mechanism for doing so.
+
+   The algorithm in this document specifies and uses the controller's
+   congestion window in bytes.
+
+   An endpoint MUST NOT send a packet if it would cause bytes_in_flight
+   (see Appendix B.2) to be larger than the congestion window, unless
+   the packet is sent on a PTO timer expiration; see Section 5.2.
+
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 18]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+6.1.  Explicit Congestion Notification
+
+   If a path has been verified to support ECN [RFC3168] [RFC8311], QUIC
+   treats a Congestion Experienced (CE) codepoint in the IP header as a
+   signal of congestion.  This document specifies an endpoint's response
+   when its peer receives packets with the ECN-CE codepoint.
+
+6.2.  Initial and Minimum Congestion Window
+
+   QUIC begins every connection in slow start with the congestion window
+   set to an initial value.  Endpoints SHOULD use an initial congestion
+   window of 10 times the maximum datagram size (max_datagram_size),
+   limited to the larger of 14720 or twice the maximum datagram size.
+   This follows the analysis and recommendations in [RFC6928],
+   increasing the byte limit to account for the smaller 8 byte overhead
+   of UDP compared to the 20 byte overhead for TCP.
+
+   Prior to validating the client's address, the server can be further
+   limited by the anti-amplification limit as specified in Section 8.1
+   of [QUIC-TRANSPORT].  Though the anti-amplification limit can prevent
+   the congestion window from being fully utilized and therefore slow
+   down the increase in congestion window, it does not directly affect
+   the congestion window.
+
+   The minimum congestion window is the smallest value the congestion
+   window can decrease to as a response to loss, ECN-CE, or persistent
+   congestion.  The RECOMMENDED value is 2 * max_datagram_size.
+
+6.3.  Slow Start
+
+   While in slow start, QUIC increases the congestion window by the
+   number of bytes acknowledged when each acknowledgment is processed,
+   resulting in exponential growth of the congestion window.
+
+   QUIC exits slow start upon loss or upon increase in the ECN-CE
+   counter.  When slow start is exited, the congestion window halves and
+   the slow start threshold is set to the new congestion window.  QUIC
+   re-enters slow start any time the congestion window is less than the
+   slow start threshold, which only occurs after persistent congestion
+   is declared.
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 19]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+6.4.  Congestion Avoidance
+
+   Slow start exits to congestion avoidance.  Congestion avoidance uses
+   an Additive Increase Multiplicative Decrease (AIMD) approach that
+   increases the congestion window by one maximum packet size per
+   congestion window acknowledged.  When a loss or ECN-CE marking is
+   detected, NewReno halves the congestion window, sets the slow start
+   threshold to the new congestion window, and then enters the recovery
+   period.
+
+6.5.  Recovery Period
+
+   A recovery period is entered when loss or ECN-CE marking of a packet
+   is detected in congestion avoidance after the congestion window and
+   slow start threshold have been decreased.  A recovery period ends
+   when a packet sent during the recovery period is acknowledged.  This
+   is slightly different from TCP's definition of recovery, which ends
+   when the lost packet that started recovery is acknowledged.
+
+   The recovery period aims to limit congestion window reduction to once
+   per round trip.  Therefore during recovery, the congestion window
+   remains unchanged irrespective of new losses or increases in the ECN-
+   CE counter.
+
+   When entering recovery, a single packet MAY be sent even if bytes in
+   flight now exceeds the recently reduced congestion window.  This
+   speeds up loss recovery if the data in the lost packet is
+   retransmitted and is similar to TCP as described in Section 5 of
+   [RFC6675].  If further packets are lost while the sender is in
+   recovery, sending any packets in response MUST obey the congestion
+   window limit.
+
+6.6.  Ignoring Loss of Undecryptable Packets
+
+   During the handshake, some packet protection keys might not be
+   available when a packet arrives and the receiver can choose to drop
+   the packet.  In particular, Handshake and 0-RTT packets cannot be
+   processed until the Initial packets arrive and 1-RTT packets cannot
+   be processed until the handshake completes.  Endpoints MAY ignore the
+   loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived
+   before the peer had packet protection keys to process those packets.
+   Endpoints MUST NOT ignore the loss of packets that were sent after
+   the earliest acknowledged packet in a given packet number space.
+
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 20]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+6.7.  Probe Timeout
+
+   Probe packets MUST NOT be blocked by the congestion controller.  A
+   sender MUST however count these packets as being additionally in
+   flight, since these packets add network load without establishing
+   packet loss.  Note that sending probe 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.
+
+6.8.  Persistent Congestion
+
+   When an ACK frame is received that establishes loss of all in-flight
+   packets sent over a long enough period of time, the network is
+   considered to be experiencing persistent congestion.  Commonly, this
+   can be established by consecutive PTOs, but since the PTO timer is
+   reset when a new ack-eliciting packet is sent, an explicit duration
+   must be used to account for those cases where PTOs do not occur or
+   are substantially delayed.  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) [RACK], before establishing
+   persistent congestion, as TCP does with a Retransmission Timeout
+   (RTO) [RFC5681].  The RECOMMENDED value for
+   kPersistentCongestionThreshold is 3, which is approximately
+   equivalent to two TLPs before an RTO in TCP.
+
+   This duration is computed as follows:
+
+   (smoothed_rtt + 4 * rttvar + max_ack_delay) *
+       kPersistentCongestionThreshold
+
+   For example, assume:
+
+   smoothed_rtt = 1
+   rttvar = 0
+   max_ack_delay = 0
+   kPersistentCongestionThreshold = 3
+
+   If an ack-eliciting packet is sent at time t = 0, the following
+   scenario would illustrate persistent congestion:
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 21]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+                     +------+------------------------+
+                     | Time | Action                 |
+                     +======+========================+
+                     | t=0  | Send Pkt #1 (App Data) |
+                     +------+------------------------+
+                     | t=1  | Send Pkt #2 (PTO 1)    |
+                     +------+------------------------+
+                     | t=3  | Send Pkt #3 (PTO 2)    |
+                     +------+------------------------+
+                     | t=7  | Send Pkt #4 (PTO 3)    |
+                     +------+------------------------+
+                     | t=8  | Recv ACK of Pkt #4     |
+                     +------+------------------------+
+
+                                  Table 1
+
+   The first three packets are determined to be lost when the
+   acknowledgement of packet 4 is received at t = 8.  The congestion
+   period is calculated as the time between the oldest and newest lost
+   packets: (3 - 0) = 3.  The duration for persistent congestion is
+   equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the
+   threshold was reached and because none of the packets between the
+   oldest and the newest packets are acknowledged, the network is
+   considered to have experienced persistent congestion.
+
+   When persistent congestion is established, the sender's congestion
+   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] after
+   Tail Loss Probes (TLP) [RACK].
+
+6.9.  Pacing
+
+   This document does not specify a pacer, but it is RECOMMENDED that a
+   sender pace sending of all in-flight packets based on input from the
+   congestion controller.  Sending multiple packets into the network
+   without any delay between them creates a packet burst that might
+   cause short-term congestion and losses.  Implementations MUST either
+   use pacing or another method to limit such bursts to the initial
+   congestion window; see Section 6.2.
+
+   An implementation should take care to architect its congestion
+   controller to work well with a pacer.  For instance, a pacer might
+   wrap the congestion controller and control the availability of the
+   congestion window, or a pacer might pace out packets handed to it by
+   the congestion controller.
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 22]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   Timely delivery of ACK frames is important for efficient loss
+   recovery.  Packets containing only ACK frames SHOULD therefore not be
+   paced, to avoid delaying their delivery to the peer.
+
+   Endpoints can implement pacing as they choose.  A perfectly paced
+   sender spreads packets exactly evenly over time.  For a window-based
+   congestion controller, such as the one in this document, that rate
+   can be computed by averaging the congestion window over the round-
+   trip time.  Expressed as a rate in bytes:
+
+   rate = N * congestion_window / smoothed_rtt
+
+   Or, expressed as an inter-packet interval:
+
+   interval = smoothed_rtt * packet_size / congestion_window / N
+
+   Using a value for "N" that is small, but at least 1 (for example,
+   1.25) ensures that variations in round-trip time don't result in
+   under-utilization of the congestion window.  Values of 'N' larger
+   than 1 ultimately result in sending packets as acknowledgments are
+   received rather than when timers fire, provided the congestion window
+   is fully utilized and acknowledgments arrive at regular intervals.
+
+   Practical considerations, such as packetization, scheduling delays,
+   and computational efficiency, can cause a sender to deviate from this
+   rate over time periods that are much shorter than a round-trip time.
+
+   One possible implementation strategy for pacing uses a leaky bucket
+   algorithm, where the capacity of the "bucket" is limited to the
+   maximum burst size and the rate the "bucket" fills is determined by
+   the above function.
+
+6.10.  Under-utilizing the Congestion Window
+
+   When bytes in flight is smaller than the congestion window and
+   sending is not pacing limited, the congestion window is under-
+   utilized.  When this occurs, the congestion window SHOULD NOT be
+   increased in either slow start or congestion avoidance.  This can
+   happen due to insufficient application data or flow control limits.
+
+   A sender MAY use the pipeACK method described in Section 4.3 of
+   [RFC7661] to determine if the congestion window is sufficiently
+   utilized.
+
+   A sender that paces packets (see Section 6.9) might delay sending
+   packets and not fully utilize the congestion window due to this
+   delay.  A sender SHOULD NOT consider itself application limited if it
+   would have fully utilized the congestion window without pacing delay.
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 23]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   A sender MAY implement alternative mechanisms to update its
+   congestion window after periods of under-utilization, such as those
+   proposed for TCP in [RFC7661].
+
+7.  Security Considerations
+
+7.1.  Congestion Signals
+
+   Congestion control fundamentally involves the consumption of signals
+   - both loss and ECN codepoints - from unauthenticated entities.  On-
+   path attackers can spoof or alter these signals.  An attacker can
+   cause endpoints to reduce their sending rate by dropping packets, or
+   alter send rate by changing ECN codepoints.
+
+7.2.  Traffic Analysis
+
+   Packets that carry only ACK frames can be heuristically identified by
+   observing packet size.  Acknowledgement patterns may expose
+   information about link characteristics or application behavior.
+   Endpoints can use PADDING frames or bundle acknowledgments with other
+   frames to reduce leaked information.
+
+7.3.  Misreporting ECN Markings
+
+   A receiver can misreport ECN markings to alter the congestion
+   response of a sender.  Suppressing reports of ECN-CE markings could
+   cause a sender to increase their send rate.  This increase could
+   result in congestion and loss.
+
+   A sender MAY attempt to detect suppression of reports by marking
+   occasional packets that they send with ECN-CE.  If a packet sent with
+   ECN-CE is not reported as having been CE marked when the packet is
+   acknowledged, then the sender SHOULD disable ECN for that path.
+
+   Reporting additional ECN-CE markings will cause a sender to reduce
+   their sending rate, which is similar in effect to advertising reduced
+   connection flow control limits and so no advantage is gained by doing
+   so.
+
+   Endpoints choose the congestion controller that they use.  Though
+   congestion controllers generally treat reports of ECN-CE markings as
+   equivalent to loss [RFC8311], the exact response for each controller
+   could be different.  Failure to correctly respond to information
+   about ECN markings is therefore difficult to detect.
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 24]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+9.  References
+
+9.1.  Normative References
+
+   [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
+              QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-
+              tls-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-tls-latest>.
+
+   [QUIC-TRANSPORT]
+              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", Work in Progress,
+              Internet-Draft, draft-ietf-quic-transport-latest, 3 June
+              2020, <https://tools.ietf.org/html/draft-ietf-quic-
+              transport-latest>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+              March 2017, <https://www.rfc-editor.org/info/rfc8085>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2.  Informative References
+
+   [FACK]     Mathis, M. and J. Mahdavi, "Forward Acknowledgement:
+              Refining TCP Congestion Control", ACM SIGCOMM , August
+              1996.
+
+   [RACK]     Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK:
+              a time-based fast loss detection algorithm for TCP", Work
+              in Progress, Internet-Draft, draft-ietf-tcpm-rack-08, 9
+              March 2020, <http://www.ietf.org/internet-drafts/draft-
+              ietf-tcpm-rack-08.txt>.
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 25]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, DOI 10.17487/RFC3168, September 2001,
+              <https://www.rfc-editor.org/info/rfc3168>.
+
+   [RFC4653]  Bhandarkar, S., Reddy, A. L. N., Allman, M., and E.
+              Blanton, "Improving the Robustness of TCP to Non-
+              Congestion Events", RFC 4653, DOI 10.17487/RFC4653, August
+              2006, <https://www.rfc-editor.org/info/rfc4653>.
+
+   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
+              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
+              <https://www.rfc-editor.org/info/rfc5681>.
+
+   [RFC5682]  Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,
+              "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
+              Spurious Retransmission Timeouts with TCP", RFC 5682,
+              DOI 10.17487/RFC5682, September 2009,
+              <https://www.rfc-editor.org/info/rfc5682>.
+
+   [RFC5827]  Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and
+              P. Hurtig, "Early Retransmit for TCP and Stream Control
+              Transmission Protocol (SCTP)", RFC 5827,
+              DOI 10.17487/RFC5827, May 2010,
+              <https://www.rfc-editor.org/info/rfc5827>.
+
+   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
+              "Computing TCP's Retransmission Timer", RFC 6298,
+              DOI 10.17487/RFC6298, June 2011,
+              <https://www.rfc-editor.org/info/rfc6298>.
+
+   [RFC6582]  Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
+              NewReno Modification to TCP's Fast Recovery Algorithm",
+              RFC 6582, DOI 10.17487/RFC6582, April 2012,
+              <https://www.rfc-editor.org/info/rfc6582>.
+
+   [RFC6675]  Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
+              and Y. Nishida, "A Conservative Loss Recovery Algorithm
+              Based on Selective Acknowledgment (SACK) for TCP",
+              RFC 6675, DOI 10.17487/RFC6675, August 2012,
+              <https://www.rfc-editor.org/info/rfc6675>.
+
+   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
+              "Increasing TCP's Initial Window", RFC 6928,
+              DOI 10.17487/RFC6928, April 2013,
+              <https://www.rfc-editor.org/info/rfc6928>.
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 26]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   [RFC7661]  Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
+              TCP to Support Rate-Limited Traffic", RFC 7661,
+              DOI 10.17487/RFC7661, October 2015,
+              <https://www.rfc-editor.org/info/rfc7661>.
+
+   [RFC8311]  Black, D., "Relaxing Restrictions on Explicit Congestion
+              Notification (ECN) Experimentation", RFC 8311,
+              DOI 10.17487/RFC8311, January 2018,
+              <https://www.rfc-editor.org/info/rfc8311>.
+
+   [RFC8312]  Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
+              R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
+              RFC 8312, DOI 10.17487/RFC8312, February 2018,
+              <https://www.rfc-editor.org/info/rfc8312>.
+
+Appendix A.  Loss Recovery Pseudocode
+
+   We now describe an example implementation of the loss detection
+   mechanisms described in Section 5.
+
+A.1.  Tracking Sent Packets
+
+   To correctly implement congestion control, a QUIC sender tracks every
+   ack-eliciting packet until the packet is acknowledged or lost.  It is
+   expected that implementations will be able to access this information
+   by packet number and crypto context and store the per-packet fields
+   (Appendix A.1.1) for loss recovery and congestion control.
+
+   After a packet is declared lost, the endpoint can track it for an
+   amount of time comparable to the maximum expected packet reordering,
+   such as 1 RTT.  This allows for detection of spurious
+   retransmissions.
+
+   Sent packets are tracked for each packet number space, and ACK
+   processing only applies to a single space.
+
+A.1.1.  Sent Packet Fields
+
+   packet_number:  The packet number of the sent packet.
+
+   ack_eliciting:  A boolean that indicates whether a packet is ack-
+      eliciting.  If true, it is expected that an acknowledgement will
+      be received, though the peer could delay sending the ACK frame
+      containing it by up to the MaxAckDelay.
+
+   in_flight:  A boolean that indicates whether the packet counts
+      towards bytes in flight.
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 27]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   sent_bytes:  The number of bytes sent in the packet, not including
+      UDP or IP overhead, but including QUIC framing overhead.
+
+   time_sent:  The time the packet was sent.
+
+A.2.  Constants of Interest
+
+   Constants used in loss recovery are based on a combination of RFCs,
+   papers, and common practice.
+
+   kPacketThreshold:  Maximum reordering in packets before packet
+      threshold loss detection considers a packet lost.  The value
+      recommended in Section 5.1.1 is 3.
+
+   kTimeThreshold:  Maximum reordering in time before time threshold
+      loss detection considers a packet lost.  Specified as an RTT
+      multiplier.  The value recommended in Section 5.1.2 is 9/8.
+
+   kGranularity:  Timer granularity.  This is a system-dependent value,
+      and Section 5.1.2 recommends a value of 1ms.
+
+   kInitialRtt:  The RTT used before an RTT sample is taken.  The value
+      recommended in Section 5.2.2 is 500ms.
+
+   kPacketNumberSpace:  An enum to enumerate the three packet number
+      spaces.
+
+     enum kPacketNumberSpace {
+       Initial,
+       Handshake,
+       ApplicationData,
+     }
+
+A.3.  Variables of interest
+
+   Variables required to implement the congestion control mechanisms are
+   described in this section.
+
+   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 Section 4.3.
+
+   rttvar:  The RTT variation, computed as described in Section 4.3.
+
+   min_rtt:  The minimum RTT seen in the connection, ignoring ack delay,
+      as described in Section 4.2.
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 28]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   max_ack_delay:  The maximum amount of time by which the receiver
+      intends to delay acknowledgments for packets in the
+      ApplicationData packet number space.  The actual ack_delay in a
+      received ACK frame may be larger due to late timers, reordering,
+      or lost ACK frames.
+
+   loss_detection_timer:  Multi-modal timer used for loss detection.
+
+   pto_count:  The number of times a PTO has been sent without receiving
+      an ack.
+
+   time_of_last_ack_eliciting_packet[kPacketNumberSpace]:  The time the
+      most recent ack-eliciting packet was sent.
+
+   largest_acked_packet[kPacketNumberSpace]:  The largest packet number
+      acknowledged in the packet number space so far.
+
+   loss_time[kPacketNumberSpace]:  The time at which the next packet in
+      that packet number space will be considered lost based on
+      exceeding the reordering window in time.
+
+   sent_packets[kPacketNumberSpace]:  An association of packet numbers
+      in a packet number space to information about them.  Described in
+      detail above in Appendix A.1.
+
+A.4.  Initialization
+
+   At the beginning of the connection, initialize the loss detection
+   variables as follows:
+
+      loss_detection_timer.reset()
+      pto_count = 0
+      latest_rtt = 0
+      smoothed_rtt = initial_rtt
+      rttvar = initial_rtt / 2
+      min_rtt = 0
+      max_ack_delay = 0
+      for pn_space in [ Initial, Handshake, ApplicationData ]:
+        largest_acked_packet[pn_space] = infinite
+        time_of_last_ack_eliciting_packet[pn_space] = 0
+        loss_time[pn_space] = 0
+
+A.5.  On Sending a Packet
+
+   After a packet is sent, information about the packet is stored.  The
+   parameters to OnPacketSent are described in detail above in
+   Appendix A.1.1.
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 29]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   Pseudocode for OnPacketSent follows:
+
+    OnPacketSent(packet_number, pn_space, ack_eliciting,
+                 in_flight, sent_bytes):
+      sent_packets[pn_space][packet_number].packet_number =
+                                               packet_number
+      sent_packets[pn_space][packet_number].time_sent = now()
+      sent_packets[pn_space][packet_number].ack_eliciting =
+                                               ack_eliciting
+      sent_packets[pn_space][packet_number].in_flight = in_flight
+      if (in_flight):
+        if (ack_eliciting):
+          time_of_last_ack_eliciting_packet[pn_space] = now()
+        OnPacketSentCC(sent_bytes)
+        sent_packets[pn_space][packet_number].size = sent_bytes
+        SetLossDetectionTimer()
+
+A.6.  On Receiving a Datagram
+
+   When a server is blocked by anti-amplification limits, receiving a
+   datagram unblocks it, even if none of the packets in the datagram are
+   successfully processed.  In such a case, the PTO timer will need to
+   be re-armed.
+
+   Pseudocode for OnDatagramReceived follows:
+
+   OnDatagramReceived(datagram):
+     // If this datagram unblocks the server, arm the
+     // PTO timer to avoid deadlock.
+     if (server was at anti-amplification limit):
+       SetLossDetectionTimer()
+
+A.7.  On Receiving an Acknowledgment
+
+   When an ACK frame is received, it may newly acknowledge any number of
+   packets.
+
+   Pseudocode for OnAckReceived and UpdateRtt follow:
+
+   OnAckReceived(ack, pn_space):
+     if (largest_acked_packet[pn_space] == infinite):
+       largest_acked_packet[pn_space] = ack.largest_acked
+     else:
+       largest_acked_packet[pn_space] =
+           max(largest_acked_packet[pn_space], ack.largest_acked)
+
+     // DetectNewlyAckedPackets finds packets that are newly
+     // acknowledged and removes them from sent_packets.
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 30]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+     newly_acked_packets =
+         DetectAndRemoveAckedPackets(ack, pn_space)
+     // Nothing to do if there are no newly acked packets.
+     if (newly_acked_packets.empty()):
+       return
+
+     // If the largest acknowledged is newly acked and
+     // at least one ack-eliciting was newly acked, update the RTT.
+     if (newly_acked_packets.largest().packet_number ==
+             ack.largest_acked &&
+         IncludesAckEliciting(newly_acked_packets)):
+       latest_rtt =
+         now - sent_packets[pn_space][ack.largest_acked].time_sent
+       ack_delay = 0
+       if (pn_space == ApplicationData):
+         ack_delay = ack.ack_delay
+       UpdateRtt(ack_delay)
+
+     // Process ECN information if present.
+     if (ACK frame contains ECN information):
+         ProcessECN(ack, pn_space)
+
+     lost_packets = DetectAndRemoveLostPackets(pn_space)
+     if (!lost_packets.empty()):
+       OnPacketsLost(lost_packets)
+     OnPacketsAcked(newly_acked_packets)
+
+     // Reset pto_count unless the client is unsure if
+     // the server has validated the client's address.
+     if (PeerCompletedAddressValidation()):
+       pto_count = 0
+     SetLossDetectionTimer()
+
+
+   UpdateRtt(ack_delay):
+     if (is first RTT sample):
+       min_rtt = latest_rtt
+       smoothed_rtt = latest_rtt
+       rttvar = latest_rtt / 2
+       return
+
+     // min_rtt ignores ack delay.
+     min_rtt = min(min_rtt, latest_rtt)
+     // Limit ack_delay by max_ack_delay
+     ack_delay = min(ack_delay, max_ack_delay)
+     // Adjust for ack delay if plausible.
+     adjusted_rtt = latest_rtt
+     if (latest_rtt > min_rtt + ack_delay):
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 31]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+       adjusted_rtt = latest_rtt - ack_delay
+
+     rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)
+     smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
+
+A.8.  Setting the Loss Detection Timer
+
+   QUIC loss detection uses a single timer for all timeout loss
+   detection.  The duration of the timer is based on the timer's mode,
+   which is set in the packet and timer events further below.  The
+   function SetLossDetectionTimer defined below shows how the single
+   timer is set.
+
+   This algorithm may result in the timer being set in the past,
+   particularly if timers wake up late.  Timers set in the past fire
+   immediately.
+
+   Pseudocode for SetLossDetectionTimer follows:
+
+   GetLossTimeAndSpace():
+     time = loss_time[Initial]
+     space = Initial
+     for pn_space in [ Handshake, ApplicationData ]:
+       if (time == 0 || loss_time[pn_space] < time):
+         time = loss_time[pn_space];
+         space = pn_space
+     return time, space
+
+   GetPtoTimeAndSpace():
+     duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
+         * (2 ^ pto_count)
+     // Arm PTO from now when there are no inflight packets.
+     if (no in-flight packets):
+       assert(!PeerCompletedAddressValidation())
+       if (has handshake keys):
+         return (now() + duration), Handshake
+       else:
+         return (now() + duration), Initial
+     pto_timeout = infinite
+     pto_space = Initial
+     for space in [ Initial, Handshake, ApplicationData ]:
+       if (no in-flight packets in space):
+           continue;
+       if (space == ApplicationData):
+         // Skip ApplicationData until handshake complete.
+         if (handshake is not complete):
+           return pto_timeout, pto_space
+         // Include max_ack_delay and backoff for ApplicationData.
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 32]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+         duration += max_ack_delay * (2 ^ pto_count)
+
+       t = time_of_last_ack_eliciting_packet[space] + duration
+       if (t < pto_timeout):
+         pto_timeout = t
+         pto_space = space
+     return pto_timeout, pto_space
+
+   PeerCompletedAddressValidation():
+     # Assume clients validate the server's address implicitly.
+     if (endpoint is server):
+       return true
+     # Servers complete address validation when a
+     # protected packet is received.
+     return has received Handshake ACK ||
+          has received 1-RTT ACK ||
+          has received HANDSHAKE_DONE
+
+   SetLossDetectionTimer():
+     earliest_loss_time, _ = GetLossTimeAndSpace()
+     if (earliest_loss_time != 0):
+       // Time threshold loss detection.
+       loss_detection_timer.update(earliest_loss_time)
+       return
+
+     if (server is at anti-amplification limit):
+       // The server's timer is not set if nothing can be sent.
+       loss_detection_timer.cancel()
+       return
+
+     if (no ack-eliciting packets in flight &&
+         PeerCompletedAddressValidation()):
+       // There is nothing to detect lost, so no timer is set.
+       // However, the client needs to arm the timer if the
+       // server might be blocked by the anti-amplification limit.
+       loss_detection_timer.cancel()
+       return
+
+     // Determine which PN space to arm PTO for.
+     timeout, _ = GetPtoTimeAndSpace()
+     loss_detection_timer.update(timeout)
+
+A.9.  On Timeout
+
+   When the loss detection timer expires, the timer's mode determines
+   the action to be performed.
+
+   Pseudocode for OnLossDetectionTimeout follows:
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 33]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   OnLossDetectionTimeout():
+     earliest_loss_time, pn_space = GetLossTimeAndSpace()
+     if (earliest_loss_time != 0):
+       // Time threshold loss Detection
+       lost_packets = DetectLostPackets(pn_space)
+       assert(!lost_packets.empty())
+       OnPacketsLost(lost_packets)
+       SetLossDetectionTimer()
+       return
+
+     if (bytes_in_flight > 0):
+       // PTO. Send new data if available, else retransmit old data.
+       // If neither is available, send a single PING frame.
+       _, pn_space = GetPtoTimeAndSpace()
+       SendOneOrTwoAckElicitingPackets(pn_space)
+     else:
+       assert(endpoint is client without 1-RTT keys)
+       // Client sends an anti-deadlock packet: Initial is padded
+       // to earn more anti-amplification credit,
+       // a Handshake packet proves address ownership.
+       if (has Handshake keys):
+         SendOneAckElicitingHandshakePacket()
+       else:
+         SendOneAckElicitingPaddedInitialPacket()
+
+     pto_count++
+     SetLossDetectionTimer()
+
+A.10.  Detecting Lost Packets
+
+   DetectAndRemoveLostPackets is called every time an ACK is received or
+   the time threshold loss detection timer expires.  This function
+   operates on the sent_packets for that packet number space and returns
+   a list of packets newly detected as lost.
+
+   Pseudocode for DetectAndRemoveLostPackets follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 34]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   DetectAndRemoveLostPackets(pn_space):
+     assert(largest_acked_packet[pn_space] != infinite)
+     loss_time[pn_space] = 0
+     lost_packets = {}
+     loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)
+
+     // Minimum time of kGranularity before packets are deemed lost.
+     loss_delay = max(loss_delay, kGranularity)
+
+     // Packets sent before this time are deemed lost.
+     lost_send_time = now() - loss_delay
+
+     foreach unacked in sent_packets[pn_space]:
+       if (unacked.packet_number > largest_acked_packet[pn_space]):
+         continue
+
+       // Mark packet as lost, or set time when it should be marked.
+       if (unacked.time_sent <= lost_send_time ||
+           largest_acked_packet[pn_space] >=
+             unacked.packet_number + kPacketThreshold):
+         sent_packets[pn_space].remove(unacked.packet_number)
+         if (unacked.in_flight):
+           lost_packets.insert(unacked)
+       else:
+         if (loss_time[pn_space] == 0):
+           loss_time[pn_space] = unacked.time_sent + loss_delay
+         else:
+           loss_time[pn_space] = min(loss_time[pn_space],
+                                     unacked.time_sent + loss_delay)
+     return lost_packets
+
+Appendix B.  Congestion Control Pseudocode
+
+   We now describe an example implementation of the congestion
+   controller described in Section 6.
+
+B.1.  Constants of interest
+
+   Constants used in congestion control are based on a combination of
+   RFCs, papers, and common practice.
+
+   kInitialWindow:  Default limit on the initial bytes in flight as
+      described in Section 6.2.
+
+   kMinimumWindow:  Minimum congestion window in bytes as described in
+      Section 6.2.
+
+   kLossReductionFactor:  Reduction in congestion window when a new loss
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 35]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+      event is detected.  The Section 6 section recommends a value is
+      0.5.
+
+   kPersistentCongestionThreshold:  Period of time for persistent
+      congestion to be established, specified as a PTO multiplier.  The
+      Section 6.8 section recommends a value of 3.
+
+B.2.  Variables of interest
+
+   Variables required to implement the congestion control mechanisms are
+   described in this section.
+
+   max_datagram_size:  The sender's current maximum payload size.  Does
+      not include UDP or IP overhead.  The max datagram size is used for
+      congestion window computations.  An endpoint sets the value of
+      this variable based on its PMTU (see Section 14.1 of
+      [QUIC-TRANSPORT]), with a minimum value of 1200 bytes.
+
+   ecn_ce_counters[kPacketNumberSpace]:  The highest value reported for
+      the ECN-CE counter in the packet number space by the peer in an
+      ACK frame.  This value is used to detect increases in the reported
+      ECN-CE counter.
+
+   bytes_in_flight:  The sum of the size in bytes of all sent packets
+      that contain at least one ack-eliciting or PADDING frame, and have
+      not been acked or declared lost.  The size does not include IP or
+      UDP overhead, but does include the QUIC header and AEAD overhead.
+      Packets only containing ACK frames do not count towards
+      bytes_in_flight to ensure congestion control does not impede
+      congestion feedback.
+
+   congestion_window:  Maximum number of bytes-in-flight that may be
+      sent.
+
+   congestion_recovery_start_time:  The time when QUIC first detects
+      congestion due to loss or ECN, causing it to enter congestion
+      recovery.  When a packet sent after this time is acknowledged,
+      QUIC exits congestion recovery.
+
+   ssthresh:  Slow start threshold in bytes.  When the congestion window
+      is below ssthresh, the mode is slow start and the window grows by
+      the number of bytes acknowledged.
+
+B.3.  Initialization
+
+   At the beginning of the connection, initialize the congestion control
+   variables as follows:
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 36]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+      congestion_window = kInitialWindow
+      bytes_in_flight = 0
+      congestion_recovery_start_time = 0
+      ssthresh = infinite
+      for pn_space in [ Initial, Handshake, ApplicationData ]:
+        ecn_ce_counters[pn_space] = 0
+
+B.4.  On Packet Sent
+
+   Whenever a packet is sent, and it contains non-ACK frames, the packet
+   increases bytes_in_flight.
+
+      OnPacketSentCC(bytes_sent):
+        bytes_in_flight += bytes_sent
+
+B.5.  On Packet Acknowledgement
+
+   Invoked from loss detection's OnAckReceived and is supplied with the
+   newly acked_packets from sent_packets.
+
+      InCongestionRecovery(sent_time):
+        return sent_time <= congestion_recovery_start_time
+
+      OnPacketsAcked(acked_packets):
+        for (packet in acked_packets):
+          // Remove from bytes_in_flight.
+          bytes_in_flight -= packet.size
+          if (InCongestionRecovery(packet.time_sent)):
+            // Do not increase congestion window in recovery period.
+            return
+          if (IsAppOrFlowControlLimited()):
+            // Do not increase congestion_window if application
+            // limited or flow control limited.
+            return
+          if (congestion_window < ssthresh):
+            // Slow start.
+            congestion_window += packet.size
+            return
+          // Congestion avoidance.
+          congestion_window += max_datagram_size * acked_packet.size
+              / congestion_window
+
+B.6.  On New Congestion Event
+
+   Invoked from ProcessECN and OnPacketsLost when a new congestion event
+   is detected.  May start a new recovery period and reduces the
+   congestion window.
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 37]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+      CongestionEvent(sent_time):
+        // Start a new congestion event if packet was sent after the
+        // start of the previous congestion recovery period.
+        if (!InCongestionRecovery(sent_time)):
+          congestion_recovery_start_time = now()
+          congestion_window *= kLossReductionFactor
+          congestion_window = max(congestion_window, kMinimumWindow)
+          ssthresh = congestion_window
+          // A packet can be sent to speed up loss recovery.
+          MaybeSendOnePacket()
+
+B.7.  Process ECN Information
+
+   Invoked when an ACK frame with an ECN section is received from the
+   peer.
+
+      ProcessECN(ack, pn_space):
+        // If the ECN-CE counter reported by the peer has increased,
+        // this could be a new congestion event.
+        if (ack.ce_counter > ecn_ce_counters[pn_space]):
+          ecn_ce_counters[pn_space] = ack.ce_counter
+          CongestionEvent(sent_packets[ack.largest_acked].time_sent)
+
+B.8.  On Packets Lost
+
+   Invoked from DetectLostPackets when packets are deemed lost.
+
+      InPersistentCongestion(lost_packets):
+        pto = smoothed_rtt + max(4 * rttvar, kGranularity) +
+          max_ack_delay
+        congestion_period = pto * kPersistentCongestionThreshold
+        // Determine if all packets in the time period before the
+        // largest newly lost packet, including the edges, are
+        // marked lost
+        return AreAllPacketsLost(lost_packets, congestion_period)
+
+      OnPacketsLost(lost_packets):
+        // Remove lost packets from bytes_in_flight.
+        for (lost_packet : lost_packets):
+          bytes_in_flight -= lost_packet.size
+        CongestionEvent(lost_packets.largest().time_sent)
+
+        // Collapse congestion window if persistent congestion
+        if (InPersistentCongestion(lost_packets)):
+          congestion_window = kMinimumWindow
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 38]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+B.9.  Upon dropping Initial or Handshake keys
+
+   When Initial or Handshake keys are discarded, packets from the space
+   are discarded and loss detection state is updated.
+
+   Pseudocode for OnPacketNumberSpaceDiscarded follows:
+
+   OnPacketNumberSpaceDiscarded(pn_space):
+     assert(pn_space != ApplicationData)
+     // Remove any unacknowledged packets from flight.
+     foreach packet in sent_packets[pn_space]:
+       if packet.in_flight
+         bytes_in_flight -= size
+     sent_packets[pn_space].clear()
+     // Reset the loss detection and PTO timer
+     time_of_last_ack_eliciting_packet[pn_space] = 0
+     loss_time[pn_space] = 0
+     pto_count = 0
+     SetLossDetectionTimer()
+
+Appendix C.  Change Log
+
+      *RFC Editor's Note:* Please remove this section prior to
+      publication of a final version of this document.
+
+   Issue and pull request numbers are listed with a leading octothorp.
+
+C.1.  Since draft-ietf-quic-recovery-27
+
+   *  Added recommendations for speeding up handshake under some loss
+      conditions (#3078, #3080)
+
+   *  PTO count is reset when handshake progress is made (#3272, #3415)
+
+   *  PTO count is not reset by a client when the server might be
+      awaiting address validation (#3546, #3551)
+
+   *  Recommend repairing losses immediately after entering the recovery
+      period (#3335, #3443)
+
+   *  Clarified what loss conditions can be ignored during the handshake
+      (#3456, #3450)
+
+   *  Allow, but don't recommend, using RTT from previous connection to
+      seed RTT (#3464, #3496)
+
+   *  Recommend use of adaptive loss detection thresholds (#3571, #3572)
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 39]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+C.2.  Since draft-ietf-quic-recovery-26
+
+   No changes.
+
+C.3.  Since draft-ietf-quic-recovery-25
+
+   No significant changes.
+
+C.4.  Since draft-ietf-quic-recovery-24
+
+   *  Require congestion control of some sort (#3247, #3244, #3248)
+
+   *  Set a minimum reordering threshold (#3256, #3240)
+
+   *  PTO is specific to a packet number space (#3067, #3074, #3066)
+
+C.5.  Since draft-ietf-quic-recovery-23
+
+   *  Define under-utilizing the congestion window (#2630, #2686, #2675)
+
+   *  PTO MUST send data if possible (#3056, #3057)
+
+   *  Connection Close is not ack-eliciting (#3097, #3098)
+
+   *  MUST limit bursts to the initial congestion window (#3160)
+
+   *  Define the current max_datagram_size for congestion control
+      (#3041, #3167)
+
+C.6.  Since draft-ietf-quic-recovery-22
+
+   *  PTO should always send an ack-eliciting packet (#2895)
+
+   *  Unify the Handshake Timer with the PTO timer (#2648, #2658, #2886)
+
+   *  Move ACK generation text to transport draft (#1860, #2916)
+
+C.7.  Since draft-ietf-quic-recovery-21
+
+   *  No changes
+
+C.8.  Since draft-ietf-quic-recovery-20
+
+   *  Path validation can be used as initial RTT value (#2644, #2687)
+
+   *  max_ack_delay transport parameter defaults to 0 (#2638, #2646)
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 40]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   *  Ack Delay only measures intentional delays induced by the
+      implementation (#2596, #2786)
+
+C.9.  Since draft-ietf-quic-recovery-19
+
+   *  Change kPersistentThreshold from an exponent to a multiplier
+      (#2557)
+
+   *  Send a PING if the PTO timer fires and there's nothing to send
+      (#2624)
+
+   *  Set loss delay to at least kGranularity (#2617)
+
+   *  Merge application limited and sending after idle sections.  Always
+      limit burst size instead of requiring resetting CWND to initial
+      CWND after idle (#2605)
+
+   *  Rewrite RTT estimation, allow RTT samples where a newly acked
+      packet is ack-eliciting but the largest_acked is not (#2592)
+
+   *  Don't arm the handshake timer if there is no handshake data
+      (#2590)
+
+   *  Clarify that the time threshold loss alarm takes precedence over
+      the crypto handshake timer (#2590, #2620)
+
+   *  Change initial RTT to 500ms to align with RFC6298 (#2184)
+
+C.10.  Since draft-ietf-quic-recovery-18
+
+   *  Change IW byte limit to 14720 from 14600 (#2494)
+
+   *  Update PTO calculation to match RFC6298 (#2480, #2489, #2490)
+
+   *  Improve loss detection's description of multiple packet number
+      spaces and pseudocode (#2485, #2451, #2417)
+
+   *  Declare persistent congestion even if non-probe packets are sent
+      and don't make persistent congestion more aggressive than RTO
+      verified was (#2365, #2244)
+
+   *  Move pseudocode to the appendices (#2408)
+
+   *  What to send on multiple PTOs (#2380)
+
+C.11.  Since draft-ietf-quic-recovery-17
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 41]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   *  After Probe Timeout discard in-flight packets or send another
+      (#2212, #1965)
+
+   *  Endpoints discard initial keys as soon as handshake keys are
+      available (#1951, #2045)
+
+   *  0-RTT state is discarded when 0-RTT is rejected (#2300)
+
+   *  Loss detection timer is cancelled when ack-eliciting frames are in
+      flight (#2117, #2093)
+
+   *  Packets are declared lost if they are in flight (#2104)
+
+   *  After becoming idle, either pace packets or reset the congestion
+      controller (#2138, 2187)
+
+   *  Process ECN counts before marking packets lost (#2142)
+
+   *  Mark packets lost before resetting crypto_count and pto_count
+      (#2208, #2209)
+
+   *  Congestion and loss recovery state are discarded when keys are
+      discarded (#2327)
+
+C.12.  Since draft-ietf-quic-recovery-16
+
+   *  Unify TLP and RTO into a single PTO; eliminate min RTO, min TLP
+      and min crypto timeouts; eliminate timeout validation (#2114,
+      #2166, #2168, #1017)
+
+   *  Redefine how congestion avoidance in terms of when the period
+      starts (#1928, #1930)
+
+   *  Document what needs to be tracked for packets that are in flight
+      (#765, #1724, #1939)
+
+   *  Integrate both time and packet thresholds into loss detection
+      (#1969, #1212, #934, #1974)
+
+   *  Reduce congestion window after idle, unless pacing is used (#2007,
+      #2023)
+
+   *  Disable RTT calculation for packets that don't elicit
+      acknowledgment (#2060, #2078)
+
+   *  Limit ack_delay by max_ack_delay (#2060, #2099)
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 42]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   *  Initial keys are discarded once Handshake keys are available
+      (#1951, #2045)
+
+   *  Reorder ECN and loss detection in pseudocode (#2142)
+
+   *  Only cancel loss detection timer if ack-eliciting packets are in
+      flight (#2093, #2117)
+
+C.13.  Since draft-ietf-quic-recovery-14
+
+   *  Used max_ack_delay from transport params (#1796, #1782)
+
+   *  Merge ACK and ACK_ECN (#1783)
+
+C.14.  Since draft-ietf-quic-recovery-13
+
+   *  Corrected the lack of ssthresh reduction in CongestionEvent
+      pseudocode (#1598)
+
+   *  Considerations for ECN spoofing (#1426, #1626)
+
+   *  Clarifications for PADDING and congestion control (#837, #838,
+      #1517, #1531, #1540)
+
+   *  Reduce early retransmission timer to RTT/8 (#945, #1581)
+
+   *  Packets are declared lost after an RTO is verified (#935, #1582)
+
+C.15.  Since draft-ietf-quic-recovery-12
+
+   *  Changes to manage separate packet number spaces and encryption
+      levels (#1190, #1242, #1413, #1450)
+
+   *  Added ECN feedback mechanisms and handling; new ACK_ECN frame
+      (#804, #805, #1372)
+
+C.16.  Since draft-ietf-quic-recovery-11
+
+   No significant changes.
+
+C.17.  Since draft-ietf-quic-recovery-10
+
+   *  Improved text on ack generation (#1139, #1159)
+
+   *  Make references to TCP recovery mechanisms informational (#1195)
+
+   *  Define time_of_last_sent_handshake_packet (#1171)
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 43]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   *  Added signal from TLS the data it includes needs to be sent in a
+      Retry packet (#1061, #1199)
+
+   *  Minimum RTT (min_rtt) is initialized with an infinite value
+      (#1169)
+
+C.18.  Since draft-ietf-quic-recovery-09
+
+   No significant changes.
+
+C.19.  Since draft-ietf-quic-recovery-08
+
+   *  Clarified pacing and RTO (#967, #977)
+
+C.20.  Since draft-ietf-quic-recovery-07
+
+   *  Include Ack Delay in RTO(and TLP) computations (#981)
+
+   *  Ack Delay in SRTT computation (#961)
+
+   *  Default RTT and Slow Start (#590)
+
+   *  Many editorial fixes.
+
+C.21.  Since draft-ietf-quic-recovery-06
+
+   No significant changes.
+
+C.22.  Since draft-ietf-quic-recovery-05
+
+   *  Add more congestion control text (#776)
+
+C.23.  Since draft-ietf-quic-recovery-04
+
+   No significant changes.
+
+C.24.  Since draft-ietf-quic-recovery-03
+
+   No significant changes.
+
+C.25.  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)
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 44]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   *  Simplify RTO calculations (#142, #417)
+
+C.26.  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
+
+C.27.  Since draft-ietf-quic-recovery-00
+
+   *  Improved description of constants and ACK behavior
+
+C.28.  Since draft-iyengar-quic-loss-recovery-01
+
+   *  Adopted as base for draft-ietf-quic-recovery
+
+   *  Updated authors/editors list
+
+   *  Added table of contents
+
+Appendix D.  Contributors
+
+   The IETF QUIC Working Group received an enormous amount of support
+   from many people.  The following people provided substantive
+   contributions to this document: Alessandro Ghedini, Benjamin
+   Saunders, Gorry Fairhurst, 奥 一穂 (Kazuho Oku), Lars Eggert, Magnus
+   Westerlund, Marten Seemann, Martin Duke, Martin Thomson, Nick Banks,
+   Praveen Balasubramaniam.
+
+Acknowledgments
+
+Authors' Addresses
+
+   Jana Iyengar (editor)
+   Fastly
+
+   Email: jri.ietf@gmail.com
+
+
+   Ian Swett (editor)
+   Google
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 45]
+
+Internet-Draft             QUIC Loss Detection                 June 2020
+
+
+   Email: ianswett@google.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Swett          Expires 5 December 2020               [Page 46]
diff --git a/jri/mustnot/draft-ietf-quic-tls.html b/jri/mustnot/draft-ietf-quic-tls.html
new file mode 100644
index 0000000000..52ee30c78f
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-tls.html
@@ -0,0 +1,3919 @@
+<!DOCTYPE html>
+<html lang="en" class="Internet-Draft">
+<head>
+<meta charset="utf-8">
+<meta content="Common,Latin" name="scripts">
+<meta content="initial-scale=1.0" name="viewport">
+<title>Using TLS to Secure QUIC</title>
+<meta content="Martin Thomson" name="author">
+<meta content="Sean Turner" name="author">
+<meta content="
+       This document describes how Transport Layer Security (TLS) is used to secure
+QUIC. 
+    " name="description">
+<meta content="xml2rfc 2.45.2" name="generator">
+<meta content="draft-ietf-quic-tls-latest" name="ietf.draft">
+<link href="draft-ietf-quic-tls.xml" rel="alternate" type="application/rfc+xml">
+<link href="#copyright" rel="license">
+<style type="text/css">@import url('https://martinthomson.github.io/i-d-template/fonts.css');
+
+html {
+  --background-color: #fff;
+  --text-color: #222;
+  --title-color: #191919;
+  --link-color: #2a6496;
+  --highlight-color: #f9f9f9;
+  --line-color: #eee;
+  --small-font-size: 14.5px;
+}
+body {
+  max-width: 600px;
+  margin: 75px auto;
+  padding: 0 5px;
+  color: var(--text-color);
+  background-color: var(--background-color);
+  font: 16px/22px "Lora", serif;
+  scroll-behavior: smooth;
+}
+
+.ears {
+  display: none;
+}
+
+/* headings */
+#title, h1, h2, h3, h4, h5, h6 {
+  font-family: "Cabin Condensed", sans-serif;
+  font-weight: 600;
+  margin: 0.8em 0 0.3em;
+  font-size-adjust: 0.5;
+  color: var(--title-color);
+}
+#title {
+  padding: 1em 0 0.2em;
+  font-size: 32px;
+  line-height: 40px;
+  clear: both;
+}
+h1, h2, h3 {
+  font-size: 22px;
+  line-height: 26px;
+}
+h4, h5, h6 {
+  font-size: 18px;
+  line-height: 22px;
+}
+
+/* general structure */
+.author {
+  padding-bottom: 0.3em;
+}
+#abstract+p, #abstract+p code, #abstract+p samp, #abstract+p tt {
+  font-size: 18px;
+  line-height: 24px;
+}
+p {
+  padding: 0;
+  margin: 0.5em 0;
+  text-align: left;
+}
+div, span {
+  position: relative;
+}
+div {
+  margin: 0;
+}
+.alignRight.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignRight.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignRight {
+  margin: 1em 0;
+}
+.alignRight > *:first-child {
+  border: none;
+  margin: 0;
+  float: right;
+  clear: both;
+}
+.alignRight > *:nth-child(2) {
+  clear: both;
+  display: block;
+  border: none;
+}
+svg {
+  display: block;
+}
+.alignCenter.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignCenter.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignCenter {
+  margin: 1em 0;
+}
+.alignCenter > *:first-child {
+  border: none;
+  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
+     support flexbox yet.
+  */
+  display: table;
+  margin: 0 auto;
+}
+
+/* lists */
+ol, ul {
+  padding: 0;
+  margin: 0 0 1em 2em;
+}
+ol ol, ul ul, ol ul, ul ol {
+  margin-left: 1em;
+}
+li {
+  margin: 0 0 0.25em 0;
+}
+.ulCompact li {
+  margin: 0;
+}
+ul.empty, .ulEmpty {
+  list-style-type: none;
+}
+ul.empty li, .ulEmpty li {
+  margin-top: 0.5em;
+}
+ul.compact, .ulCompact,
+ol.compact, .olCompact {
+  line-height: 100%;
+  margin: 0 0 0 2em;
+}
+
+/* definition lists */
+dl {
+}
+dl > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl > dd {
+  margin-bottom: .8em;
+  min-height: 1.3em;
+}
+dl.compact > dd, .dlCompact > dd {
+  margin-bottom: 0em;
+}
+dl > dd > dl {
+  margin-top: 0.5em;
+  margin-bottom: 0em;
+}
+dd.break {
+  display: none;
+}
+
+/* links */
+a, a[href].selfRef:hover {
+  text-decoration: none;
+}
+a[href].selfRef {
+  color: var(--text-color);
+}
+a[href] {
+  color: var(--link-color);
+}
+a[href]:hover {
+  text-decoration: underline;
+}
+a[href].selfRef:hover {
+  background-color: var(--highlight-color);
+}
+a.xref {
+  white-space: nowrap;
+}
+
+/* Figures */
+tt, code, pre {
+  background-color: var(--highlight-color);
+  font: 14px/22px 'Oxygen Mono', monospace;
+}
+pre {
+  border: 1px solid var(--line-color);
+  font-size: 13.5px;
+  line-height: 16px;
+  letter-spacing: -0.2px;
+  margin: 5px;
+  padding: 5px;
+}
+img {
+  max-width: 100%;
+}
+figure {
+  margin: 0.5em 0;
+}
+figure blockquote {
+  margin: 0.8em 0.4em 0.4em;
+}
+figcaption, caption {
+  font-style: italic;
+  margin: 0.5em 1.5em;
+  text-align: left;
+}
+@media screen {
+  pre {
+    display: inline-block;
+    overflow-x: auto;
+    max-width: 100%;
+    width: calc(100% - 22px - 1em);
+  }
+  figure pre {
+    display: block;
+    width: calc(100% - 25px);
+  }
+  pre + .pilcrow {
+    display: inline-block;
+    vertical-align: text-bottom;
+    padding-bottom: 8px;
+  }
+  table {
+    display: inline-block;
+    overflow-x: auto;
+  }
+}
+
+/* aside, blockquote */
+aside, blockquote {
+  margin-left: 0;
+  padding: 0 2em;
+  font-style: italic;
+}
+blockquote {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  margin: 1em 0;
+}
+cite {
+  display: block;
+  text-align: right;
+  font-style: italic;
+}
+
+/* tables */
+table {
+  width: 100%;
+  margin: 0 0 1em;
+  border-collapse: collapse;
+}
+thead, tbody {
+  border: 1px solid var(--line-color);
+}
+th, td {
+  text-align: left;
+  vertical-align: top;
+  padding: 5px 10px;
+}
+th {
+  text-align: left;
+  background-color: #eee;
+}
+tr:nth-child(2n) > td {
+  background-color: var(--background-color);
+}
+tr:nth-child(2n+1) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n+1) > td {
+  background-color: var(--background-color);
+}
+table caption {
+  margin: 0;
+  padding: 3px 1em;
+}
+table p {
+  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
+     be allowed within tables more generally, it would be far better to select on a class. */
+  margin: 0;
+}
+
+/* pilcrow */
+a.pilcrow {
+  margin-left: 3px;
+  visibility: hidden;
+  user-select: none;
+}
+a.pilcrow[href] { color: #ddd; }
+a.pilcrow[href]:hover { text-decoration: none; }
+@media screen {
+  :hover > a.pilcrow {
+    visibility: visible;
+  }
+  a.pilcrow:hover {
+    background-color: transparent;
+  }
+}
+
+/* misc */
+hr {
+  border: 0;
+  border-top: 1px solid var(--line-color);
+}
+.bcp14 {
+  font-variant: small-caps;
+}
+
+.role {
+  font-variant: all-small-caps;
+}
+
+/* info block */
+#identifiers {
+  margin: 0;
+  font-size: var(--small-font-size);
+  line-height: 18px;
+  --identifier-width: 8em;
+}
+#identifiers dt {
+  width: var(--identifier-width);
+  margin: 0;
+  clear: left;
+  float: left;
+  text-align: right;
+}
+#identifiers dd {
+  margin: 0 0 0 calc(1em + var(--identifier-width));
+  min-width: 5em;
+}
+#identifiers .authors .author {
+  display: inline-block;
+  margin-right: 1.5em;
+}
+#identifiers .authors .org {
+  font-style: italic;
+}
+
+/* The prepared/rendered info at the very bottom of the page */
+.docInfo {
+  color: #999;
+  font-size: 0.9em;
+  font-style: italic;
+  margin-top: 2em;
+}
+.docInfo .prepared {
+  float: left;
+}
+.docInfo .prepared {
+  float: right;
+}
+
+/* table of contents */
+#toc {
+  padding: 0.75em 0 2em 0;
+  margin-bottom: 1em;
+}
+#toc nav ul {
+  margin: 0 0.5em 0 0;
+  padding: 0;
+  list-style: none;
+}
+#toc nav li {
+  line-height: 1.3em;
+  margin: 0.75em 0;
+  padding-left: 1.2em;
+  text-indent: -1.2em;
+}
+#toc a.xref {
+  white-space: normal;
+}
+/* references */
+.references dt {
+  text-align: right;
+  font-weight: bold;
+  min-width: 7em;
+}
+.references dd {
+  margin-left: 8em;
+  overflow: auto;
+}
+
+.refInstance {
+  margin-bottom: 1.25em;
+}
+
+.references .ascii {
+  margin-bottom: 0.25em;
+}
+
+/* index */
+.index ul {
+  margin: 0 0 0 1em;
+  padding: 0;
+  list-style: none;
+}
+.index ul ul {
+  margin: 0;
+}
+.index li {
+  margin: 0;
+  text-indent: -2em;
+  padding-left: 2em;
+  padding-bottom: 5px;
+}
+.indexIndex {
+  margin: 0.5em 0 1em;
+}
+.index a {
+  font-weight: 700;
+}
+/* make the index two-column on all but the smallest screens */
+@media (min-width: 500px) {
+  .index ul {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  .index ul ul {
+    column-count: 1;
+    column-gap: 0;
+  }
+}
+
+/* authors */
+address.vcard {
+  font-style: normal;
+  margin: 1em 0;
+}
+address.vcard .nameRole {
+  font-weight: 700;
+  margin-left: 0;
+}
+address.vcard .label {
+  margin: 0.5em 0;
+}
+address.vcard .type {
+  display: none;
+}
+.alternative-contact {
+  margin: 1.5em 0 1em;
+}
+hr.addr {
+  border-top: 1px dashed;
+  margin: 0;
+  color: #ddd;
+  max-width: calc(100% - 16px);
+}
+@media (min-width: 500px) {
+  #authors-addresses > section {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  #authors-addresses > section > h2 {
+    column-span: all;
+  }
+  /* hack for break-inside: avoid-column */
+  #authors-addresses address {
+    display: inline-block;
+    break-inside: avoid-column;
+  }
+}
+
+.rfcEditorRemove p:first-of-type {
+  font-style: italic;
+}
+.cref {
+  background-color: rgba(249, 232, 105, 0.3);
+  padding: 2px 4px;
+}
+.crefSource {
+  font-style: italic;
+}
+/* alternative layout for smaller screens */
+@media screen and (max-width: 929px) {
+  #toc {
+    position: fixed;
+    z-index: 2;
+    top: 0;
+    right: 0;
+    padding: 0;
+    margin: 0;
+    border-bottom: 1px solid #ccc;
+    opacity: 0.6;
+  }
+  #toc.active {
+      opacity: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 2px 0 2px 6px;
+    padding-right: 1em;
+    font-size: 18px;
+    line-height: 24px;
+    min-width: 190px;
+    text-align: right;
+    background-color: #444;
+    color: white;
+    cursor: pointer;
+  }
+  #toc h2::before { /* css hamburger */
+    float: right;
+    position: relative;
+    width: 1em;
+    height: 1px;
+    left: -164px;
+    margin: 8px 0 0 0;
+    background: white none repeat scroll 0 0;
+    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
+    content: "";
+  }
+  #toc nav {
+    display: none;
+    background-color: var(--background-color);
+    padding: 0.5em 1em 1em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    height: calc(100vh - 48px);
+    border-left: 1px solid #ddd;
+  }
+  #toc.active nav {
+    display: block;
+  }
+  /* Make the collapsed ToC header render white on gray also when it's a link */
+  #toc h2 a,
+  #toc h2 a:link,
+  #toc h2 a:focus,
+  #toc h2 a:hover,
+  #toc a.toplink,
+  #toc a.toplink:hover {
+    color: white;
+    background-color: #444;
+    text-decoration: none;
+  }
+  #toc a.toplink {
+    margin-top: 2px;
+  }
+}
+
+/* alternative layout for wide screens */
+@media screen and (min-width: 930px) {
+  body {
+    padding-right: 360px;
+    padding-right: calc(min(180px + 20%, 500px));
+  }
+  #toc {
+    position: fixed;
+    bottom: 0;
+    right: 0;
+    right: calc(50vw - 480px);
+    width: 312px;
+    margin: 0;
+    padding: 0;
+    z-index: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 0.25em 1em 1em 0;
+  }
+  #toc nav {
+    display: block;
+    height: calc(90vh - 84px);
+    bottom: 0;
+    padding: 0.5em 0 2em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    scrollbar-width: thin;
+  }
+  #toc nav > ul  {
+    margin-bottom: 2em;
+  }
+  #toc ul {
+    margin: 0 0 0 4px;
+    font-size: var(--small-font-size);
+  }
+  #toc ul p, #toc ul li {
+    margin: 2px 0;
+    line-height: 22px;
+  }
+  img { /* future proofing */
+    max-width: 100%;
+    height: auto;
+  }
+}
+
+/* pagination */
+@media print {
+  body {
+    width: 100%;
+  }
+  p {
+    orphans: 3;
+    widows: 3;
+  }
+  #n-copyright-notice {
+    border-bottom: none;
+  }
+  #toc, #n-introduction {
+    page-break-before: always;
+  }
+  #toc {
+    border-top: none;
+    padding-top: 0;
+  }
+  figure, pre {
+    page-break-inside: avoid;
+  }
+  figure {
+    overflow: scroll;
+  }
+  h1, h2, h3, h4, h5, h6 {
+    page-break-after: avoid;
+  }
+  h2+*, h3+*, h4+*, h5+*, h6+* {
+    page-break-before: avoid;
+  }
+  pre {
+    white-space: pre-wrap;
+    word-wrap: break-word;
+    font-size: 10pt;
+  }
+  table {
+    border: 1px solid #ddd;
+  }
+  td {
+    border-top: 1px solid #ddd;
+  }
+}
+
+@page :first {
+  padding-top: 0;
+  @top-left {
+    content: normal;
+    border: none;
+  }
+  @top-center {
+    content: normal;
+    border: none;
+  }
+  @top-right {
+    content: normal;
+    border: none;
+  }
+}
+
+@page {
+  size: A4;
+  margin-bottom: 45mm;
+  padding-top: 20px;
+}
+
+/* Changes introduced to fix issues found during implementation */
+
+/* Separate body from document info even without intervening H1 */
+section {
+  clear: both;
+}
+
+/* Top align author divs, to avoid names without organization dropping level with org names */
+.author {
+  vertical-align: top;
+}
+
+/* Style section numbers with more space between number and title */
+.section-number {
+  padding-right: 0.5em;
+}
+
+/* Add styling for a link in the ToC that points to the top of the document */
+a.toplink {
+  float: right;
+  margin: 8px 0.5em 0;
+}
+
+/* Fix the dl styling to match the RFC 7992 attributes */
+dl > dt,
+dl.dlParallel > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl.dlNewline > dt {
+  float: none;
+}
+
+/* Provide styling for table cell text alignment */
+table .text-left, table .text-left {
+  text-align: left;
+}
+table .text-center, table .text-center {
+  text-align: center;
+}
+table .text-right, table .text-right {
+  text-align: right;
+}
+
+/* Make the alternative author contact information look less like just another
+   author, and group it closer with the primary author contact information */
+.alternative-contact {
+  margin: 0.5em 0 0.25em 0;
+}
+address .non-ascii {
+  margin: 0 0 0 2em;
+}
+
+/* With it being possible to set tables with alignment
+  left, center, and right, { width: 100%; } does not make sense */
+table {
+  width: auto;
+}
+
+/* Avoid reference text that sits in a block with very wide left margin,
+   because of a long floating dt label.*/
+.references dd {
+  overflow: visible;
+}
+
+/* Control caption placement */
+caption {
+  caption-side: bottom;
+}
+
+/* Limit the width of the author address vcard, so names in right-to-left
+   script don't end up on the other side of the page. */
+
+address.vcard {
+  max-width: 20em;
+  margin-right: auto;
+}
+
+/* For address alignment dependent on LTR or RTL scripts */
+address div.left {
+  text-align: left;
+}
+address div.right {
+  text-align: right;
+}
+
+/* Provide table alignment support.  We can't use the alignX classes above
+   since they do unwanted things with caption and other styling. */
+table.right {
+ margin-left: auto;
+ margin-right: 0;
+}
+table.center {
+ margin-left: auto;
+ margin-right: auto;
+}
+table.left {
+ margin-left: 0;
+ margin-right: auto;
+}
+
+/* Give the table caption label the same styling as the figcaption */
+
+@media print {
+  .toplink {
+    display: none;
+  }
+
+  /* avoid overwriting the top border line with the ToC header */
+  #toc {
+    padding-top: 1px;
+  }
+
+  /* Avoid page breaks inside dl and author address entries */
+  dd {
+    page-break-before: avoid;
+  }
+  .vcard {
+    page-break-inside: avoid;
+  }
+
+}
+/* Tweak the bcp14 keyword presentation */
+.bcp14 {
+  font-variant: small-caps;
+  font-weight: bold;
+  font-size: 0.9em;
+}
+</style>
+<link href="rfc-local.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<table class="ears">
+<thead><tr>
+<td class="left">Internet-Draft</td>
+<td class="center">Using TLS to Secure QUIC</td>
+<td class="right">June 2020</td>
+</tr></thead>
+<tfoot><tr>
+<td class="left">Thomson &amp; Turner</td>
+<td class="center">Expires 5 December 2020</td>
+<td class="right">[Page]</td>
+</tr></tfoot>
+</table>
+<div id="external-metadata" class="document-information"></div>
+<div id="internal-metadata" class="document-information">
+<dl id="identifiers">
+<dt class="label-workgroup">Workgroup:</dt>
+<dd class="workgroup">QUIC</dd>
+<dt class="label-internet-draft">Internet-Draft:</dt>
+<dd class="internet-draft">draft-ietf-quic-tls-latest</dd>
+<dt class="label-published">Published:</dt>
+<dd class="published">
+<time datetime="2020-06-03" class="published">3 June 2020</time>
+    </dd>
+<dt class="label-intended-status">Intended Status:</dt>
+<dd class="intended-status">Standards Track</dd>
+<dt class="label-expires">Expires:</dt>
+<dd class="expires"><time datetime="2020-12-05">5 December 2020</time></dd>
+<dt class="label-authors">Authors:</dt>
+<dd class="authors">
+<div class="author">
+      <div class="author-name">M. Thomson, <span class="editor">Ed.</span>
+</div>
+<div class="org">Mozilla</div>
+</div>
+<div class="author">
+      <div class="author-name">S. Turner, <span class="editor">Ed.</span>
+</div>
+<div class="org">sn3rd</div>
+</div>
+</dd>
+</dl>
+</div>
+<h1 id="title">Using TLS to Secure QUIC</h1>
+<section id="section-abstract">
+      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
+<p id="section-abstract-1">This document describes how Transport Layer Security (TLS) is used to secure
+QUIC.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.1">
+      <h2 id="name-note-to-readers">
+<a href="#name-note-to-readers" class="section-name selfRef">Note to Readers</a>
+      </h2>
+<p id="section-note.1-1">Discussion of this draft takes place on the QUIC working group mailing list
+(<a href="mailto:quic@ietf.org">quic@ietf.org</a>), which is archived at
+<span><a href="https://mailarchive.ietf.org/arch/search/?email_list=quic">https://mailarchive.ietf.org/arch/search/?email_list=quic</a></span>.<a href="#section-note.1-1" class="pilcrow">¶</a></p>
+<p id="section-note.1-2">Working Group information can be found at <span><a href="https://github.com/quicwg">https://github.com/quicwg</a></span>; source
+code and issues list for this draft can be found at
+<span><a href="https://github.com/quicwg/base-drafts/labels/-tls">https://github.com/quicwg/base-drafts/labels/-tls</a></span>.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
+</section>
+<div id="status-of-memo">
+<section id="section-boilerplate.1">
+        <h2 id="name-status-of-this-memo">
+<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
+        </h2>
+<p id="section-boilerplate.1-1">
+        This Internet-Draft is submitted in full conformance with the
+        provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-2">
+        Internet-Drafts are working documents of the Internet Engineering Task
+        Force (IETF). Note that other groups may also distribute working
+        documents as Internet-Drafts. The list of current Internet-Drafts is
+        at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-3">
+        Internet-Drafts are draft documents valid for a maximum of six months
+        and may be updated, replaced, or obsoleted by other documents at any
+        time. It is inappropriate to use Internet-Drafts as reference
+        material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-4">
+        This Internet-Draft will expire on 5 December 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="copyright">
+<section id="section-boilerplate.2">
+        <h2 id="name-copyright-notice">
+<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
+        </h2>
+<p id="section-boilerplate.2-1">
+            Copyright (c) 2020 IETF Trust and the persons identified as the
+            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.2-2">
+            This document is subject to BCP 78 and the IETF Trust's Legal
+            Provisions Relating to IETF Documents
+            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
+            publication of this document. Please review these documents
+            carefully, as they describe your rights and restrictions with
+            respect to this document. Code Components extracted from this
+            document must include Simplified BSD License text as described in
+            Section 4.e of the Trust Legal Provisions and are provided without
+            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="toc">
+<section id="section-toc.1">
+        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
+<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
+        </h2>
+<nav class="toc"><ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-notational-conventions" class="xref">Notational Conventions</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.1">
+                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-tls-overview" class="xref">TLS Overview</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-protocol-overview" class="xref">Protocol Overview</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-carrying-tls-messages" class="xref">Carrying TLS Messages</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1">
+                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-interface-to-tls" class="xref">Interface to TLS</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1.2.1">
+                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-handshake-complete" class="xref">Handshake Complete</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1.2.2">
+                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-handshake-confirmed" class="xref">Handshake Confirmed</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1.2.3">
+                    <p id="section-toc.1-1.4.2.1.2.3.1"><a href="#section-4.1.3" class="xref">4.1.3</a>.  <a href="#name-sending-and-receiving-hands" class="xref">Sending and Receiving Handshake Messages</a><a href="#section-toc.1-1.4.2.1.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1.2.4">
+                    <p id="section-toc.1-1.4.2.1.2.4.1"><a href="#section-4.1.4" class="xref">4.1.4</a>.  <a href="#name-encryption-level-changes" class="xref">Encryption Level Changes</a><a href="#section-toc.1-1.4.2.1.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1.2.5">
+                    <p id="section-toc.1-1.4.2.1.2.5.1"><a href="#section-4.1.5" class="xref">4.1.5</a>.  <a href="#name-tls-interface-summary" class="xref">TLS Interface Summary</a><a href="#section-toc.1-1.4.2.1.2.5.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2">
+                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-tls-version" class="xref">TLS Version</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.3">
+                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-clienthello-size" class="xref">ClientHello Size</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.4">
+                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-peer-authentication" class="xref">Peer Authentication</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.5">
+                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-session-resumption" class="xref">Session Resumption</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.6">
+                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-enabling-0-rtt" class="xref">Enabling 0-RTT</a><a href="#section-toc.1-1.4.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.7">
+                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-accepting-and-rejecting-0-r" class="xref">Accepting and Rejecting 0-RTT</a><a href="#section-toc.1-1.4.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.8">
+                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="xref">4.8</a>.  <a href="#name-validating-0-rtt-configurat" class="xref">Validating 0-RTT Configuration</a><a href="#section-toc.1-1.4.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.9">
+                <p id="section-toc.1-1.4.2.9.1"><a href="#section-4.9" class="xref">4.9</a>.  <a href="#name-helloretryrequest" class="xref">HelloRetryRequest</a><a href="#section-toc.1-1.4.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.10">
+                <p id="section-toc.1-1.4.2.10.1"><a href="#section-4.10" class="xref">4.10</a>. <a href="#name-tls-errors" class="xref">TLS Errors</a><a href="#section-toc.1-1.4.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.11">
+                <p id="section-toc.1-1.4.2.11.1"><a href="#section-4.11" class="xref">4.11</a>. <a href="#name-discarding-unused-keys" class="xref">Discarding Unused Keys</a><a href="#section-toc.1-1.4.2.11.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.11.2.1">
+                    <p id="section-toc.1-1.4.2.11.2.1.1"><a href="#section-4.11.1" class="xref">4.11.1</a>.  <a href="#name-discarding-initial-keys" class="xref">Discarding Initial Keys</a><a href="#section-toc.1-1.4.2.11.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.11.2.2">
+                    <p id="section-toc.1-1.4.2.11.2.2.1"><a href="#section-4.11.2" class="xref">4.11.2</a>.  <a href="#name-discarding-handshake-keys" class="xref">Discarding Handshake Keys</a><a href="#section-toc.1-1.4.2.11.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.11.2.3">
+                    <p id="section-toc.1-1.4.2.11.2.3.1"><a href="#section-4.11.3" class="xref">4.11.3</a>.  <a href="#name-discarding-0-rtt-keys" class="xref">Discarding 0-RTT Keys</a><a href="#section-toc.1-1.4.2.11.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-packet-protection" class="xref">Packet Protection</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.1">
+                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-packet-protection-keys" class="xref">Packet Protection Keys</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.2">
+                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-initial-secrets" class="xref">Initial Secrets</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.3">
+                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-aead-usage" class="xref">AEAD Usage</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.4">
+                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-header-protection" class="xref">Header Protection</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.4.2.1">
+                    <p id="section-toc.1-1.5.2.4.2.1.1"><a href="#section-5.4.1" class="xref">5.4.1</a>.  <a href="#name-header-protection-applicati" class="xref">Header Protection Application</a><a href="#section-toc.1-1.5.2.4.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.4.2.2">
+                    <p id="section-toc.1-1.5.2.4.2.2.1"><a href="#section-5.4.2" class="xref">5.4.2</a>.  <a href="#name-header-protection-sample" class="xref">Header Protection Sample</a><a href="#section-toc.1-1.5.2.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.4.2.3">
+                    <p id="section-toc.1-1.5.2.4.2.3.1"><a href="#section-5.4.3" class="xref">5.4.3</a>.  <a href="#name-aes-based-header-protection" class="xref">AES-Based Header Protection</a><a href="#section-toc.1-1.5.2.4.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.4.2.4">
+                    <p id="section-toc.1-1.5.2.4.2.4.1"><a href="#section-5.4.4" class="xref">5.4.4</a>.  <a href="#name-chacha20-based-header-prote" class="xref">ChaCha20-Based Header Protection</a><a href="#section-toc.1-1.5.2.4.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.5">
+                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-receiving-protected-packets" class="xref">Receiving Protected Packets</a><a href="#section-toc.1-1.5.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.6">
+                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-use-of-0-rtt-keys" class="xref">Use of 0-RTT Keys</a><a href="#section-toc.1-1.5.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.7">
+                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-receiving-out-of-order-prot" class="xref">Receiving Out-of-Order Protected Frames</a><a href="#section-toc.1-1.5.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5.2.8">
+                <p id="section-toc.1-1.5.2.8.1"><a href="#section-5.8" class="xref">5.8</a>.  <a href="#name-retry-packet-integrity" class="xref">Retry Packet Integrity</a><a href="#section-toc.1-1.5.2.8.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-key-update" class="xref">Key Update</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-initiating-a-key-update" class="xref">Initiating a Key Update</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.2">
+                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-responding-to-a-key-update" class="xref">Responding to a Key Update</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.3">
+                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-timing-of-receive-key-gener" class="xref">Timing of Receive Key Generation</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.4">
+                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-sending-with-updated-keys" class="xref">Sending with Updated Keys</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.5">
+                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-receiving-with-different-ke" class="xref">Receiving with Different Keys</a><a href="#section-toc.1-1.6.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.6">
+                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-key-update-frequency" class="xref">Key Update Frequency</a><a href="#section-toc.1-1.6.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6.2.7">
+                <p id="section-toc.1-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-key-update-error-code" class="xref">Key Update Error Code</a><a href="#section-toc.1-1.6.2.7.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-of-initial-message" class="xref">Security of Initial Messages</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-quic-specific-adjustments-t" class="xref">QUIC-Specific Adjustments to the TLS Handshake</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.1">
+                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-protocol-negotiation" class="xref">Protocol Negotiation</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.2">
+                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-quic-transport-parameters-e" class="xref">QUIC Transport Parameters Extension</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.3">
+                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-removing-the-endofearlydata" class="xref">Removing the EndOfEarlyData Message</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.4">
+                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-prohibit-tls-middlebox-comp" class="xref">Prohibit TLS Middlebox Compatibility Mode</a><a href="#section-toc.1-1.8.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1">
+                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-session-linkability" class="xref">Session Linkability</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2">
+                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-replay-attacks-with-0-rtt" class="xref">Replay Attacks with 0-RTT</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.3">
+                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-packet-reflection-attack-mi" class="xref">Packet Reflection Attack Mitigation</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.4">
+                <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="xref">9.4</a>.  <a href="#name-header-protection-analysis" class="xref">Header Protection Analysis</a><a href="#section-toc.1-1.9.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.5">
+                <p id="section-toc.1-1.9.2.5.1"><a href="#section-9.5" class="xref">9.5</a>.  <a href="#name-header-protection-timing-si" class="xref">Header Protection Timing Side-Channels</a><a href="#section-toc.1-1.9.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.6">
+                <p id="section-toc.1-1.9.2.6.1"><a href="#section-9.6" class="xref">9.6</a>.  <a href="#name-key-diversity" class="xref">Key Diversity</a><a href="#section-toc.1-1.9.2.6.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.11.2.1">
+                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.11.2.2">
+                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12">
+            <p id="section-toc.1-1.12.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-sample-packet-protection" class="xref">Sample Packet Protection</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.1">
+                <p id="section-toc.1-1.12.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-keys" class="xref">Keys</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.2">
+                <p id="section-toc.1-1.12.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-client-initial" class="xref">Client Initial</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.3">
+                <p id="section-toc.1-1.12.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-server-initial" class="xref">Server Initial</a><a href="#section-toc.1-1.12.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.4">
+                <p id="section-toc.1-1.12.2.4.1"><a href="#section-a.4" class="xref">A.4</a>.  <a href="#name-retry" class="xref">Retry</a><a href="#section-toc.1-1.12.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13">
+            <p id="section-toc.1-1.13.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-change-log" class="xref">Change Log</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
+<ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.1">
+                <p id="section-toc.1-1.13.2.1.1"><a href="#section-b.1" class="xref">B.1</a>.  <a href="#name-since-draft-ietf-quic-tls-2" class="xref">Since draft-ietf-quic-tls-27</a><a href="#section-toc.1-1.13.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.2">
+                <p id="section-toc.1-1.13.2.2.1"><a href="#section-b.2" class="xref">B.2</a>.  <a href="#name-since-draft-ietf-quic-tls-26" class="xref">Since draft-ietf-quic-tls-26</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.3">
+                <p id="section-toc.1-1.13.2.3.1"><a href="#section-b.3" class="xref">B.3</a>.  <a href="#name-since-draft-ietf-quic-tls-25" class="xref">Since draft-ietf-quic-tls-25</a><a href="#section-toc.1-1.13.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.4">
+                <p id="section-toc.1-1.13.2.4.1"><a href="#section-b.4" class="xref">B.4</a>.  <a href="#name-since-draft-ietf-quic-tls-24" class="xref">Since draft-ietf-quic-tls-24</a><a href="#section-toc.1-1.13.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.5">
+                <p id="section-toc.1-1.13.2.5.1"><a href="#section-b.5" class="xref">B.5</a>.  <a href="#name-since-draft-ietf-quic-tls-23" class="xref">Since draft-ietf-quic-tls-23</a><a href="#section-toc.1-1.13.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.6">
+                <p id="section-toc.1-1.13.2.6.1"><a href="#section-b.6" class="xref">B.6</a>.  <a href="#name-since-draft-ietf-quic-tls-22" class="xref">Since draft-ietf-quic-tls-22</a><a href="#section-toc.1-1.13.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.7">
+                <p id="section-toc.1-1.13.2.7.1"><a href="#section-b.7" class="xref">B.7</a>.  <a href="#name-since-draft-ietf-quic-tls-21" class="xref">Since draft-ietf-quic-tls-21</a><a href="#section-toc.1-1.13.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.8">
+                <p id="section-toc.1-1.13.2.8.1"><a href="#section-b.8" class="xref">B.8</a>.  <a href="#name-since-draft-ietf-quic-tls-20" class="xref">Since draft-ietf-quic-tls-20</a><a href="#section-toc.1-1.13.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.9">
+                <p id="section-toc.1-1.13.2.9.1"><a href="#section-b.9" class="xref">B.9</a>.  <a href="#name-since-draft-ietf-quic-tls-1" class="xref">Since draft-ietf-quic-tls-18</a><a href="#section-toc.1-1.13.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.10">
+                <p id="section-toc.1-1.13.2.10.1"><a href="#section-b.10" class="xref">B.10</a>. <a href="#name-since-draft-ietf-quic-tls-17" class="xref">Since draft-ietf-quic-tls-17</a><a href="#section-toc.1-1.13.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.11">
+                <p id="section-toc.1-1.13.2.11.1"><a href="#section-b.11" class="xref">B.11</a>. <a href="#name-since-draft-ietf-quic-tls-14" class="xref">Since draft-ietf-quic-tls-14</a><a href="#section-toc.1-1.13.2.11.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.12">
+                <p id="section-toc.1-1.13.2.12.1"><a href="#section-b.12" class="xref">B.12</a>. <a href="#name-since-draft-ietf-quic-tls-13" class="xref">Since draft-ietf-quic-tls-13</a><a href="#section-toc.1-1.13.2.12.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.13">
+                <p id="section-toc.1-1.13.2.13.1"><a href="#section-b.13" class="xref">B.13</a>. <a href="#name-since-draft-ietf-quic-tls-12" class="xref">Since draft-ietf-quic-tls-12</a><a href="#section-toc.1-1.13.2.13.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.14">
+                <p id="section-toc.1-1.13.2.14.1"><a href="#section-b.14" class="xref">B.14</a>. <a href="#name-since-draft-ietf-quic-tls-11" class="xref">Since draft-ietf-quic-tls-11</a><a href="#section-toc.1-1.13.2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.15">
+                <p id="section-toc.1-1.13.2.15.1"><a href="#section-b.15" class="xref">B.15</a>. <a href="#name-since-draft-ietf-quic-tls-10" class="xref">Since draft-ietf-quic-tls-10</a><a href="#section-toc.1-1.13.2.15.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.16">
+                <p id="section-toc.1-1.13.2.16.1"><a href="#section-b.16" class="xref">B.16</a>. <a href="#name-since-draft-ietf-quic-tls-0" class="xref">Since draft-ietf-quic-tls-09</a><a href="#section-toc.1-1.13.2.16.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.17">
+                <p id="section-toc.1-1.13.2.17.1"><a href="#section-b.17" class="xref">B.17</a>. <a href="#name-since-draft-ietf-quic-tls-08" class="xref">Since draft-ietf-quic-tls-08</a><a href="#section-toc.1-1.13.2.17.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.18">
+                <p id="section-toc.1-1.13.2.18.1"><a href="#section-b.18" class="xref">B.18</a>. <a href="#name-since-draft-ietf-quic-tls-07" class="xref">Since draft-ietf-quic-tls-07</a><a href="#section-toc.1-1.13.2.18.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.19">
+                <p id="section-toc.1-1.13.2.19.1"><a href="#section-b.19" class="xref">B.19</a>. <a href="#name-since-draft-ietf-quic-tls-05" class="xref">Since draft-ietf-quic-tls-05</a><a href="#section-toc.1-1.13.2.19.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.20">
+                <p id="section-toc.1-1.13.2.20.1"><a href="#section-b.20" class="xref">B.20</a>. <a href="#name-since-draft-ietf-quic-tls-04" class="xref">Since draft-ietf-quic-tls-04</a><a href="#section-toc.1-1.13.2.20.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.21">
+                <p id="section-toc.1-1.13.2.21.1"><a href="#section-b.21" class="xref">B.21</a>. <a href="#name-since-draft-ietf-quic-tls-03" class="xref">Since draft-ietf-quic-tls-03</a><a href="#section-toc.1-1.13.2.21.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.22">
+                <p id="section-toc.1-1.13.2.22.1"><a href="#section-b.22" class="xref">B.22</a>. <a href="#name-since-draft-ietf-quic-tls-02" class="xref">Since draft-ietf-quic-tls-02</a><a href="#section-toc.1-1.13.2.22.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.23">
+                <p id="section-toc.1-1.13.2.23.1"><a href="#section-b.23" class="xref">B.23</a>. <a href="#name-since-draft-ietf-quic-tls-01" class="xref">Since draft-ietf-quic-tls-01</a><a href="#section-toc.1-1.13.2.23.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.24">
+                <p id="section-toc.1-1.13.2.24.1"><a href="#section-b.24" class="xref">B.24</a>. <a href="#name-since-draft-ietf-quic-tls-00" class="xref">Since draft-ietf-quic-tls-00</a><a href="#section-toc.1-1.13.2.24.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13.2.25">
+                <p id="section-toc.1-1.13.2.25.1"><a href="#section-b.25" class="xref">B.25</a>. <a href="#name-since-draft-thomson-quic-tl" class="xref">Since draft-thomson-quic-tls-01</a><a href="#section-toc.1-1.13.2.25.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.14">
+            <p id="section-toc.1-1.14.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.15">
+            <p id="section-toc.1-1.15.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</nav>
+</section>
+</div>
+<div id="introduction">
+<section id="section-1">
+      <h2 id="name-introduction">
+<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
+      </h2>
+<p id="section-1-1">This document describes how QUIC <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> is secured using TLS
+<span>[<a href="#TLS13" class="xref">TLS13</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
+<p id="section-1-2">TLS 1.3 provides critical latency improvements for connection establishment over
+previous versions.  Absent packet loss, most new connections can be established
+and secured within a single round trip; on subsequent connections between the
+same client and server, the client can often send application data immediately,
+that is, using a zero round trip setup.<a href="#section-1-2" class="pilcrow">¶</a></p>
+<p id="section-1-3">This document describes how TLS acts as a security component of QUIC.<a href="#section-1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="notational-conventions">
+<section id="section-2">
+      <h2 id="name-notational-conventions">
+<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-notational-conventions" class="section-name selfRef">Notational Conventions</a>
+      </h2>
+<p id="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
+"MAY", and "OPTIONAL" in this document are to be interpreted as
+described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they
+appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
+<p id="section-2-2">This document uses the terminology established in <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
+<p id="section-2-3">For brevity, the acronym TLS is used to refer to TLS 1.3, though a newer version
+could be used (see <a href="#tls-version" class="xref">Section 4.2</a>).<a href="#section-2-3" class="pilcrow">¶</a></p>
+<div id="tls-overview">
+<section id="section-2.1">
+        <h3 id="name-tls-overview">
+<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-tls-overview" class="section-name selfRef">TLS Overview</a>
+        </h3>
+<p id="section-2.1-1">TLS provides two endpoints with a way to establish a means of communication over
+an untrusted medium (that is, the Internet) that ensures that messages they
+exchange cannot be observed, modified, or forged.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
+<p id="section-2.1-2">Internally, TLS is a layered protocol, with the structure shown in
+<a href="#tls-layers" class="xref">Figure 1</a>.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
+<span id="name-tls-layers"></span><div id="tls-layers">
+<figure id="figure-1">
+          <div class="artwork art-text alignLeft" id="section-2.1-3.1">
+<pre>
+          +-------------+------------+--------------+---------+
+Handshake |             |            |  Application |         |
+Layer     |  Handshake  |   Alerts   |     Data     |   ...   |
+          |             |            |              |         |
+          +-------------+------------+--------------+---------+
+Record    |                                                   |
+Layer     |                      Records                      |
+          |                                                   |
+          +---------------------------------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
+<a href="#name-tls-layers" class="selfRef">TLS Layers</a>
+          </figcaption></figure>
+</div>
+<p id="section-2.1-4">Each Handshake layer message (e.g., Handshake, Alerts, and Application Data) is
+carried as a series of typed TLS records by the Record layer.  Records are
+individually cryptographically protected and then transmitted over a reliable
+transport (typically TCP) which provides sequencing and guaranteed delivery.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
+<p id="section-2.1-5">The TLS authenticated key exchange occurs between two endpoints: client and
+server.  The client initiates the exchange and the server responds.  If the key
+exchange completes successfully, both client and server will agree on a secret.
+TLS supports both pre-shared key (PSK) and Diffie-Hellman over either finite
+fields or elliptic curves ((EC)DHE) key exchanges.  PSK is the basis for 0-RTT;
+the latter provides perfect forward secrecy (PFS) when the (EC)DHE keys are
+destroyed.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
+<p id="section-2.1-6">After completing the TLS handshake, the client will have learned and
+authenticated an identity for the server and the server is optionally able to
+learn and authenticate an identity for the client.  TLS supports X.509
+<span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> certificate-based authentication for both server and client.<a href="#section-2.1-6" class="pilcrow">¶</a></p>
+<p id="section-2.1-7">The TLS key exchange is resistant to tampering by attackers and it produces
+shared secrets that cannot be controlled by either participating peer.<a href="#section-2.1-7" class="pilcrow">¶</a></p>
+<p id="section-2.1-8">TLS provides two basic handshake modes of interest to QUIC:<a href="#section-2.1-8" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-2.1-9.1">A full 1-RTT handshake in which the client is able to send Application Data
+after one round trip and the server immediately responds after receiving the
+first handshake message from the client.<a href="#section-2.1-9.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-9.2">A 0-RTT handshake in which the client uses information it has previously
+learned about the server to send Application Data immediately.  This
+Application Data can be replayed by an attacker so it MUST NOT carry a
+self-contained trigger for any non-idempotent action.<a href="#section-2.1-9.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-2.1-10">A simplified TLS handshake with 0-RTT application data is shown in <a href="#tls-full" class="xref">Figure 2</a>.<a href="#section-2.1-10" class="pilcrow">¶</a></p>
+<span id="name-tls-handshake-with-0-rtt"></span><div id="tls-full">
+<figure id="figure-2">
+          <div class="artwork art-text alignLeft" id="section-2.1-11.1">
+<pre>
+    Client                                             Server
+
+    ClientHello
+   (0-RTT Application Data)  --------&gt;
+                                                  ServerHello
+                                         {EncryptedExtensions}
+                                                    {Finished}
+                             &lt;--------      [Application Data]
+   {Finished}                --------&gt;
+
+   [Application Data]        &lt;-------&gt;      [Application Data]
+
+    () Indicates messages protected by Early Data (0-RTT) Keys
+    {} Indicates messages protected using Handshake Keys
+    [] Indicates messages protected using Application Data
+       (1-RTT) Keys
+</pre>
+</div>
+<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
+<a href="#name-tls-handshake-with-0-rtt" class="selfRef">TLS Handshake with 0-RTT</a>
+          </figcaption></figure>
+</div>
+<p id="section-2.1-12"><a href="#tls-full" class="xref">Figure 2</a> omits the EndOfEarlyData message, which is not used in QUIC; see
+<a href="#remove-eoed" class="xref">Section 8.3</a>. Likewise, neither ChangeCipherSpec nor KeyUpdate messages are
+used by QUIC. ChangeCipherSpec is redundant in TLS 1.3; see <a href="#compat-mode" class="xref">Section 8.4</a>.
+QUIC has its own key update mechanism; see <a href="#key-update" class="xref">Section 6</a>.<a href="#section-2.1-12" class="pilcrow">¶</a></p>
+<p id="section-2.1-13">Data is protected using a number of encryption levels:<a href="#section-2.1-13" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-2.1-14.1">Initial Keys<a href="#section-2.1-14.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-14.2">Early Data (0-RTT) Keys<a href="#section-2.1-14.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-14.3">Handshake Keys<a href="#section-2.1-14.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.1-14.4">Application Data (1-RTT) Keys<a href="#section-2.1-14.4" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-2.1-15">Application Data may appear only in the Early Data and Application Data
+levels. Handshake and Alert messages may appear in any level.<a href="#section-2.1-15" class="pilcrow">¶</a></p>
+<p id="section-2.1-16">The 0-RTT handshake is only possible if the client and server have previously
+communicated.  In the 1-RTT handshake, the client is unable to send protected
+Application Data until it has received all of the Handshake messages sent by the
+server.<a href="#section-2.1-16" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="protocol-overview">
+<section id="section-3">
+      <h2 id="name-protocol-overview">
+<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-protocol-overview" class="section-name selfRef">Protocol Overview</a>
+      </h2>
+<p id="section-3-1">QUIC <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> assumes responsibility for the confidentiality and
+integrity protection of packets.  For this it uses keys derived from a TLS
+handshake <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>, but instead of carrying TLS records over QUIC (as with
+TCP), TLS Handshake and Alert messages are carried directly over the QUIC
+transport, which takes over the responsibilities of the TLS record layer, as
+shown in <a href="#quic-layers" class="xref">Figure 3</a>.<a href="#section-3-1" class="pilcrow">¶</a></p>
+<span id="name-quic-layers"></span><div id="quic-layers">
+<figure id="figure-3">
+        <div class="artwork art-text alignLeft" id="section-3-2.1">
+<pre>
++--------------+--------------+ +-------------+
+|     TLS      |     TLS      | |    QUIC     |
+|  Handshake   |    Alerts    | | Applications|
+|              |              | |  (h3, etc.) |
++--------------+--------------+-+-------------+
+|                                             |
+|                QUIC Transport               |
+|   (streams, reliability, congestion, etc.)  |
+|                                             |
++---------------------------------------------+
+|                                             |
+|            QUIC Packet Protection           |
+|                                             |
++---------------------------------------------+
+</pre>
+</div>
+<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
+<a href="#name-quic-layers" class="selfRef">QUIC Layers</a>
+        </figcaption></figure>
+</div>
+<p id="section-3-3">QUIC also relies on TLS for authentication and negotiation of parameters that
+are critical to security and performance.<a href="#section-3-3" class="pilcrow">¶</a></p>
+<p id="section-3-4">Rather than a strict layering, these two protocols cooperate: QUIC uses the TLS
+handshake; TLS uses the reliability, ordered delivery, and record layer provided
+by QUIC.<a href="#section-3-4" class="pilcrow">¶</a></p>
+<p id="section-3-5">At a high level, there are two main interactions between the TLS and QUIC
+components:<a href="#section-3-5" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-3-6.1">The TLS component sends and receives messages via the QUIC component, with
+QUIC providing a reliable stream abstraction to TLS.<a href="#section-3-6.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-3-6.2">The TLS component provides a series of updates to the QUIC component,
+including (a) new packet protection keys to install (b) state changes such as
+handshake completion, the server certificate, etc.<a href="#section-3-6.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-3-7"><a href="#schematic" class="xref">Figure 4</a> shows these interactions in more detail, with the QUIC packet
+protection being called out specially.<a href="#section-3-7" class="pilcrow">¶</a></p>
+<span id="name-quic-and-tls-interactions"></span><div id="schematic">
+<figure id="figure-4">
+        <div class="artwork art-text alignLeft" id="section-3-8.1">
+<pre>
++------------+                               +------------+
+|            |&lt;---- Handshake Messages -----&gt;|            |
+|            |&lt;- Validate 0-RTT parameters -&gt;|            |
+|            |&lt;--------- 0-RTT Keys ---------|            |
+|    QUIC    |&lt;------- Handshake Keys -------|    TLS     |
+|            |&lt;--------- 1-RTT Keys ---------|            |
+|            |&lt;------- Handshake Done -------|            |
++------------+                               +------------+
+ |         ^
+ | Protect | Protected
+ v         | Packet
++------------+
+|   QUIC     |
+|  Packet    |
+| Protection |
++------------+
+</pre>
+</div>
+<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
+<a href="#name-quic-and-tls-interactions" class="selfRef">QUIC and TLS Interactions</a>
+        </figcaption></figure>
+</div>
+<p id="section-3-9">Unlike TLS over TCP, QUIC applications which want to send data do not send it
+through TLS "application_data" records. Rather, they send it as QUIC STREAM
+frames or other frame types which are then carried in QUIC packets.<a href="#section-3-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="carrying-tls">
+<section id="section-4">
+      <h2 id="name-carrying-tls-messages">
+<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-carrying-tls-messages" class="section-name selfRef">Carrying TLS Messages</a>
+      </h2>
+<p id="section-4-1">QUIC carries TLS handshake data in CRYPTO frames, each of which consists of a
+contiguous block of handshake data identified by an offset and length. Those
+frames are packaged into QUIC packets and encrypted under the current TLS
+encryption level.  As with TLS over TCP, once TLS handshake data has been
+delivered to QUIC, it is QUIC's responsibility to deliver it reliably. Each
+chunk of data that is produced by TLS is associated with the set of keys that
+TLS is currently using.  If QUIC needs to retransmit that data, it MUST use the
+same keys even if TLS has already updated to newer keys.<a href="#section-4-1" class="pilcrow">¶</a></p>
+<p id="section-4-2">One important difference between TLS records (used with TCP) and QUIC CRYPTO
+frames is that in QUIC multiple frames may appear in the same QUIC packet as
+long as they are associated with the same packet number space. For instance,
+an endpoint can bundle a Handshake message and an ACK for some Handshake data
+into the same packet.<a href="#section-4-2" class="pilcrow">¶</a></p>
+<p id="section-4-3">Some frames are prohibited in different packet number spaces. The rules here
+generalize those of TLS, in that frames associated with establishing the
+connection can usually appear in packets in any packet number space, whereas
+those associated with transferring data can only appear in the application
+data packet number space:<a href="#section-4-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4-4.1">PADDING, PING, and CRYPTO frames MAY appear in any packet number space.<a href="#section-4-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4-4.2">CONNECTION_CLOSE frames signaling errors at the QUIC layer (type 0x1c) MAY
+appear in any packet number space. CONNECTION_CLOSE frames signaling
+application errors (type 0x1d) MUST only appear in the application data packet
+number space.<a href="#section-4-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4-4.3">ACK frames MAY appear in any packet number space, but can only acknowledge
+packets which appeared in that packet number space.  However, as noted below,
+0-RTT packets cannot contain ACK frames.<a href="#section-4-4.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4-4.4">All other frame types MUST only be sent in the application data packet number
+space.<a href="#section-4-4.4" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4-5">Note that it is not possible to send the following frames in 0-RTT packets for
+various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, and
+RETIRE_CONNECTION_ID.  A server MAY treat receipt of these frames in 0-RTT
+packets as a connection error of type PROTOCOL_VIOLATION.<a href="#section-4-5" class="pilcrow">¶</a></p>
+<p id="section-4-6">Because packets could be reordered on the wire, QUIC uses the packet type to
+indicate which keys were used to protect a given packet, as shown in
+<a href="#packet-types-keys" class="xref">Table 1</a>. When packets of different types need to be sent,
+endpoints SHOULD use coalesced packets to send them in the same UDP datagram.<a href="#section-4-6" class="pilcrow">¶</a></p>
+<span id="name-encryption-keys-by-packet-t"></span><div id="packet-types-keys">
+<table class="center" id="table-1">
+        <caption>
+<a href="#table-1" class="selfRef">Table 1</a>:
+<a href="#name-encryption-keys-by-packet-t" class="selfRef">Encryption Keys by Packet Type</a>
+        </caption>
+<thead>
+          <tr>
+            <th class="text-left" rowspan="1" colspan="1">Packet Type</th>
+            <th class="text-left" rowspan="1" colspan="1">Encryption Keys</th>
+            <th class="text-left" rowspan="1" colspan="1">PN Space</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">Initial</td>
+            <td class="text-left" rowspan="1" colspan="1">Initial secrets</td>
+            <td class="text-left" rowspan="1" colspan="1">Initial</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">0-RTT Protected</td>
+            <td class="text-left" rowspan="1" colspan="1">0-RTT</td>
+            <td class="text-left" rowspan="1" colspan="1">Application data</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">Handshake</td>
+            <td class="text-left" rowspan="1" colspan="1">Handshake</td>
+            <td class="text-left" rowspan="1" colspan="1">Handshake</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">Retry</td>
+            <td class="text-left" rowspan="1" colspan="1">Retry</td>
+            <td class="text-left" rowspan="1" colspan="1">N/A</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">Version Negotiation</td>
+            <td class="text-left" rowspan="1" colspan="1">N/A</td>
+            <td class="text-left" rowspan="1" colspan="1">N/A</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">Short Header</td>
+            <td class="text-left" rowspan="1" colspan="1">1-RTT</td>
+            <td class="text-left" rowspan="1" colspan="1">Application data</td>
+          </tr>
+        </tbody>
+      </table>
+</div>
+<p id="section-4-8">Section 17 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> shows how packets at the various encryption
+levels fit into the handshake process.<a href="#section-4-8" class="pilcrow">¶</a></p>
+<div id="interface-to-tls">
+<section id="section-4.1">
+        <h3 id="name-interface-to-tls">
+<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-interface-to-tls" class="section-name selfRef">Interface to TLS</a>
+        </h3>
+<p id="section-4.1-1">As shown in <a href="#schematic" class="xref">Figure 4</a>, the interface from QUIC to TLS consists of four
+primary functions:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.1-2.1">Sending and receiving handshake messages<a href="#section-4.1-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1-2.2">Processing stored transport and application state from a resumed session
+and determining if it is valid to accept early data<a href="#section-4.1-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1-2.3">Rekeying (both transmit and receive)<a href="#section-4.1-2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1-2.4">Handshake state updates<a href="#section-4.1-2.4" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.1-3">Additional functions might be needed to configure TLS.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
+<div id="handshake-complete">
+<section id="section-4.1.1">
+          <h4 id="name-handshake-complete">
+<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-handshake-complete" class="section-name selfRef">Handshake Complete</a>
+          </h4>
+<p id="section-4.1.1-1">In this document, the TLS handshake is considered complete when the TLS stack
+has reported that the handshake is complete.  This happens when the TLS stack
+has both sent a Finished message and verified the peer's Finished message.
+Verifying the peer's Finished provides the endpoints with an assurance that
+previous handshake messages have not been modified.  Note that the handshake
+does not complete at both endpoints simultaneously.  Consequently, any
+requirement that is based on the completion of the handshake depends on the
+perspective of the endpoint in question.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="handshake-confirmed">
+<section id="section-4.1.2">
+          <h4 id="name-handshake-confirmed">
+<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-handshake-confirmed" class="section-name selfRef">Handshake Confirmed</a>
+          </h4>
+<p id="section-4.1.2-1">In this document, the TLS handshake is considered confirmed at the server when
+the handshake completes.  At the client, the handshake is considered confirmed
+when a HANDSHAKE_DONE frame is received.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.2-2">A client MAY consider the handshake to be confirmed when it receives an
+acknowledgement for a 1-RTT packet.  This can be implemented by recording the
+lowest packet number sent with 1-RTT keys, and comparing it to the Largest
+Acknowledged field in any received 1-RTT ACK frame: once the latter is greater
+than or equal to the former, the handshake is confirmed.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="sending-and-receiving-handshake-messages">
+<section id="section-4.1.3">
+          <h4 id="name-sending-and-receiving-hands">
+<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-sending-and-receiving-hands" class="section-name selfRef">Sending and Receiving Handshake Messages</a>
+          </h4>
+<p id="section-4.1.3-1">In order to drive the handshake, TLS depends on being able to send and receive
+handshake messages. There are two basic functions on this interface: one where
+QUIC requests handshake messages and one where QUIC provides handshake packets.<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-2">Before starting the handshake QUIC provides TLS with the transport parameters
+(see <a href="#quic_parameters" class="xref">Section 8.2</a>) that it wishes to carry.<a href="#section-4.1.3-2" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-3">A QUIC client starts TLS by requesting TLS handshake bytes from TLS.  The client
+acquires handshake bytes before sending its first packet.  A QUIC server starts
+the process by providing TLS with the client's handshake bytes.<a href="#section-4.1.3-3" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-4">At any time, the TLS stack at an endpoint will have a current sending
+encryption level and receiving encryption level. Encryption levels determine
+the packet type and keys that are used for protecting data.<a href="#section-4.1.3-4" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-5">Each encryption level is associated with a different sequence of bytes, which is
+reliably transmitted to the peer in CRYPTO frames. When TLS provides handshake
+bytes to be sent, they are appended to the current flow. Any packet that
+includes the CRYPTO frame is protected using keys from the corresponding
+encryption level. Four encryption levels are used, producing keys for Initial,
+0-RTT, Handshake, and 1-RTT packets. CRYPTO frames are carried in just three of
+these levels, omitting the 0-RTT level. These four levels correspond to three
+packet number spaces: Initial and Handshake encrypted packets use their own
+separate spaces; 0-RTT and 1-RTT packets use the application data packet number
+space.<a href="#section-4.1.3-5" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-6">QUIC takes the unprotected content of TLS handshake records as the content of
+CRYPTO frames. TLS record protection is not used by QUIC. QUIC assembles
+CRYPTO frames into QUIC packets, which are protected using QUIC packet
+protection.<a href="#section-4.1.3-6" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-7">QUIC is only capable of conveying TLS handshake records in CRYPTO frames.  TLS
+alerts are turned into QUIC CONNECTION_CLOSE error codes; see <a href="#tls-errors" class="xref">Section 4.10</a>.
+TLS application data and other message types cannot be carried by QUIC at any
+encryption level and is an error if they are received from the TLS stack.<a href="#section-4.1.3-7" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-8">When an endpoint receives a QUIC packet containing a CRYPTO frame from the
+network, it proceeds as follows:<a href="#section-4.1.3-8" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.1.3-9.1">If the packet was in the TLS receiving encryption level, sequence the data
+into the input flow as usual. As with STREAM frames, the offset is used to
+find the proper location in the data sequence.  If the result of this process
+is that new data is available, then it is delivered to TLS in order.<a href="#section-4.1.3-9.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.3-9.2">If the packet is from a previously installed encryption level, it MUST NOT
+contain data which extends past the end of previously received data in that
+flow. Implementations MUST treat any violations of this requirement as a
+connection error of type PROTOCOL_VIOLATION.<a href="#section-4.1.3-9.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.3-9.3">If the packet is from a new encryption level, it is saved for later processing
+by TLS.  Once TLS moves to receiving from this encryption level, saved data
+can be provided.  When providing data from any new encryption level to TLS, if
+there is data from a previous encryption level that TLS has not consumed, this
+MUST be treated as a connection error of type PROTOCOL_VIOLATION.<a href="#section-4.1.3-9.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.1.3-10">Each time that TLS is provided with new data, new handshake bytes are requested
+from TLS.  TLS might not provide any bytes if the handshake messages it has
+received are incomplete or it has no data to send.<a href="#section-4.1.3-10" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-11">Once the TLS handshake is complete, this is indicated to QUIC along with any
+final handshake bytes that TLS needs to send.  TLS also provides QUIC with the
+transport parameters that the peer advertised during the handshake.<a href="#section-4.1.3-11" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-12">Once the handshake is complete, TLS becomes passive.  TLS can still receive data
+from its peer and respond in kind, but it will not need to send more data unless
+specifically requested - either by an application or QUIC.  One reason to send
+data is that the server might wish to provide additional or updated session
+tickets to a client.<a href="#section-4.1.3-12" class="pilcrow">¶</a></p>
+<p id="section-4.1.3-13">When the handshake is complete, QUIC only needs to provide TLS with any data
+that arrives in CRYPTO streams.  In the same way that is done during the
+handshake, new data is requested from TLS after providing received data.<a href="#section-4.1.3-13" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="encryption-level-changes">
+<section id="section-4.1.4">
+          <h4 id="name-encryption-level-changes">
+<a href="#section-4.1.4" class="section-number selfRef">4.1.4. </a><a href="#name-encryption-level-changes" class="section-name selfRef">Encryption Level Changes</a>
+          </h4>
+<p id="section-4.1.4-1">As keys for new encryption levels become available, TLS provides QUIC with those
+keys.  Separately, as keys at a given encryption level become available to TLS,
+TLS indicates to QUIC that reading or writing keys at that encryption level are
+available.  These events are not asynchronous; they always occur immediately
+after TLS is provided with new handshake bytes, or after TLS produces handshake
+bytes.<a href="#section-4.1.4-1" class="pilcrow">¶</a></p>
+<p id="section-4.1.4-2">TLS provides QUIC with three items as a new encryption level becomes available:<a href="#section-4.1.4-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.1.4-3.1">A secret<a href="#section-4.1.4-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.4-3.2">An Authenticated Encryption with Associated Data (AEAD) function<a href="#section-4.1.4-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1.4-3.3">A Key Derivation Function (KDF)<a href="#section-4.1.4-3.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.1.4-4">These values are based on the values that TLS negotiates and are used by QUIC to
+generate packet and header protection keys (see <a href="#packet-protection" class="xref">Section 5</a> and
+<a href="#header-protect" class="xref">Section 5.4</a>).<a href="#section-4.1.4-4" class="pilcrow">¶</a></p>
+<p id="section-4.1.4-5">If 0-RTT is possible, it is ready after the client sends a TLS ClientHello
+message or the server receives that message.  After providing a QUIC client with
+the first handshake bytes, the TLS stack might signal the change to 0-RTT
+keys. On the server, after receiving handshake bytes that contain a ClientHello
+message, a TLS server might signal that 0-RTT keys are available.<a href="#section-4.1.4-5" class="pilcrow">¶</a></p>
+<p id="section-4.1.4-6">Although TLS only uses one encryption level at a time, QUIC may use more than
+one level. For instance, after sending its Finished message (using a CRYPTO
+frame at the Handshake encryption level) an endpoint can send STREAM data (in
+1-RTT encryption). If the Finished message is lost, the endpoint uses the
+Handshake encryption level to retransmit the lost message.  Reordering or loss
+of packets can mean that QUIC will need to handle packets at multiple encryption
+levels.  During the handshake, this means potentially handling packets at higher
+and lower encryption levels than the current encryption level used by TLS.<a href="#section-4.1.4-6" class="pilcrow">¶</a></p>
+<p id="section-4.1.4-7">In particular, server implementations need to be able to read packets at the
+Handshake encryption level at the same time as the 0-RTT encryption level.  A
+client could interleave ACK frames that are protected with Handshake keys with
+0-RTT data and the server needs to process those acknowledgments in order to
+detect lost Handshake packets.<a href="#section-4.1.4-7" class="pilcrow">¶</a></p>
+<p id="section-4.1.4-8">QUIC also needs access to keys that might not ordinarily be available to a TLS
+implementation.  For instance, a client might need to acknowledge Handshake
+packets before it is ready to send CRYPTO frames at that encryption level.  TLS
+therefore needs to provide keys to QUIC before it might produce them for its own
+use.<a href="#section-4.1.4-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="tls-interface-summary">
+<section id="section-4.1.5">
+          <h4 id="name-tls-interface-summary">
+<a href="#section-4.1.5" class="section-number selfRef">4.1.5. </a><a href="#name-tls-interface-summary" class="section-name selfRef">TLS Interface Summary</a>
+          </h4>
+<p id="section-4.1.5-1"><a href="#exchange-summary" class="xref">Figure 5</a> summarizes the exchange between QUIC and TLS for both
+client and server. Each arrow is tagged with the encryption level used for that
+transmission.<a href="#section-4.1.5-1" class="pilcrow">¶</a></p>
+<span id="name-interaction-summary-between"></span><div id="exchange-summary">
+<figure id="figure-5">
+            <div class="artwork art-text alignLeft" id="section-4.1.5-2.1">
+<pre>
+Client                                                    Server
+
+Get Handshake
+                     Initial -------------&gt;
+                                              Handshake Received
+Install tx 0-RTT Keys
+                     0-RTT ---------------&gt;
+                                                   Get Handshake
+                     &lt;------------- Initial
+Handshake Received
+Install Handshake keys
+                                           Install rx 0-RTT keys
+                                          Install Handshake keys
+                                                   Get Handshake
+                     &lt;----------- Handshake
+Handshake Received
+                                           Install tx 1-RTT keys
+                     &lt;--------------- 1-RTT
+Get Handshake
+Handshake Complete
+                     Handshake -----------&gt;
+                                              Handshake Received
+                                           Install rx 1-RTT keys
+                                              Handshake Complete
+Install 1-RTT keys
+                     1-RTT ---------------&gt;
+                                                   Get Handshake
+                     &lt;--------------- 1-RTT
+Handshake Received
+</pre>
+</div>
+<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
+<a href="#name-interaction-summary-between" class="selfRef">Interaction Summary between QUIC and TLS</a>
+            </figcaption></figure>
+</div>
+<p id="section-4.1.5-3"><a href="#exchange-summary" class="xref">Figure 5</a> shows the multiple packets that form a single "flight" of
+messages being processed individually, to show what incoming messages trigger
+different actions.  New handshake messages are requested after all incoming
+packets have been processed.  This process might vary depending on how QUIC
+implementations and the packets they receive are structured.<a href="#section-4.1.5-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="tls-version">
+<section id="section-4.2">
+        <h3 id="name-tls-version">
+<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-tls-version" class="section-name selfRef">TLS Version</a>
+        </h3>
+<p id="section-4.2-1">This document describes how TLS 1.3 <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> is used with QUIC.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.2-2">In practice, the TLS handshake will negotiate a version of TLS to use.  This
+could result in a newer version of TLS than 1.3 being negotiated if both
+endpoints support that version.  This is acceptable provided that the features
+of TLS 1.3 that are used by QUIC are supported by the newer version.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
+<p id="section-4.2-3">A badly configured TLS implementation could negotiate TLS 1.2 or another older
+version of TLS.  An endpoint MUST terminate the connection if a version of TLS
+older than 1.3 is negotiated.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="clienthello-size">
+<section id="section-4.3">
+        <h3 id="name-clienthello-size">
+<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-clienthello-size" class="section-name selfRef">ClientHello Size</a>
+        </h3>
+<p id="section-4.3-1">The first Initial packet from a client contains the start or all of its first
+cryptographic handshake message, which for TLS is the ClientHello.  Servers
+might need to parse the entire ClientHello (e.g., to access extensions such as
+Server Name Identification (SNI) or Application Layer Protocol Negotiation
+(ALPN)) in order to decide whether to accept the new incoming QUIC connection.
+If the ClientHello spans multiple Initial packets, such servers would need to
+buffer the first received fragments, which could consume excessive resources if
+the client's address has not yet been validated.  To avoid this, servers MAY
+use the Retry feature (see Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>) to only buffer
+partial ClientHello messages from clients with a validated address.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+<p id="section-4.3-2">QUIC packet and framing add at least 36 bytes of overhead to the ClientHello
+message.  That overhead increases if the client chooses a connection ID without
+zero length.  Overheads also do not include the token or a connection ID longer
+than 8 bytes, both of which might be required if a server sends a Retry packet.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
+<p id="section-4.3-3">A typical TLS ClientHello can easily fit into a 1200 byte packet.  However, in
+addition to the overheads added by QUIC, there are several variables that could
+cause this limit to be exceeded.  Large session tickets, 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.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
+<p id="section-4.3-4">For servers, in addition to connection IDs and tokens, the size of TLS session
+tickets can have an effect on a client's ability to connect efficiently.
+Minimizing the size of these values increases the probability that clients can
+use them and still fit their ClientHello message in their first Initial packet.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
+<p id="section-4.3-5">The TLS implementation does not need to ensure that the ClientHello is
+sufficiently large.  QUIC PADDING frames are added to increase the size of the
+packet as necessary.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="peer-authentication">
+<section id="section-4.4">
+        <h3 id="name-peer-authentication">
+<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-peer-authentication" class="section-name selfRef">Peer Authentication</a>
+        </h3>
+<p id="section-4.4-1">The requirements for authentication depend on the application protocol that is
+in use.  TLS provides server authentication and permits the server to request
+client authentication.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
+<p id="section-4.4-2">A client MUST authenticate the identity of the server.  This typically involves
+verification that the identity of the server is included in a certificate and
+that the certificate is issued by a trusted entity (see for example
+<span>[<a href="#RFC2818" class="xref">RFC2818</a>]</span>).<a href="#section-4.4-2" class="pilcrow">¶</a></p>
+<p id="section-4.4-3">A server MAY request that the client authenticate during the handshake. A server
+MAY refuse a connection if the client is unable to authenticate when requested.
+The requirements for client authentication vary based on application protocol
+and deployment.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
+<p id="section-4.4-4">A server MUST NOT use post-handshake client authentication (as defined in
+Section 4.6.2 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>), because the multiplexing offered by QUIC prevents
+clients from correlating the certificate request with the application-level
+event that triggered it (see <span>[<a href="#HTTP2-TLS13" class="xref">HTTP2-TLS13</a>]</span>).
+More specifically, servers MUST NOT send post-handshake TLS CertificateRequest
+messages and clients MUST treat receipt of such messages as a connection error
+of type PROTOCOL_VIOLATION.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="resumption">
+<section id="section-4.5">
+        <h3 id="name-session-resumption">
+<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-session-resumption" class="section-name selfRef">Session Resumption</a>
+        </h3>
+<p id="section-4.5-1">QUIC can use the session resumption feature of TLS 1.3. It does this by
+carrying NewSessionTicket messages in CRYPTO frames after the handshake is
+complete. Session resumption is the basis of 0-RTT, but can be used without
+also enabling 0-RTT.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
+<p id="section-4.5-2">Endpoints that use session resumption might need to remember some information
+about the current connection when creating a resumed connection. TLS requires
+that some information be retained; see Section 4.6.1 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>. QUIC itself
+does not depend on any state being retained when resuming a connection, unless
+0-RTT is also used; see <a href="#enable-0rtt" class="xref">Section 4.6</a> and Section 7.4.1 of
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>. Application protocols could depend on state that is
+retained between resumed connections.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
+<p id="section-4.5-3">Clients can store any state required for resumption along with the session
+ticket. Servers can use the session ticket to help carry state.<a href="#section-4.5-3" class="pilcrow">¶</a></p>
+<p id="section-4.5-4">Session resumption allows servers to link activity on the original connection
+with the resumed connection, which might be a privacy issue for clients.
+Clients can choose not to enable resumption to avoid creating this correlation.
+Client SHOULD NOT reuse tickets as that allows entities other than the server
+to correlate connections; see Section C.4 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>.<a href="#section-4.5-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="enable-0rtt">
+<section id="section-4.6">
+        <h3 id="name-enabling-0-rtt">
+<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-enabling-0-rtt" class="section-name selfRef">Enabling 0-RTT</a>
+        </h3>
+<p id="section-4.6-1">To communicate their willingness to process 0-RTT data, servers send a
+NewSessionTicket message that contains the "early_data" extension with a
+max_early_data_size of 0xffffffff; the amount of data which the client can send
+in 0-RTT is controlled by the "initial_max_data" transport parameter supplied
+by the server.  Servers MUST NOT send the "early_data" extension with a
+max_early_data_size set to any value other than 0xffffffff.  A client MUST
+treat receipt of a NewSessionTicket that contains an "early_data" extension
+with any other value as a connection error of type PROTOCOL_VIOLATION.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
+<p id="section-4.6-2">A client that wishes to send 0-RTT packets uses the "early_data" extension in
+the ClientHello message of a subsequent handshake (see Section 4.2.10 of
+<span>[<a href="#TLS13" class="xref">TLS13</a>]</span>). It then sends the application data in 0-RTT packets.<a href="#section-4.6-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="accepting-and-rejecting-0-rtt">
+<section id="section-4.7">
+        <h3 id="name-accepting-and-rejecting-0-r">
+<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-accepting-and-rejecting-0-r" class="section-name selfRef">Accepting and Rejecting 0-RTT</a>
+        </h3>
+<p id="section-4.7-1">A server accepts 0-RTT by sending an early_data extension in the
+EncryptedExtensions (see Section 4.2.10 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>).  The server then
+processes and acknowledges the 0-RTT packets that it receives.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
+<p id="section-4.7-2">A server rejects 0-RTT by sending the EncryptedExtensions without an early_data
+extension.  A server will always reject 0-RTT if it sends a TLS
+HelloRetryRequest.  When rejecting 0-RTT, a server MUST NOT process any 0-RTT
+packets, even if it could.  When 0-RTT was rejected, a client SHOULD treat
+receipt of an acknowledgement for a 0-RTT packet as a connection error of type
+PROTOCOL_VIOLATION, if it is able to detect the condition.<a href="#section-4.7-2" class="pilcrow">¶</a></p>
+<p id="section-4.7-3">When 0-RTT is rejected, all connection characteristics that the client assumed
+might be incorrect.  This includes the choice of application protocol, transport
+parameters, and any application configuration.  The client therefore MUST reset
+the state of all streams, including application state bound to those streams.<a href="#section-4.7-3" class="pilcrow">¶</a></p>
+<p id="section-4.7-4">A client MAY attempt to send 0-RTT again if it receives a Retry or Version
+Negotiation packet.  These packets do not signify rejection of 0-RTT.<a href="#section-4.7-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="validating-0-rtt-configuration">
+<section id="section-4.8">
+        <h3 id="name-validating-0-rtt-configurat">
+<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-validating-0-rtt-configurat" class="section-name selfRef">Validating 0-RTT Configuration</a>
+        </h3>
+<p id="section-4.8-1">When a server receives a ClientHello with the "early_data" extension, it has to
+decide whether to accept or reject early data from the client. Some of this
+decision is made by the TLS stack (e.g., checking that the cipher suite being
+resumed was included in the ClientHello; see Section 4.2.10 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>). Even
+when the TLS stack has no reason to reject early data, the QUIC stack or the
+application protocol using QUIC might reject early data because the
+configuration of the transport or application associated with the resumed
+session is not compatible with the server's current configuration.<a href="#section-4.8-1" class="pilcrow">¶</a></p>
+<p id="section-4.8-2">QUIC requires additional transport state to be associated with a 0-RTT session
+ticket. One common way to implement this is using stateless session tickets and
+storing this state in the session ticket. Application protocols that use QUIC
+might have similar requirements regarding associating or storing state. This
+associated state is used for deciding whether early data must be rejected. For
+example, HTTP/3 (<span>[<a href="#QUIC-HTTP" class="xref">QUIC-HTTP</a>]</span>) settings determine how early data from the
+client is interpreted. Other applications using QUIC could have different
+requirements for determining whether to accept or reject early data.<a href="#section-4.8-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="helloretryrequest">
+<section id="section-4.9">
+        <h3 id="name-helloretryrequest">
+<a href="#section-4.9" class="section-number selfRef">4.9. </a><a href="#name-helloretryrequest" class="section-name selfRef">HelloRetryRequest</a>
+        </h3>
+<p id="section-4.9-1">In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
+<span>[<a href="#TLS13" class="xref">TLS13</a>]</span>) can be used to correct a client's incorrect KeyShare extension as
+well as for a stateless round-trip check. From the perspective of QUIC, this
+just looks like additional messages carried in Initial packets. Although it is
+in principle possible to use this feature for address verification in QUIC,
+QUIC implementations SHOULD instead use the Retry feature (see Section 8.1 of
+<span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>). HelloRetryRequest is still used to request key shares.<a href="#section-4.9-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="tls-errors">
+<section id="section-4.10">
+        <h3 id="name-tls-errors">
+<a href="#section-4.10" class="section-number selfRef">4.10. </a><a href="#name-tls-errors" class="section-name selfRef">TLS Errors</a>
+        </h3>
+<p id="section-4.10-1">If TLS experiences an error, it generates an appropriate alert as defined in
+Section 6 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>.<a href="#section-4.10-1" class="pilcrow">¶</a></p>
+<p id="section-4.10-2">A TLS alert is converted into a QUIC connection error. The alert description is
+added to 0x100 to produce a QUIC error code from the range reserved for
+CRYPTO_ERROR. The resulting value is sent in a QUIC CONNECTION_CLOSE frame of
+type 0x1c.<a href="#section-4.10-2" class="pilcrow">¶</a></p>
+<p id="section-4.10-3">The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate
+alerts at the "warning" level.<a href="#section-4.10-3" class="pilcrow">¶</a></p>
+<p id="section-4.10-4">QUIC permits the use of a generic code in place of a specific error code; see
+Section 11 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>. For TLS alerts, this includes replacing any
+alert with a generic alert, such as handshake_failure (0x128 in QUIC).
+Endpoints MAY use a generic error code to avoid possibly exposing confidential
+information.<a href="#section-4.10-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="discarding-unused-keys">
+<section id="section-4.11">
+        <h3 id="name-discarding-unused-keys">
+<a href="#section-4.11" class="section-number selfRef">4.11. </a><a href="#name-discarding-unused-keys" class="section-name selfRef">Discarding Unused Keys</a>
+        </h3>
+<p id="section-4.11-1">After QUIC moves to a new encryption level, packet protection keys for previous
+encryption levels can be discarded.  This occurs several times during the
+handshake, as well as when keys are updated; see <a href="#key-update" class="xref">Section 6</a>.<a href="#section-4.11-1" class="pilcrow">¶</a></p>
+<p id="section-4.11-2">Packet protection keys are not discarded immediately when new keys are
+available.  If packets from a lower encryption level contain CRYPTO frames,
+frames that retransmit that data MUST be sent at the same encryption level.
+Similarly, an endpoint generates acknowledgements for packets at the same
+encryption level as the packet being acknowledged.  Thus, it is possible that
+keys for a lower encryption level are needed for a short time after keys for a
+newer encryption level are available.<a href="#section-4.11-2" class="pilcrow">¶</a></p>
+<p id="section-4.11-3">An endpoint cannot discard keys for a given encryption level unless it has both
+received and acknowledged all CRYPTO frames for that encryption level and when
+all CRYPTO frames for that encryption level have been acknowledged by its peer.
+However, this does not guarantee that no further packets will need to be
+received or sent at that encryption level because a peer might not have received
+all the acknowledgements necessary to reach the same state.<a href="#section-4.11-3" class="pilcrow">¶</a></p>
+<p id="section-4.11-4">Though an endpoint might retain older keys, new data MUST be sent at the highest
+currently-available encryption level.  Only ACK frames and retransmissions of
+data in CRYPTO frames are sent at a previous encryption level.  These packets
+MAY also include PADDING frames.<a href="#section-4.11-4" class="pilcrow">¶</a></p>
+<div id="discarding-initial-keys">
+<section id="section-4.11.1">
+          <h4 id="name-discarding-initial-keys">
+<a href="#section-4.11.1" class="section-number selfRef">4.11.1. </a><a href="#name-discarding-initial-keys" class="section-name selfRef">Discarding Initial Keys</a>
+          </h4>
+<p id="section-4.11.1-1">Packets protected with Initial secrets (<a href="#initial-secrets" class="xref">Section 5.2</a>) are not
+authenticated, meaning that an attacker could spoof packets with the intent to
+disrupt a connection.  To limit these attacks, Initial packet protection keys
+can be discarded more aggressively than other keys.<a href="#section-4.11.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.11.1-2">The successful use of Handshake packets indicates that no more Initial packets
+need to be exchanged, as these keys can only be produced after receiving all
+CRYPTO frames from Initial packets.  Thus, a client MUST discard Initial keys
+when it first sends a Handshake packet and a server MUST discard Initial keys
+when it first successfully processes a Handshake packet.  Endpoints MUST NOT
+send Initial packets after this point.<a href="#section-4.11.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.11.1-3">This results in abandoning loss recovery state for the Initial encryption level
+and ignoring any outstanding Initial packets.<a href="#section-4.11.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="discarding-handshake-keys">
+<section id="section-4.11.2">
+          <h4 id="name-discarding-handshake-keys">
+<a href="#section-4.11.2" class="section-number selfRef">4.11.2. </a><a href="#name-discarding-handshake-keys" class="section-name selfRef">Discarding Handshake Keys</a>
+          </h4>
+<p id="section-4.11.2-1">An endpoint MUST discard its handshake keys when the TLS handshake is confirmed
+(<a href="#handshake-confirmed" class="xref">Section 4.1.2</a>).  The server MUST send a HANDSHAKE_DONE frame as soon
+as it completes the handshake.<a href="#section-4.11.2-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="discarding-0-rtt-keys">
+<section id="section-4.11.3">
+          <h4 id="name-discarding-0-rtt-keys">
+<a href="#section-4.11.3" class="section-number selfRef">4.11.3. </a><a href="#name-discarding-0-rtt-keys" class="section-name selfRef">Discarding 0-RTT Keys</a>
+          </h4>
+<p id="section-4.11.3-1">0-RTT and 1-RTT packets share the same packet number space, and clients do not
+send 0-RTT packets after sending a 1-RTT packet (<a href="#using-early-data" class="xref">Section 5.6</a>).<a href="#section-4.11.3-1" class="pilcrow">¶</a></p>
+<p id="section-4.11.3-2">Therefore, a client SHOULD discard 0-RTT keys as soon as it installs 1-RTT
+keys, since they have no use after that moment.<a href="#section-4.11.3-2" class="pilcrow">¶</a></p>
+<p id="section-4.11.3-3">Additionally, a server MAY discard 0-RTT keys as soon as it receives a 1-RTT
+packet.  However, due to packet reordering, a 0-RTT packet could arrive after
+a 1-RTT packet.  Servers MAY temporarily retain 0-RTT keys to allow decrypting
+reordered packets without requiring their contents to be retransmitted with
+1-RTT keys.  After receiving a 1-RTT packet, servers MUST discard 0-RTT keys
+within a short time; the RECOMMENDED time period is three times the Probe
+Timeout (PTO, see <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>).  A server MAY discard 0-RTT keys earlier
+if it determines that it has received all 0-RTT packets, which can be done by
+keeping track of missing packet numbers.<a href="#section-4.11.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="packet-protection">
+<section id="section-5">
+      <h2 id="name-packet-protection">
+<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-packet-protection" class="section-name selfRef">Packet Protection</a>
+      </h2>
+<p id="section-5-1">As with TLS over TCP, QUIC protects packets with keys derived from the TLS
+handshake, using the AEAD algorithm negotiated by TLS.<a href="#section-5-1" class="pilcrow">¶</a></p>
+<div id="protection-keys">
+<section id="section-5.1">
+        <h3 id="name-packet-protection-keys">
+<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-packet-protection-keys" class="section-name selfRef">Packet Protection Keys</a>
+        </h3>
+<p id="section-5.1-1">QUIC derives packet protection keys in the same way that TLS derives record
+protection keys.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.1-2">Each encryption level has separate secret values for protection of packets sent
+in each direction.  These traffic secrets are derived by TLS (see Section 7.1 of
+<span>[<a href="#TLS13" class="xref">TLS13</a>]</span>) and are used by QUIC for all encryption levels except the Initial
+encryption level.  The secrets for the Initial encryption level are computed
+based on the client's initial Destination Connection ID, as described in
+<a href="#initial-secrets" class="xref">Section 5.2</a>.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.1-3">The keys used for packet protection are computed from the TLS secrets using the
+KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label function described in
+Section 7.1 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> is used, using the hash function from the negotiated
+cipher suite.  Other versions of TLS MUST provide a similar function in order to
+be used with QUIC.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
+<p id="section-5.1-4">The current encryption level secret and the label "quic key" are input to the
+KDF to produce the AEAD key; the label "quic iv" is used to derive the IV; see
+<a href="#aead" class="xref">Section 5.3</a>.  The header protection key uses the "quic hp" label; see
+<a href="#header-protect" class="xref">Section 5.4</a>.  Using these labels provides key separation between QUIC
+and TLS; see <a href="#key-diversity" class="xref">Section 9.6</a>.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
+<p id="section-5.1-5">The KDF used for initial secrets is always the HKDF-Expand-Label function from
+TLS 1.3 (see <a href="#initial-secrets" class="xref">Section 5.2</a>).<a href="#section-5.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="initial-secrets">
+<section id="section-5.2">
+        <h3 id="name-initial-secrets">
+<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-initial-secrets" class="section-name selfRef">Initial Secrets</a>
+        </h3>
+<p id="section-5.2-1">Initial packets are protected with a secret derived from the Destination
+Connection ID field from the client's Initial packet. Specifically:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-5.2-2">
+<pre>
+initial_salt = 0xc3eef712c72ebb5a11a7d2432bb46365bef9f502
+initial_secret = HKDF-Extract(initial_salt,
+                              client_dst_connection_id)
+
+client_initial_secret = HKDF-Expand-Label(initial_secret,
+                                          "client in", "",
+                                          Hash.length)
+server_initial_secret = HKDF-Expand-Label(initial_secret,
+                                          "server in", "",
+                                          Hash.length)
+</pre><a href="#section-5.2-2" class="pilcrow">¶</a>
+</div>
+<p id="section-5.2-3">The hash function for HKDF when deriving initial secrets and keys is SHA-256
+<span>[<a href="#SHA" class="xref">SHA</a>]</span>.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.2-4">The connection ID used with HKDF-Expand-Label is the Destination Connection ID
+in the Initial packet sent by the client.  This will be a randomly-selected
+value unless the client creates the Initial packet after receiving a Retry
+packet, where the Destination Connection ID is selected by the server.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
+<p id="section-5.2-5">The value of initial_salt is a 20 byte sequence shown in the figure in
+hexadecimal notation. Future versions of QUIC SHOULD generate a new salt value,
+thus ensuring that the keys are different for each version of QUIC. This
+prevents a middlebox that only recognizes one version of QUIC from seeing or
+modifying the contents of packets from future versions.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
+<p id="section-5.2-6">The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial
+packets even where the TLS versions offered do not include TLS 1.3.<a href="#section-5.2-6" class="pilcrow">¶</a></p>
+<p id="section-5.2-7">The secrets used for protecting Initial packets change when a server sends a
+Retry packet to use the connection ID value selected by the server.  The secrets
+do not change when a client changes the Destination Connection ID it uses in
+response to an Initial packet from the server.<a href="#section-5.2-7" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-5.2-8">
+          <dt id="section-5.2-8.1">Note:</dt>
+<dd id="section-5.2-8.2">
+  The Destination Connection ID is of arbitrary length, and it could be zero
+length if the server sends a Retry packet with a zero-length Source Connection
+ID field.  In this case, the Initial keys provide no assurance to the client
+that the server received its packet; the client has to rely on the exchange
+that included the Retry packet for that property.<a href="#section-5.2-8.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-5.2-9"><a href="#test-vectors" class="xref">Appendix A</a> contains test vectors for packet encryption.<a href="#section-5.2-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="aead">
+<section id="section-5.3">
+        <h3 id="name-aead-usage">
+<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-aead-usage" class="section-name selfRef">AEAD Usage</a>
+        </h3>
+<p id="section-5.3-1">The Authentication Encryption with Associated Data (AEAD) <span>[<a href="#AEAD" class="xref">AEAD</a>]</span> function
+used for QUIC packet protection is the AEAD that is negotiated for use with the
+TLS connection.  For example, if TLS is using the TLS_AES_128_GCM_SHA256, the
+AEAD_AES_128_GCM function is used.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
+<p id="section-5.3-2">Packets are protected prior to applying header protection (<a href="#header-protect" class="xref">Section 5.4</a>).
+The unprotected packet header is part of the associated data (A).  When removing
+packet protection, an endpoint first removes the header protection.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
+<p id="section-5.3-3">All QUIC packets other than Version Negotiation and Retry packets are protected
+with an AEAD algorithm <span>[<a href="#AEAD" class="xref">AEAD</a>]</span>. Prior to establishing a shared secret, packets
+are protected with AEAD_AES_128_GCM and a key derived from the Destination
+Connection ID in the client's first Initial packet (see <a href="#initial-secrets" class="xref">Section 5.2</a>).
+This provides protection against off-path attackers and robustness against QUIC
+version unaware middleboxes, but not against on-path attackers.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
+<p id="section-5.3-4">QUIC can use any of the ciphersuites defined in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> with the exception of
+TLS_AES_128_CCM_8_SHA256.  A ciphersuite MUST NOT be negotiated unless a header
+protection scheme is defined for the ciphersuite.  This document defines a
+header protection scheme for all ciphersuites defined in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> aside from
+TLS_AES_128_CCM_8_SHA256.  These ciphersuites have a 16-byte authentication tag
+and produce an output 16 bytes larger than their input.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-5.3-5">
+          <dt id="section-5.3-5.1">Note:</dt>
+<dd id="section-5.3-5.2">
+  An endpoint MUST NOT reject a ClientHello that offers a ciphersuite that it
+does not support, or it would be impossible to deploy a new ciphersuite.  This
+also applies to TLS_AES_128_CCM_8_SHA256.<a href="#section-5.3-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-5.3-6">The key and IV for the packet are computed as described in <a href="#protection-keys" class="xref">Section 5.1</a>.
+The nonce, N, is formed by combining the packet protection IV with the packet
+number.  The 62 bits of the reconstructed QUIC packet number in network byte
+order are left-padded with zeros to the size of the IV.  The exclusive OR of the
+padded packet number and the IV forms the AEAD nonce.<a href="#section-5.3-6" class="pilcrow">¶</a></p>
+<p id="section-5.3-7">The associated data, A, for the AEAD is the contents of the QUIC header,
+starting from the flags byte in either the short or long header, up to and
+including the unprotected packet number.<a href="#section-5.3-7" class="pilcrow">¶</a></p>
+<p id="section-5.3-8">The input plaintext, P, for the AEAD is the payload of the QUIC packet, as
+described in <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>.<a href="#section-5.3-8" class="pilcrow">¶</a></p>
+<p id="section-5.3-9">The output ciphertext, C, of the AEAD is transmitted in place of P.<a href="#section-5.3-9" class="pilcrow">¶</a></p>
+<p id="section-5.3-10">Some AEAD functions have limits for how many packets can be encrypted under the
+same key and IV (see for example <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span>).  This might be lower than the
+packet number limit.  An endpoint MUST initiate a key update (<a href="#key-update" class="xref">Section 6</a>)
+prior to exceeding any limit set for the AEAD that is in use.<a href="#section-5.3-10" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="header-protect">
+<section id="section-5.4">
+        <h3 id="name-header-protection">
+<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-header-protection" class="section-name selfRef">Header Protection</a>
+        </h3>
+<p id="section-5.4-1">Parts of QUIC packet headers, in particular the Packet Number field, are
+protected using a key that is derived separate to the packet protection key and
+IV.  The key derived using the "quic hp" label is used to provide
+confidentiality protection for those fields that are not exposed to on-path
+elements.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
+<p id="section-5.4-2">This protection applies to the least-significant bits of the first byte, plus
+the Packet Number field.  The four least-significant bits of the first byte are
+protected for packets with long headers; the five least significant bits of the
+first byte are protected for packets with short headers.  For both header forms,
+this covers the reserved bits and the Packet Number Length field; the Key Phase
+bit is also protected for packets with a short header.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
+<p id="section-5.4-3">The same header protection key is used for the duration of the connection, with
+the value not changing after a key update (see <a href="#key-update" class="xref">Section 6</a>).  This allows
+header protection to be used to protect the key phase.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
+<p id="section-5.4-4">This process does not apply to Retry or Version Negotiation packets, which do
+not contain a protected payload or any of the fields that are protected by this
+process.<a href="#section-5.4-4" class="pilcrow">¶</a></p>
+<div id="header-protection-application">
+<section id="section-5.4.1">
+          <h4 id="name-header-protection-applicati">
+<a href="#section-5.4.1" class="section-number selfRef">5.4.1. </a><a href="#name-header-protection-applicati" class="section-name selfRef">Header Protection Application</a>
+          </h4>
+<p id="section-5.4.1-1">Header protection is applied after packet protection is applied (see <a href="#aead" class="xref">Section 5.3</a>).
+The ciphertext of the packet is sampled and used as input to an encryption
+algorithm.  The algorithm used depends on the negotiated AEAD.<a href="#section-5.4.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.4.1-2">The output of this algorithm is a 5 byte mask which is applied to the protected
+header fields using exclusive OR.  The least significant bits of the first byte
+of the packet are masked by the least significant bits of the first mask byte,
+and the packet number is masked with the remaining bytes.  Any unused bytes of
+mask that might result from a shorter packet number encoding are unused.<a href="#section-5.4.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.4.1-3"><a href="#pseudo-hp" class="xref">Figure 6</a> shows a sample algorithm for applying header protection. Removing
+header protection only differs in the order in which the packet number length
+(pn_length) is determined.<a href="#section-5.4.1-3" class="pilcrow">¶</a></p>
+<span id="name-header-protection-pseudocod"></span><div id="pseudo-hp">
+<figure id="figure-6">
+            <div class="artwork art-text alignLeft" id="section-5.4.1-4.1">
+<pre>
+mask = header_protection(hp_key, sample)
+
+pn_length = (packet[0] &amp; 0x03) + 1
+if (packet[0] &amp; 0x80) == 0x80:
+   # Long header: 4 bits masked
+   packet[0] ^= mask[0] &amp; 0x0f
+else:
+   # Short header: 5 bits masked
+   packet[0] ^= mask[0] &amp; 0x1f
+
+# pn_offset is the start of the Packet Number field.
+packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]
+</pre>
+</div>
+<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
+<a href="#name-header-protection-pseudocod" class="selfRef">Header Protection Pseudocode</a>
+            </figcaption></figure>
+</div>
+<p id="section-5.4.1-5"><a href="#fig-sample" class="xref">Figure 7</a> shows an example long header packet (Initial) and a short header
+packet. <a href="#fig-sample" class="xref">Figure 7</a> shows the fields in each header that are covered by
+header protection and the portion of the protected packet payload that is
+sampled.<a href="#section-5.4.1-5" class="pilcrow">¶</a></p>
+<span id="name-header-protection-and-ciphe"></span><div id="fig-sample">
+<figure id="figure-7">
+            <div class="artwork art-text alignLeft" id="section-5.4.1-6.1">
+<pre>
+Initial Packet {
+  Header Form (1) = 1,
+  Fixed Bit (1) = 1,
+  Long Packet Type (2) = 0,
+  Reserved Bits (2),         # Protected
+  Packet Number Length (2),  # Protected
+  Version (32),
+  DCID Len (8),
+  Destination Connection ID (0..160),
+  SCID Len (8),
+  Source Connection ID (0..160),
+  Token Length (i),
+  Token (..),
+  Packet Number (8..32),     # Protected
+  Protected Payload (0..24), # Skipped Part
+  Protected Payload (128),   # Sampled Part
+  Protected Payload (..)     # Remainder
+}
+
+Short Header Packet {
+  Header Form (1) = 0,
+  Fixed Bit (1) = 1,
+  Spin Bit (1),
+  Reserved Bits (2),         # Protected
+  Key Phase (1),             # Protected
+  Packet Number Length (2),  # Protected
+  Destination Connection ID (0..160),
+  Packet Number (8..32),     # Protected
+  Protected Payload (0..24), # Skipped Part
+  Protected Payload (128),   # Sampled Part
+  Protected Payload (..),    # Remainder
+}
+</pre>
+</div>
+<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
+<a href="#name-header-protection-and-ciphe" class="selfRef">Header Protection and Ciphertext Sample</a>
+            </figcaption></figure>
+</div>
+<p id="section-5.4.1-7">Before a TLS ciphersuite can be used with QUIC, a header protection algorithm
+MUST be specified for the AEAD used with that ciphersuite.  This document
+defines algorithms for AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM
+(all AES AEADs are defined in <span>[<a href="#AEAD" class="xref">AEAD</a>]</span>), and
+AEAD_CHACHA20_POLY1305 <span>[<a href="#CHACHA" class="xref">CHACHA</a>]</span>.  Prior to TLS selecting a
+ciphersuite, AES header protection is used (<a href="#hp-aes" class="xref">Section 5.4.3</a>), matching the
+AEAD_AES_128_GCM packet protection.<a href="#section-5.4.1-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="hp-sample">
+<section id="section-5.4.2">
+          <h4 id="name-header-protection-sample">
+<a href="#section-5.4.2" class="section-number selfRef">5.4.2. </a><a href="#name-header-protection-sample" class="section-name selfRef">Header Protection Sample</a>
+          </h4>
+<p id="section-5.4.2-1">The header protection algorithm uses both the header protection key and a sample
+of the ciphertext from the packet Payload field.<a href="#section-5.4.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.4.2-2">The same number of bytes are always sampled, but an allowance needs to be made
+for the endpoint removing protection, which will not know the length of the
+Packet Number field.  In sampling the packet ciphertext, the Packet Number field
+is assumed to be 4 bytes long (its maximum possible encoded length).<a href="#section-5.4.2-2" class="pilcrow">¶</a></p>
+<p id="section-5.4.2-3">An endpoint MUST discard packets that are not long enough to contain a complete
+sample.<a href="#section-5.4.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.4.2-4">To ensure that sufficient data is available for sampling, packets are padded so
+that the combined lengths of the encoded packet number and protected payload is
+at least 4 bytes longer than the sample required for header protection.  The
+ciphersuites defined in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> - other than TLS_AES_128_CCM_8_SHA256, for
+which a header protection scheme is not defined in this document - have 16-byte
+expansions and 16-byte header protection samples.  This results in needing at
+least 3 bytes of frames in the unprotected payload if the packet number is
+encoded on a single byte, or 2 bytes of frames for a 2-byte packet number
+encoding.<a href="#section-5.4.2-4" class="pilcrow">¶</a></p>
+<p id="section-5.4.2-5">The sampled ciphertext for a packet with a short header can be determined by the
+following pseudocode:<a href="#section-5.4.2-5" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-5.4.2-6">
+<pre>
+sample_offset = 1 + len(connection_id) + 4
+
+sample = packet[sample_offset..sample_offset+sample_length]
+</pre><a href="#section-5.4.2-6" class="pilcrow">¶</a>
+</div>
+<p id="section-5.4.2-7">For example, for a packet with a short header, an 8 byte connection ID, and
+protected with AEAD_AES_128_GCM, the sample takes bytes 13 to 28 inclusive
+(using zero-based indexing).<a href="#section-5.4.2-7" class="pilcrow">¶</a></p>
+<p id="section-5.4.2-8">A packet with a long header is sampled in the same way, noting that multiple
+QUIC packets might be included in the same UDP datagram and that each one is
+handled separately.<a href="#section-5.4.2-8" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-5.4.2-9">
+<pre>
+sample_offset = 7 + len(destination_connection_id) +
+                    len(source_connection_id) +
+                    len(payload_length) + 4
+if packet_type == Initial:
+    sample_offset += len(token_length) +
+                     len(token)
+
+sample = packet[sample_offset..sample_offset+sample_length]
+</pre><a href="#section-5.4.2-9" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="hp-aes">
+<section id="section-5.4.3">
+          <h4 id="name-aes-based-header-protection">
+<a href="#section-5.4.3" class="section-number selfRef">5.4.3. </a><a href="#name-aes-based-header-protection" class="section-name selfRef">AES-Based Header Protection</a>
+          </h4>
+<p id="section-5.4.3-1">This section defines the packet protection algorithm for AEAD_AES_128_GCM,
+AEAD_AES_128_CCM, and AEAD_AES_256_GCM. AEAD_AES_128_GCM and
+AEAD_AES_128_CCM use 128-bit AES <span>[<a href="#AES" class="xref">AES</a>]</span> in
+electronic code-book (ECB) mode. AEAD_AES_256_GCM uses
+256-bit AES in ECB mode.<a href="#section-5.4.3-1" class="pilcrow">¶</a></p>
+<p id="section-5.4.3-2">This algorithm samples 16 bytes from the packet ciphertext. This value is used
+as the input to AES-ECB.  In pseudocode:<a href="#section-5.4.3-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-5.4.3-3">
+<pre>
+mask = AES-ECB(hp_key, sample)
+</pre><a href="#section-5.4.3-3" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="hp-chacha">
+<section id="section-5.4.4">
+          <h4 id="name-chacha20-based-header-prote">
+<a href="#section-5.4.4" class="section-number selfRef">5.4.4. </a><a href="#name-chacha20-based-header-prote" class="section-name selfRef">ChaCha20-Based Header Protection</a>
+          </h4>
+<p id="section-5.4.4-1">When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw ChaCha20
+function as defined in Section 2.4 of <span>[<a href="#CHACHA" class="xref">CHACHA</a>]</span>.  This uses a 256-bit key and
+16 bytes sampled from the packet protection output.<a href="#section-5.4.4-1" class="pilcrow">¶</a></p>
+<p id="section-5.4.4-2">The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20
+implementation could take a 32-bit integer in place of a byte sequence, in
+which case the byte sequence is interpreted as a little-endian value.<a href="#section-5.4.4-2" class="pilcrow">¶</a></p>
+<p id="section-5.4.4-3">The remaining 12 bytes are used as the nonce. A ChaCha20 implementation might
+take an array of three 32-bit integers in place of a byte sequence, in which
+case the nonce bytes are interpreted as a sequence of 32-bit little-endian
+integers.<a href="#section-5.4.4-3" class="pilcrow">¶</a></p>
+<p id="section-5.4.4-4">The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes. In
+pseudocode:<a href="#section-5.4.4-4" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-5.4.4-5">
+<pre>
+counter = sample[0..3]
+nonce = sample[4..15]
+mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})
+</pre><a href="#section-5.4.4-5" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="receiving-protected-packets">
+<section id="section-5.5">
+        <h3 id="name-receiving-protected-packets">
+<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-receiving-protected-packets" class="section-name selfRef">Receiving Protected Packets</a>
+        </h3>
+<p id="section-5.5-1">Once an endpoint successfully receives a packet with a given packet number, it
+MUST discard all packets in the same packet number space with higher packet
+numbers if they cannot be successfully unprotected with either the same key, or
+- if there is a key update - the next packet protection key (see
+<a href="#key-update" class="xref">Section 6</a>).  Similarly, a packet that appears to trigger a key update, but
+cannot be unprotected successfully MUST be discarded.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
+<p id="section-5.5-2">Failure to unprotect a packet does not necessarily indicate the existence of a
+protocol error in a peer or an attack.  The truncated packet number encoding
+used in QUIC can cause packet numbers to be decoded incorrectly if they are
+delayed significantly.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="using-early-data">
+<section id="section-5.6">
+        <h3 id="name-use-of-0-rtt-keys">
+<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-use-of-0-rtt-keys" class="section-name selfRef">Use of 0-RTT Keys</a>
+        </h3>
+<p id="section-5.6-1">If 0-RTT keys are available (see <a href="#enable-0rtt" class="xref">Section 4.6</a>), the lack of replay protection
+means that restrictions on their use are necessary to avoid replay attacks on
+the protocol.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
+<p id="section-5.6-2">A client MUST only use 0-RTT keys to protect data that is idempotent.  A client
+MAY wish to apply additional restrictions on what data it sends prior to the
+completion of the TLS handshake.  A client otherwise treats 0-RTT keys as
+equivalent to 1-RTT keys, except that it MUST NOT send ACKs with 0-RTT keys.<a href="#section-5.6-2" class="pilcrow">¶</a></p>
+<p id="section-5.6-3">A client that receives an indication that its 0-RTT data has been accepted by a
+server can send 0-RTT data until it receives all of the server's handshake
+messages.  A client SHOULD stop sending 0-RTT data if it receives an indication
+that 0-RTT data has been rejected.<a href="#section-5.6-3" class="pilcrow">¶</a></p>
+<p id="section-5.6-4">A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT keys to
+protect acknowledgements of 0-RTT packets.  A client MUST NOT attempt to
+decrypt 0-RTT packets it receives and instead MUST discard them.<a href="#section-5.6-4" class="pilcrow">¶</a></p>
+<p id="section-5.6-5">Once a client has installed 1-RTT keys, it MUST NOT send any more 0-RTT
+packets.<a href="#section-5.6-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-5.6-6">
+          <dt id="section-5.6-6.1">Note:</dt>
+<dd id="section-5.6-6.2">
+  0-RTT data can be acknowledged by the server as it receives it, but any
+packets containing acknowledgments of 0-RTT data cannot have packet protection
+removed by the client until the TLS handshake is complete.  The 1-RTT keys
+necessary to remove packet protection cannot be derived until the client
+receives all server handshake messages.<a href="#section-5.6-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="pre-hs-protected">
+<section id="section-5.7">
+        <h3 id="name-receiving-out-of-order-prot">
+<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-receiving-out-of-order-prot" class="section-name selfRef">Receiving Out-of-Order Protected Frames</a>
+        </h3>
+<p id="section-5.7-1">Due to reordering and loss, protected packets might be received by an endpoint
+before the final TLS handshake messages are received.  A client will be unable
+to decrypt 1-RTT packets from the server, whereas a server will be able to
+decrypt 1-RTT packets from the client.  Endpoints in either role MUST NOT
+decrypt 1-RTT packets from their peer prior to completing the handshake.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
+<p id="section-5.7-2">Even though 1-RTT keys are available to a server after receiving the first
+handshake messages from a client, it is missing assurances on the client state:<a href="#section-5.7-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.7-3.1">The client is not authenticated, unless the server has chosen to use a
+pre-shared key and validated the client's pre-shared key binder; see Section
+4.2.11 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>.<a href="#section-5.7-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.7-3.2">The client has not demonstrated liveness, unless a RETRY packet was used.<a href="#section-5.7-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.7-3.3">Any received 0-RTT data that the server responds to might be due to a replay
+attack.<a href="#section-5.7-3.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-5.7-4">Therefore, the server's use of 1-RTT keys MUST be limited to sending data before
+the handshake is complete.  A server MUST NOT process incoming 1-RTT protected
+packets before the TLS handshake is complete.  Because sending acknowledgments
+indicates that all frames in a packet have been processed, a server cannot send
+acknowledgments for 1-RTT packets until the TLS handshake is complete.  Received
+packets protected with 1-RTT keys MAY be stored and later decrypted and used
+once the handshake is complete.<a href="#section-5.7-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-5.7-5">
+          <dt id="section-5.7-5.1">Note:</dt>
+<dd id="section-5.7-5.2">
+  TLS implementations might provide all 1-RTT secrets prior to handshake
+completion.  Even where QUIC implementations have 1-RTT read keys, those keys
+cannot be used prior to completing the handshake.<a href="#section-5.7-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-5.7-6">The requirement for the server to wait for the client Finished message creates
+a dependency on that message being delivered.  A client can avoid the
+potential for head-of-line blocking that this implies by sending its 1-RTT
+packets coalesced with a handshake packet containing a copy of the CRYPTO frame
+that carries the Finished message, until one of the handshake packets is
+acknowledged.  This enables immediate server processing for those packets.<a href="#section-5.7-6" class="pilcrow">¶</a></p>
+<p id="section-5.7-7">A server could receive packets protected with 0-RTT keys prior to receiving a
+TLS ClientHello.  The server MAY retain these packets for later decryption in
+anticipation of receiving a ClientHello.<a href="#section-5.7-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="retry-integrity">
+<section id="section-5.8">
+        <h3 id="name-retry-packet-integrity">
+<a href="#section-5.8" class="section-number selfRef">5.8. </a><a href="#name-retry-packet-integrity" class="section-name selfRef">Retry Packet Integrity</a>
+        </h3>
+<p id="section-5.8-1">Retry packets (see the Retry Packet section of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>) carry a
+Retry Integrity Tag that provides two properties: it allows discarding
+packets that have accidentally been corrupted by the network, and it diminishes
+off-path attackers' ability to send valid Retry packets.<a href="#section-5.8-1" class="pilcrow">¶</a></p>
+<p id="section-5.8-2">The Retry Integrity Tag is a 128-bit field that is computed as the output of
+AEAD_AES_128_GCM <span>[<a href="#AEAD" class="xref">AEAD</a>]</span> used with the following inputs:<a href="#section-5.8-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.8-3.1">The secret key, K, is 128 bits equal to 0x4d32ecdb2a2133c841e4043df27d4430.<a href="#section-5.8-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.8-3.2">The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575.<a href="#section-5.8-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.8-3.3">The plaintext, P, is empty.<a href="#section-5.8-3.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.8-3.4">The associated data, A, is the contents of the Retry Pseudo-Packet, as
+illustrated in <a href="#retry-pseudo" class="xref">Figure 8</a>:<a href="#section-5.8-3.4" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-5.8-4">The secret key and the nonce are values derived by calling HKDF-Expand-Label
+using 0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as the
+secret, with labels being "quic key" and "quic iv" (<a href="#protection-keys" class="xref">Section 5.1</a>).<a href="#section-5.8-4" class="pilcrow">¶</a></p>
+<span id="name-retry-pseudo-packet"></span><div id="retry-pseudo">
+<figure id="figure-8">
+          <div class="artwork art-text alignLeft" id="section-5.8-5.1">
+<pre>
+Retry Pseudo-Packet {
+  ODCID Length (8),
+  Original Destination Connection ID (0..160),
+  Header Form (1) = 1,
+  Fixed Bit (1) = 1,
+  Long Packet Type (2) = 3,
+  Type-Specific Bits (4),
+  Version (32),
+  DCID Len (8),
+  Destination Connection ID (0..160),
+  SCID Len (8),
+  Retry Token (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
+<a href="#name-retry-pseudo-packet" class="selfRef">Retry Pseudo-Packet</a>
+          </figcaption></figure>
+</div>
+<p id="section-5.8-6">The Retry Pseudo-Packet is not sent over the wire. It is computed by taking
+the transmitted Retry packet, removing the Retry Integrity Tag and prepending
+the two following fields:<a href="#section-5.8-6" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-5.8-7">
+          <dt id="section-5.8-7.1">ODCID Length:</dt>
+<dd id="section-5.8-7.2">
+  The ODCID Len contains the length in bytes of the Original Destination
+Connection ID field that follows it, encoded as an 8-bit unsigned integer.<a href="#section-5.8-7.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-5.8-7.3">Original Destination Connection ID:</dt>
+<dd id="section-5.8-7.4">
+  The Original Destination Connection ID contains the value of the Destination
+Connection ID from the Initial packet that this Retry is in response to. The
+length of this field is given in ODCID Len. The presence of this field
+mitigates an off-path attacker's ability to inject a Retry packet.<a href="#section-5.8-7.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+</section>
+</div>
+<div id="key-update">
+<section id="section-6">
+      <h2 id="name-key-update">
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-key-update" class="section-name selfRef">Key Update</a>
+      </h2>
+<p id="section-6-1">Once the handshake is confirmed (see <a href="#handshake-confirmed" class="xref">Section 4.1.2</a>), an endpoint MAY
+initiate a key update.<a href="#section-6-1" class="pilcrow">¶</a></p>
+<p id="section-6-2">The Key Phase bit indicates which packet protection keys are used to protect the
+packet.  The Key Phase bit is initially set to 0 for the first set of 1-RTT
+packets and toggled to signal each subsequent key update.<a href="#section-6-2" class="pilcrow">¶</a></p>
+<p id="section-6-3">The Key Phase bit allows a recipient to detect a change in keying material
+without needing to receive the first packet that triggered the change.  An
+endpoint that notices a changed Key Phase bit updates keys and decrypts the
+packet that contains the changed value.<a href="#section-6-3" class="pilcrow">¶</a></p>
+<p id="section-6-4">This mechanism replaces the TLS KeyUpdate message.  Endpoints MUST NOT send a
+TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate
+message as a connection error of type 0x10a, equivalent to a fatal TLS alert of
+unexpected_message (see <a href="#tls-errors" class="xref">Section 4.10</a>).<a href="#section-6-4" class="pilcrow">¶</a></p>
+<p id="section-6-5"><a href="#ex-key-update" class="xref">Figure 9</a> shows a key update process, where the initial set of keys used
+(identified with @M) are replaced by updated keys (identified with @N).  The
+value of the Key Phase bit is indicated in brackets [].<a href="#section-6-5" class="pilcrow">¶</a></p>
+<span id="name-key-update-2"></span><div id="ex-key-update">
+<figure id="figure-9">
+        <div class="artwork art-text alignLeft" id="section-6-6.1">
+<pre>
+   Initiating Peer                    Responding Peer
+
+@M [0] QUIC Packets
+
+... Update to @N
+@N [1] QUIC Packets
+                      --------&gt;
+                                         Update to @N ...
+                                      QUIC Packets [1] @N
+                      &lt;--------
+                                      QUIC Packets [1] @N
+                                    containing ACK
+                      &lt;--------
+... Key Update Permitted
+
+@N [1] QUIC Packets
+         containing ACK for @N packets
+                      --------&gt;
+                                 Key Update Permitted ...
+</pre>
+</div>
+<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
+<a href="#name-key-update-2" class="selfRef">Key Update</a>
+        </figcaption></figure>
+</div>
+<div id="key-update-initiate">
+<section id="section-6.1">
+        <h3 id="name-initiating-a-key-update">
+<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-initiating-a-key-update" class="section-name selfRef">Initiating a Key Update</a>
+        </h3>
+<p id="section-6.1-1">Endpoints maintain separate read and write secrets for packet protection.  An
+endpoint initiates a key update by updating its packet protection write secret
+and using that to protect new packets.  The endpoint creates a new write secret
+from the existing write secret as performed in Section 7.2 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>.  This
+uses the KDF function provided by TLS with a label of "quic ku".  The
+corresponding key and IV are created from that secret as defined in
+<a href="#protection-keys" class="xref">Section 5.1</a>.  The header protection key is not updated.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
+<p id="section-6.1-2">For example, to update write keys with TLS 1.3, HKDF-Expand-Label is used as:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-6.1-3">
+<pre>
+secret_&lt;n+1&gt; = HKDF-Expand-Label(secret_&lt;n&gt;, "quic ku",
+                                 "", Hash.length)
+</pre><a href="#section-6.1-3" class="pilcrow">¶</a>
+</div>
+<p id="section-6.1-4">The endpoint toggles the value of the Key Phase bit and uses the updated key and
+IV to protect all subsequent packets.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
+<p id="section-6.1-5">An endpoint MUST NOT initiate a key update prior to having confirmed the
+handshake (<a href="#handshake-confirmed" class="xref">Section 4.1.2</a>).  An endpoint MUST NOT initiate a subsequent
+key update prior unless it has received an acknowledgment for a packet that was
+sent protected with keys from the current key phase.  This ensures that keys are
+available to both peers before another key update can be initiated.  This can be
+implemented by tracking the lowest packet number sent with each key phase, and
+the highest acknowledged packet number in the 1-RTT space: once the latter is
+higher than or equal to the former, another key update can be initiated.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-6.1-6">
+          <dt id="section-6.1-6.1">Note:</dt>
+<dd id="section-6.1-6.2">
+  Keys of packets other than the 1-RTT packets are never updated; their keys are
+derived solely from the TLS handshake state.<a href="#section-6.1-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-6.1-7">The endpoint that initiates a key update also updates the keys that it uses for
+receiving packets.  These keys will be needed to process packets the peer sends
+after updating.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
+<p id="section-6.1-8">An endpoint SHOULD retain old keys so that packets sent by its peer prior to
+receiving the key update can be processed.  Discarding old keys too early can
+cause delayed packets to be discarded.  Discarding packets will be interpreted
+as packet loss by the peer and could adversely affect performance.<a href="#section-6.1-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="responding-to-a-key-update">
+<section id="section-6.2">
+        <h3 id="name-responding-to-a-key-update">
+<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-responding-to-a-key-update" class="section-name selfRef">Responding to a Key Update</a>
+        </h3>
+<p id="section-6.2-1">A peer is permitted to initiate a key update after receiving an acknowledgement
+of a packet in the current key phase.  An endpoint detects a key update when
+processing a packet with a key phase that differs from the value last used to
+protect the last packet it sent.  To process this packet, the endpoint uses the
+next packet protection key and IV.  See <a href="#receive-key-generation" class="xref">Section 6.3</a> for
+considerations about generating these keys.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
+<p id="section-6.2-2">If a packet is successfully processed using the next key and IV, then the peer
+has initiated a key update.  The endpoint MUST update its send keys to the
+corresponding key phase in response, as described in <a href="#key-update-initiate" class="xref">Section 6.1</a>.
+Sending keys MUST be updated before sending an acknowledgement for the packet
+that was received with updated keys.  By acknowledging the packet that triggered
+the key update in a packet protected with the updated keys, the endpoint signals
+that the key update is complete.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.2-3">An endpoint can defer sending the packet or acknowledgement according to its
+normal packet sending behaviour; it is not necessary to immediately generate a
+packet in response to a key update.  The next packet sent by the endpoint will
+use the updated keys.  The next packet that contains an acknowledgement will
+cause the key update to be completed.  If an endpoint detects a second update
+before it has sent any packets with updated keys containing an
+acknowledgement for the packet that initiated the key update, it indicates that
+its peer has updated keys twice without awaiting confirmation.  An endpoint MAY
+treat consecutive key updates as a connection error of type KEY_UPDATE_ERROR.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
+<p id="section-6.2-4">An endpoint that receives an acknowledgement that is carried in a packet
+protected with old keys where any acknowledged packet was protected with newer
+keys MAY treat that as a connection error of type KEY_UPDATE_ERROR.  This
+indicates that a peer has received and acknowledged a packet that initiates a
+key update, but has not updated keys in response.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="receive-key-generation">
+<section id="section-6.3">
+        <h3 id="name-timing-of-receive-key-gener">
+<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-timing-of-receive-key-gener" class="section-name selfRef">Timing of Receive Key Generation</a>
+        </h3>
+<p id="section-6.3-1">Endpoints responding to an apparent key update MUST NOT generate a timing
+side-channel signal that might indicate that the Key Phase bit was invalid (see
+<a href="#header-protect-analysis" class="xref">Section 9.4</a>).  Endpoints can use dummy packet protection keys in
+place of discarded keys when key updates are not yet permitted.  Using dummy
+keys will generate no variation in the timing signal produced by attempting to
+remove packet protection, and results in all packets with an invalid Key Phase
+bit being rejected.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
+<p id="section-6.3-2">The process of creating new packet protection keys for receiving packets could
+reveal that a key update has occurred.  An endpoint MAY perform this process as
+part of packet processing, but this creates a timing signal that can be used by
+an attacker to learn when key updates happen and thus the value of the Key Phase
+bit in certain packets.  Endpoints MAY instead defer the creation of the next
+set of receive packet protection keys until some time after a key update
+completes, up to three times the PTO; see <a href="#old-keys-recv" class="xref">Section 6.5</a>.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
+<p id="section-6.3-3">Once generated, the next set of packet protection keys SHOULD be retained, even
+if the packet that was received was subsequently discarded.  Packets containing
+apparent key updates are easy to forge and - while the process of key update
+does not require significant effort - triggering this process could be used by
+an attacker for DoS.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
+<p id="section-6.3-4">For this reason, endpoints MUST be able to retain two sets of packet protection
+keys for receiving packets: the current and the next.  Retaining the previous
+keys in addition to these might improve performance, but this is not essential.<a href="#section-6.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="old-keys-send">
+<section id="section-6.4">
+        <h3 id="name-sending-with-updated-keys">
+<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-sending-with-updated-keys" class="section-name selfRef">Sending with Updated Keys</a>
+        </h3>
+<p id="section-6.4-1">An endpoint always sends packets that are protected with the newest keys.  Keys
+used for packet protection can be discarded immediately after switching to newer
+keys.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
+<p id="section-6.4-2">Packets with higher packet numbers MUST be protected with either the same or
+newer packet protection keys than packets with lower packet numbers.  An
+endpoint that successfully removes protection with old keys when newer keys were
+used for packets with lower packet numbers MUST treat this as a connection error
+of type KEY_UPDATE_ERROR.<a href="#section-6.4-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="old-keys-recv">
+<section id="section-6.5">
+        <h3 id="name-receiving-with-different-ke">
+<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-receiving-with-different-ke" class="section-name selfRef">Receiving with Different Keys</a>
+        </h3>
+<p id="section-6.5-1">For receiving packets during a key update, packets protected with older keys
+might arrive if they were delayed by the network.  Retaining old packet
+protection keys allows these packets to be successfully processed.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
+<p id="section-6.5-2">As packets protected with keys from the next key phase use the same Key Phase
+value as those protected with keys from the previous key phase, it can be
+necessary to distinguish between the two.  This can be done using packet
+numbers.  A recovered packet number that is lower than any packet number from
+the current key phase uses the previous packet protection keys; a recovered
+packet number that is higher than any packet number from the current key phase
+requires the use of the next packet protection keys.<a href="#section-6.5-2" class="pilcrow">¶</a></p>
+<p id="section-6.5-3">Some care is necessary to ensure that any process for selecting between
+previous, current, and next packet protection keys does not expose a timing side
+channel that might reveal which keys were used to remove packet protection.  See
+<a href="#hp-side-channel" class="xref">Section 9.5</a> for more information.<a href="#section-6.5-3" class="pilcrow">¶</a></p>
+<p id="section-6.5-4">Alternatively, endpoints can retain only two sets of packet protection keys,
+swapping previous for next after enough time has passed to allow for reordering
+in the network.  In this case, the Key Phase bit alone can be used to select
+keys.<a href="#section-6.5-4" class="pilcrow">¶</a></p>
+<p id="section-6.5-5">An endpoint MAY allow a period of approximately the Probe Timeout (PTO; see
+<span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>) after a key update before it creates the next set of packet
+protection keys.  These updated keys MAY replace the previous keys at that time.
+With the caveat that PTO is a subjective measure - that is, a peer could have a
+different view of the RTT - this time is expected to be long enough that any
+reordered packets would be declared lost by a peer even if they were
+acknowledged and short enough to allow for subsequent key updates.<a href="#section-6.5-5" class="pilcrow">¶</a></p>
+<p id="section-6.5-6">Endpoints need to allow for the possibility that a peer might not be able to
+decrypt packets that initiate a key update during the period when it retains old
+keys.  Endpoints SHOULD wait three times the PTO before initiating a key update
+after receiving an acknowledgment that confirms that the previous key update was
+received.  Failing to allow sufficient time could lead to packets being
+discarded.<a href="#section-6.5-6" class="pilcrow">¶</a></p>
+<p id="section-6.5-7">An endpoint SHOULD retain old read keys for no more than three times the PTO.
+After this period, old read keys and their corresponding secrets SHOULD be
+discarded.<a href="#section-6.5-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="key-update-frequency">
+<section id="section-6.6">
+        <h3 id="name-key-update-frequency">
+<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-key-update-frequency" class="section-name selfRef">Key Update Frequency</a>
+        </h3>
+<p id="section-6.6-1">Key updates MUST be initiated before usage limits on packet protection keys are
+exceeded.  For the cipher suites mentioned in this document, the limits in
+Section 5.5 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> apply.  Other cipher suites MUST define usage limits
+in order to be used with QUIC.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="key-update-error">
+<section id="section-6.7">
+        <h3 id="name-key-update-error-code">
+<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-key-update-error-code" class="section-name selfRef">Key Update Error Code</a>
+        </h3>
+<p id="section-6.7-1">The KEY_UPDATE_ERROR error code (0xE) is used to signal errors related to key
+updates.<a href="#section-6.7-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="security-of-initial-messages">
+<section id="section-7">
+      <h2 id="name-security-of-initial-message">
+<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-of-initial-message" class="section-name selfRef">Security of Initial Messages</a>
+      </h2>
+<p id="section-7-1">Initial packets are not protected with a secret key, so they are subject to
+potential tampering by an attacker.  QUIC provides protection against attackers
+that cannot read packets, but does not attempt to provide additional protection
+against attacks where the attacker can observe and inject packets.  Some forms
+of tampering - such as modifying the TLS messages themselves - are detectable,
+but some - such as modifying ACKs - are not.<a href="#section-7-1" class="pilcrow">¶</a></p>
+<p id="section-7-2">For example, an attacker could inject a packet containing an ACK frame that
+makes it appear that a packet had not been received or to create a false
+impression of the state of the connection (e.g., by modifying the ACK Delay).
+Note that such a packet could cause a legitimate packet to be dropped as a
+duplicate.  Implementations SHOULD use caution in relying on any data which is
+contained in Initial packets that is not otherwise authenticated.<a href="#section-7-2" class="pilcrow">¶</a></p>
+<p id="section-7-3">It is also possible for the attacker to tamper with data that is carried in
+Handshake packets, but because that tampering requires modifying TLS handshake
+messages, that tampering will cause the TLS handshake to fail.<a href="#section-7-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="quic-specific-adjustments-to-the-tls-handshake">
+<section id="section-8">
+      <h2 id="name-quic-specific-adjustments-t">
+<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-quic-specific-adjustments-t" class="section-name selfRef">QUIC-Specific Adjustments to the TLS Handshake</a>
+      </h2>
+<p id="section-8-1">QUIC uses the TLS handshake for more than just negotiation of cryptographic
+parameters.  The TLS handshake provides preliminary values for QUIC transport
+parameters and allows a server to perform return routability checks on clients.<a href="#section-8-1" class="pilcrow">¶</a></p>
+<div id="protocol-negotiation">
+<section id="section-8.1">
+        <h3 id="name-protocol-negotiation">
+<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-protocol-negotiation" class="section-name selfRef">Protocol Negotiation</a>
+        </h3>
+<p id="section-8.1-1">QUIC requires that the cryptographic handshake provide authenticated protocol
+negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN)
+<span>[<a href="#ALPN" class="xref">ALPN</a>]</span> to select an application protocol.  Unless another mechanism
+is used for agreeing on an application protocol, endpoints MUST use ALPN for
+this purpose.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
+<p id="section-8.1-2">When using ALPN, endpoints MUST immediately close a connection (see Section
+10.3 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>) with a no_application_protocol TLS alert (QUIC error
+code 0x178; see <a href="#tls-errors" class="xref">Section 4.10</a>) if an application protocol is not negotiated.
+While <span>[<a href="#ALPN" class="xref">ALPN</a>]</span> only specifies that servers use this alert, QUIC clients MUST
+use error 0x178 to terminate a connection when ALPN negotiation fails.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
+<p id="section-8.1-3">An application protocol MAY restrict the QUIC versions that it can operate over.
+Servers MUST select an application protocol compatible with the QUIC version
+that the client has selected.  The server MUST treat the inability to select a
+compatible application protocol as a connection error of type 0x178
+(no_application_protocol).  Similarly, a client MUST treat the selection of an
+incompatible application protocol by a server as a connection error of type
+0x178.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="quic_parameters">
+<section id="section-8.2">
+        <h3 id="name-quic-transport-parameters-e">
+<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-quic-transport-parameters-e" class="section-name selfRef">QUIC Transport Parameters Extension</a>
+        </h3>
+<p id="section-8.2-1">QUIC transport parameters are carried in a TLS extension. Different versions of
+QUIC might define a different method for negotiating transport configuration.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
+<p id="section-8.2-2">Including transport parameters in the TLS handshake provides integrity
+protection for these values.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-8.2-3">
+<pre>
+   enum {
+      quic_transport_parameters(0xffa5), (65535)
+   } ExtensionType;
+</pre><a href="#section-8.2-3" class="pilcrow">¶</a>
+</div>
+<p id="section-8.2-4">The extension_data field of the quic_transport_parameters extension contains a
+value that is defined by the version of QUIC that is in use.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
+<p id="section-8.2-5">The quic_transport_parameters extension is carried in the ClientHello and the
+EncryptedExtensions messages during the handshake. Endpoints MUST send the
+quic_transport_parameters extension; endpoints that receive ClientHello or
+EncryptedExtensions messages without the quic_transport_parameters extension
+MUST close the connection with an error of type 0x16d (equivalent to a fatal TLS
+missing_extension alert, see <a href="#tls-errors" class="xref">Section 4.10</a>).<a href="#section-8.2-5" class="pilcrow">¶</a></p>
+<p id="section-8.2-6">While the transport parameters are technically available prior to the completion
+of the handshake, they cannot be fully trusted until the handshake completes,
+and reliance on them should be minimized.  However, any tampering with the
+parameters will cause the handshake to fail.<a href="#section-8.2-6" class="pilcrow">¶</a></p>
+<p id="section-8.2-7">Endpoints MUST NOT send this extension in a TLS connection that does not use
+QUIC (such as the use of TLS with TCP defined in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>).  A fatal
+unsupported_extension alert MUST be sent by an implementation that supports this
+extension if the extension is received when the transport is not QUIC.<a href="#section-8.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="remove-eoed">
+<section id="section-8.3">
+        <h3 id="name-removing-the-endofearlydata">
+<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-removing-the-endofearlydata" class="section-name selfRef">Removing the EndOfEarlyData Message</a>
+        </h3>
+<p id="section-8.3-1">The TLS EndOfEarlyData message is not used with QUIC.  QUIC does not rely on
+this message to mark the end of 0-RTT data or to signal the change to Handshake
+keys.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
+<p id="section-8.3-2">Clients MUST NOT send the EndOfEarlyData message.  A server MUST treat receipt
+of a CRYPTO frame in a 0-RTT packet as a connection error of type
+PROTOCOL_VIOLATION.<a href="#section-8.3-2" class="pilcrow">¶</a></p>
+<p id="section-8.3-3">As a result, EndOfEarlyData does not appear in the TLS handshake transcript.<a href="#section-8.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="compat-mode">
+<section id="section-8.4">
+        <h3 id="name-prohibit-tls-middlebox-comp">
+<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-prohibit-tls-middlebox-comp" class="section-name selfRef">Prohibit TLS Middlebox Compatibility Mode</a>
+        </h3>
+<p id="section-8.4-1">Appendix D.4 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> describes an alteration to the TLS 1.3 handshake as
+a workaround for bugs in some middleboxes. The TLS 1.3 middlebox compatibility
+mode involves setting the legacy_session_id field to a 32-byte value in the
+ClientHello and ServerHello, then sending a change_cipher_spec record. Both
+field and record carry no semantic content and are ignored.<a href="#section-8.4-1" class="pilcrow">¶</a></p>
+<p id="section-8.4-2">This mode has no use in QUIC as it only applies to middleboxes that interfere
+with TLS over TCP. QUIC also provides no means to carry a change_cipher_spec
+record. A client MUST NOT request the use of the TLS 1.3 compatibility mode. A
+server SHOULD treat the receipt of a TLS ClientHello with a non-empty
+legacy_session_id field as a connection error of type PROTOCOL_VIOLATION.<a href="#section-8.4-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="security-considerations">
+<section id="section-9">
+      <h2 id="name-security-considerations">
+<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
+      </h2>
+<p id="section-9-1">All of the security considerations that apply to TLS also apply to the use of
+TLS in QUIC. Reading all of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> and its appendices is the best way to
+gain an understanding of the security properties of QUIC.<a href="#section-9-1" class="pilcrow">¶</a></p>
+<p id="section-9-2">This section summarizes some of the more important security aspects specific to
+the TLS integration, though there are many security-relevant details in the
+remainder of the document.<a href="#section-9-2" class="pilcrow">¶</a></p>
+<div id="session-linkability">
+<section id="section-9.1">
+        <h3 id="name-session-linkability">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-session-linkability" class="section-name selfRef">Session Linkability</a>
+        </h3>
+<p id="section-9.1-1">Use of TLS session tickets allows servers and possibly other entities to
+correlate connections made by the same client; see <a href="#resumption" class="xref">Section 4.5</a> for details.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="replay-attacks-with-0-rtt">
+<section id="section-9.2">
+        <h3 id="name-replay-attacks-with-0-rtt">
+<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-replay-attacks-with-0-rtt" class="section-name selfRef">Replay Attacks with 0-RTT</a>
+        </h3>
+<p id="section-9.2-1">As described in Section 8 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>, use of TLS early data comes with an
+exposure to replay attack.  The use of 0-RTT in QUIC is similarly vulnerable to
+replay attack.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
+<p id="section-9.2-2">Endpoints MUST implement and use the replay protections described in <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>,
+however it is recognized that these protections are imperfect.  Therefore,
+additional consideration of the risk of replay is needed.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
+<p id="section-9.2-3">QUIC is not vulnerable to replay attack, except via the application protocol
+information it might carry.  The management of QUIC protocol state based on the
+frame types defined in <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> is not vulnerable to replay.
+Processing of QUIC frames is idempotent and cannot result in invalid connection
+states if frames are replayed, reordered or lost.  QUIC connections do not
+produce effects that last beyond the lifetime of the connection, except for
+those produced by the application protocol that QUIC serves.<a href="#section-9.2-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-9.2-4">
+          <dt id="section-9.2-4.1">Note:</dt>
+<dd id="section-9.2-4.2">
+  TLS session tickets and address validation tokens are used to carry QUIC
+configuration information between connections.  These MUST NOT be used to
+carry application semantics.  The potential for reuse of these tokens means
+that they require stronger protections against replay.<a href="#section-9.2-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-9.2-5">A server that accepts 0-RTT on a connection incurs a higher cost than accepting
+a connection without 0-RTT.  This includes higher processing and computation
+costs.  Servers need to consider the probability of replay and all associated
+costs when accepting 0-RTT.<a href="#section-9.2-5" class="pilcrow">¶</a></p>
+<p id="section-9.2-6">Ultimately, the responsibility for managing the risks of replay attacks with
+0-RTT lies with an application protocol.  An application protocol that uses QUIC
+MUST describe how the protocol uses 0-RTT and the measures that are employed to
+protect against replay attack.  An analysis of replay risk needs to consider
+all QUIC protocol features that carry application semantics.<a href="#section-9.2-6" class="pilcrow">¶</a></p>
+<p id="section-9.2-7">Disabling 0-RTT entirely is the most effective defense against replay attack.<a href="#section-9.2-7" class="pilcrow">¶</a></p>
+<p id="section-9.2-8">QUIC extensions MUST describe how replay attacks affect their operation, or
+prohibit their use in 0-RTT.  Application protocols MUST either prohibit the use
+of extensions that carry application semantics in 0-RTT or provide replay
+mitigation strategies.<a href="#section-9.2-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="reflection">
+<section id="section-9.3">
+        <h3 id="name-packet-reflection-attack-mi">
+<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-packet-reflection-attack-mi" class="section-name selfRef">Packet Reflection Attack Mitigation</a>
+        </h3>
+<p id="section-9.3-1">A small ClientHello that results in a large block of handshake messages from a
+server can be used in packet reflection attacks to amplify the traffic generated
+by an attacker.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
+<p id="section-9.3-2">QUIC includes three defenses against this attack. First, the packet containing a
+ClientHello MUST be padded to a minimum size. Second, if responding to an
+unverified source address, the server is forbidden to send more than three UDP
+datagrams in its first flight (see Section 8.1 of <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span>). Finally,
+because acknowledgements of Handshake packets are authenticated, a blind
+attacker cannot forge them.  Put together, these defenses limit the level of
+amplification.<a href="#section-9.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="header-protect-analysis">
+<section id="section-9.4">
+        <h3 id="name-header-protection-analysis">
+<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-header-protection-analysis" class="section-name selfRef">Header Protection Analysis</a>
+        </h3>
+<p id="section-9.4-1"><span>[<a href="#NAN" class="xref">NAN</a>]</span> analyzes authenticated encryption
+algorithms which provide nonce privacy, referred to as "Hide Nonce" (HN)
+transforms. The general header protection construction in this document is
+one of those algorithms (HN1). Header protection uses the output of the packet
+protection AEAD to derive <code>sample</code>, and then encrypts the header field using
+a pseudorandom function (PRF) as follows:<a href="#section-9.4-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-9.4-2">
+<pre>
+protected_field = field XOR PRF(hp_key, sample)
+</pre><a href="#section-9.4-2" class="pilcrow">¶</a>
+</div>
+<p id="section-9.4-3">The header protection variants in this document use a pseudorandom permutation
+(PRP) in place of a generic PRF. However, since all PRPs are also PRFs <span>[<a href="#IMC" class="xref">IMC</a>]</span>,
+these variants do not deviate from the HN1 construction.<a href="#section-9.4-3" class="pilcrow">¶</a></p>
+<p id="section-9.4-4">As <code>hp_key</code> is distinct from the packet protection key, it follows that header
+protection achieves AE2 security as defined in <span>[<a href="#NAN" class="xref">NAN</a>]</span> and therefore guarantees
+privacy of <code>field</code>, the protected packet header. Future header protection
+variants based on this construction MUST use a PRF to ensure equivalent
+security guarantees.<a href="#section-9.4-4" class="pilcrow">¶</a></p>
+<p id="section-9.4-5">Use of the same key and ciphertext sample more than once risks compromising
+header protection. Protecting two different headers with the same key and
+ciphertext sample reveals the exclusive OR of the protected fields.  Assuming
+that the AEAD acts as a PRF, if L bits are sampled, the odds of two ciphertext
+samples being identical approach 2^(-L/2), that is, the birthday bound. For the
+algorithms described in this document, that probability is one in 2^64.<a href="#section-9.4-5" class="pilcrow">¶</a></p>
+<p id="section-9.4-6">To prevent an attacker from modifying packet headers, the header is transitively
+authenticated using packet protection; the entire packet header is part of the
+authenticated additional data.  Protected fields that are falsified or modified
+can only be detected once the packet protection is removed.<a href="#section-9.4-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="hp-side-channel">
+<section id="section-9.5">
+        <h3 id="name-header-protection-timing-si">
+<a href="#section-9.5" class="section-number selfRef">9.5. </a><a href="#name-header-protection-timing-si" class="section-name selfRef">Header Protection Timing Side-Channels</a>
+        </h3>
+<p id="section-9.5-1">An attacker could guess values for packet numbers or Key Phase and have an
+endpoint confirm guesses through timing side channels.  Similarly, guesses for
+the packet number length can be trialed and exposed.  If the recipient of a
+packet discards packets with duplicate packet numbers without attempting to
+remove packet protection they could reveal through timing side-channels that the
+packet number matches a received packet.  For authentication to be free from
+side-channels, the entire process of header protection removal, packet number
+recovery, and packet protection removal MUST be applied together without timing
+and other side-channels.<a href="#section-9.5-1" class="pilcrow">¶</a></p>
+<p id="section-9.5-2">For the sending of packets, construction and protection of packet payloads and
+packet numbers MUST be free from side-channels that would reveal the packet
+number or its encoded size.<a href="#section-9.5-2" class="pilcrow">¶</a></p>
+<p id="section-9.5-3">During a key update, the time taken to generate new keys could reveal through
+timing side-channels that a key update has occurred.  Alternatively, where an
+attacker injects packets this side-channel could reveal the value of the Key
+Phase on injected packets.  After receiving a key update, an endpoint SHOULD
+generate and save the next set of receive packet protection keys, as described
+in <a href="#receive-key-generation" class="xref">Section 6.3</a>.  By generating new keys before a key update is
+received, receipt of packets will not create timing signals that leak the value
+of the Key Phase.<a href="#section-9.5-3" class="pilcrow">¶</a></p>
+<p id="section-9.5-4">This depends on not doing this key generation during packet processing and it
+can require that endpoints maintain three sets of packet protection keys for
+receiving: for the previous key phase, for the current key phase, and for the
+next key phase.  Endpoints can instead choose to defer generation of the next
+receive packet protection keys until they discard old keys so that only two sets
+of receive keys need to be retained at any point in time.<a href="#section-9.5-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="key-diversity">
+<section id="section-9.6">
+        <h3 id="name-key-diversity">
+<a href="#section-9.6" class="section-number selfRef">9.6. </a><a href="#name-key-diversity" class="section-name selfRef">Key Diversity</a>
+        </h3>
+<p id="section-9.6-1">In using TLS, the central key schedule of TLS is used.  As a result of the TLS
+handshake messages being integrated into the calculation of secrets, the
+inclusion of the QUIC transport parameters extension ensures that handshake and
+1-RTT keys are not the same as those that might be produced by a server running
+TLS over TCP.  To avoid the possibility of cross-protocol key synchronization,
+additional measures are provided to improve key separation.<a href="#section-9.6-1" class="pilcrow">¶</a></p>
+<p id="section-9.6-2">The QUIC packet protection keys and IVs are derived using a different label than
+the equivalent keys in TLS.<a href="#section-9.6-2" class="pilcrow">¶</a></p>
+<p id="section-9.6-3">To preserve this separation, a new version of QUIC SHOULD define new labels for
+key derivation for packet protection key and IV, plus the header protection
+keys.  This version of QUIC uses the string "quic".  Other versions can use a
+version-specific label in place of that string.<a href="#section-9.6-3" class="pilcrow">¶</a></p>
+<p id="section-9.6-4">The initial secrets use a key that is specific to the negotiated QUIC version.
+New QUIC versions SHOULD define a new salt value used in calculating initial
+secrets.<a href="#section-9.6-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="iana-considerations">
+<section id="section-10">
+      <h2 id="name-iana-considerations">
+<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
+      </h2>
+<p id="section-10-1">This document does not create any new IANA registries, but it registers the
+values in the following registries:<a href="#section-10-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-10-2.1">TLS ExtensionType Values Registry <span>[<a href="#TLS-REGISTRIES" class="xref">TLS-REGISTRIES</a>]</span> - IANA is to
+register the quic_transport_parameters extension found in <a href="#quic_parameters" class="xref">Section 8.2</a>.
+The Recommended column is to be marked Yes.  The TLS 1.3 Column is to include
+CH and EE.<a href="#section-10-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-10-2.2">QUIC Transport Error Codes Registry <span>[<a href="#QUIC-TRANSPORT" class="xref">QUIC-TRANSPORT</a>]</span> - IANA is to register
+the KEY_UPDATE_ERROR (0xE), as described in <a href="#key-update-error" class="xref">Section 6.7</a>.<a href="#section-10-2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<section id="section-11">
+      <h2 id="name-references">
+<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
+      </h2>
+<section id="section-11.1">
+        <h3 id="name-normative-references">
+<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
+        </h3>
+<dl class="references">
+<dt id="AEAD">[AEAD]</dt>
+<dd>
+<span class="refAuthor">McGrew, D.</span>, <span class="refTitle">"An Interface and Algorithms for Authenticated Encryption"</span>, <span class="seriesInfo">RFC 5116</span>, <span class="seriesInfo">DOI 10.17487/RFC5116</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5116">https://www.rfc-editor.org/info/rfc5116</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="AES">[AES]</dt>
+<dd>
+<span class="refTitle">"Advanced encryption standard (AES)"</span>, <span class="seriesInfo">DOI 10.6028/nist.fips.197</span>, <span class="seriesInfo">National Institute of Standards and Technology report</span>, <time datetime="2001-11">November 2001</time>, <span>&lt;<a href="https://doi.org/10.6028/nist.fips.197">https://doi.org/10.6028/nist.fips.197</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="ALPN">[ALPN]</dt>
+<dd>
+<span class="refAuthor">Friedl, S.</span><span class="refAuthor">, Popov, A.</span><span class="refAuthor">, Langley, A.</span><span class="refAuthor">, and E. Stephan</span>, <span class="refTitle">"Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension"</span>, <span class="seriesInfo">RFC 7301</span>, <span class="seriesInfo">DOI 10.17487/RFC7301</span>, <time datetime="2014-07">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7301">https://www.rfc-editor.org/info/rfc7301</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="CHACHA">[CHACHA]</dt>
+<dd>
+<span class="refAuthor">Nir, Y.</span><span class="refAuthor"> and A. Langley</span>, <span class="refTitle">"ChaCha20 and Poly1305 for IETF Protocols"</span>, <span class="seriesInfo">RFC 8439</span>, <span class="seriesInfo">DOI 10.17487/RFC8439</span>, <time datetime="2018-06">June 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8439">https://www.rfc-editor.org/info/rfc8439</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-RECOVERY">[QUIC-RECOVERY]</dt>
+<dd>
+<span class="refAuthor">Iyengar, J., Ed.</span><span class="refAuthor"> and I. Swett, Ed.</span>, <span class="refTitle">"QUIC Loss Detection and Congestion Control"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-recovery-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-recovery-latest">https://tools.ietf.org/html/draft-ietf-quic-recovery-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-TRANSPORT">[QUIC-TRANSPORT]</dt>
+<dd>
+<span class="refAuthor">Iyengar, J., Ed.</span><span class="refAuthor"> and M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-transport-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-transport-latest">https://tools.ietf.org/html/draft-ietf-quic-transport-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2119">[RFC2119]</dt>
+<dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8174">[RFC8174]</dt>
+<dd>
+<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="SHA">[SHA]</dt>
+<dd>
+<span class="refAuthor">Dang, Q.</span>, <span class="refTitle">"Secure Hash Standard"</span>, <span class="seriesInfo">DOI 10.6028/nist.fips.180-4</span>, <span class="seriesInfo">National Institute of Standards and Technology report</span>, <time datetime="2015-07">July 2015</time>, <span>&lt;<a href="https://doi.org/10.6028/nist.fips.180-4">https://doi.org/10.6028/nist.fips.180-4</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="TLS-REGISTRIES">[TLS-REGISTRIES]</dt>
+<dd>
+<span class="refAuthor">Salowey, J.</span><span class="refAuthor"> and S. Turner</span>, <span class="refTitle">"IANA Registry Updates for TLS and DTLS"</span>, <span class="seriesInfo">RFC 8447</span>, <span class="seriesInfo">DOI 10.17487/RFC8447</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8447">https://www.rfc-editor.org/info/rfc8447</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="TLS13">[TLS13]</dt>
+<dd>
+<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+<section id="section-11.2">
+        <h3 id="name-informative-references">
+<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
+        </h3>
+<dl class="references">
+<dt id="AEBounds">[AEBounds]</dt>
+<dd>
+<span class="refAuthor">Luykx, A.</span><span class="refAuthor"> and K. Paterson</span>, <span class="refTitle">"Limits on Authenticated Encryption Use in TLS"</span>, <time datetime="2016-03-08">8 March 2016</time>, <span>&lt;<a href="http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf">http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="HTTP2-TLS13">[HTTP2-TLS13]</dt>
+<dd>
+<span class="refAuthor">Benjamin, D.</span>, <span class="refTitle">"Using TLS 1.3 with HTTP/2"</span>, <span class="seriesInfo">RFC 8740</span>, <span class="seriesInfo">DOI 10.17487/RFC8740</span>, <time datetime="2020-02">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8740">https://www.rfc-editor.org/info/rfc8740</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="IMC">[IMC]</dt>
+<dd>
+<span class="refAuthor">Katz, J.</span><span class="refAuthor"> and Y. Lindell</span>, <span class="refTitle">"Introduction to Modern Cryptography, Second Edition"</span>, <span class="seriesInfo">ISBN 978-1466570269</span>, <time datetime="2014-11-06">6 November 2014</time>. </dd>
+<dd class="break"></dd>
+<dt id="NAN">[NAN]</dt>
+<dd>
+<span class="refAuthor">Bellare, M.</span><span class="refAuthor">, Ng, R.</span><span class="refAuthor">, and B. Tackmann</span>, <span class="refTitle">"Nonces Are Noticed: AEAD Revisited"</span>, <span class="seriesInfo">DOI 10.1007/978-3-030-26948-7_9</span>, <span class="seriesInfo">Advances in Cryptology - CRYPTO 2019 pp. 235-265</span>, <time datetime="2019">2019</time>, <span>&lt;<a href="https://doi.org/10.1007/978-3-030-26948-7_9">https://doi.org/10.1007/978-3-030-26948-7_9</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-HTTP">[QUIC-HTTP]</dt>
+<dd>
+<span class="refAuthor">Bishop, M., Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol Version 3 (HTTP/3)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-http-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-http-latest">https://tools.ietf.org/html/draft-ietf-quic-http-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2818">[RFC2818]</dt>
+<dd>
+<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"HTTP Over TLS"</span>, <span class="seriesInfo">RFC 2818</span>, <span class="seriesInfo">DOI 10.17487/RFC2818</span>, <time datetime="2000-05">May 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2818">https://www.rfc-editor.org/info/rfc2818</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5280">[RFC5280]</dt>
+<dd>
+<span class="refAuthor">Cooper, D.</span><span class="refAuthor">, Santesson, S.</span><span class="refAuthor">, Farrell, S.</span><span class="refAuthor">, Boeyen, S.</span><span class="refAuthor">, Housley, R.</span><span class="refAuthor">, and W. Polk</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 5280</span>, <span class="seriesInfo">DOI 10.17487/RFC5280</span>, <time datetime="2008-05">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</section>
+<div id="test-vectors">
+<section id="section-appendix.a">
+      <h2 id="name-sample-packet-protection">
+<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-sample-packet-protection" class="section-name selfRef">Sample Packet Protection</a>
+      </h2>
+<p id="section-appendix.a-1">This section shows examples of packet protection so that implementations can be
+verified incrementally. Samples of Initial packets from both client and server,
+plus a Retry packet are defined. These packets use an 8-byte client-chosen
+Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are
+included. All values are shown in hexadecimal.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
+<div id="keys">
+<section id="section-a.1">
+        <h2 id="name-keys">
+<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-keys" class="section-name selfRef">Keys</a>
+        </h2>
+<p id="section-a.1-1">The labels generated by the HKDF-Expand-Label function are:<a href="#section-a.1-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-a.1-2">
+          <dt id="section-a.1-2.1">client in:</dt>
+<dd id="section-a.1-2.2">
+  00200f746c73313320636c69656e7420696e00<a href="#section-a.1-2.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.1-2.3">server in:</dt>
+<dd id="section-a.1-2.4">
+  00200f746c7331332073657276657220696e00<a href="#section-a.1-2.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.1-2.5">quic key:</dt>
+<dd id="section-a.1-2.6">
+  00100e746c7331332071756963206b657900<a href="#section-a.1-2.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.1-2.7">quic iv:</dt>
+<dd id="section-a.1-2.8">
+  000c0d746c733133207175696320697600<a href="#section-a.1-2.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-a.1-2.9">quic hp:</dt>
+<dd id="section-a.1-2.10">
+  00100d746c733133207175696320687000<a href="#section-a.1-2.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-a.1-3">The initial secret is common:<a href="#section-a.1-3" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.1-4">
+<pre>
+initial_secret = HKDF-Extract(initial_salt, cid)
+    = 524e374c6da8cf8b496f4bcb69678350
+      7aafee6198b202b4bc823ebf7514a423
+</pre><a href="#section-a.1-4" class="pilcrow">¶</a>
+</div>
+<p id="section-a.1-5">The secrets for protecting client packets are:<a href="#section-a.1-5" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.1-6">
+<pre>
+client_initial_secret
+    = HKDF-Expand-Label(initial_secret, "client in", _, 32)
+    = fda3953aecc040e48b34e27ef87de3a6
+      098ecf0e38b7e032c5c57bcbd5975b84
+
+key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16)
+    = af7fd7efebd21878ff66811248983694
+
+iv  = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12)
+    = 8681359410a70bb9c92f0420
+
+hp  = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16)
+    = a980b8b4fb7d9fbc13e814c23164253d
+</pre><a href="#section-a.1-6" class="pilcrow">¶</a>
+</div>
+<p id="section-a.1-7">The secrets for protecting server packets are:<a href="#section-a.1-7" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.1-8">
+<pre>
+server_initial_secret
+    = HKDF-Expand-Label(initial_secret, "server in", _, 32)
+    = 554366b81912ff90be41f17e80222130
+      90ab17d8149179bcadf222f29ff2ddd5
+
+key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16)
+    = 5d51da9ee897a21b2659ccc7e5bfa577
+
+iv  = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
+    = 5e5ae651fd1e8495af13508b
+
+hp  = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
+    = a8ed82e6664f865aedf6106943f95fb8
+</pre><a href="#section-a.1-8" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="sample-client-initial">
+<section id="section-a.2">
+        <h2 id="name-client-initial">
+<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-client-initial" class="section-name selfRef">Client Initial</a>
+        </h2>
+<p id="section-a.2-1">The client sends an Initial packet.  The unprotected payload of this packet
+contains the following CRYPTO frame, plus enough PADDING frames to make a 1162
+byte payload:<a href="#section-a.2-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.2-2">
+<pre>
+060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1
+4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006
+736572766572ff01000100000a001400 12001d00170018001901000101010201
+03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f
+2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403
+05030603020308040805080604010501 060102010402050206020202002d0002
+0101001c00024001
+</pre><a href="#section-a.2-2" class="pilcrow">¶</a>
+</div>
+<p id="section-a.2-3">The unprotected header includes the connection ID and a 4 byte packet number
+encoding for a packet number of 2:<a href="#section-a.2-3" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.2-4">
+<pre>
+c3ff00001c088394c8f03e5157080000449e00000002
+</pre><a href="#section-a.2-4" class="pilcrow">¶</a>
+</div>
+<p id="section-a.2-5">Protecting the payload produces output that is sampled for header protection.
+Because the header uses a 4 byte packet number encoding, the first 16 bytes of
+the protected payload is sampled, then applied to the header:<a href="#section-a.2-5" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.2-6">
+<pre>
+sample = 535064a4268a0d9d7b1c9d250ae35516
+
+mask = AES-ECB(hp, sample)[0..4]
+     = 833b343aaa
+
+header[0] ^= mask[0] &amp; 0x0f
+     = c0
+header[18..21] ^= mask[1..4]
+     = 3b343aa8
+header = c0ff00001c088394c8f03e5157080000449e3b343aa8
+</pre><a href="#section-a.2-6" class="pilcrow">¶</a>
+</div>
+<p id="section-a.2-7">The resulting protected packet is:<a href="#section-a.2-7" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.2-8">
+<pre>
+c0ff00001c088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c
+9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752
+4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec
+b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f
+e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d
+12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6
+11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50
+1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008
+0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f
+cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724
+87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d
+7f85181a366663387ddc20551807e007 673bd7e26bf9b29b5ab10a1ca87cbb7a
+d97e99eb66959c2a9bc3cbde4707ff77 20b110fa95354674e395812e47a0ae53
+b464dcb2d1f345df360dc227270c7506 76f6724eb479f0d2fbb6124429990457
+ac6c9167f40aab739998f38b9eccb24f d47c8410131bf65a52af841275d5b3d1
+880b197df2b5dea3e6de56ebce3ffb6e 9277a82082f8d9677a6767089b671ebd
+244c214f0bde95c2beb02cd1172d58bd f39dce56ff68eb35ab39b49b4eac7c81
+5ea60451d6e6ab82119118df02a58684 4a9ffe162ba006d0669ef57668cab38b
+62f71a2523a084852cd1d079b3658dc2 f3e87949b550bab3e177cfc49ed190df
+f0630e43077c30de8f6ae081537f1e83 da537da980afa668e7b7fb25301cf741
+524be3c49884b42821f17552fbd1931a 813017b6b6590a41ea18b6ba49cd48a4
+40bd9a3346a7623fb4ba34a3ee571e3c 731f35a7a3cf25b551a680fa68763507
+b7fde3aaf023c50b9d22da6876ba337e b5e9dd9ec3daf970242b6c5aab3aa4b2
+96ad8b9f6832f686ef70fa938b31b4e5 ddd7364442d3ea72e73d668fb0937796
+f462923a81a47e1cee7426ff6d922126 9b5a62ec03d6ec94d12606cb485560ba
+b574816009e96504249385bb61a819be 04f62c2066214d8360a2022beb316240
+b6c7d78bbe56c13082e0ca272661210a bf020bf3b5783f1426436cf9ff418405
+93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9
+44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14
+a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5
+b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6
+6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e
+c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e
+eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f
+cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da
+acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc
+13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d
+ea5388b911e76d2856d68cf6cf394185
+</pre><a href="#section-a.2-8" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="server-initial">
+<section id="section-a.3">
+        <h2 id="name-server-initial">
+<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-server-initial" class="section-name selfRef">Server Initial</a>
+        </h2>
+<p id="section-a.3-1">The server sends the following payload in response, including an ACK frame, a
+CRYPTO frame, and no PADDING frames:<a href="#section-a.3-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.3-2">
+<pre>
+0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988
+cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d
+89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002
+0304
+</pre><a href="#section-a.3-2" class="pilcrow">¶</a>
+</div>
+<p id="section-a.3-3">The header from the server includes a new connection ID and a 2-byte packet
+number encoding for a packet number of 1:<a href="#section-a.3-3" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.3-4">
+<pre>
+c1ff00001c0008f067a5502a4262b50040740001
+</pre><a href="#section-a.3-4" class="pilcrow">¶</a>
+</div>
+<p id="section-a.3-5">As a result, after protection, the header protection sample is taken starting
+from the third protected octet:<a href="#section-a.3-5" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.3-6">
+<pre>
+sample = 7002596f99ae67abf65a5852f54f58c3
+mask   = 38168a0c25
+header = c9ff00001c0008f067a5502a4262b5004074168b
+</pre><a href="#section-a.3-6" class="pilcrow">¶</a>
+</div>
+<p id="section-a.3-7">The final protected packet is then:<a href="#section-a.3-7" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.3-8">
+<pre>
+c9ff00001c0008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a
+5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493
+537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3
+cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92bda5b23c81034ab74f54c
+b1bd72951256
+</pre><a href="#section-a.3-8" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="retry">
+<section id="section-a.4">
+        <h2 id="name-retry">
+<a href="#section-a.4" class="section-number selfRef">A.4. </a><a href="#name-retry" class="section-name selfRef">Retry</a>
+        </h2>
+<p id="section-a.4-1">This shows a Retry packet that might be sent in response to the Initial packet
+in <a href="#sample-client-initial" class="xref">Appendix A.2</a>. The integrity check includes the client-chosen
+connection ID value of 0x8394c8f03e515708, but that value is not
+included in the final Retry packet:<a href="#section-a.4-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-a.4-2">
+<pre>
+ffff00001c0008f067a5502a4262b574 6f6b656ef71a5f12afe3ecf8001a920e
+6fdf1d63
+</pre><a href="#section-a.4-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="change-log">
+<section id="section-appendix.b">
+      <h2 id="name-change-log">
+<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-change-log" class="section-name selfRef">Change Log</a>
+      </h2>
+<ul class="ulEmpty normal">
+<li class="ulEmpty normal" id="section-appendix.b-1.1">
+          <strong>RFC Editor's Note:</strong> Please remove this section prior to publication of a
+final version of this document.<a href="#section-appendix.b-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-appendix.b-2">Issue and pull request numbers are listed with a leading octothorp.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
+<div id="since-draft-ietf-quic-tls-27">
+<section id="section-b.1">
+        <h2 id="name-since-draft-ietf-quic-tls-2">
+<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-since-draft-ietf-quic-tls-2" class="section-name selfRef">Since draft-ietf-quic-tls-27</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.1-1.1">Allowed CONNECTION_CLOSE in any packet number space, with restrictions on
+use of the application-specific variant (#3430, #3435, #3440)<a href="#section-b.1-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.1-1.2">Prohibit the use of the compatibility mode from TLS 1.3 (#3594, #3595)<a href="#section-b.1-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-26">
+<section id="section-b.2">
+        <h2 id="name-since-draft-ietf-quic-tls-26">
+<a href="#section-b.2" class="section-number selfRef">B.2. </a><a href="#name-since-draft-ietf-quic-tls-26" class="section-name selfRef">Since draft-ietf-quic-tls-26</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.2-1.1">No changes<a href="#section-b.2-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-25">
+<section id="section-b.3">
+        <h2 id="name-since-draft-ietf-quic-tls-25">
+<a href="#section-b.3" class="section-number selfRef">B.3. </a><a href="#name-since-draft-ietf-quic-tls-25" class="section-name selfRef">Since draft-ietf-quic-tls-25</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.3-1.1">No changes<a href="#section-b.3-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-24">
+<section id="section-b.4">
+        <h2 id="name-since-draft-ietf-quic-tls-24">
+<a href="#section-b.4" class="section-number selfRef">B.4. </a><a href="#name-since-draft-ietf-quic-tls-24" class="section-name selfRef">Since draft-ietf-quic-tls-24</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.4-1.1">
+            <p id="section-b.4-1.1.1">Rewrite key updates (#3050)<a href="#section-b.4-1.1.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.4-1.1.2.1">Allow but don't recommend deferring key updates (#2792, #3263)<a href="#section-b.4-1.1.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.4-1.1.2.2">More completely define received behavior (#2791)<a href="#section-b.4-1.1.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.4-1.1.2.3">Define the label used with HKDF-Expand-Label (#3054)<a href="#section-b.4-1.1.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-23">
+<section id="section-b.5">
+        <h2 id="name-since-draft-ietf-quic-tls-23">
+<a href="#section-b.5" class="section-number selfRef">B.5. </a><a href="#name-since-draft-ietf-quic-tls-23" class="section-name selfRef">Since draft-ietf-quic-tls-23</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.5-1.1">
+            <p id="section-b.5-1.1.1">Key update text update (#3050):<a href="#section-b.5-1.1.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.5-1.1.2.1">Recommend constant-time key replacement (#2792)<a href="#section-b.5-1.1.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.5-1.1.2.2">Provide explicit labels for key update key derivation (#3054)<a href="#section-b.5-1.1.2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.5-1.2">Allow first Initial from a client to span multiple packets (#2928, #3045)<a href="#section-b.5-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.5-1.3">PING can be sent at any encryption level (#3034, #3035)<a href="#section-b.5-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-22">
+<section id="section-b.6">
+        <h2 id="name-since-draft-ietf-quic-tls-22">
+<a href="#section-b.6" class="section-number selfRef">B.6. </a><a href="#name-since-draft-ietf-quic-tls-22" class="section-name selfRef">Since draft-ietf-quic-tls-22</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.6-1.1">Update the salt used for Initial secrets (#2887, #2980)<a href="#section-b.6-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-21">
+<section id="section-b.7">
+        <h2 id="name-since-draft-ietf-quic-tls-21">
+<a href="#section-b.7" class="section-number selfRef">B.7. </a><a href="#name-since-draft-ietf-quic-tls-21" class="section-name selfRef">Since draft-ietf-quic-tls-21</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.7-1.1">No changes<a href="#section-b.7-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-20">
+<section id="section-b.8">
+        <h2 id="name-since-draft-ietf-quic-tls-20">
+<a href="#section-b.8" class="section-number selfRef">B.8. </a><a href="#name-since-draft-ietf-quic-tls-20" class="section-name selfRef">Since draft-ietf-quic-tls-20</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.8-1.1">Mandate the use of the QUIC transport parameters extension (#2528, #2560)<a href="#section-b.8-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.8-1.2">Define handshake completion and confirmation; define clearer rules when it
+encryption keys should be discarded (#2214, #2267, #2673)<a href="#section-b.8-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-18">
+<section id="section-b.9">
+        <h2 id="name-since-draft-ietf-quic-tls-1">
+<a href="#section-b.9" class="section-number selfRef">B.9. </a><a href="#name-since-draft-ietf-quic-tls-1" class="section-name selfRef">Since draft-ietf-quic-tls-18</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.9-1.1">Increased the set of permissible frames in 0-RTT (#2344, #2355)<a href="#section-b.9-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.9-1.2">Transport parameter extension is mandatory (#2528, #2560)<a href="#section-b.9-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-17">
+<section id="section-b.10">
+        <h2 id="name-since-draft-ietf-quic-tls-17">
+<a href="#section-b.10" class="section-number selfRef">B.10. </a><a href="#name-since-draft-ietf-quic-tls-17" class="section-name selfRef">Since draft-ietf-quic-tls-17</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.10-1.1">Endpoints discard initial keys as soon as handshake keys are available (#1951,
+#2045)<a href="#section-b.10-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.10-1.2">Use of ALPN or equivalent is mandatory (#2263, #2284)<a href="#section-b.10-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-14">
+<section id="section-b.11">
+        <h2 id="name-since-draft-ietf-quic-tls-14">
+<a href="#section-b.11" class="section-number selfRef">B.11. </a><a href="#name-since-draft-ietf-quic-tls-14" class="section-name selfRef">Since draft-ietf-quic-tls-14</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.11-1.1">Update the salt used for Initial secrets (#1970)<a href="#section-b.11-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.11-1.2">Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)<a href="#section-b.11-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.11-1.3">
+            <p id="section-b.11-1.3.1">Change header protection<a href="#section-b.11-1.3.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.11-1.3.2.1">Sample from a fixed offset (#1575, #2030)<a href="#section-b.11-1.3.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.11-1.3.2.2">Cover part of the first byte, including the key phase (#1322, #2006)<a href="#section-b.11-1.3.2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.11-1.4">
+            <p id="section-b.11-1.4.1">TLS provides an AEAD and KDF function (#2046)<a href="#section-b.11-1.4.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.11-1.4.2.1">Clarify that the TLS KDF is used with TLS (#1997)<a href="#section-b.11-1.4.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.11-1.4.2.2">Change the labels for calculation of QUIC keys (#1845, #1971, #1991)<a href="#section-b.11-1.4.2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.11-1.5">Initial keys are discarded once Handshake keys are available (#1951, #2045)<a href="#section-b.11-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-13">
+<section id="section-b.12">
+        <h2 id="name-since-draft-ietf-quic-tls-13">
+<a href="#section-b.12" class="section-number selfRef">B.12. </a><a href="#name-since-draft-ietf-quic-tls-13" class="section-name selfRef">Since draft-ietf-quic-tls-13</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.12-1.1">Updated to TLS 1.3 final (#1660)<a href="#section-b.12-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-12">
+<section id="section-b.13">
+        <h2 id="name-since-draft-ietf-quic-tls-12">
+<a href="#section-b.13" class="section-number selfRef">B.13. </a><a href="#name-since-draft-ietf-quic-tls-12" class="section-name selfRef">Since draft-ietf-quic-tls-12</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.13-1.1">
+            <p id="section-b.13-1.1.1">Changes to integration of the TLS handshake (#829, #1018, #1094, #1165, #1190,
+#1233, #1242, #1252, #1450)<a href="#section-b.13-1.1.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-b.13-1.1.2.1">The cryptographic handshake uses CRYPTO frames, not stream 0<a href="#section-b.13-1.1.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.13-1.1.2.2">QUIC packet protection is used in place of TLS record protection<a href="#section-b.13-1.1.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.13-1.1.2.3">Separate QUIC packet number spaces are used for the handshake<a href="#section-b.13-1.1.2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.13-1.1.2.4">Changed Retry to be independent of the cryptographic handshake<a href="#section-b.13-1.1.2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.13-1.1.2.5">Limit the use of HelloRetryRequest to address TLS needs (like key shares)<a href="#section-b.13-1.1.2.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-b.13-1.2">Changed codepoint of TLS extension (#1395, #1402)<a href="#section-b.13-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-11">
+<section id="section-b.14">
+        <h2 id="name-since-draft-ietf-quic-tls-11">
+<a href="#section-b.14" class="section-number selfRef">B.14. </a><a href="#name-since-draft-ietf-quic-tls-11" class="section-name selfRef">Since draft-ietf-quic-tls-11</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.14-1.1">Encrypted packet numbers.<a href="#section-b.14-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-10">
+<section id="section-b.15">
+        <h2 id="name-since-draft-ietf-quic-tls-10">
+<a href="#section-b.15" class="section-number selfRef">B.15. </a><a href="#name-since-draft-ietf-quic-tls-10" class="section-name selfRef">Since draft-ietf-quic-tls-10</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.15-1.1">No significant changes.<a href="#section-b.15-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-09">
+<section id="section-b.16">
+        <h2 id="name-since-draft-ietf-quic-tls-0">
+<a href="#section-b.16" class="section-number selfRef">B.16. </a><a href="#name-since-draft-ietf-quic-tls-0" class="section-name selfRef">Since draft-ietf-quic-tls-09</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.16-1.1">Cleaned up key schedule and updated the salt used for handshake packet
+protection (#1077)<a href="#section-b.16-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-08">
+<section id="section-b.17">
+        <h2 id="name-since-draft-ietf-quic-tls-08">
+<a href="#section-b.17" class="section-number selfRef">B.17. </a><a href="#name-since-draft-ietf-quic-tls-08" class="section-name selfRef">Since draft-ietf-quic-tls-08</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.17-1.1">Specify value for max_early_data_size to enable 0-RTT (#942)<a href="#section-b.17-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.17-1.2">Update key derivation function (#1003, #1004)<a href="#section-b.17-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-07">
+<section id="section-b.18">
+        <h2 id="name-since-draft-ietf-quic-tls-07">
+<a href="#section-b.18" class="section-number selfRef">B.18. </a><a href="#name-since-draft-ietf-quic-tls-07" class="section-name selfRef">Since draft-ietf-quic-tls-07</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.18-1.1">Handshake errors can be reported with CONNECTION_CLOSE (#608, #891)<a href="#section-b.18-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-05">
+<section id="section-b.19">
+        <h2 id="name-since-draft-ietf-quic-tls-05">
+<a href="#section-b.19" class="section-number selfRef">B.19. </a><a href="#name-since-draft-ietf-quic-tls-05" class="section-name selfRef">Since draft-ietf-quic-tls-05</a>
+        </h2>
+<p id="section-b.19-1">No significant changes.<a href="#section-b.19-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-04">
+<section id="section-b.20">
+        <h2 id="name-since-draft-ietf-quic-tls-04">
+<a href="#section-b.20" class="section-number selfRef">B.20. </a><a href="#name-since-draft-ietf-quic-tls-04" class="section-name selfRef">Since draft-ietf-quic-tls-04</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.20-1.1">Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)<a href="#section-b.20-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-03">
+<section id="section-b.21">
+        <h2 id="name-since-draft-ietf-quic-tls-03">
+<a href="#section-b.21" class="section-number selfRef">B.21. </a><a href="#name-since-draft-ietf-quic-tls-03" class="section-name selfRef">Since draft-ietf-quic-tls-03</a>
+        </h2>
+<p id="section-b.21-1">No significant changes.<a href="#section-b.21-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-02">
+<section id="section-b.22">
+        <h2 id="name-since-draft-ietf-quic-tls-02">
+<a href="#section-b.22" class="section-number selfRef">B.22. </a><a href="#name-since-draft-ietf-quic-tls-02" class="section-name selfRef">Since draft-ietf-quic-tls-02</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.22-1.1">Updates to match changes in transport draft<a href="#section-b.22-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-01">
+<section id="section-b.23">
+        <h2 id="name-since-draft-ietf-quic-tls-01">
+<a href="#section-b.23" class="section-number selfRef">B.23. </a><a href="#name-since-draft-ietf-quic-tls-01" class="section-name selfRef">Since draft-ietf-quic-tls-01</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.23-1.1">Use TLS alerts to signal TLS errors (#272, #374)<a href="#section-b.23-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.2">Require ClientHello to fit in a single packet (#338)<a href="#section-b.23-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.3">The second client handshake flight is now sent in the clear (#262, #337)<a href="#section-b.23-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.4">The QUIC header is included as AEAD Associated Data (#226, #243, #302)<a href="#section-b.23-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.5">Add interface necessary for client address validation (#275)<a href="#section-b.23-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.6">Define peer authentication (#140)<a href="#section-b.23-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.7">Require at least TLS 1.3 (#138)<a href="#section-b.23-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.8">Define transport parameters as a TLS extension (#122)<a href="#section-b.23-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.9">Define handling for protected packets before the handshake completes (#39)<a href="#section-b.23-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.23-1.10">Decouple QUIC version and ALPN (#12)<a href="#section-b.23-1.10" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-tls-00">
+<section id="section-b.24">
+        <h2 id="name-since-draft-ietf-quic-tls-00">
+<a href="#section-b.24" class="section-number selfRef">B.24. </a><a href="#name-since-draft-ietf-quic-tls-00" class="section-name selfRef">Since draft-ietf-quic-tls-00</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.24-1.1">Changed bit used to signal key phase<a href="#section-b.24-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.2">Updated key phase markings during the handshake<a href="#section-b.24-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.3">Added TLS interface requirements section<a href="#section-b.24-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.4">Moved to use of TLS exporters for key derivation<a href="#section-b.24-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.24-1.5">Moved TLS error code definitions into this document<a href="#section-b.24-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-thomson-quic-tls-01">
+<section id="section-b.25">
+        <h2 id="name-since-draft-thomson-quic-tl">
+<a href="#section-b.25" class="section-number selfRef">B.25. </a><a href="#name-since-draft-thomson-quic-tl" class="section-name selfRef">Since draft-thomson-quic-tls-01</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-b.25-1.1">Adopted as base for draft-ietf-quic-tls<a href="#section-b.25-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.25-1.2">Updated authors/editors list<a href="#section-b.25-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-b.25-1.3">Added status note<a href="#section-b.25-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+</section>
+</div>
+<div id="contributors">
+<section id="section-appendix.c">
+      <h2 id="name-contributors">
+<a href="#name-contributors" class="section-name selfRef">Contributors</a>
+      </h2>
+<p id="section-appendix.c-1">The IETF QUIC Working Group received an enormous amount of support from many
+people. The following people provided substantive contributions to this
+document:<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-appendix.c-2.1">Adam Langley<a href="#section-appendix.c-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.2">Alessandro Ghedini<a href="#section-appendix.c-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.3">Christian Huitema<a href="#section-appendix.c-2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.4">Christopher Wood<a href="#section-appendix.c-2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.5">David Schinazi<a href="#section-appendix.c-2.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.6">Dragana Damjanovic<a href="#section-appendix.c-2.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.7">Eric Rescorla<a href="#section-appendix.c-2.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.8">Ian Swett<a href="#section-appendix.c-2.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.9">Jana Iyengar<a href="#section-appendix.c-2.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.10">
+          <p id="section-appendix.c-2.10.1">        <span class="contact-name"><span class="non-ascii">奥 一穂</span> (<span class="ascii">Kazuho Oku</span>)</span><a href="#section-appendix.c-2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="normal" id="section-appendix.c-2.11">Marten Seemann<a href="#section-appendix.c-2.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.12">Martin Duke<a href="#section-appendix.c-2.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.13">Mike Bishop<a href="#section-appendix.c-2.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.14">
+          <p id="section-appendix.c-2.14.1">        <span class="contact-name">Mikkel Fahnøe Jørgensen</span><a href="#section-appendix.c-2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="normal" id="section-appendix.c-2.15">Nick Banks<a href="#section-appendix.c-2.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.16">Nick Harper<a href="#section-appendix.c-2.16" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.17">Roberto Peon<a href="#section-appendix.c-2.17" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.18">Rui Paulo<a href="#section-appendix.c-2.18" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.19">Ryan Hamilton<a href="#section-appendix.c-2.19" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.c-2.20">Victor Vasiliev<a href="#section-appendix.c-2.20" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="authors-addresses">
+<section id="section-appendix.d">
+      <h2 id="name-authors-addresses">
+<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+      </h2>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Martin Thomson (<span class="role">editor</span>)</span></div>
+<div dir="auto" class="left"><span class="org">Mozilla</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:mt@lowentropy.net" class="email">mt@lowentropy.net</a>
+</div>
+</address>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Sean Turner (<span class="role">editor</span>)</span></div>
+<div dir="auto" class="left"><span class="org">sn3rd</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:sean@sn3rd.com" class="email">sean@sn3rd.com</a>
+</div>
+</address>
+</section>
+</div>
+<script>const toc = document.getElementById("toc");
+toc.querySelector("h2").addEventListener("click", e => {
+  toc.classList.toggle("active");
+});
+toc.querySelector("nav").addEventListener("click", e => {
+  toc.classList.remove("active");
+});
+</script>
+</body>
+</html>
diff --git a/jri/mustnot/draft-ietf-quic-tls.txt b/jri/mustnot/draft-ietf-quic-tls.txt
new file mode 100644
index 0000000000..9ebed1a8b1
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-tls.txt
@@ -0,0 +1,3080 @@
+
+
+
+
+QUIC                                                     M. Thomson, Ed.
+Internet-Draft                                                   Mozilla
+Intended status: Standards Track                          S. Turner, Ed.
+Expires: 5 December 2020                                           sn3rd
+                                                             3 June 2020
+
+
+                        Using TLS to Secure QUIC
+                       draft-ietf-quic-tls-latest
+
+Abstract
+
+   This document describes how Transport Layer Security (TLS) is used to
+   secure QUIC.
+
+Note to Readers
+
+   Discussion of this draft takes place on the QUIC working group
+   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
+   archived at https://mailarchive.ietf.org/arch/
+   search/?email_list=quic.
+
+   Working Group information can be found at https://github.com/quicwg;
+   source code and issues list for this draft can be found at
+   https://github.com/quicwg/base-drafts/labels/-tls.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at https://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on 5 December 2020.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 1]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (https://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.  Code Components
+   extracted from this document must include Simplified BSD License text
+   as described in Section 4.e of the Trust Legal Provisions and are
+   provided without warranty as described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   4
+     2.1.  TLS Overview  . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   7
+   4.  Carrying TLS Messages . . . . . . . . . . . . . . . . . . . .   8
+     4.1.  Interface to TLS  . . . . . . . . . . . . . . . . . . . .  10
+       4.1.1.  Handshake Complete  . . . . . . . . . . . . . . . . .  10
+       4.1.2.  Handshake Confirmed . . . . . . . . . . . . . . . . .  11
+       4.1.3.  Sending and Receiving Handshake Messages  . . . . . .  11
+       4.1.4.  Encryption Level Changes  . . . . . . . . . . . . . .  13
+       4.1.5.  TLS Interface Summary . . . . . . . . . . . . . . . .  14
+     4.2.  TLS Version . . . . . . . . . . . . . . . . . . . . . . .  15
+     4.3.  ClientHello Size  . . . . . . . . . . . . . . . . . . . .  15
+     4.4.  Peer Authentication . . . . . . . . . . . . . . . . . . .  16
+     4.5.  Session Resumption  . . . . . . . . . . . . . . . . . . .  17
+     4.6.  Enabling 0-RTT  . . . . . . . . . . . . . . . . . . . . .  17
+     4.7.  Accepting and Rejecting 0-RTT . . . . . . . . . . . . . .  18
+     4.8.  Validating 0-RTT Configuration  . . . . . . . . . . . . .  18
+     4.9.  HelloRetryRequest . . . . . . . . . . . . . . . . . . . .  19
+     4.10. TLS Errors  . . . . . . . . . . . . . . . . . . . . . . .  19
+     4.11. Discarding Unused Keys  . . . . . . . . . . . . . . . . .  19
+       4.11.1.  Discarding Initial Keys  . . . . . . . . . . . . . .  20
+       4.11.2.  Discarding Handshake Keys  . . . . . . . . . . . . .  20
+       4.11.3.  Discarding 0-RTT Keys  . . . . . . . . . . . . . . .  20
+   5.  Packet Protection . . . . . . . . . . . . . . . . . . . . . .  21
+     5.1.  Packet Protection Keys  . . . . . . . . . . . . . . . . .  21
+     5.2.  Initial Secrets . . . . . . . . . . . . . . . . . . . . .  21
+     5.3.  AEAD Usage  . . . . . . . . . . . . . . . . . . . . . . .  23
+     5.4.  Header Protection . . . . . . . . . . . . . . . . . . . .  24
+       5.4.1.  Header Protection Application . . . . . . . . . . . .  24
+       5.4.2.  Header Protection Sample  . . . . . . . . . . . . . .  26
+       5.4.3.  AES-Based Header Protection . . . . . . . . . . . . .  28
+       5.4.4.  ChaCha20-Based Header Protection  . . . . . . . . . .  28
+     5.5.  Receiving Protected Packets . . . . . . . . . . . . . . .  28
+     5.6.  Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . .  29
+     5.7.  Receiving Out-of-Order Protected Frames . . . . . . . . .  29
+     5.8.  Retry Packet Integrity  . . . . . . . . . . . . . . . . .  30
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 2]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   6.  Key Update  . . . . . . . . . . . . . . . . . . . . . . . . .  32
+     6.1.  Initiating a Key Update . . . . . . . . . . . . . . . . .  33
+     6.2.  Responding to a Key Update  . . . . . . . . . . . . . . .  34
+     6.3.  Timing of Receive Key Generation  . . . . . . . . . . . .  34
+     6.4.  Sending with Updated Keys . . . . . . . . . . . . . . . .  35
+     6.5.  Receiving with Different Keys . . . . . . . . . . . . . .  35
+     6.6.  Key Update Frequency  . . . . . . . . . . . . . . . . . .  36
+     6.7.  Key Update Error Code . . . . . . . . . . . . . . . . . .  36
+   7.  Security of Initial Messages  . . . . . . . . . . . . . . . .  37
+   8.  QUIC-Specific Adjustments to the TLS Handshake  . . . . . . .  37
+     8.1.  Protocol Negotiation  . . . . . . . . . . . . . . . . . .  37
+     8.2.  QUIC Transport Parameters Extension . . . . . . . . . . .  38
+     8.3.  Removing the EndOfEarlyData Message . . . . . . . . . . .  38
+     8.4.  Prohibit TLS Middlebox Compatibility Mode . . . . . . . .  39
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  39
+     9.1.  Session Linkability . . . . . . . . . . . . . . . . . . .  39
+     9.2.  Replay Attacks with 0-RTT . . . . . . . . . . . . . . . .  39
+     9.3.  Packet Reflection Attack Mitigation . . . . . . . . . . .  40
+     9.4.  Header Protection Analysis  . . . . . . . . . . . . . . .  41
+     9.5.  Header Protection Timing Side-Channels  . . . . . . . . .  42
+     9.6.  Key Diversity . . . . . . . . . . . . . . . . . . . . . .  42
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  43
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .  43
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  44
+   Appendix A.  Sample Packet Protection . . . . . . . . . . . . . .  45
+     A.1.  Keys  . . . . . . . . . . . . . . . . . . . . . . . . . .  45
+     A.2.  Client Initial  . . . . . . . . . . . . . . . . . . . . .  46
+     A.3.  Server Initial  . . . . . . . . . . . . . . . . . . . . .  48
+     A.4.  Retry . . . . . . . . . . . . . . . . . . . . . . . . . .  49
+   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  49
+     B.1.  Since draft-ietf-quic-tls-27  . . . . . . . . . . . . . .  49
+     B.2.  Since draft-ietf-quic-tls-26  . . . . . . . . . . . . . .  49
+     B.3.  Since draft-ietf-quic-tls-25  . . . . . . . . . . . . . .  50
+     B.4.  Since draft-ietf-quic-tls-24  . . . . . . . . . . . . . .  50
+     B.5.  Since draft-ietf-quic-tls-23  . . . . . . . . . . . . . .  50
+     B.6.  Since draft-ietf-quic-tls-22  . . . . . . . . . . . . . .  50
+     B.7.  Since draft-ietf-quic-tls-21  . . . . . . . . . . . . . .  50
+     B.8.  Since draft-ietf-quic-tls-20  . . . . . . . . . . . . . .  50
+     B.9.  Since draft-ietf-quic-tls-18  . . . . . . . . . . . . . .  51
+     B.10. Since draft-ietf-quic-tls-17  . . . . . . . . . . . . . .  51
+     B.11. Since draft-ietf-quic-tls-14  . . . . . . . . . . . . . .  51
+     B.12. Since draft-ietf-quic-tls-13  . . . . . . . . . . . . . .  51
+     B.13. Since draft-ietf-quic-tls-12  . . . . . . . . . . . . . .  51
+     B.14. Since draft-ietf-quic-tls-11  . . . . . . . . . . . . . .  52
+     B.15. Since draft-ietf-quic-tls-10  . . . . . . . . . . . . . .  52
+     B.16. Since draft-ietf-quic-tls-09  . . . . . . . . . . . . . .  52
+     B.17. Since draft-ietf-quic-tls-08  . . . . . . . . . . . . . .  52
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 3]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+     B.18. Since draft-ietf-quic-tls-07  . . . . . . . . . . . . . .  52
+     B.19. Since draft-ietf-quic-tls-05  . . . . . . . . . . . . . .  52
+     B.20. Since draft-ietf-quic-tls-04  . . . . . . . . . . . . . .  52
+     B.21. Since draft-ietf-quic-tls-03  . . . . . . . . . . . . . .  52
+     B.22. Since draft-ietf-quic-tls-02  . . . . . . . . . . . . . .  53
+     B.23. Since draft-ietf-quic-tls-01  . . . . . . . . . . . . . .  53
+     B.24. Since draft-ietf-quic-tls-00  . . . . . . . . . . . . . .  53
+     B.25. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . .  53
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  54
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  54
+
+1.  Introduction
+
+   This document describes how QUIC [QUIC-TRANSPORT] is secured using
+   TLS [TLS13].
+
+   TLS 1.3 provides critical latency improvements for connection
+   establishment over previous versions.  Absent packet loss, most new
+   connections can be established and secured within a single round
+   trip; on subsequent connections between the same client and server,
+   the client can often send application data immediately, that is,
+   using a zero round trip setup.
+
+   This document describes how TLS acts as a security component of QUIC.
+
+2.  Notational Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This document uses the terminology established in [QUIC-TRANSPORT].
+
+   For brevity, the acronym TLS is used to refer to TLS 1.3, though a
+   newer version could be used (see Section 4.2).
+
+2.1.  TLS Overview
+
+   TLS provides two endpoints with a way to establish a means of
+   communication over an untrusted medium (that is, the Internet) that
+   ensures that messages they exchange cannot be observed, modified, or
+   forged.
+
+   Internally, TLS is a layered protocol, with the structure shown in
+   Figure 1.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 4]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+             +-------------+------------+--------------+---------+
+   Handshake |             |            |  Application |         |
+   Layer     |  Handshake  |   Alerts   |     Data     |   ...   |
+             |             |            |              |         |
+             +-------------+------------+--------------+---------+
+   Record    |                                                   |
+   Layer     |                      Records                      |
+             |                                                   |
+             +---------------------------------------------------+
+
+                            Figure 1: TLS Layers
+
+   Each Handshake layer message (e.g., Handshake, Alerts, and
+   Application Data) is carried as a series of typed TLS records by the
+   Record layer.  Records are individually cryptographically protected
+   and then transmitted over a reliable transport (typically TCP) which
+   provides sequencing and guaranteed delivery.
+
+   The TLS authenticated key exchange occurs between two endpoints:
+   client and server.  The client initiates the exchange and the server
+   responds.  If the key exchange completes successfully, both client
+   and server will agree on a secret.  TLS supports both pre-shared key
+   (PSK) and Diffie-Hellman over either finite fields or elliptic curves
+   ((EC)DHE) key exchanges.  PSK is the basis for 0-RTT; the latter
+   provides perfect forward secrecy (PFS) when the (EC)DHE keys are
+   destroyed.
+
+   After completing the TLS handshake, the client will have learned and
+   authenticated an identity for the server and the server is optionally
+   able to learn and authenticate an identity for the client.  TLS
+   supports X.509 [RFC5280] certificate-based authentication for both
+   server and client.
+
+   The TLS key exchange is resistant to tampering by attackers and it
+   produces shared secrets that cannot be controlled by either
+   participating peer.
+
+   TLS provides two basic handshake modes of interest to QUIC:
+
+   *  A full 1-RTT handshake in which the client is able to send
+      Application Data after one round trip and the server immediately
+      responds after receiving the first handshake message from the
+      client.
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 5]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   *  A 0-RTT handshake in which the client uses information it has
+      previously learned about the server to send Application Data
+      immediately.  This Application Data can be replayed by an attacker
+      so it MUST NOT carry a self-contained trigger for any non-
+      idempotent action.
+
+   A simplified TLS handshake with 0-RTT application data is shown in
+   Figure 2.
+
+       Client                                             Server
+
+       ClientHello
+      (0-RTT Application Data)  -------->
+                                                     ServerHello
+                                            {EncryptedExtensions}
+                                                       {Finished}
+                                <--------      [Application Data]
+      {Finished}                -------->
+
+      [Application Data]        <------->      [Application Data]
+
+       () Indicates messages protected by Early Data (0-RTT) Keys
+       {} Indicates messages protected using Handshake Keys
+       [] Indicates messages protected using Application Data
+          (1-RTT) Keys
+
+                     Figure 2: TLS Handshake with 0-RTT
+
+   Figure 2 omits the EndOfEarlyData message, which is not used in QUIC;
+   see Section 8.3.  Likewise, neither ChangeCipherSpec nor KeyUpdate
+   messages are used by QUIC.  ChangeCipherSpec is redundant in TLS 1.3;
+   see Section 8.4.  QUIC has its own key update mechanism; see
+   Section 6.
+
+   Data is protected using a number of encryption levels:
+
+   *  Initial Keys
+
+   *  Early Data (0-RTT) Keys
+
+   *  Handshake Keys
+
+   *  Application Data (1-RTT) Keys
+
+   Application Data may appear only in the Early Data and Application
+   Data levels.  Handshake and Alert messages may appear in any level.
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 6]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   The 0-RTT handshake is only possible if the client and server have
+   previously communicated.  In the 1-RTT handshake, the client is
+   unable to send protected Application Data until it has received all
+   of the Handshake messages sent by the server.
+
+3.  Protocol Overview
+
+   QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality
+   and integrity protection of packets.  For this it uses keys derived
+   from a TLS handshake [TLS13], but instead of carrying TLS records
+   over QUIC (as with TCP), TLS Handshake and Alert messages are carried
+   directly over the QUIC transport, which takes over the
+   responsibilities of the TLS record layer, as shown in Figure 3.
+
+   +--------------+--------------+ +-------------+
+   |     TLS      |     TLS      | |    QUIC     |
+   |  Handshake   |    Alerts    | | Applications|
+   |              |              | |  (h3, etc.) |
+   +--------------+--------------+-+-------------+
+   |                                             |
+   |                QUIC Transport               |
+   |   (streams, reliability, congestion, etc.)  |
+   |                                             |
+   +---------------------------------------------+
+   |                                             |
+   |            QUIC Packet Protection           |
+   |                                             |
+   +---------------------------------------------+
+
+                           Figure 3: QUIC Layers
+
+   QUIC also relies on TLS for authentication and negotiation of
+   parameters that are critical to security and performance.
+
+   Rather than a strict layering, these two protocols cooperate: QUIC
+   uses the TLS handshake; TLS uses the reliability, ordered delivery,
+   and record layer provided by QUIC.
+
+   At a high level, there are two main interactions between the TLS and
+   QUIC components:
+
+   *  The TLS component sends and receives messages via the QUIC
+      component, with QUIC providing a reliable stream abstraction to
+      TLS.
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 7]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   *  The TLS component provides a series of updates to the QUIC
+      component, including (a) new packet protection keys to install (b)
+      state changes such as handshake completion, the server
+      certificate, etc.
+
+   Figure 4 shows these interactions in more detail, with the QUIC
+   packet protection being called out specially.
+
+   +------------+                               +------------+
+   |            |<---- Handshake Messages ----->|            |
+   |            |<- Validate 0-RTT parameters ->|            |
+   |            |<--------- 0-RTT Keys ---------|            |
+   |    QUIC    |<------- Handshake Keys -------|    TLS     |
+   |            |<--------- 1-RTT Keys ---------|            |
+   |            |<------- Handshake Done -------|            |
+   +------------+                               +------------+
+    |         ^
+    | Protect | Protected
+    v         | Packet
+   +------------+
+   |   QUIC     |
+   |  Packet    |
+   | Protection |
+   +------------+
+
+                    Figure 4: QUIC and TLS Interactions
+
+   Unlike TLS over TCP, QUIC applications which want to send data do not
+   send it through TLS "application_data" records.  Rather, they send it
+   as QUIC STREAM frames or other frame types which are then carried in
+   QUIC packets.
+
+4.  Carrying TLS Messages
+
+   QUIC carries TLS handshake data in CRYPTO frames, each of which
+   consists of a contiguous block of handshake data identified by an
+   offset and length.  Those frames are packaged into QUIC packets and
+   encrypted under the current TLS encryption level.  As with TLS over
+   TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's
+   responsibility to deliver it reliably.  Each chunk of data that is
+   produced by TLS is associated with the set of keys that TLS is
+   currently using.  If QUIC needs to retransmit that data, it MUST use
+   the same keys even if TLS has already updated to newer keys.
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 8]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   One important difference between TLS records (used with TCP) and QUIC
+   CRYPTO frames is that in QUIC multiple frames may appear in the same
+   QUIC packet as long as they are associated with the same packet
+   number space.  For instance, an endpoint can bundle a Handshake
+   message and an ACK for some Handshake data into the same packet.
+
+   Some frames are prohibited in different packet number spaces.  The
+   rules here generalize those of TLS, in that frames associated with
+   establishing the connection can usually appear in packets in any
+   packet number space, whereas those associated with transferring data
+   can only appear in the application data packet number space:
+
+   *  PADDING, PING, and CRYPTO frames MAY appear in any packet number
+      space.
+
+   *  CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
+      0x1c) MAY appear in any packet number space.  CONNECTION_CLOSE
+      frames signaling application errors (type 0x1d) MUST only appear
+      in the application data packet number space.
+
+   *  ACK frames MAY appear in any packet number space, but can only
+      acknowledge packets which appeared in that packet number space.
+      However, as noted below, 0-RTT packets cannot contain ACK frames.
+
+   *  All other frame types MUST only be sent in the application data
+      packet number space.
+
+   Note that it is not possible to send the following frames in 0-RTT
+   packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
+   PATH_RESPONSE, and RETIRE_CONNECTION_ID.  A server MAY treat receipt
+   of these frames in 0-RTT packets as a connection error of type
+   PROTOCOL_VIOLATION.
+
+   Because packets could be reordered on the wire, QUIC uses the packet
+   type to indicate which keys were used to protect a given packet, as
+   shown in Table 1.  When packets of different types need to be sent,
+   endpoints SHOULD use coalesced packets to send them in the same UDP
+   datagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020                [Page 9]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+       +---------------------+-----------------+------------------+
+       | Packet Type         | Encryption Keys | PN Space         |
+       +=====================+=================+==================+
+       | Initial             | Initial secrets | Initial          |
+       +---------------------+-----------------+------------------+
+       | 0-RTT Protected     | 0-RTT           | Application data |
+       +---------------------+-----------------+------------------+
+       | Handshake           | Handshake       | Handshake        |
+       +---------------------+-----------------+------------------+
+       | Retry               | Retry           | N/A              |
+       +---------------------+-----------------+------------------+
+       | Version Negotiation | N/A             | N/A              |
+       +---------------------+-----------------+------------------+
+       | Short Header        | 1-RTT           | Application data |
+       +---------------------+-----------------+------------------+
+
+                 Table 1: Encryption Keys by Packet Type
+
+   Section 17 of [QUIC-TRANSPORT] shows how packets at the various
+   encryption levels fit into the handshake process.
+
+4.1.  Interface to TLS
+
+   As shown in Figure 4, the interface from QUIC to TLS consists of four
+   primary functions:
+
+   *  Sending and receiving handshake messages
+
+   *  Processing stored transport and application state from a resumed
+      session and determining if it is valid to accept early data
+
+   *  Rekeying (both transmit and receive)
+
+   *  Handshake state updates
+
+   Additional functions might be needed to configure TLS.
+
+4.1.1.  Handshake Complete
+
+   In this document, the TLS handshake is considered complete when the
+   TLS stack has reported that the handshake is complete.  This happens
+   when the TLS stack has both sent a Finished message and verified the
+   peer's Finished message.  Verifying the peer's Finished provides the
+   endpoints with an assurance that previous handshake messages have not
+   been modified.  Note that the handshake does not complete at both
+   endpoints simultaneously.  Consequently, any requirement that is
+   based on the completion of the handshake depends on the perspective
+   of the endpoint in question.
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 10]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+4.1.2.  Handshake Confirmed
+
+   In this document, the TLS handshake is considered confirmed at the
+   server when the handshake completes.  At the client, the handshake is
+   considered confirmed when a HANDSHAKE_DONE frame is received.
+
+   A client MAY consider the handshake to be confirmed when it receives
+   an acknowledgement for a 1-RTT packet.  This can be implemented by
+   recording the lowest packet number sent with 1-RTT keys, and
+   comparing it to the Largest Acknowledged field in any received 1-RTT
+   ACK frame: once the latter is greater than or equal to the former,
+   the handshake is confirmed.
+
+4.1.3.  Sending and Receiving Handshake Messages
+
+   In order to drive the handshake, TLS depends on being able to send
+   and receive handshake messages.  There are two basic functions on
+   this interface: one where QUIC requests handshake messages and one
+   where QUIC provides handshake packets.
+
+   Before starting the handshake QUIC provides TLS with the transport
+   parameters (see Section 8.2) that it wishes to carry.
+
+   A QUIC client starts TLS by requesting TLS handshake bytes from TLS.
+   The client acquires handshake bytes before sending its first packet.
+   A QUIC server starts the process by providing TLS with the client's
+   handshake bytes.
+
+   At any time, the TLS stack at an endpoint will have a current sending
+   encryption level and receiving encryption level.  Encryption levels
+   determine the packet type and keys that are used for protecting data.
+
+   Each encryption level is associated with a different sequence of
+   bytes, which is reliably transmitted to the peer in CRYPTO frames.
+   When TLS provides handshake bytes to be sent, they are appended to
+   the current flow.  Any packet that includes the CRYPTO frame is
+   protected using keys from the corresponding encryption level.  Four
+   encryption levels are used, producing keys for Initial, 0-RTT,
+   Handshake, and 1-RTT packets.  CRYPTO frames are carried in just
+   three of these levels, omitting the 0-RTT level.  These four levels
+   correspond to three packet number spaces: Initial and Handshake
+   encrypted packets use their own separate spaces; 0-RTT and 1-RTT
+   packets use the application data packet number space.
+
+   QUIC takes the unprotected content of TLS handshake records as the
+   content of CRYPTO frames.  TLS record protection is not used by QUIC.
+   QUIC assembles CRYPTO frames into QUIC packets, which are protected
+   using QUIC packet protection.
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 11]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   QUIC is only capable of conveying TLS handshake records in CRYPTO
+   frames.  TLS alerts are turned into QUIC CONNECTION_CLOSE error
+   codes; see Section 4.10.  TLS application data and other message
+   types cannot be carried by QUIC at any encryption level and is an
+   error if they are received from the TLS stack.
+
+   When an endpoint receives a QUIC packet containing a CRYPTO frame
+   from the network, it proceeds as follows:
+
+   *  If the packet was in the TLS receiving encryption level, sequence
+      the data into the input flow as usual.  As with STREAM frames, the
+      offset is used to find the proper location in the data sequence.
+      If the result of this process is that new data is available, then
+      it is delivered to TLS in order.
+
+   *  If the packet is from a previously installed encryption level, it
+      MUST NOT contain data which extends past the end of previously
+      received data in that flow.  Implementations MUST treat any
+      violations of this requirement as a connection error of type
+      PROTOCOL_VIOLATION.
+
+   *  If the packet is from a new encryption level, it is saved for
+      later processing by TLS.  Once TLS moves to receiving from this
+      encryption level, saved data can be provided.  When providing data
+      from any new encryption level to TLS, if there is data from a
+      previous encryption level that TLS has not consumed, this MUST be
+      treated as a connection error of type PROTOCOL_VIOLATION.
+
+   Each time that TLS is provided with new data, new handshake bytes are
+   requested from TLS.  TLS might not provide any bytes if the handshake
+   messages it has received are incomplete or it has no data to send.
+
+   Once the TLS handshake is complete, this is indicated to QUIC along
+   with any final handshake bytes that TLS needs to send.  TLS also
+   provides QUIC with the transport parameters that the peer advertised
+   during the handshake.
+
+   Once the handshake is complete, TLS becomes passive.  TLS can still
+   receive data from its peer and respond in kind, but it will not need
+   to send more data unless specifically requested - either by an
+   application or QUIC.  One reason to send data is that the server
+   might wish to provide additional or updated session tickets to a
+   client.
+
+   When the handshake is complete, QUIC only needs to provide TLS with
+   any data that arrives in CRYPTO streams.  In the same way that is
+   done during the handshake, new data is requested from TLS after
+   providing received data.
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 12]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+4.1.4.  Encryption Level Changes
+
+   As keys for new encryption levels become available, TLS provides QUIC
+   with those keys.  Separately, as keys at a given encryption level
+   become available to TLS, TLS indicates to QUIC that reading or
+   writing keys at that encryption level are available.  These events
+   are not asynchronous; they always occur immediately after TLS is
+   provided with new handshake bytes, or after TLS produces handshake
+   bytes.
+
+   TLS provides QUIC with three items as a new encryption level becomes
+   available:
+
+   *  A secret
+
+   *  An Authenticated Encryption with Associated Data (AEAD) function
+
+   *  A Key Derivation Function (KDF)
+
+   These values are based on the values that TLS negotiates and are used
+   by QUIC to generate packet and header protection keys (see Section 5
+   and Section 5.4).
+
+   If 0-RTT is possible, it is ready after the client sends a TLS
+   ClientHello message or the server receives that message.  After
+   providing a QUIC client with the first handshake bytes, the TLS stack
+   might signal the change to 0-RTT keys.  On the server, after
+   receiving handshake bytes that contain a ClientHello message, a TLS
+   server might signal that 0-RTT keys are available.
+
+   Although TLS only uses one encryption level at a time, QUIC may use
+   more than one level.  For instance, after sending its Finished
+   message (using a CRYPTO frame at the Handshake encryption level) an
+   endpoint can send STREAM data (in 1-RTT encryption).  If the Finished
+   message is lost, the endpoint uses the Handshake encryption level to
+   retransmit the lost message.  Reordering or loss of packets can mean
+   that QUIC will need to handle packets at multiple encryption levels.
+   During the handshake, this means potentially handling packets at
+   higher and lower encryption levels than the current encryption level
+   used by TLS.
+
+   In particular, server implementations need to be able to read packets
+   at the Handshake encryption level at the same time as the 0-RTT
+   encryption level.  A client could interleave ACK frames that are
+   protected with Handshake keys with 0-RTT data and the server needs to
+   process those acknowledgments in order to detect lost Handshake
+   packets.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 13]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   QUIC also needs access to keys that might not ordinarily be available
+   to a TLS implementation.  For instance, a client might need to
+   acknowledge Handshake packets before it is ready to send CRYPTO
+   frames at that encryption level.  TLS therefore needs to provide keys
+   to QUIC before it might produce them for its own use.
+
+4.1.5.  TLS Interface Summary
+
+   Figure 5 summarizes the exchange between QUIC and TLS for both client
+   and server.  Each arrow is tagged with the encryption level used for
+   that transmission.
+
+   Client                                                    Server
+
+   Get Handshake
+                        Initial ------------->
+                                                 Handshake Received
+   Install tx 0-RTT Keys
+                        0-RTT --------------->
+                                                      Get Handshake
+                        <------------- Initial
+   Handshake Received
+   Install Handshake keys
+                                              Install rx 0-RTT keys
+                                             Install Handshake keys
+                                                      Get Handshake
+                        <----------- Handshake
+   Handshake Received
+                                              Install tx 1-RTT keys
+                        <--------------- 1-RTT
+   Get Handshake
+   Handshake Complete
+                        Handshake ----------->
+                                                 Handshake Received
+                                              Install rx 1-RTT keys
+                                                 Handshake Complete
+   Install 1-RTT keys
+                        1-RTT --------------->
+                                                      Get Handshake
+                        <--------------- 1-RTT
+   Handshake Received
+
+             Figure 5: Interaction Summary between QUIC and TLS
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 14]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Figure 5 shows the multiple packets that form a single "flight" of
+   messages being processed individually, to show what incoming messages
+   trigger different actions.  New handshake messages are requested
+   after all incoming packets have been processed.  This process might
+   vary depending on how QUIC implementations and the packets they
+   receive are structured.
+
+4.2.  TLS Version
+
+   This document describes how TLS 1.3 [TLS13] is used with QUIC.
+
+   In practice, the TLS handshake will negotiate a version of TLS to
+   use.  This could result in a newer version of TLS than 1.3 being
+   negotiated if both endpoints support that version.  This is
+   acceptable provided that the features of TLS 1.3 that are used by
+   QUIC are supported by the newer version.
+
+   A badly configured TLS implementation could negotiate TLS 1.2 or
+   another older version of TLS.  An endpoint MUST terminate the
+   connection if a version of TLS older than 1.3 is negotiated.
+
+4.3.  ClientHello Size
+
+   The first Initial packet from a client contains the start or all of
+   its first cryptographic handshake message, which for TLS is the
+   ClientHello.  Servers might need to parse the entire ClientHello
+   (e.g., to access extensions such as Server Name Identification (SNI)
+   or Application Layer Protocol Negotiation (ALPN)) in order to decide
+   whether to accept the new incoming QUIC connection.  If the
+   ClientHello spans multiple Initial packets, such servers would need
+   to buffer the first received fragments, which could consume excessive
+   resources if the client's address has not yet been validated.  To
+   avoid this, servers MAY use the Retry feature (see Section 8.1 of
+   [QUIC-TRANSPORT]) to only buffer partial ClientHello messages from
+   clients with a validated address.
+
+   QUIC packet and framing add at least 36 bytes of overhead to the
+   ClientHello message.  That overhead increases if the client chooses a
+   connection ID without zero length.  Overheads also do not include the
+   token or a connection ID longer than 8 bytes, both of which might be
+   required if a server sends a Retry packet.
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 15]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   A typical TLS ClientHello can easily fit into a 1200 byte packet.
+   However, in addition to the overheads added by QUIC, there are
+   several variables that could cause this limit to be exceeded.  Large
+   session tickets, 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, in addition to connection IDs and tokens, the size of
+   TLS session tickets can have an effect on a client's ability to
+   connect efficiently.  Minimizing the size of these values increases
+   the probability that clients can use them and still fit their
+   ClientHello message in their first Initial packet.
+
+   The TLS implementation does not need to ensure that the ClientHello
+   is sufficiently large.  QUIC PADDING frames are added to increase the
+   size of the packet as necessary.
+
+4.4.  Peer Authentication
+
+   The requirements for authentication depend on the application
+   protocol that is in use.  TLS provides server authentication and
+   permits the server to request client authentication.
+
+   A client MUST authenticate the identity of the server.  This
+   typically involves verification that the identity of the server is
+   included in a certificate and that the certificate is issued by a
+   trusted entity (see for example [RFC2818]).
+
+   A server MAY request that the client authenticate during the
+   handshake.  A server MAY refuse a connection if the client is unable
+   to authenticate when requested.  The requirements for client
+   authentication vary based on application protocol and deployment.
+
+   A server MUST NOT use post-handshake client authentication (as
+   defined in Section 4.6.2 of [TLS13]), because the multiplexing
+   offered by QUIC prevents clients from correlating the certificate
+   request with the application-level event that triggered it (see
+   [HTTP2-TLS13]).  More specifically, servers MUST NOT send post-
+   handshake TLS CertificateRequest messages and clients MUST treat
+   receipt of such messages as a connection error of type
+   PROTOCOL_VIOLATION.
+
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 16]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+4.5.  Session Resumption
+
+   QUIC can use the session resumption feature of TLS 1.3.  It does this
+   by carrying NewSessionTicket messages in CRYPTO frames after the
+   handshake is complete.  Session resumption is the basis of 0-RTT, but
+   can be used without also enabling 0-RTT.
+
+   Endpoints that use session resumption might need to remember some
+   information about the current connection when creating a resumed
+   connection.  TLS requires that some information be retained; see
+   Section 4.6.1 of [TLS13].  QUIC itself does not depend on any state
+   being retained when resuming a connection, unless 0-RTT is also used;
+   see Section 4.6 and Section 7.4.1 of [QUIC-TRANSPORT].  Application
+   protocols could depend on state that is retained between resumed
+   connections.
+
+   Clients can store any state required for resumption along with the
+   session ticket.  Servers can use the session ticket to help carry
+   state.
+
+   Session resumption allows servers to link activity on the original
+   connection with the resumed connection, which might be a privacy
+   issue for clients.  Clients can choose not to enable resumption to
+   avoid creating this correlation.  Client SHOULD NOT reuse tickets as
+   that allows entities other than the server to correlate connections;
+   see Section C.4 of [TLS13].
+
+4.6.  Enabling 0-RTT
+
+   To communicate their willingness to process 0-RTT data, servers send
+   a NewSessionTicket message that contains the "early_data" extension
+   with a max_early_data_size of 0xffffffff; the amount of data which
+   the client can send in 0-RTT is controlled by the "initial_max_data"
+   transport parameter supplied by the server.  Servers MUST NOT send
+   the "early_data" extension with a max_early_data_size set to any
+   value other than 0xffffffff.  A client MUST treat receipt of a
+   NewSessionTicket that contains an "early_data" extension with any
+   other value as a connection error of type PROTOCOL_VIOLATION.
+
+   A client that wishes to send 0-RTT packets uses the "early_data"
+   extension in the ClientHello message of a subsequent handshake (see
+   Section 4.2.10 of [TLS13]).  It then sends the application data in
+   0-RTT packets.
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 17]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+4.7.  Accepting and Rejecting 0-RTT
+
+   A server accepts 0-RTT by sending an early_data extension in the
+   EncryptedExtensions (see Section 4.2.10 of [TLS13]).  The server then
+   processes and acknowledges the 0-RTT packets that it receives.
+
+   A server rejects 0-RTT by sending the EncryptedExtensions without an
+   early_data extension.  A server will always reject 0-RTT if it sends
+   a TLS HelloRetryRequest.  When rejecting 0-RTT, a server MUST NOT
+   process any 0-RTT packets, even if it could.  When 0-RTT was
+   rejected, a client SHOULD treat receipt of an acknowledgement for a
+   0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it
+   is able to detect the condition.
+
+   When 0-RTT is rejected, all connection characteristics that the
+   client assumed might be incorrect.  This includes the choice of
+   application protocol, transport parameters, and any application
+   configuration.  The client therefore MUST reset the state of all
+   streams, including application state bound to those streams.
+
+   A client MAY attempt to send 0-RTT again if it receives a Retry or
+   Version Negotiation packet.  These packets do not signify rejection
+   of 0-RTT.
+
+4.8.  Validating 0-RTT Configuration
+
+   When a server receives a ClientHello with the "early_data" extension,
+   it has to decide whether to accept or reject early data from the
+   client.  Some of this decision is made by the TLS stack (e.g.,
+   checking that the cipher suite being resumed was included in the
+   ClientHello; see Section 4.2.10 of [TLS13]).  Even when the TLS stack
+   has no reason to reject early data, the QUIC stack or the application
+   protocol using QUIC might reject early data because the configuration
+   of the transport or application associated with the resumed session
+   is not compatible with the server's current configuration.
+
+   QUIC requires additional transport state to be associated with a
+   0-RTT session ticket.  One common way to implement this is using
+   stateless session tickets and storing this state in the session
+   ticket.  Application protocols that use QUIC might have similar
+   requirements regarding associating or storing state.  This associated
+   state is used for deciding whether early data must be rejected.  For
+   example, HTTP/3 ([QUIC-HTTP]) settings determine how early data from
+   the client is interpreted.  Other applications using QUIC could have
+   different requirements for determining whether to accept or reject
+   early data.
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 18]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+4.9.  HelloRetryRequest
+
+   In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
+   [TLS13]) can be used to correct a client's incorrect KeyShare
+   extension as well as for a stateless round-trip check.  From the
+   perspective of QUIC, this just looks like additional messages carried
+   in Initial packets.  Although it is in principle possible to use this
+   feature for address verification in QUIC, QUIC implementations SHOULD
+   instead use the Retry feature (see Section 8.1 of [QUIC-TRANSPORT]).
+   HelloRetryRequest is still used to request key shares.
+
+4.10.  TLS Errors
+
+   If TLS experiences an error, it generates an appropriate alert as
+   defined in Section 6 of [TLS13].
+
+   A TLS alert is converted into a QUIC connection error.  The alert
+   description is added to 0x100 to produce a QUIC error code from the
+   range reserved for CRYPTO_ERROR.  The resulting value is sent in a
+   QUIC CONNECTION_CLOSE frame of type 0x1c.
+
+   The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
+   generate alerts at the "warning" level.
+
+   QUIC permits the use of a generic code in place of a specific error
+   code; see Section 11 of [QUIC-TRANSPORT].  For TLS alerts, this
+   includes replacing any alert with a generic alert, such as
+   handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error
+   code to avoid possibly exposing confidential information.
+
+4.11.  Discarding Unused Keys
+
+   After QUIC moves to a new encryption level, packet protection keys
+   for previous encryption levels can be discarded.  This occurs several
+   times during the handshake, as well as when keys are updated; see
+   Section 6.
+
+   Packet protection keys are not discarded immediately when new keys
+   are available.  If packets from a lower encryption level contain
+   CRYPTO frames, frames that retransmit that data MUST be sent at the
+   same encryption level.  Similarly, an endpoint generates
+   acknowledgements for packets at the same encryption level as the
+   packet being acknowledged.  Thus, it is possible that keys for a
+   lower encryption level are needed for a short time after keys for a
+   newer encryption level are available.
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 19]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   An endpoint cannot discard keys for a given encryption level unless
+   it has both received and acknowledged all CRYPTO frames for that
+   encryption level and when all CRYPTO frames for that encryption level
+   have been acknowledged by its peer.  However, this does not guarantee
+   that no further packets will need to be received or sent at that
+   encryption level because a peer might not have received all the
+   acknowledgements necessary to reach the same state.
+
+   Though an endpoint might retain older keys, new data MUST be sent at
+   the highest currently-available encryption level.  Only ACK frames
+   and retransmissions of data in CRYPTO frames are sent at a previous
+   encryption level.  These packets MAY also include PADDING frames.
+
+4.11.1.  Discarding Initial Keys
+
+   Packets protected with Initial secrets (Section 5.2) are not
+   authenticated, meaning that an attacker could spoof packets with the
+   intent to disrupt a connection.  To limit these attacks, Initial
+   packet protection keys can be discarded more aggressively than other
+   keys.
+
+   The successful use of Handshake packets indicates that no more
+   Initial packets need to be exchanged, as these keys can only be
+   produced after receiving all CRYPTO frames from Initial packets.
+   Thus, a client MUST discard Initial keys when it first sends a
+   Handshake packet and a server MUST discard Initial keys when it first
+   successfully processes a Handshake packet.  Endpoints MUST NOT send
+   Initial packets after this point.
+
+   This results in abandoning loss recovery state for the Initial
+   encryption level and ignoring any outstanding Initial packets.
+
+4.11.2.  Discarding Handshake Keys
+
+   An endpoint MUST discard its handshake keys when the TLS handshake is
+   confirmed (Section 4.1.2).  The server MUST send a HANDSHAKE_DONE
+   frame as soon as it completes the handshake.
+
+4.11.3.  Discarding 0-RTT Keys
+
+   0-RTT and 1-RTT packets share the same packet number space, and
+   clients do not send 0-RTT packets after sending a 1-RTT packet
+   (Section 5.6).
+
+   Therefore, a client SHOULD discard 0-RTT keys as soon as it installs
+   1-RTT keys, since they have no use after that moment.
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 20]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Additionally, a server MAY discard 0-RTT keys as soon as it receives
+   a 1-RTT packet.  However, due to packet reordering, a 0-RTT packet
+   could arrive after a 1-RTT packet.  Servers MAY temporarily retain
+   0-RTT keys to allow decrypting reordered packets without requiring
+   their contents to be retransmitted with 1-RTT keys.  After receiving
+   a 1-RTT packet, servers MUST discard 0-RTT keys within a short time;
+   the RECOMMENDED time period is three times the Probe Timeout (PTO,
+   see [QUIC-RECOVERY]).  A server MAY discard 0-RTT keys earlier if it
+   determines that it has received all 0-RTT packets, which can be done
+   by keeping track of missing packet numbers.
+
+5.  Packet Protection
+
+   As with TLS over TCP, QUIC protects packets with keys derived from
+   the TLS handshake, using the AEAD algorithm negotiated by TLS.
+
+5.1.  Packet Protection Keys
+
+   QUIC derives packet protection keys in the same way that TLS derives
+   record protection keys.
+
+   Each encryption level has separate secret values for protection of
+   packets sent in each direction.  These traffic secrets are derived by
+   TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all
+   encryption levels except the Initial encryption level.  The secrets
+   for the Initial encryption level are computed based on the client's
+   initial Destination Connection ID, as described in Section 5.2.
+
+   The keys used for packet protection are computed from the TLS secrets
+   using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label
+   function described in Section 7.1 of [TLS13] is used, using the hash
+   function from the negotiated cipher suite.  Other versions of TLS
+   MUST provide a similar function in order to be used with QUIC.
+
+   The current encryption level secret and the label "quic key" are
+   input to the KDF to produce the AEAD key; the label "quic iv" is used
+   to derive the IV; see Section 5.3.  The header protection key uses
+   the "quic hp" label; see Section 5.4.  Using these labels provides
+   key separation between QUIC and TLS; see Section 9.6.
+
+   The KDF used for initial secrets is always the HKDF-Expand-Label
+   function from TLS 1.3 (see Section 5.2).
+
+5.2.  Initial Secrets
+
+   Initial packets are protected with a secret derived from the
+   Destination Connection ID field from the client's Initial packet.
+   Specifically:
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 21]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   initial_salt = 0xc3eef712c72ebb5a11a7d2432bb46365bef9f502
+   initial_secret = HKDF-Extract(initial_salt,
+                                 client_dst_connection_id)
+
+   client_initial_secret = HKDF-Expand-Label(initial_secret,
+                                             "client in", "",
+                                             Hash.length)
+   server_initial_secret = HKDF-Expand-Label(initial_secret,
+                                             "server in", "",
+                                             Hash.length)
+
+   The hash function for HKDF when deriving initial secrets and keys is
+   SHA-256 [SHA].
+
+   The connection ID used with HKDF-Expand-Label is the Destination
+   Connection ID in the Initial packet sent by the client.  This will be
+   a randomly-selected value unless the client creates the Initial
+   packet after receiving a Retry packet, where the Destination
+   Connection ID is selected by the server.
+
+   The value of initial_salt is a 20 byte sequence shown in the figure
+   in hexadecimal notation.  Future versions of QUIC SHOULD generate a
+   new salt value, thus ensuring that the keys are different for each
+   version of QUIC.  This prevents a middlebox that only recognizes one
+   version of QUIC from seeing or modifying the contents of packets from
+   future versions.
+
+   The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
+   Initial packets even where the TLS versions offered do not include
+   TLS 1.3.
+
+   The secrets used for protecting Initial packets change when a server
+   sends a Retry packet to use the connection ID value selected by the
+   server.  The secrets do not change when a client changes the
+   Destination Connection ID it uses in response to an Initial packet
+   from the server.
+
+   Note:  The Destination Connection ID is of arbitrary length, and it
+      could be zero length if the server sends a Retry packet with a
+      zero-length Source Connection ID field.  In this case, the Initial
+      keys provide no assurance to the client that the server received
+      its packet; the client has to rely on the exchange that included
+      the Retry packet for that property.
+
+   Appendix A contains test vectors for packet encryption.
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 22]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+5.3.  AEAD Usage
+
+   The Authentication Encryption with Associated Data (AEAD) [AEAD]
+   function used for QUIC packet protection is the AEAD that is
+   negotiated for use with the TLS connection.  For example, if TLS is
+   using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is
+   used.
+
+   Packets are protected prior to applying header protection
+   (Section 5.4).  The unprotected packet header is part of the
+   associated data (A).  When removing packet protection, an endpoint
+   first removes the header protection.
+
+   All QUIC packets other than Version Negotiation and Retry packets are
+   protected with an AEAD algorithm [AEAD].  Prior to establishing a
+   shared secret, packets are protected with AEAD_AES_128_GCM and a key
+   derived from the Destination Connection ID in the client's first
+   Initial packet (see Section 5.2).  This provides protection against
+   off-path attackers and robustness against QUIC version unaware
+   middleboxes, but not against on-path attackers.
+
+   QUIC can use any of the ciphersuites defined in [TLS13] with the
+   exception of TLS_AES_128_CCM_8_SHA256.  A ciphersuite MUST NOT be
+   negotiated unless a header protection scheme is defined for the
+   ciphersuite.  This document defines a header protection scheme for
+   all ciphersuites defined in [TLS13] aside from
+   TLS_AES_128_CCM_8_SHA256.  These ciphersuites have a 16-byte
+   authentication tag and produce an output 16 bytes larger than their
+   input.
+
+   Note:  An endpoint MUST NOT reject a ClientHello that offers a
+      ciphersuite that it does not support, or it would be impossible to
+      deploy a new ciphersuite.  This also applies to
+      TLS_AES_128_CCM_8_SHA256.
+
+   The key and IV for the packet are computed as described in
+   Section 5.1.  The nonce, N, is formed by combining the packet
+   protection IV with the packet number.  The 62 bits of the
+   reconstructed QUIC packet number in network byte order are left-
+   padded with zeros to the size of the IV.  The exclusive OR of the
+   padded packet number and the IV forms the AEAD nonce.
+
+   The associated data, A, for the AEAD is the contents of the QUIC
+   header, starting from the flags byte in either the short or long
+   header, up to and including the unprotected packet number.
+
+   The input plaintext, P, for the AEAD is the payload of the QUIC
+   packet, as described in [QUIC-TRANSPORT].
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 23]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   The output ciphertext, C, of the AEAD is transmitted in place of P.
+
+   Some AEAD functions have limits for how many packets can be encrypted
+   under the same key and IV (see for example [AEBounds]).  This might
+   be lower than the packet number limit.  An endpoint MUST initiate a
+   key update (Section 6) prior to exceeding any limit set for the AEAD
+   that is in use.
+
+5.4.  Header Protection
+
+   Parts of QUIC packet headers, in particular the Packet Number field,
+   are protected using a key that is derived separate to the packet
+   protection key and IV.  The key derived using the "quic hp" label is
+   used to provide confidentiality protection for those fields that are
+   not exposed to on-path elements.
+
+   This protection applies to the least-significant bits of the first
+   byte, plus the Packet Number field.  The four least-significant bits
+   of the first byte are protected for packets with long headers; the
+   five least significant bits of the first byte are protected for
+   packets with short headers.  For both header forms, this covers the
+   reserved bits and the Packet Number Length field; the Key Phase bit
+   is also protected for packets with a short header.
+
+   The same header protection key is used for the duration of the
+   connection, with the value not changing after a key update (see
+   Section 6).  This allows header protection to be used to protect the
+   key phase.
+
+   This process does not apply to Retry or Version Negotiation packets,
+   which do not contain a protected payload or any of the fields that
+   are protected by this process.
+
+5.4.1.  Header Protection Application
+
+   Header protection is applied after packet protection is applied (see
+   Section 5.3).  The ciphertext of the packet is sampled and used as
+   input to an encryption algorithm.  The algorithm used depends on the
+   negotiated AEAD.
+
+   The output of this algorithm is a 5 byte mask which is applied to the
+   protected header fields using exclusive OR.  The least significant
+   bits of the first byte of the packet are masked by the least
+   significant bits of the first mask byte, and the packet number is
+   masked with the remaining bytes.  Any unused bytes of mask that might
+   result from a shorter packet number encoding are unused.
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 24]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Figure 6 shows a sample algorithm for applying header protection.
+   Removing header protection only differs in the order in which the
+   packet number length (pn_length) is determined.
+
+   mask = header_protection(hp_key, sample)
+
+   pn_length = (packet[0] & 0x03) + 1
+   if (packet[0] & 0x80) == 0x80:
+      # Long header: 4 bits masked
+      packet[0] ^= mask[0] & 0x0f
+   else:
+      # Short header: 5 bits masked
+      packet[0] ^= mask[0] & 0x1f
+
+   # pn_offset is the start of the Packet Number field.
+   packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]
+
+                   Figure 6: Header Protection Pseudocode
+
+   Figure 7 shows an example long header packet (Initial) and a short
+   header packet.  Figure 7 shows the fields in each header that are
+   covered by header protection and the portion of the protected packet
+   payload that is sampled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 25]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Initial Packet {
+     Header Form (1) = 1,
+     Fixed Bit (1) = 1,
+     Long Packet Type (2) = 0,
+     Reserved Bits (2),         # Protected
+     Packet Number Length (2),  # Protected
+     Version (32),
+     DCID Len (8),
+     Destination Connection ID (0..160),
+     SCID Len (8),
+     Source Connection ID (0..160),
+     Token Length (i),
+     Token (..),
+     Packet Number (8..32),     # Protected
+     Protected Payload (0..24), # Skipped Part
+     Protected Payload (128),   # Sampled Part
+     Protected Payload (..)     # Remainder
+   }
+
+   Short Header Packet {
+     Header Form (1) = 0,
+     Fixed Bit (1) = 1,
+     Spin Bit (1),
+     Reserved Bits (2),         # Protected
+     Key Phase (1),             # Protected
+     Packet Number Length (2),  # Protected
+     Destination Connection ID (0..160),
+     Packet Number (8..32),     # Protected
+     Protected Payload (0..24), # Skipped Part
+     Protected Payload (128),   # Sampled Part
+     Protected Payload (..),    # Remainder
+   }
+
+             Figure 7: Header Protection and Ciphertext Sample
+
+   Before a TLS ciphersuite can be used with QUIC, a header protection
+   algorithm MUST be specified for the AEAD used with that ciphersuite.
+   This document defines algorithms for AEAD_AES_128_GCM,
+   AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in
+   [AEAD]), and AEAD_CHACHA20_POLY1305 [CHACHA].  Prior to TLS selecting
+   a ciphersuite, AES header protection is used (Section 5.4.3),
+   matching the AEAD_AES_128_GCM packet protection.
+
+5.4.2.  Header Protection Sample
+
+   The header protection algorithm uses both the header protection key
+   and a sample of the ciphertext from the packet Payload field.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 26]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   The same number of bytes are always sampled, but an allowance needs
+   to be made for the endpoint removing protection, which will not know
+   the length of the Packet Number field.  In sampling the packet
+   ciphertext, the Packet Number field is assumed to be 4 bytes long
+   (its maximum possible encoded length).
+
+   An endpoint MUST discard packets that are not long enough to contain
+   a complete sample.
+
+   To ensure that sufficient data is available for sampling, packets are
+   padded so that the combined lengths of the encoded packet number and
+   protected payload is at least 4 bytes longer than the sample required
+   for header protection.  The ciphersuites defined in [TLS13] - other
+   than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme
+   is not defined in this document - have 16-byte expansions and 16-byte
+   header protection samples.  This results in needing at least 3 bytes
+   of frames in the unprotected payload if the packet number is encoded
+   on a single byte, or 2 bytes of frames for a 2-byte packet number
+   encoding.
+
+   The sampled ciphertext for a packet with a short header can be
+   determined by the following pseudocode:
+
+   sample_offset = 1 + len(connection_id) + 4
+
+   sample = packet[sample_offset..sample_offset+sample_length]
+
+   For example, for a packet with a short header, an 8 byte connection
+   ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to
+   28 inclusive (using zero-based indexing).
+
+   A packet with a long header is sampled in the same way, noting that
+   multiple QUIC packets might be included in the same UDP datagram and
+   that each one is handled separately.
+
+   sample_offset = 7 + len(destination_connection_id) +
+                       len(source_connection_id) +
+                       len(payload_length) + 4
+   if packet_type == Initial:
+       sample_offset += len(token_length) +
+                        len(token)
+
+   sample = packet[sample_offset..sample_offset+sample_length]
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 27]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+5.4.3.  AES-Based Header Protection
+
+   This section defines the packet protection algorithm for
+   AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM.
+   AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES [AES] in
+   electronic code-book (ECB) mode.  AEAD_AES_256_GCM uses 256-bit AES
+   in ECB mode.
+
+   This algorithm samples 16 bytes from the packet ciphertext.  This
+   value is used as the input to AES-ECB.  In pseudocode:
+
+   mask = AES-ECB(hp_key, sample)
+
+5.4.4.  ChaCha20-Based Header Protection
+
+   When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw
+   ChaCha20 function as defined in Section 2.4 of [CHACHA].  This uses a
+   256-bit key and 16 bytes sampled from the packet protection output.
+
+   The first 4 bytes of the sampled ciphertext are the block counter.  A
+   ChaCha20 implementation could take a 32-bit integer in place of a
+   byte sequence, in which case the byte sequence is interpreted as a
+   little-endian value.
+
+   The remaining 12 bytes are used as the nonce.  A ChaCha20
+   implementation might take an array of three 32-bit integers in place
+   of a byte sequence, in which case the nonce bytes are interpreted as
+   a sequence of 32-bit little-endian integers.
+
+   The encryption mask is produced by invoking ChaCha20 to protect 5
+   zero bytes.  In pseudocode:
+
+   counter = sample[0..3]
+   nonce = sample[4..15]
+   mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})
+
+5.5.  Receiving Protected Packets
+
+   Once an endpoint successfully receives a packet with a given packet
+   number, it MUST discard all packets in the same packet number space
+   with higher packet numbers if they cannot be successfully unprotected
+   with either the same key, or - if there is a key update - the next
+   packet protection key (see Section 6).  Similarly, a packet that
+   appears to trigger a key update, but cannot be unprotected
+   successfully MUST be discarded.
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 28]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Failure to unprotect a packet does not necessarily indicate the
+   existence of a protocol error in a peer or an attack.  The truncated
+   packet number encoding used in QUIC can cause packet numbers to be
+   decoded incorrectly if they are delayed significantly.
+
+5.6.  Use of 0-RTT Keys
+
+   If 0-RTT keys are available (see Section 4.6), the lack of replay
+   protection means that restrictions on their use are necessary to
+   avoid replay attacks on the protocol.
+
+   A client MUST only use 0-RTT keys to protect data that is idempotent.
+   A client MAY wish to apply additional restrictions on what data it
+   sends prior to the completion of the TLS handshake.  A client
+   otherwise treats 0-RTT keys as equivalent to 1-RTT keys, except that
+   it MUST NOT send ACKs with 0-RTT keys.
+
+   A client that receives an indication that its 0-RTT data has been
+   accepted by a server can send 0-RTT data until it receives all of the
+   server's handshake messages.  A client SHOULD stop sending 0-RTT data
+   if it receives an indication that 0-RTT data has been rejected.
+
+   A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT
+   keys to protect acknowledgements of 0-RTT packets.  A client MUST NOT
+   attempt to decrypt 0-RTT packets it receives and instead MUST discard
+   them.
+
+   Once a client has installed 1-RTT keys, it MUST NOT send any more
+   0-RTT packets.
+
+   Note:  0-RTT data can be acknowledged by the server as it receives
+      it, but any packets containing acknowledgments of 0-RTT data
+      cannot have packet protection removed by the client until the TLS
+      handshake is complete.  The 1-RTT keys necessary to remove packet
+      protection cannot be derived until the client receives all server
+      handshake messages.
+
+5.7.  Receiving Out-of-Order Protected Frames
+
+   Due to reordering and loss, protected packets might be received by an
+   endpoint before the final TLS handshake messages are received.  A
+   client will be unable to decrypt 1-RTT packets from the server,
+   whereas a server will be able to decrypt 1-RTT packets from the
+   client.  Endpoints in either role MUST NOT decrypt 1-RTT packets from
+   their peer prior to completing the handshake.
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 29]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Even though 1-RTT keys are available to a server after receiving the
+   first handshake messages from a client, it is missing assurances on
+   the client state:
+
+   *  The client is not authenticated, unless the server has chosen to
+      use a pre-shared key and validated the client's pre-shared key
+      binder; see Section 4.2.11 of [TLS13].
+
+   *  The client has not demonstrated liveness, unless a RETRY packet
+      was used.
+
+   *  Any received 0-RTT data that the server responds to might be due
+      to a replay attack.
+
+   Therefore, the server's use of 1-RTT keys MUST be limited to sending
+   data before the handshake is complete.  A server MUST NOT process
+   incoming 1-RTT protected packets before the TLS handshake is
+   complete.  Because sending acknowledgments indicates that all frames
+   in a packet have been processed, a server cannot send acknowledgments
+   for 1-RTT packets until the TLS handshake is complete.  Received
+   packets protected with 1-RTT keys MAY be stored and later decrypted
+   and used once the handshake is complete.
+
+   Note:  TLS implementations might provide all 1-RTT secrets prior to
+      handshake completion.  Even where QUIC implementations have 1-RTT
+      read keys, those keys cannot be used prior to completing the
+      handshake.
+
+   The requirement for the server to wait for the client Finished
+   message creates a dependency on that message being delivered.  A
+   client can avoid the potential for head-of-line blocking that this
+   implies by sending its 1-RTT packets coalesced with a handshake
+   packet containing a copy of the CRYPTO frame that carries the
+   Finished message, until one of the handshake packets is acknowledged.
+   This enables immediate server processing for those packets.
+
+   A server could receive packets protected with 0-RTT keys prior to
+   receiving a TLS ClientHello.  The server MAY retain these packets for
+   later decryption in anticipation of receiving a ClientHello.
+
+5.8.  Retry Packet Integrity
+
+   Retry packets (see the Retry Packet section of [QUIC-TRANSPORT])
+   carry a Retry Integrity Tag that provides two properties: it allows
+   discarding packets that have accidentally been corrupted by the
+   network, and it diminishes off-path attackers' ability to send valid
+   Retry packets.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 30]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   The Retry Integrity Tag is a 128-bit field that is computed as the
+   output of AEAD_AES_128_GCM [AEAD] used with the following inputs:
+
+   *  The secret key, K, is 128 bits equal to
+      0x4d32ecdb2a2133c841e4043df27d4430.
+
+   *  The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575.
+
+   *  The plaintext, P, is empty.
+
+   *  The associated data, A, is the contents of the Retry Pseudo-
+      Packet, as illustrated in Figure 8:
+
+   The secret key and the nonce are values derived by calling HKDF-
+   Expand-Label using
+   0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as
+   the secret, with labels being "quic key" and "quic iv" (Section 5.1).
+
+   Retry Pseudo-Packet {
+     ODCID Length (8),
+     Original Destination Connection ID (0..160),
+     Header Form (1) = 1,
+     Fixed Bit (1) = 1,
+     Long Packet Type (2) = 3,
+     Type-Specific Bits (4),
+     Version (32),
+     DCID Len (8),
+     Destination Connection ID (0..160),
+     SCID Len (8),
+     Retry Token (..),
+   }
+
+                       Figure 8: Retry Pseudo-Packet
+
+   The Retry Pseudo-Packet is not sent over the wire.  It is computed by
+   taking the transmitted Retry packet, removing the Retry Integrity Tag
+   and prepending the two following fields:
+
+   ODCID Length:  The ODCID Len contains the length in bytes of the
+      Original Destination Connection ID field that follows it, encoded
+      as an 8-bit unsigned integer.
+
+   Original Destination Connection ID:  The Original Destination
+      Connection ID contains the value of the Destination Connection ID
+      from the Initial packet that this Retry is in response to.  The
+      length of this field is given in ODCID Len. The presence of this
+      field mitigates an off-path attacker's ability to inject a Retry
+      packet.
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 31]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+6.  Key Update
+
+   Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY
+   initiate a key update.
+
+   The Key Phase bit indicates which packet protection keys are used to
+   protect the packet.  The Key Phase bit is initially set to 0 for the
+   first set of 1-RTT packets and toggled to signal each subsequent key
+   update.
+
+   The Key Phase bit allows a recipient to detect a change in keying
+   material without needing to receive the first packet that triggered
+   the change.  An endpoint that notices a changed Key Phase bit updates
+   keys and decrypts the packet that contains the changed value.
+
+   This mechanism replaces the TLS KeyUpdate message.  Endpoints MUST
+   NOT send a TLS KeyUpdate message.  Endpoints MUST treat the receipt
+   of a TLS KeyUpdate message as a connection error of type 0x10a,
+   equivalent to a fatal TLS alert of unexpected_message (see
+   Section 4.10).
+
+   Figure 9 shows a key update process, where the initial set of keys
+   used (identified with @M) are replaced by updated keys (identified
+   with @N).  The value of the Key Phase bit is indicated in brackets
+   [].
+
+      Initiating Peer                    Responding Peer
+
+   @M [0] QUIC Packets
+
+   ... Update to @N
+   @N [1] QUIC Packets
+                         -------->
+                                            Update to @N ...
+                                         QUIC Packets [1] @N
+                         <--------
+                                         QUIC Packets [1] @N
+                                       containing ACK
+                         <--------
+   ... Key Update Permitted
+
+   @N [1] QUIC Packets
+            containing ACK for @N packets
+                         -------->
+                                    Key Update Permitted ...
+
+                            Figure 9: Key Update
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 32]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+6.1.  Initiating a Key Update
+
+   Endpoints maintain separate read and write secrets for packet
+   protection.  An endpoint initiates a key update by updating its
+   packet protection write secret and using that to protect new packets.
+   The endpoint creates a new write secret from the existing write
+   secret as performed in Section 7.2 of [TLS13].  This uses the KDF
+   function provided by TLS with a label of "quic ku".  The
+   corresponding key and IV are created from that secret as defined in
+   Section 5.1.  The header protection key is not updated.
+
+   For example, to update write keys with TLS 1.3, HKDF-Expand-Label is
+   used as:
+
+   secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku",
+                                    "", Hash.length)
+
+   The endpoint toggles the value of the Key Phase bit and uses the
+   updated key and IV to protect all subsequent packets.
+
+   An endpoint MUST NOT initiate a key update prior to having confirmed
+   the handshake (Section 4.1.2).  An endpoint MUST NOT initiate a
+   subsequent key update prior unless it has received an acknowledgment
+   for a packet that was sent protected with keys from the current key
+   phase.  This ensures that keys are available to both peers before
+   another key update can be initiated.  This can be implemented by
+   tracking the lowest packet number sent with each key phase, and the
+   highest acknowledged packet number in the 1-RTT space: once the
+   latter is higher than or equal to the former, another key update can
+   be initiated.
+
+   Note:  Keys of packets other than the 1-RTT packets are never
+      updated; their keys are derived solely from the TLS handshake
+      state.
+
+   The endpoint that initiates a key update also updates the keys that
+   it uses for receiving packets.  These keys will be needed to process
+   packets the peer sends after updating.
+
+   An endpoint SHOULD retain old keys so that packets sent by its peer
+   prior to receiving the key update can be processed.  Discarding old
+   keys too early can cause delayed packets to be discarded.  Discarding
+   packets will be interpreted as packet loss by the peer and could
+   adversely affect performance.
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 33]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+6.2.  Responding to a Key Update
+
+   A peer is permitted to initiate a key update after receiving an
+   acknowledgement of a packet in the current key phase.  An endpoint
+   detects a key update when processing a packet with a key phase that
+   differs from the value last used to protect the last packet it sent.
+   To process this packet, the endpoint uses the next packet protection
+   key and IV.  See Section 6.3 for considerations about generating
+   these keys.
+
+   If a packet is successfully processed using the next key and IV, then
+   the peer has initiated a key update.  The endpoint MUST update its
+   send keys to the corresponding key phase in response, as described in
+   Section 6.1.  Sending keys MUST be updated before sending an
+   acknowledgement for the packet that was received with updated keys.
+   By acknowledging the packet that triggered the key update in a packet
+   protected with the updated keys, the endpoint signals that the key
+   update is complete.
+
+   An endpoint can defer sending the packet or acknowledgement according
+   to its normal packet sending behaviour; it is not necessary to
+   immediately generate a packet in response to a key update.  The next
+   packet sent by the endpoint will use the updated keys.  The next
+   packet that contains an acknowledgement will cause the key update to
+   be completed.  If an endpoint detects a second update before it has
+   sent any packets with updated keys containing an acknowledgement for
+   the packet that initiated the key update, it indicates that its peer
+   has updated keys twice without awaiting confirmation.  An endpoint
+   MAY treat consecutive key updates as a connection error of type
+   KEY_UPDATE_ERROR.
+
+   An endpoint that receives an acknowledgement that is carried in a
+   packet protected with old keys where any acknowledged packet was
+   protected with newer keys MAY treat that as a connection error of
+   type KEY_UPDATE_ERROR.  This indicates that a peer has received and
+   acknowledged a packet that initiates a key update, but has not
+   updated keys in response.
+
+6.3.  Timing of Receive Key Generation
+
+   Endpoints responding to an apparent key update MUST NOT generate a
+   timing side-channel signal that might indicate that the Key Phase bit
+   was invalid (see Section 9.4).  Endpoints can use dummy packet
+   protection keys in place of discarded keys when key updates are not
+   yet permitted.  Using dummy keys will generate no variation in the
+   timing signal produced by attempting to remove packet protection, and
+   results in all packets with an invalid Key Phase bit being rejected.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 34]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   The process of creating new packet protection keys for receiving
+   packets could reveal that a key update has occurred.  An endpoint MAY
+   perform this process as part of packet processing, but this creates a
+   timing signal that can be used by an attacker to learn when key
+   updates happen and thus the value of the Key Phase bit in certain
+   packets.  Endpoints MAY instead defer the creation of the next set of
+   receive packet protection keys until some time after a key update
+   completes, up to three times the PTO; see Section 6.5.
+
+   Once generated, the next set of packet protection keys SHOULD be
+   retained, even if the packet that was received was subsequently
+   discarded.  Packets containing apparent key updates are easy to forge
+   and - while the process of key update does not require significant
+   effort - triggering this process could be used by an attacker for
+   DoS.
+
+   For this reason, endpoints MUST be able to retain two sets of packet
+   protection keys for receiving packets: the current and the next.
+   Retaining the previous keys in addition to these might improve
+   performance, but this is not essential.
+
+6.4.  Sending with Updated Keys
+
+   An endpoint always sends packets that are protected with the newest
+   keys.  Keys used for packet protection can be discarded immediately
+   after switching to newer keys.
+
+   Packets with higher packet numbers MUST be protected with either the
+   same or newer packet protection keys than packets with lower packet
+   numbers.  An endpoint that successfully removes protection with old
+   keys when newer keys were used for packets with lower packet numbers
+   MUST treat this as a connection error of type KEY_UPDATE_ERROR.
+
+6.5.  Receiving with Different Keys
+
+   For receiving packets during a key update, packets protected with
+   older keys might arrive if they were delayed by the network.
+   Retaining old packet protection keys allows these packets to be
+   successfully processed.
+
+   As packets protected with keys from the next key phase use the same
+   Key Phase value as those protected with keys from the previous key
+   phase, it can be necessary to distinguish between the two.  This can
+   be done using packet numbers.  A recovered packet number that is
+   lower than any packet number from the current key phase uses the
+   previous packet protection keys; a recovered packet number that is
+   higher than any packet number from the current key phase requires the
+   use of the next packet protection keys.
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 35]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Some care is necessary to ensure that any process for selecting
+   between previous, current, and next packet protection keys does not
+   expose a timing side channel that might reveal which keys were used
+   to remove packet protection.  See Section 9.5 for more information.
+
+   Alternatively, endpoints can retain only two sets of packet
+   protection keys, swapping previous for next after enough time has
+   passed to allow for reordering in the network.  In this case, the Key
+   Phase bit alone can be used to select keys.
+
+   An endpoint MAY allow a period of approximately the Probe Timeout
+   (PTO; see [QUIC-RECOVERY]) after a key update before it creates the
+   next set of packet protection keys.  These updated keys MAY replace
+   the previous keys at that time.  With the caveat that PTO is a
+   subjective measure - that is, a peer could have a different view of
+   the RTT - this time is expected to be long enough that any reordered
+   packets would be declared lost by a peer even if they were
+   acknowledged and short enough to allow for subsequent key updates.
+
+   Endpoints need to allow for the possibility that a peer might not be
+   able to decrypt packets that initiate a key update during the period
+   when it retains old keys.  Endpoints SHOULD wait three times the PTO
+   before initiating a key update after receiving an acknowledgment that
+   confirms that the previous key update was received.  Failing to allow
+   sufficient time could lead to packets being discarded.
+
+   An endpoint SHOULD retain old read keys for no more than three times
+   the PTO.  After this period, old read keys and their corresponding
+   secrets SHOULD be discarded.
+
+6.6.  Key Update Frequency
+
+   Key updates MUST be initiated before usage limits on packet
+   protection keys are exceeded.  For the cipher suites mentioned in
+   this document, the limits in Section 5.5 of [TLS13] apply.  Other
+   cipher suites MUST define usage limits in order to be used with QUIC.
+
+6.7.  Key Update Error Code
+
+   The KEY_UPDATE_ERROR error code (0xE) is used to signal errors
+   related to key updates.
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 36]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+7.  Security of Initial Messages
+
+   Initial packets are not protected with a secret key, so they are
+   subject to potential tampering by an attacker.  QUIC provides
+   protection against attackers that cannot read packets, but does not
+   attempt to provide additional protection against attacks where the
+   attacker can observe and inject packets.  Some forms of tampering -
+   such as modifying the TLS messages themselves - are detectable, but
+   some - such as modifying ACKs - are not.
+
+   For example, an attacker could inject a packet containing an ACK
+   frame that makes it appear that a packet had not been received or to
+   create a false impression of the state of the connection (e.g., by
+   modifying the ACK Delay).  Note that such a packet could cause a
+   legitimate packet to be dropped as a duplicate.  Implementations
+   SHOULD use caution in relying on any data which is contained in
+   Initial packets that is not otherwise authenticated.
+
+   It is also possible for the attacker to tamper with data that is
+   carried in Handshake packets, but because that tampering requires
+   modifying TLS handshake messages, that tampering will cause the TLS
+   handshake to fail.
+
+8.  QUIC-Specific Adjustments to the TLS Handshake
+
+   QUIC uses the TLS handshake for more than just negotiation of
+   cryptographic parameters.  The TLS handshake provides preliminary
+   values for QUIC transport parameters and allows a server to perform
+   return routability checks on clients.
+
+8.1.  Protocol Negotiation
+
+   QUIC requires that the cryptographic handshake provide authenticated
+   protocol negotiation.  TLS uses Application Layer Protocol
+   Negotiation (ALPN) [ALPN] to select an application protocol.  Unless
+   another mechanism is used for agreeing on an application protocol,
+   endpoints MUST use ALPN for this purpose.
+
+   When using ALPN, endpoints MUST immediately close a connection (see
+   Section 10.3 of [QUIC-TRANSPORT]) with a no_application_protocol TLS
+   alert (QUIC error code 0x178; see Section 4.10) if an application
+   protocol is not negotiated.  While [ALPN] only specifies that servers
+   use this alert, QUIC clients MUST use error 0x178 to terminate a
+   connection when ALPN negotiation fails.
+
+   An application protocol MAY restrict the QUIC versions that it can
+   operate over.  Servers MUST select an application protocol compatible
+   with the QUIC version that the client has selected.  The server MUST
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 37]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   treat the inability to select a compatible application protocol as a
+   connection error of type 0x178 (no_application_protocol).  Similarly,
+   a client MUST treat the selection of an incompatible application
+   protocol by a server as a connection error of type 0x178.
+
+8.2.  QUIC Transport Parameters Extension
+
+   QUIC transport parameters are carried in a TLS extension.  Different
+   versions of QUIC might define a different method for negotiating
+   transport configuration.
+
+   Including transport parameters in the TLS handshake provides
+   integrity protection for these values.
+
+      enum {
+         quic_transport_parameters(0xffa5), (65535)
+      } ExtensionType;
+
+   The extension_data field of the quic_transport_parameters extension
+   contains a value that is defined by the version of QUIC that is in
+   use.
+
+   The quic_transport_parameters extension is carried in the ClientHello
+   and the EncryptedExtensions messages during the handshake.  Endpoints
+   MUST send the quic_transport_parameters extension; endpoints that
+   receive ClientHello or EncryptedExtensions messages without the
+   quic_transport_parameters extension MUST close the connection with an
+   error of type 0x16d (equivalent to a fatal TLS missing_extension
+   alert, see Section 4.10).
+
+   While the transport parameters are technically available prior to the
+   completion of the handshake, they cannot be fully trusted until the
+   handshake completes, and reliance on them should be minimized.
+   However, any tampering with the parameters will cause the handshake
+   to fail.
+
+   Endpoints MUST NOT send this extension in a TLS connection that does
+   not use QUIC (such as the use of TLS with TCP defined in [TLS13]).  A
+   fatal unsupported_extension alert MUST be sent by an implementation
+   that supports this extension if the extension is received when the
+   transport is not QUIC.
+
+8.3.  Removing the EndOfEarlyData Message
+
+   The TLS EndOfEarlyData message is not used with QUIC.  QUIC does not
+   rely on this message to mark the end of 0-RTT data or to signal the
+   change to Handshake keys.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 38]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Clients MUST NOT send the EndOfEarlyData message.  A server MUST
+   treat receipt of a CRYPTO frame in a 0-RTT packet as a connection
+   error of type PROTOCOL_VIOLATION.
+
+   As a result, EndOfEarlyData does not appear in the TLS handshake
+   transcript.
+
+8.4.  Prohibit TLS Middlebox Compatibility Mode
+
+   Appendix D.4 of [TLS13] describes an alteration to the TLS 1.3
+   handshake as a workaround for bugs in some middleboxes.  The TLS 1.3
+   middlebox compatibility mode involves setting the legacy_session_id
+   field to a 32-byte value in the ClientHello and ServerHello, then
+   sending a change_cipher_spec record.  Both field and record carry no
+   semantic content and are ignored.
+
+   This mode has no use in QUIC as it only applies to middleboxes that
+   interfere with TLS over TCP.  QUIC also provides no means to carry a
+   change_cipher_spec record.  A client MUST NOT request the use of the
+   TLS 1.3 compatibility mode.  A server SHOULD treat the receipt of a
+   TLS ClientHello with a non-empty legacy_session_id field as a
+   connection error of type PROTOCOL_VIOLATION.
+
+9.  Security Considerations
+
+   All of the security considerations that apply to TLS also apply to
+   the use of TLS in QUIC.  Reading all of [TLS13] and its appendices is
+   the best way to gain an understanding of the security properties of
+   QUIC.
+
+   This section summarizes some of the more important security aspects
+   specific to the TLS integration, though there are many security-
+   relevant details in the remainder of the document.
+
+9.1.  Session Linkability
+
+   Use of TLS session tickets allows servers and possibly other entities
+   to correlate connections made by the same client; see Section 4.5 for
+   details.
+
+9.2.  Replay Attacks with 0-RTT
+
+   As described in Section 8 of [TLS13], use of TLS early data comes
+   with an exposure to replay attack.  The use of 0-RTT in QUIC is
+   similarly vulnerable to replay attack.
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 39]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Endpoints MUST implement and use the replay protections described in
+   [TLS13], however it is recognized that these protections are
+   imperfect.  Therefore, additional consideration of the risk of replay
+   is needed.
+
+   QUIC is not vulnerable to replay attack, except via the application
+   protocol information it might carry.  The management of QUIC protocol
+   state based on the frame types defined in [QUIC-TRANSPORT] is not
+   vulnerable to replay.  Processing of QUIC frames is idempotent and
+   cannot result in invalid connection states if frames are replayed,
+   reordered or lost.  QUIC connections do not produce effects that last
+   beyond the lifetime of the connection, except for those produced by
+   the application protocol that QUIC serves.
+
+   Note:  TLS session tickets and address validation tokens are used to
+      carry QUIC configuration information between connections.  These
+      MUST NOT be used to carry application semantics.  The potential
+      for reuse of these tokens means that they require stronger
+      protections against replay.
+
+   A server that accepts 0-RTT on a connection incurs a higher cost than
+   accepting a connection without 0-RTT.  This includes higher
+   processing and computation costs.  Servers need to consider the
+   probability of replay and all associated costs when accepting 0-RTT.
+
+   Ultimately, the responsibility for managing the risks of replay
+   attacks with 0-RTT lies with an application protocol.  An application
+   protocol that uses QUIC MUST describe how the protocol uses 0-RTT and
+   the measures that are employed to protect against replay attack.  An
+   analysis of replay risk needs to consider all QUIC protocol features
+   that carry application semantics.
+
+   Disabling 0-RTT entirely is the most effective defense against replay
+   attack.
+
+   QUIC extensions MUST describe how replay attacks affect their
+   operation, or prohibit their use in 0-RTT.  Application protocols
+   MUST either prohibit the use of extensions that carry application
+   semantics in 0-RTT or provide replay mitigation strategies.
+
+9.3.  Packet Reflection Attack Mitigation
+
+   A small ClientHello that results in a large block of handshake
+   messages from a server can be used in packet reflection attacks to
+   amplify the traffic generated by an attacker.
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 40]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   QUIC includes three defenses against this attack.  First, the packet
+   containing a ClientHello MUST be padded to a minimum size.  Second,
+   if responding to an unverified source address, the server is
+   forbidden to send more than three UDP datagrams in its first flight
+   (see Section 8.1 of [QUIC-TRANSPORT]).  Finally, because
+   acknowledgements of Handshake packets are authenticated, a blind
+   attacker cannot forge them.  Put together, these defenses limit the
+   level of amplification.
+
+9.4.  Header Protection Analysis
+
+   [NAN] analyzes authenticated encryption algorithms which provide
+   nonce privacy, referred to as "Hide Nonce" (HN) transforms.  The
+   general header protection construction in this document is one of
+   those algorithms (HN1).  Header protection uses the output of the
+   packet protection AEAD to derive "sample", and then encrypts the
+   header field using a pseudorandom function (PRF) as follows:
+
+   protected_field = field XOR PRF(hp_key, sample)
+
+   The header protection variants in this document use a pseudorandom
+   permutation (PRP) in place of a generic PRF.  However, since all PRPs
+   are also PRFs [IMC], these variants do not deviate from the HN1
+   construction.
+
+   As "hp_key" is distinct from the packet protection key, it follows
+   that header protection achieves AE2 security as defined in [NAN] and
+   therefore guarantees privacy of "field", the protected packet header.
+   Future header protection variants based on this construction MUST use
+   a PRF to ensure equivalent security guarantees.
+
+   Use of the same key and ciphertext sample more than once risks
+   compromising header protection.  Protecting two different headers
+   with the same key and ciphertext sample reveals the exclusive OR of
+   the protected fields.  Assuming that the AEAD acts as a PRF, if L
+   bits are sampled, the odds of two ciphertext samples being identical
+   approach 2^(-L/2), that is, the birthday bound.  For the algorithms
+   described in this document, that probability is one in 2^64.
+
+   To prevent an attacker from modifying packet headers, the header is
+   transitively authenticated using packet protection; the entire packet
+   header is part of the authenticated additional data.  Protected
+   fields that are falsified or modified can only be detected once the
+   packet protection is removed.
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 41]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+9.5.  Header Protection Timing Side-Channels
+
+   An attacker could guess values for packet numbers or Key Phase and
+   have an endpoint confirm guesses through timing side channels.
+   Similarly, guesses for the packet number length can be trialed and
+   exposed.  If the recipient of a packet discards packets with
+   duplicate packet numbers without attempting to remove packet
+   protection they could reveal through timing side-channels that the
+   packet number matches a received packet.  For authentication to be
+   free from side-channels, the entire process of header protection
+   removal, packet number recovery, and packet protection removal MUST
+   be applied together without timing and other side-channels.
+
+   For the sending of packets, construction and protection of packet
+   payloads and packet numbers MUST be free from side-channels that
+   would reveal the packet number or its encoded size.
+
+   During a key update, the time taken to generate new keys could reveal
+   through timing side-channels that a key update has occurred.
+   Alternatively, where an attacker injects packets this side-channel
+   could reveal the value of the Key Phase on injected packets.  After
+   receiving a key update, an endpoint SHOULD generate and save the next
+   set of receive packet protection keys, as described in Section 6.3.
+   By generating new keys before a key update is received, receipt of
+   packets will not create timing signals that leak the value of the Key
+   Phase.
+
+   This depends on not doing this key generation during packet
+   processing and it can require that endpoints maintain three sets of
+   packet protection keys for receiving: for the previous key phase, for
+   the current key phase, and for the next key phase.  Endpoints can
+   instead choose to defer generation of the next receive packet
+   protection keys until they discard old keys so that only two sets of
+   receive keys need to be retained at any point in time.
+
+9.6.  Key Diversity
+
+   In using TLS, the central key schedule of TLS is used.  As a result
+   of the TLS handshake messages being integrated into the calculation
+   of secrets, the inclusion of the QUIC transport parameters extension
+   ensures that handshake and 1-RTT keys are not the same as those that
+   might be produced by a server running TLS over TCP.  To avoid the
+   possibility of cross-protocol key synchronization, additional
+   measures are provided to improve key separation.
+
+   The QUIC packet protection keys and IVs are derived using a different
+   label than the equivalent keys in TLS.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 42]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   To preserve this separation, a new version of QUIC SHOULD define new
+   labels for key derivation for packet protection key and IV, plus the
+   header protection keys.  This version of QUIC uses the string "quic".
+   Other versions can use a version-specific label in place of that
+   string.
+
+   The initial secrets use a key that is specific to the negotiated QUIC
+   version.  New QUIC versions SHOULD define a new salt value used in
+   calculating initial secrets.
+
+10.  IANA Considerations
+
+   This document does not create any new IANA registries, but it
+   registers the values in the following registries:
+
+   *  TLS ExtensionType Values Registry [TLS-REGISTRIES] - IANA is to
+      register the quic_transport_parameters extension found in
+      Section 8.2.  The Recommended column is to be marked Yes.  The TLS
+      1.3 Column is to include CH and EE.
+
+   *  QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to
+      register the KEY_UPDATE_ERROR (0xE), as described in Section 6.7.
+
+11.  References
+
+11.1.  Normative References
+
+   [AEAD]     McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
+              <https://www.rfc-editor.org/info/rfc5116>.
+
+   [AES]      "Advanced encryption standard (AES)",
+              DOI 10.6028/nist.fips.197, National Institute of Standards
+              and Technology report, November 2001,
+              <https://doi.org/10.6028/nist.fips.197>.
+
+   [ALPN]     Friedl, S., Popov, A., Langley, A., and E. Stephan,
+              "Transport Layer Security (TLS) Application-Layer Protocol
+              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
+              July 2014, <https://www.rfc-editor.org/info/rfc7301>.
+
+   [CHACHA]   Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
+              Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
+              <https://www.rfc-editor.org/info/rfc8439>.
+
+   [QUIC-RECOVERY]
+              Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
+              and Congestion Control", Work in Progress, Internet-Draft,
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 43]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+              draft-ietf-quic-recovery-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-recovery-
+              latest>.
+
+   [QUIC-TRANSPORT]
+              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", Work in Progress,
+              Internet-Draft, draft-ietf-quic-transport-latest, 3 June
+              2020, <https://tools.ietf.org/html/draft-ietf-quic-
+              transport-latest>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [SHA]      Dang, Q., "Secure Hash Standard",
+              DOI 10.6028/nist.fips.180-4, National Institute of
+              Standards and Technology report, July 2015,
+              <https://doi.org/10.6028/nist.fips.180-4>.
+
+   [TLS-REGISTRIES]
+              Salowey, J. and S. Turner, "IANA Registry Updates for TLS
+              and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
+              <https://www.rfc-editor.org/info/rfc8447>.
+
+   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+11.2.  Informative References
+
+   [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated
+              Encryption Use in TLS", 8 March 2016,
+              <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
+
+   [HTTP2-TLS13]
+              Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
+              DOI 10.17487/RFC8740, February 2020,
+              <https://www.rfc-editor.org/info/rfc8740>.
+
+   [IMC]      Katz, J. and Y. Lindell, "Introduction to Modern
+              Cryptography, Second Edition", ISBN 978-1466570269, 6
+              November 2014.
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 44]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   [NAN]      Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
+              AEAD Revisited", DOI 10.1007/978-3-030-26948-7_9, Advances
+              in Cryptology - CRYPTO 2019 pp. 235-265, 2019,
+              <https://doi.org/10.1007/978-3-030-26948-7_9>.
+
+   [QUIC-HTTP]
+              Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
+              (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
+              quic-http-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-http-latest>.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
+              DOI 10.17487/RFC2818, May 2000,
+              <https://www.rfc-editor.org/info/rfc2818>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+Appendix A.  Sample Packet Protection
+
+   This section shows examples of packet protection so that
+   implementations can be verified incrementally.  Samples of Initial
+   packets from both client and server, plus a Retry packet are defined.
+   These packets use an 8-byte client-chosen Destination Connection ID
+   of 0x8394c8f03e515708.  Some intermediate values are included.  All
+   values are shown in hexadecimal.
+
+A.1.  Keys
+
+   The labels generated by the HKDF-Expand-Label function are:
+
+   client in:  00200f746c73313320636c69656e7420696e00
+
+   server in:  00200f746c7331332073657276657220696e00
+
+   quic key:  00100e746c7331332071756963206b657900
+
+   quic iv:  000c0d746c733133207175696320697600
+
+   quic hp:  00100d746c733133207175696320687000
+
+   The initial secret is common:
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 45]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   initial_secret = HKDF-Extract(initial_salt, cid)
+       = 524e374c6da8cf8b496f4bcb69678350
+         7aafee6198b202b4bc823ebf7514a423
+
+   The secrets for protecting client packets are:
+
+   client_initial_secret
+       = HKDF-Expand-Label(initial_secret, "client in", _, 32)
+       = fda3953aecc040e48b34e27ef87de3a6
+         098ecf0e38b7e032c5c57bcbd5975b84
+
+   key = HKDF-Expand-Label(client_initial_secret, "quic key", _, 16)
+       = af7fd7efebd21878ff66811248983694
+
+   iv  = HKDF-Expand-Label(client_initial_secret, "quic iv", _, 12)
+       = 8681359410a70bb9c92f0420
+
+   hp  = HKDF-Expand-Label(client_initial_secret, "quic hp", _, 16)
+       = a980b8b4fb7d9fbc13e814c23164253d
+
+   The secrets for protecting server packets are:
+
+   server_initial_secret
+       = HKDF-Expand-Label(initial_secret, "server in", _, 32)
+       = 554366b81912ff90be41f17e80222130
+         90ab17d8149179bcadf222f29ff2ddd5
+
+   key = HKDF-Expand-Label(server_initial_secret, "quic key", _, 16)
+       = 5d51da9ee897a21b2659ccc7e5bfa577
+
+   iv  = HKDF-Expand-Label(server_initial_secret, "quic iv", _, 12)
+       = 5e5ae651fd1e8495af13508b
+
+   hp  = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
+       = a8ed82e6664f865aedf6106943f95fb8
+
+A.2.  Client Initial
+
+   The client sends an Initial packet.  The unprotected payload of this
+   packet contains the following CRYPTO frame, plus enough PADDING
+   frames to make a 1162 byte payload:
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 46]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   060040c4010000c003036660261ff947 cea49cce6cfad687f457cf1b14531ba1
+   4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006
+   736572766572ff01000100000a001400 12001d00170018001901000101010201
+   03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f
+   2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403
+   05030603020308040805080604010501 060102010402050206020202002d0002
+   0101001c00024001
+
+   The unprotected header includes the connection ID and a 4 byte packet
+   number encoding for a packet number of 2:
+
+   c3ff00001c088394c8f03e5157080000449e00000002
+
+   Protecting the payload produces output that is sampled for header
+   protection.  Because the header uses a 4 byte packet number encoding,
+   the first 16 bytes of the protected payload is sampled, then applied
+   to the header:
+
+   sample = 535064a4268a0d9d7b1c9d250ae35516
+
+   mask = AES-ECB(hp, sample)[0..4]
+        = 833b343aaa
+
+   header[0] ^= mask[0] & 0x0f
+        = c0
+   header[18..21] ^= mask[1..4]
+        = 3b343aa8
+   header = c0ff00001c088394c8f03e5157080000449e3b343aa8
+
+   The resulting protected packet is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 47]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   c0ff00001c088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c
+   9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752
+   4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec
+   b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f
+   e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d
+   12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6
+   11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50
+   1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008
+   0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f
+   cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724
+   87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d
+   7f85181a366663387ddc20551807e007 673bd7e26bf9b29b5ab10a1ca87cbb7a
+   d97e99eb66959c2a9bc3cbde4707ff77 20b110fa95354674e395812e47a0ae53
+   b464dcb2d1f345df360dc227270c7506 76f6724eb479f0d2fbb6124429990457
+   ac6c9167f40aab739998f38b9eccb24f d47c8410131bf65a52af841275d5b3d1
+   880b197df2b5dea3e6de56ebce3ffb6e 9277a82082f8d9677a6767089b671ebd
+   244c214f0bde95c2beb02cd1172d58bd f39dce56ff68eb35ab39b49b4eac7c81
+   5ea60451d6e6ab82119118df02a58684 4a9ffe162ba006d0669ef57668cab38b
+   62f71a2523a084852cd1d079b3658dc2 f3e87949b550bab3e177cfc49ed190df
+   f0630e43077c30de8f6ae081537f1e83 da537da980afa668e7b7fb25301cf741
+   524be3c49884b42821f17552fbd1931a 813017b6b6590a41ea18b6ba49cd48a4
+   40bd9a3346a7623fb4ba34a3ee571e3c 731f35a7a3cf25b551a680fa68763507
+   b7fde3aaf023c50b9d22da6876ba337e b5e9dd9ec3daf970242b6c5aab3aa4b2
+   96ad8b9f6832f686ef70fa938b31b4e5 ddd7364442d3ea72e73d668fb0937796
+   f462923a81a47e1cee7426ff6d922126 9b5a62ec03d6ec94d12606cb485560ba
+   b574816009e96504249385bb61a819be 04f62c2066214d8360a2022beb316240
+   b6c7d78bbe56c13082e0ca272661210a bf020bf3b5783f1426436cf9ff418405
+   93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9
+   44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14
+   a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5
+   b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6
+   6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e
+   c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e
+   eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f
+   cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da
+   acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc
+   13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d
+   ea5388b911e76d2856d68cf6cf394185
+
+A.3.  Server Initial
+
+   The server sends the following payload in response, including an ACK
+   frame, a CRYPTO frame, and no PADDING frames:
+
+   0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988
+   cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d
+   89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002
+   0304
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 48]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   The header from the server includes a new connection ID and a 2-byte
+   packet number encoding for a packet number of 1:
+
+   c1ff00001c0008f067a5502a4262b50040740001
+
+   As a result, after protection, the header protection sample is taken
+   starting from the third protected octet:
+
+   sample = 7002596f99ae67abf65a5852f54f58c3
+   mask   = 38168a0c25
+   header = c9ff00001c0008f067a5502a4262b5004074168b
+
+   The final protected packet is then:
+
+   c9ff00001c0008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a
+   5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493
+   537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3
+   cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92bda5b23c81034ab74f54c
+   b1bd72951256
+
+A.4.  Retry
+
+   This shows a Retry packet that might be sent in response to the
+   Initial packet in Appendix A.2.  The integrity check includes the
+   client-chosen connection ID value of 0x8394c8f03e515708, but that
+   value is not included in the final Retry packet:
+
+   ffff00001c0008f067a5502a4262b574 6f6b656ef71a5f12afe3ecf8001a920e
+   6fdf1d63
+
+Appendix B.  Change Log
+
+      *RFC Editor's Note:* Please remove this section prior to
+      publication of a final version of this document.
+
+   Issue and pull request numbers are listed with a leading octothorp.
+
+B.1.  Since draft-ietf-quic-tls-27
+
+   *  Allowed CONNECTION_CLOSE in any packet number space, with
+      restrictions on use of the application-specific variant (#3430,
+      #3435, #3440)
+
+   *  Prohibit the use of the compatibility mode from TLS 1.3 (#3594,
+      #3595)
+
+B.2.  Since draft-ietf-quic-tls-26
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 49]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   *  No changes
+
+B.3.  Since draft-ietf-quic-tls-25
+
+   *  No changes
+
+B.4.  Since draft-ietf-quic-tls-24
+
+   *  Rewrite key updates (#3050)
+
+      -  Allow but don't recommend deferring key updates (#2792, #3263)
+
+      -  More completely define received behavior (#2791)
+
+      -  Define the label used with HKDF-Expand-Label (#3054)
+
+B.5.  Since draft-ietf-quic-tls-23
+
+   *  Key update text update (#3050):
+
+      -  Recommend constant-time key replacement (#2792)
+
+      -  Provide explicit labels for key update key derivation (#3054)
+
+   *  Allow first Initial from a client to span multiple packets (#2928,
+      #3045)
+
+   *  PING can be sent at any encryption level (#3034, #3035)
+
+B.6.  Since draft-ietf-quic-tls-22
+
+   *  Update the salt used for Initial secrets (#2887, #2980)
+
+B.7.  Since draft-ietf-quic-tls-21
+
+   *  No changes
+
+B.8.  Since draft-ietf-quic-tls-20
+
+   *  Mandate the use of the QUIC transport parameters extension (#2528,
+      #2560)
+
+   *  Define handshake completion and confirmation; define clearer rules
+      when it encryption keys should be discarded (#2214, #2267, #2673)
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 50]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+B.9.  Since draft-ietf-quic-tls-18
+
+   *  Increased the set of permissible frames in 0-RTT (#2344, #2355)
+
+   *  Transport parameter extension is mandatory (#2528, #2560)
+
+B.10.  Since draft-ietf-quic-tls-17
+
+   *  Endpoints discard initial keys as soon as handshake keys are
+      available (#1951, #2045)
+
+   *  Use of ALPN or equivalent is mandatory (#2263, #2284)
+
+B.11.  Since draft-ietf-quic-tls-14
+
+   *  Update the salt used for Initial secrets (#1970)
+
+   *  Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
+
+   *  Change header protection
+
+      -  Sample from a fixed offset (#1575, #2030)
+
+      -  Cover part of the first byte, including the key phase (#1322,
+         #2006)
+
+   *  TLS provides an AEAD and KDF function (#2046)
+
+      -  Clarify that the TLS KDF is used with TLS (#1997)
+
+      -  Change the labels for calculation of QUIC keys (#1845, #1971,
+         #1991)
+
+   *  Initial keys are discarded once Handshake keys are available
+      (#1951, #2045)
+
+B.12.  Since draft-ietf-quic-tls-13
+
+   *  Updated to TLS 1.3 final (#1660)
+
+B.13.  Since draft-ietf-quic-tls-12
+
+   *  Changes to integration of the TLS handshake (#829, #1018, #1094,
+      #1165, #1190, #1233, #1242, #1252, #1450)
+
+      -  The cryptographic handshake uses CRYPTO frames, not stream 0
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 51]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+      -  QUIC packet protection is used in place of TLS record
+         protection
+
+      -  Separate QUIC packet number spaces are used for the handshake
+
+      -  Changed Retry to be independent of the cryptographic handshake
+
+      -  Limit the use of HelloRetryRequest to address TLS needs (like
+         key shares)
+
+   *  Changed codepoint of TLS extension (#1395, #1402)
+
+B.14.  Since draft-ietf-quic-tls-11
+
+   *  Encrypted packet numbers.
+
+B.15.  Since draft-ietf-quic-tls-10
+
+   *  No significant changes.
+
+B.16.  Since draft-ietf-quic-tls-09
+
+   *  Cleaned up key schedule and updated the salt used for handshake
+      packet protection (#1077)
+
+B.17.  Since draft-ietf-quic-tls-08
+
+   *  Specify value for max_early_data_size to enable 0-RTT (#942)
+
+   *  Update key derivation function (#1003, #1004)
+
+B.18.  Since draft-ietf-quic-tls-07
+
+   *  Handshake errors can be reported with CONNECTION_CLOSE (#608,
+      #891)
+
+B.19.  Since draft-ietf-quic-tls-05
+
+   No significant changes.
+
+B.20.  Since draft-ietf-quic-tls-04
+
+   *  Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
+
+B.21.  Since draft-ietf-quic-tls-03
+
+   No significant changes.
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 52]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+B.22.  Since draft-ietf-quic-tls-02
+
+   *  Updates to match changes in transport draft
+
+B.23.  Since draft-ietf-quic-tls-01
+
+   *  Use TLS alerts to signal TLS errors (#272, #374)
+
+   *  Require ClientHello to fit in a single packet (#338)
+
+   *  The second client handshake flight is now sent in the clear (#262,
+      #337)
+
+   *  The QUIC header is included as AEAD Associated Data (#226, #243,
+      #302)
+
+   *  Add interface necessary for client address validation (#275)
+
+   *  Define peer authentication (#140)
+
+   *  Require at least TLS 1.3 (#138)
+
+   *  Define transport parameters as a TLS extension (#122)
+
+   *  Define handling for protected packets before the handshake
+      completes (#39)
+
+   *  Decouple QUIC version and ALPN (#12)
+
+B.24.  Since draft-ietf-quic-tls-00
+
+   *  Changed bit used to signal key phase
+
+   *  Updated key phase markings during the handshake
+
+   *  Added TLS interface requirements section
+
+   *  Moved to use of TLS exporters for key derivation
+
+   *  Moved TLS error code definitions into this document
+
+B.25.  Since draft-thomson-quic-tls-01
+
+   *  Adopted as base for draft-ietf-quic-tls
+
+   *  Updated authors/editors list
+
+   *  Added status note
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 53]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+Contributors
+
+   The IETF QUIC Working Group received an enormous amount of support
+   from many people.  The following people provided substantive
+   contributions to this document:
+
+   *  Adam Langley
+
+   *  Alessandro Ghedini
+
+   *  Christian Huitema
+
+   *  Christopher Wood
+
+   *  David Schinazi
+
+   *  Dragana Damjanovic
+
+   *  Eric Rescorla
+
+   *  Ian Swett
+
+   *  Jana Iyengar
+
+   *  奥 一穂 (Kazuho Oku)
+
+   *  Marten Seemann
+
+   *  Martin Duke
+
+   *  Mike Bishop
+
+   *  Mikkel Fahnøe Jørgensen
+
+   *  Nick Banks
+
+   *  Nick Harper
+
+   *  Roberto Peon
+
+   *  Rui Paulo
+
+   *  Ryan Hamilton
+
+   *  Victor Vasiliev
+
+Authors' Addresses
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 54]
+
+Internet-Draft          Using TLS to Secure QUIC               June 2020
+
+
+   Martin Thomson (editor)
+   Mozilla
+
+   Email: mt@lowentropy.net
+
+
+   Sean Turner (editor)
+   sn3rd
+
+   Email: sean@sn3rd.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner         Expires 5 December 2020               [Page 55]
diff --git a/jri/mustnot/draft-ietf-quic-transport.html b/jri/mustnot/draft-ietf-quic-transport.html
new file mode 100644
index 0000000000..fefb160a58
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-transport.html
@@ -0,0 +1,10782 @@
+<!DOCTYPE html>
+<html lang="en" class="Internet-Draft">
+<head>
+<meta charset="utf-8">
+<meta content="Common,Latin" name="scripts">
+<meta content="initial-scale=1.0" name="viewport">
+<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
+<meta content="Jana Iyengar" name="author">
+<meta content="Martin Thomson" name="author">
+<meta content="
+       This document defines the core of the QUIC transport protocol.  Accompanying
+documents describe QUIC's loss detection and congestion control and the use of
+TLS for key negotiation. 
+    " name="description">
+<meta content="xml2rfc 2.45.2" name="generator">
+<meta content="draft-ietf-quic-transport-latest" name="ietf.draft">
+<link href="draft-ietf-quic-transport.xml" rel="alternate" type="application/rfc+xml">
+<link href="#copyright" rel="license">
+<style type="text/css">@import url('https://martinthomson.github.io/i-d-template/fonts.css');
+
+html {
+  --background-color: #fff;
+  --text-color: #222;
+  --title-color: #191919;
+  --link-color: #2a6496;
+  --highlight-color: #f9f9f9;
+  --line-color: #eee;
+  --small-font-size: 14.5px;
+}
+body {
+  max-width: 600px;
+  margin: 75px auto;
+  padding: 0 5px;
+  color: var(--text-color);
+  background-color: var(--background-color);
+  font: 16px/22px "Lora", serif;
+  scroll-behavior: smooth;
+}
+
+.ears {
+  display: none;
+}
+
+/* headings */
+#title, h1, h2, h3, h4, h5, h6 {
+  font-family: "Cabin Condensed", sans-serif;
+  font-weight: 600;
+  margin: 0.8em 0 0.3em;
+  font-size-adjust: 0.5;
+  color: var(--title-color);
+}
+#title {
+  padding: 1em 0 0.2em;
+  font-size: 32px;
+  line-height: 40px;
+  clear: both;
+}
+h1, h2, h3 {
+  font-size: 22px;
+  line-height: 26px;
+}
+h4, h5, h6 {
+  font-size: 18px;
+  line-height: 22px;
+}
+
+/* general structure */
+.author {
+  padding-bottom: 0.3em;
+}
+#abstract+p, #abstract+p code, #abstract+p samp, #abstract+p tt {
+  font-size: 18px;
+  line-height: 24px;
+}
+p {
+  padding: 0;
+  margin: 0.5em 0;
+  text-align: left;
+}
+div, span {
+  position: relative;
+}
+div {
+  margin: 0;
+}
+.alignRight.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignRight.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignRight {
+  margin: 1em 0;
+}
+.alignRight > *:first-child {
+  border: none;
+  margin: 0;
+  float: right;
+  clear: both;
+}
+.alignRight > *:nth-child(2) {
+  clear: both;
+  display: block;
+  border: none;
+}
+svg {
+  display: block;
+}
+.alignCenter.art-text {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  padding: 0.5em 1em 0;
+  margin-bottom: 0.5em;
+}
+.alignCenter.art-text pre {
+  padding: 0;
+  width: auto;
+}
+.alignCenter {
+  margin: 1em 0;
+}
+.alignCenter > *:first-child {
+  border: none;
+  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
+     support flexbox yet.
+  */
+  display: table;
+  margin: 0 auto;
+}
+
+/* lists */
+ol, ul {
+  padding: 0;
+  margin: 0 0 1em 2em;
+}
+ol ol, ul ul, ol ul, ul ol {
+  margin-left: 1em;
+}
+li {
+  margin: 0 0 0.25em 0;
+}
+.ulCompact li {
+  margin: 0;
+}
+ul.empty, .ulEmpty {
+  list-style-type: none;
+}
+ul.empty li, .ulEmpty li {
+  margin-top: 0.5em;
+}
+ul.compact, .ulCompact,
+ol.compact, .olCompact {
+  line-height: 100%;
+  margin: 0 0 0 2em;
+}
+
+/* definition lists */
+dl {
+}
+dl > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl > dd {
+  margin-bottom: .8em;
+  min-height: 1.3em;
+}
+dl.compact > dd, .dlCompact > dd {
+  margin-bottom: 0em;
+}
+dl > dd > dl {
+  margin-top: 0.5em;
+  margin-bottom: 0em;
+}
+dd.break {
+  display: none;
+}
+
+/* links */
+a, a[href].selfRef:hover {
+  text-decoration: none;
+}
+a[href].selfRef {
+  color: var(--text-color);
+}
+a[href] {
+  color: var(--link-color);
+}
+a[href]:hover {
+  text-decoration: underline;
+}
+a[href].selfRef:hover {
+  background-color: var(--highlight-color);
+}
+a.xref {
+  white-space: nowrap;
+}
+
+/* Figures */
+tt, code, pre {
+  background-color: var(--highlight-color);
+  font: 14px/22px 'Oxygen Mono', monospace;
+}
+pre {
+  border: 1px solid var(--line-color);
+  font-size: 13.5px;
+  line-height: 16px;
+  letter-spacing: -0.2px;
+  margin: 5px;
+  padding: 5px;
+}
+img {
+  max-width: 100%;
+}
+figure {
+  margin: 0.5em 0;
+}
+figure blockquote {
+  margin: 0.8em 0.4em 0.4em;
+}
+figcaption, caption {
+  font-style: italic;
+  margin: 0.5em 1.5em;
+  text-align: left;
+}
+@media screen {
+  pre {
+    display: inline-block;
+    overflow-x: auto;
+    max-width: 100%;
+    width: calc(100% - 22px - 1em);
+  }
+  figure pre {
+    display: block;
+    width: calc(100% - 25px);
+  }
+  pre + .pilcrow {
+    display: inline-block;
+    vertical-align: text-bottom;
+    padding-bottom: 8px;
+  }
+  table {
+    display: inline-block;
+    overflow-x: auto;
+  }
+}
+
+/* aside, blockquote */
+aside, blockquote {
+  margin-left: 0;
+  padding: 0 2em;
+  font-style: italic;
+}
+blockquote {
+  background-color: var(--highlight-color);
+  border: 1px solid var(--line-color);
+  border-radius: 3px;
+  margin: 1em 0;
+}
+cite {
+  display: block;
+  text-align: right;
+  font-style: italic;
+}
+
+/* tables */
+table {
+  width: 100%;
+  margin: 0 0 1em;
+  border-collapse: collapse;
+}
+thead, tbody {
+  border: 1px solid var(--line-color);
+}
+th, td {
+  text-align: left;
+  vertical-align: top;
+  padding: 5px 10px;
+}
+th {
+  text-align: left;
+  background-color: #eee;
+}
+tr:nth-child(2n) > td {
+  background-color: var(--background-color);
+}
+tr:nth-child(2n+1) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n) > td {
+  background-color: var(--highlight-color);
+}
+thead+tbody > tr:nth-child(2n+1) > td {
+  background-color: var(--background-color);
+}
+table caption {
+  margin: 0;
+  padding: 3px 1em;
+}
+table p {
+  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
+     be allowed within tables more generally, it would be far better to select on a class. */
+  margin: 0;
+}
+
+/* pilcrow */
+a.pilcrow {
+  margin-left: 3px;
+  visibility: hidden;
+  user-select: none;
+}
+a.pilcrow[href] { color: #ddd; }
+a.pilcrow[href]:hover { text-decoration: none; }
+@media screen {
+  :hover > a.pilcrow {
+    visibility: visible;
+  }
+  a.pilcrow:hover {
+    background-color: transparent;
+  }
+}
+
+/* misc */
+hr {
+  border: 0;
+  border-top: 1px solid var(--line-color);
+}
+.bcp14 {
+  font-variant: small-caps;
+}
+
+.role {
+  font-variant: all-small-caps;
+}
+
+/* info block */
+#identifiers {
+  margin: 0;
+  font-size: var(--small-font-size);
+  line-height: 18px;
+  --identifier-width: 8em;
+}
+#identifiers dt {
+  width: var(--identifier-width);
+  margin: 0;
+  clear: left;
+  float: left;
+  text-align: right;
+}
+#identifiers dd {
+  margin: 0 0 0 calc(1em + var(--identifier-width));
+  min-width: 5em;
+}
+#identifiers .authors .author {
+  display: inline-block;
+  margin-right: 1.5em;
+}
+#identifiers .authors .org {
+  font-style: italic;
+}
+
+/* The prepared/rendered info at the very bottom of the page */
+.docInfo {
+  color: #999;
+  font-size: 0.9em;
+  font-style: italic;
+  margin-top: 2em;
+}
+.docInfo .prepared {
+  float: left;
+}
+.docInfo .prepared {
+  float: right;
+}
+
+/* table of contents */
+#toc {
+  padding: 0.75em 0 2em 0;
+  margin-bottom: 1em;
+}
+#toc nav ul {
+  margin: 0 0.5em 0 0;
+  padding: 0;
+  list-style: none;
+}
+#toc nav li {
+  line-height: 1.3em;
+  margin: 0.75em 0;
+  padding-left: 1.2em;
+  text-indent: -1.2em;
+}
+#toc a.xref {
+  white-space: normal;
+}
+/* references */
+.references dt {
+  text-align: right;
+  font-weight: bold;
+  min-width: 7em;
+}
+.references dd {
+  margin-left: 8em;
+  overflow: auto;
+}
+
+.refInstance {
+  margin-bottom: 1.25em;
+}
+
+.references .ascii {
+  margin-bottom: 0.25em;
+}
+
+/* index */
+.index ul {
+  margin: 0 0 0 1em;
+  padding: 0;
+  list-style: none;
+}
+.index ul ul {
+  margin: 0;
+}
+.index li {
+  margin: 0;
+  text-indent: -2em;
+  padding-left: 2em;
+  padding-bottom: 5px;
+}
+.indexIndex {
+  margin: 0.5em 0 1em;
+}
+.index a {
+  font-weight: 700;
+}
+/* make the index two-column on all but the smallest screens */
+@media (min-width: 500px) {
+  .index ul {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  .index ul ul {
+    column-count: 1;
+    column-gap: 0;
+  }
+}
+
+/* authors */
+address.vcard {
+  font-style: normal;
+  margin: 1em 0;
+}
+address.vcard .nameRole {
+  font-weight: 700;
+  margin-left: 0;
+}
+address.vcard .label {
+  margin: 0.5em 0;
+}
+address.vcard .type {
+  display: none;
+}
+.alternative-contact {
+  margin: 1.5em 0 1em;
+}
+hr.addr {
+  border-top: 1px dashed;
+  margin: 0;
+  color: #ddd;
+  max-width: calc(100% - 16px);
+}
+@media (min-width: 500px) {
+  #authors-addresses > section {
+    column-count: 2;
+    column-gap: 20px;
+  }
+  #authors-addresses > section > h2 {
+    column-span: all;
+  }
+  /* hack for break-inside: avoid-column */
+  #authors-addresses address {
+    display: inline-block;
+    break-inside: avoid-column;
+  }
+}
+
+.rfcEditorRemove p:first-of-type {
+  font-style: italic;
+}
+.cref {
+  background-color: rgba(249, 232, 105, 0.3);
+  padding: 2px 4px;
+}
+.crefSource {
+  font-style: italic;
+}
+/* alternative layout for smaller screens */
+@media screen and (max-width: 929px) {
+  #toc {
+    position: fixed;
+    z-index: 2;
+    top: 0;
+    right: 0;
+    padding: 0;
+    margin: 0;
+    border-bottom: 1px solid #ccc;
+    opacity: 0.6;
+  }
+  #toc.active {
+      opacity: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 2px 0 2px 6px;
+    padding-right: 1em;
+    font-size: 18px;
+    line-height: 24px;
+    min-width: 190px;
+    text-align: right;
+    background-color: #444;
+    color: white;
+    cursor: pointer;
+  }
+  #toc h2::before { /* css hamburger */
+    float: right;
+    position: relative;
+    width: 1em;
+    height: 1px;
+    left: -164px;
+    margin: 8px 0 0 0;
+    background: white none repeat scroll 0 0;
+    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
+    content: "";
+  }
+  #toc nav {
+    display: none;
+    background-color: var(--background-color);
+    padding: 0.5em 1em 1em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    height: calc(100vh - 48px);
+    border-left: 1px solid #ddd;
+  }
+  #toc.active nav {
+    display: block;
+  }
+  /* Make the collapsed ToC header render white on gray also when it's a link */
+  #toc h2 a,
+  #toc h2 a:link,
+  #toc h2 a:focus,
+  #toc h2 a:hover,
+  #toc a.toplink,
+  #toc a.toplink:hover {
+    color: white;
+    background-color: #444;
+    text-decoration: none;
+  }
+  #toc a.toplink {
+    margin-top: 2px;
+  }
+}
+
+/* alternative layout for wide screens */
+@media screen and (min-width: 930px) {
+  body {
+    padding-right: 360px;
+    padding-right: calc(min(180px + 20%, 500px));
+  }
+  #toc {
+    position: fixed;
+    bottom: 0;
+    right: 0;
+    right: calc(50vw - 480px);
+    width: 312px;
+    margin: 0;
+    padding: 0;
+    z-index: 1;
+  }
+  #toc h2 {
+    margin: 0;
+    padding: 0.25em 1em 1em 0;
+  }
+  #toc nav {
+    display: block;
+    height: calc(90vh - 84px);
+    bottom: 0;
+    padding: 0.5em 0 2em;
+    overflow: auto;
+    overscroll-behavior: contain;
+    scrollbar-width: thin;
+  }
+  #toc nav > ul  {
+    margin-bottom: 2em;
+  }
+  #toc ul {
+    margin: 0 0 0 4px;
+    font-size: var(--small-font-size);
+  }
+  #toc ul p, #toc ul li {
+    margin: 2px 0;
+    line-height: 22px;
+  }
+  img { /* future proofing */
+    max-width: 100%;
+    height: auto;
+  }
+}
+
+/* pagination */
+@media print {
+  body {
+    width: 100%;
+  }
+  p {
+    orphans: 3;
+    widows: 3;
+  }
+  #n-copyright-notice {
+    border-bottom: none;
+  }
+  #toc, #n-introduction {
+    page-break-before: always;
+  }
+  #toc {
+    border-top: none;
+    padding-top: 0;
+  }
+  figure, pre {
+    page-break-inside: avoid;
+  }
+  figure {
+    overflow: scroll;
+  }
+  h1, h2, h3, h4, h5, h6 {
+    page-break-after: avoid;
+  }
+  h2+*, h3+*, h4+*, h5+*, h6+* {
+    page-break-before: avoid;
+  }
+  pre {
+    white-space: pre-wrap;
+    word-wrap: break-word;
+    font-size: 10pt;
+  }
+  table {
+    border: 1px solid #ddd;
+  }
+  td {
+    border-top: 1px solid #ddd;
+  }
+}
+
+@page :first {
+  padding-top: 0;
+  @top-left {
+    content: normal;
+    border: none;
+  }
+  @top-center {
+    content: normal;
+    border: none;
+  }
+  @top-right {
+    content: normal;
+    border: none;
+  }
+}
+
+@page {
+  size: A4;
+  margin-bottom: 45mm;
+  padding-top: 20px;
+}
+
+/* Changes introduced to fix issues found during implementation */
+
+/* Separate body from document info even without intervening H1 */
+section {
+  clear: both;
+}
+
+/* Top align author divs, to avoid names without organization dropping level with org names */
+.author {
+  vertical-align: top;
+}
+
+/* Style section numbers with more space between number and title */
+.section-number {
+  padding-right: 0.5em;
+}
+
+/* Add styling for a link in the ToC that points to the top of the document */
+a.toplink {
+  float: right;
+  margin: 8px 0.5em 0;
+}
+
+/* Fix the dl styling to match the RFC 7992 attributes */
+dl > dt,
+dl.dlParallel > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl.dlNewline > dt {
+  float: none;
+}
+
+/* Provide styling for table cell text alignment */
+table .text-left, table .text-left {
+  text-align: left;
+}
+table .text-center, table .text-center {
+  text-align: center;
+}
+table .text-right, table .text-right {
+  text-align: right;
+}
+
+/* Make the alternative author contact information look less like just another
+   author, and group it closer with the primary author contact information */
+.alternative-contact {
+  margin: 0.5em 0 0.25em 0;
+}
+address .non-ascii {
+  margin: 0 0 0 2em;
+}
+
+/* With it being possible to set tables with alignment
+  left, center, and right, { width: 100%; } does not make sense */
+table {
+  width: auto;
+}
+
+/* Avoid reference text that sits in a block with very wide left margin,
+   because of a long floating dt label.*/
+.references dd {
+  overflow: visible;
+}
+
+/* Control caption placement */
+caption {
+  caption-side: bottom;
+}
+
+/* Limit the width of the author address vcard, so names in right-to-left
+   script don't end up on the other side of the page. */
+
+address.vcard {
+  max-width: 20em;
+  margin-right: auto;
+}
+
+/* For address alignment dependent on LTR or RTL scripts */
+address div.left {
+  text-align: left;
+}
+address div.right {
+  text-align: right;
+}
+
+/* Provide table alignment support.  We can't use the alignX classes above
+   since they do unwanted things with caption and other styling. */
+table.right {
+ margin-left: auto;
+ margin-right: 0;
+}
+table.center {
+ margin-left: auto;
+ margin-right: auto;
+}
+table.left {
+ margin-left: 0;
+ margin-right: auto;
+}
+
+/* Give the table caption label the same styling as the figcaption */
+
+@media print {
+  .toplink {
+    display: none;
+  }
+
+  /* avoid overwriting the top border line with the ToC header */
+  #toc {
+    padding-top: 1px;
+  }
+
+  /* Avoid page breaks inside dl and author address entries */
+  dd {
+    page-break-before: avoid;
+  }
+  .vcard {
+    page-break-inside: avoid;
+  }
+
+}
+/* Tweak the bcp14 keyword presentation */
+.bcp14 {
+  font-variant: small-caps;
+  font-weight: bold;
+  font-size: 0.9em;
+}
+</style>
+<link href="rfc-local.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<table class="ears">
+<thead><tr>
+<td class="left">Internet-Draft</td>
+<td class="center">QUIC Transport Protocol</td>
+<td class="right">June 2020</td>
+</tr></thead>
+<tfoot><tr>
+<td class="left">Iyengar &amp; Thomson</td>
+<td class="center">Expires 5 December 2020</td>
+<td class="right">[Page]</td>
+</tr></tfoot>
+</table>
+<div id="external-metadata" class="document-information"></div>
+<div id="internal-metadata" class="document-information">
+<dl id="identifiers">
+<dt class="label-workgroup">Workgroup:</dt>
+<dd class="workgroup">QUIC</dd>
+<dt class="label-internet-draft">Internet-Draft:</dt>
+<dd class="internet-draft">draft-ietf-quic-transport-latest</dd>
+<dt class="label-published">Published:</dt>
+<dd class="published">
+<time datetime="2020-06-03" class="published">3 June 2020</time>
+    </dd>
+<dt class="label-intended-status">Intended Status:</dt>
+<dd class="intended-status">Standards Track</dd>
+<dt class="label-expires">Expires:</dt>
+<dd class="expires"><time datetime="2020-12-05">5 December 2020</time></dd>
+<dt class="label-authors">Authors:</dt>
+<dd class="authors">
+<div class="author">
+      <div class="author-name">J. Iyengar, <span class="editor">Ed.</span>
+</div>
+<div class="org">Fastly</div>
+</div>
+<div class="author">
+      <div class="author-name">M. Thomson, <span class="editor">Ed.</span>
+</div>
+<div class="org">Mozilla</div>
+</div>
+</dd>
+</dl>
+</div>
+<h1 id="title">QUIC: A UDP-Based Multiplexed and Secure Transport</h1>
+<section id="section-abstract">
+      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
+<p id="section-abstract-1">This document defines the core of the QUIC transport protocol.  Accompanying
+documents describe QUIC's loss detection and congestion control and the use of
+TLS for key negotiation.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.1">
+      <h2 id="name-note-to-readers">
+<a href="#name-note-to-readers" class="section-name selfRef">Note to Readers</a>
+      </h2>
+<p id="section-note.1-1">Discussion of this draft takes place on the QUIC working group mailing list
+(<a href="mailto:quic@ietf.org">quic@ietf.org</a>), which is archived at
+<span><a href="https://mailarchive.ietf.org/arch/search/?email_list=quic">https://mailarchive.ietf.org/arch/search/?email_list=quic</a></span><a href="#section-note.1-1" class="pilcrow">¶</a></p>
+<p id="section-note.1-2">Working Group information can be found at <span><a href="https://github.com/quicwg">https://github.com/quicwg</a></span>; source
+code and issues list for this draft can be found at
+<span><a href="https://github.com/quicwg/base-drafts/labels/-transport">https://github.com/quicwg/base-drafts/labels/-transport</a></span>.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
+</section>
+<div id="status-of-memo">
+<section id="section-boilerplate.1">
+        <h2 id="name-status-of-this-memo">
+<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
+        </h2>
+<p id="section-boilerplate.1-1">
+        This Internet-Draft is submitted in full conformance with the
+        provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-2">
+        Internet-Drafts are working documents of the Internet Engineering Task
+        Force (IETF). Note that other groups may also distribute working
+        documents as Internet-Drafts. The list of current Internet-Drafts is
+        at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-3">
+        Internet-Drafts are draft documents valid for a maximum of six months
+        and may be updated, replaced, or obsoleted by other documents at any
+        time. It is inappropriate to use Internet-Drafts as reference
+        material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-4">
+        This Internet-Draft will expire on 5 December 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="copyright">
+<section id="section-boilerplate.2">
+        <h2 id="name-copyright-notice">
+<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
+        </h2>
+<p id="section-boilerplate.2-1">
+            Copyright (c) 2020 IETF Trust and the persons identified as the
+            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.2-2">
+            This document is subject to BCP 78 and the IETF Trust's Legal
+            Provisions Relating to IETF Documents
+            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
+            publication of this document. Please review these documents
+            carefully, as they describe your rights and restrictions with
+            respect to this document. Code Components extracted from this
+            document must include Simplified BSD License text as described in
+            Section 4.e of the Trust Legal Provisions and are provided without
+            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="toc">
+<section id="section-toc.1">
+        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
+<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
+        </h2>
+<nav class="toc"><ul class="ulEmpty compact toc">
+<li class="ulEmpty compact toc" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.1.2.1">
+                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-document-structure" class="xref">Document Structure</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.1.2.2">
+                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-terms-and-definitions" class="xref">Terms and Definitions</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.1.2.3">
+                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-notational-conventions" class="xref">Notational Conventions</a><a href="#section-toc.1-1.1.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-streams" class="xref">Streams</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.2.2.1">
+                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-stream-types-and-identifier" class="xref">Stream Types and Identifiers</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.2.2.2">
+                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-sending-and-receiving-data" class="xref">Sending and Receiving Data</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.2.2.3">
+                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-stream-prioritization" class="xref">Stream Prioritization</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.2.2.4">
+                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-required-operations-on-stre" class="xref">Required Operations on Streams</a><a href="#section-toc.1-1.2.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-stream-states" class="xref">Stream States</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.3.2.1">
+                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-sending-stream-states" class="xref">Sending Stream States</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.3.2.2">
+                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-receiving-stream-states" class="xref">Receiving Stream States</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.3.2.3">
+                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-permitted-frame-types" class="xref">Permitted Frame Types</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.3.2.4">
+                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-bidirectional-stream-states" class="xref">Bidirectional Stream States</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.3.2.5">
+                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-solicited-state-transitions" class="xref">Solicited State Transitions</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-flow-control" class="xref">Flow Control</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.1">
+                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-data-flow-control" class="xref">Data Flow Control</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.2">
+                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-flow-credit-increments" class="xref">Flow Credit Increments</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.3">
+                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-handling-stream-cancellatio" class="xref">Handling Stream Cancellation</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.4">
+                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-stream-final-size" class="xref">Stream Final Size</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.5">
+                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-controlling-concurrency" class="xref">Controlling Concurrency</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-connections" class="xref">Connections</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1">
+                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-connection-id" class="xref">Connection ID</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1.2.1">
+                    <p id="section-toc.1-1.5.2.1.2.1.1"><a href="#section-5.1.1" class="xref">5.1.1</a>.  <a href="#name-issuing-connection-ids" class="xref">Issuing Connection IDs</a><a href="#section-toc.1-1.5.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1.2.2">
+                    <p id="section-toc.1-1.5.2.1.2.2.1"><a href="#section-5.1.2" class="xref">5.1.2</a>.  <a href="#name-consuming-and-retiring-conn" class="xref">Consuming and Retiring Connection IDs</a><a href="#section-toc.1-1.5.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2">
+                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-matching-packets-to-connect" class="xref">Matching Packets to Connections</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2.2.1">
+                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-client-packet-handling" class="xref">Client Packet Handling</a><a href="#section-toc.1-1.5.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2.2.2">
+                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-server-packet-handling" class="xref">Server Packet Handling</a><a href="#section-toc.1-1.5.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2.2.3">
+                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-considerations-for-simple-l" class="xref">Considerations for Simple Load Balancers</a><a href="#section-toc.1-1.5.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.3">
+                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-life-of-a-quic-connection" class="xref">Life of a QUIC Connection</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.4">
+                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-required-operations-on-conn" class="xref">Required Operations on Connections</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-version-negotiation" class="xref">Version Negotiation</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-sending-version-negotiation" class="xref">Sending Version Negotiation Packets</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.6.2.2">
+                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-handling-version-negotiatio" class="xref">Handling Version Negotiation Packets</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.6.2.2.2.1">
+                    <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="xref">6.2.1</a>.  <a href="#name-version-negotiation-between" class="xref">Version Negotiation Between Draft Versions</a><a href="#section-toc.1-1.6.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.6.2.3">
+                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-using-reserved-versions" class="xref">Using Reserved Versions</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-cryptographic-and-transport" class="xref">Cryptographic and Transport Handshake</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-example-handshake-flows" class="xref">Example Handshake Flows</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-negotiating-connection-ids" class="xref">Negotiating Connection IDs</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.3">
+                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-authenticating-connection-i" class="xref">Authenticating Connection IDs</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.4">
+                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-transport-parameters" class="xref">Transport Parameters</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.4.2.1">
+                    <p id="section-toc.1-1.7.2.4.2.1.1"><a href="#section-7.4.1" class="xref">7.4.1</a>.  <a href="#name-values-of-transport-paramet" class="xref">Values of Transport Parameters for 0-RTT</a><a href="#section-toc.1-1.7.2.4.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.4.2.2">
+                    <p id="section-toc.1-1.7.2.4.2.2.1"><a href="#section-7.4.2" class="xref">7.4.2</a>.  <a href="#name-new-transport-parameters" class="xref">New Transport Parameters</a><a href="#section-toc.1-1.7.2.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.7.2.5">
+                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-cryptographic-message-buffe" class="xref">Cryptographic Message Buffering</a><a href="#section-toc.1-1.7.2.5.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-address-validation" class="xref">Address Validation</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.1">
+                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-address-validation-during-c" class="xref">Address Validation During Connection Establishment</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.1.2.1">
+                    <p id="section-toc.1-1.8.2.1.2.1.1"><a href="#section-8.1.1" class="xref">8.1.1</a>.  <a href="#name-token-construction" class="xref">Token Construction</a><a href="#section-toc.1-1.8.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.1.2.2">
+                    <p id="section-toc.1-1.8.2.1.2.2.1"><a href="#section-8.1.2" class="xref">8.1.2</a>.  <a href="#name-address-validation-using-re" class="xref">Address Validation using Retry Packets</a><a href="#section-toc.1-1.8.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.1.2.3">
+                    <p id="section-toc.1-1.8.2.1.2.3.1"><a href="#section-8.1.3" class="xref">8.1.3</a>.  <a href="#name-address-validation-for-futu" class="xref">Address Validation for Future Connections</a><a href="#section-toc.1-1.8.2.1.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.1.2.4">
+                    <p id="section-toc.1-1.8.2.1.2.4.1"><a href="#section-8.1.4" class="xref">8.1.4</a>.  <a href="#name-address-validation-token-in" class="xref">Address Validation Token Integrity</a><a href="#section-toc.1-1.8.2.1.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.2">
+                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-path-validation" class="xref">Path Validation</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.3">
+                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-initiating-path-validation" class="xref">Initiating Path Validation</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.4">
+                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-path-validation-responses" class="xref">Path Validation Responses</a><a href="#section-toc.1-1.8.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.5">
+                <p id="section-toc.1-1.8.2.5.1"><a href="#section-8.5" class="xref">8.5</a>.  <a href="#name-successful-path-validation" class="xref">Successful Path Validation</a><a href="#section-toc.1-1.8.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.8.2.6">
+                <p id="section-toc.1-1.8.2.6.1"><a href="#section-8.6" class="xref">8.6</a>.  <a href="#name-failed-path-validation" class="xref">Failed Path Validation</a><a href="#section-toc.1-1.8.2.6.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-connection-migration" class="xref">Connection Migration</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.1">
+                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-probing-a-new-path" class="xref">Probing a New Path</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.2">
+                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-initiating-connection-migra" class="xref">Initiating Connection Migration</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.3">
+                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-responding-to-connection-mi" class="xref">Responding to Connection Migration</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.3.2.1">
+                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#section-9.3.1" class="xref">9.3.1</a>.  <a href="#name-peer-address-spoofing" class="xref">Peer Address Spoofing</a><a href="#section-toc.1-1.9.2.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.3.2.2">
+                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#section-9.3.2" class="xref">9.3.2</a>.  <a href="#name-on-path-address-spoofing" class="xref">On-Path Address Spoofing</a><a href="#section-toc.1-1.9.2.3.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.3.2.3">
+                    <p id="section-toc.1-1.9.2.3.2.3.1"><a href="#section-9.3.3" class="xref">9.3.3</a>.  <a href="#name-off-path-packet-forwarding" class="xref">Off-Path Packet Forwarding</a><a href="#section-toc.1-1.9.2.3.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.4">
+                <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="xref">9.4</a>.  <a href="#name-loss-detection-and-congesti" class="xref">Loss Detection and Congestion Control</a><a href="#section-toc.1-1.9.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.5">
+                <p id="section-toc.1-1.9.2.5.1"><a href="#section-9.5" class="xref">9.5</a>.  <a href="#name-privacy-implications-of-con" class="xref">Privacy Implications of Connection Migration</a><a href="#section-toc.1-1.9.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.6">
+                <p id="section-toc.1-1.9.2.6.1"><a href="#section-9.6" class="xref">9.6</a>.  <a href="#name-servers-preferred-address" class="xref">Server's Preferred Address</a><a href="#section-toc.1-1.9.2.6.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.6.2.1">
+                    <p id="section-toc.1-1.9.2.6.2.1.1"><a href="#section-9.6.1" class="xref">9.6.1</a>.  <a href="#name-communicating-a-preferred-a" class="xref">Communicating a Preferred Address</a><a href="#section-toc.1-1.9.2.6.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.6.2.2">
+                    <p id="section-toc.1-1.9.2.6.2.2.1"><a href="#section-9.6.2" class="xref">9.6.2</a>.  <a href="#name-responding-to-connection-mig" class="xref">Responding to Connection Migration</a><a href="#section-toc.1-1.9.2.6.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.6.2.3">
+                    <p id="section-toc.1-1.9.2.6.2.3.1"><a href="#section-9.6.3" class="xref">9.6.3</a>.  <a href="#name-interaction-of-client-migra" class="xref">Interaction of Client Migration and Preferred Address</a><a href="#section-toc.1-1.9.2.6.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.9.2.7">
+                <p id="section-toc.1-1.9.2.7.1"><a href="#section-9.7" class="xref">9.7</a>.  <a href="#name-use-of-ipv6-flow-label-and-" class="xref">Use of IPv6 Flow-Label and Migration</a><a href="#section-toc.1-1.9.2.7.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-connection-termination" class="xref">Connection Termination</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.10.2.1">
+                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-closing-and-draining-connec" class="xref">Closing and Draining Connection States</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.10.2.2">
+                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-idle-timeout" class="xref">Idle Timeout</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.10.2.3">
+                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-immediate-close" class="xref">Immediate Close</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.10.2.3.2.1">
+                    <p id="section-toc.1-1.10.2.3.2.1.1"><a href="#section-10.3.1" class="xref">10.3.1</a>.  <a href="#name-immediate-close-during-the-" class="xref">Immediate Close During the Handshake</a><a href="#section-toc.1-1.10.2.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.10.2.4">
+                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="xref">10.4</a>.  <a href="#name-stateless-reset" class="xref">Stateless Reset</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.10.2.4.2.1">
+                    <p id="section-toc.1-1.10.2.4.2.1.1"><a href="#section-10.4.1" class="xref">10.4.1</a>.  <a href="#name-detecting-a-stateless-reset" class="xref">Detecting a Stateless Reset</a><a href="#section-toc.1-1.10.2.4.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.10.2.4.2.2">
+                    <p id="section-toc.1-1.10.2.4.2.2.1"><a href="#section-10.4.2" class="xref">10.4.2</a>.  <a href="#name-calculating-a-stateless-res" class="xref">Calculating a Stateless Reset Token</a><a href="#section-toc.1-1.10.2.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.10.2.4.2.3">
+                    <p id="section-toc.1-1.10.2.4.2.3.1"><a href="#section-10.4.3" class="xref">10.4.3</a>.  <a href="#name-looping" class="xref">Looping</a><a href="#section-toc.1-1.10.2.4.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-error-handling" class="xref">Error Handling</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.11.2.1">
+                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-connection-errors" class="xref">Connection Errors</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.11.2.2">
+                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-stream-errors" class="xref">Stream Errors</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.12">
+            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-packets-and-frames" class="xref">Packets and Frames</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.12.2.1">
+                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-protected-packets" class="xref">Protected Packets</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.12.2.2">
+                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-coalescing-packets" class="xref">Coalescing Packets</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.12.2.3">
+                <p id="section-toc.1-1.12.2.3.1"><a href="#section-12.3" class="xref">12.3</a>.  <a href="#name-packet-numbers" class="xref">Packet Numbers</a><a href="#section-toc.1-1.12.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.12.2.4">
+                <p id="section-toc.1-1.12.2.4.1"><a href="#section-12.4" class="xref">12.4</a>.  <a href="#name-frames-and-frame-types" class="xref">Frames and Frame Types</a><a href="#section-toc.1-1.12.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.13">
+            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-packetization-and-reliabili" class="xref">Packetization and Reliability</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.1">
+                <p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="xref">13.1</a>.  <a href="#name-packet-processing" class="xref">Packet Processing</a><a href="#section-toc.1-1.13.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2">
+                <p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="xref">13.2</a>.  <a href="#name-generating-acknowledgements" class="xref">Generating Acknowledgements</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2.2.1">
+                    <p id="section-toc.1-1.13.2.2.2.1.1"><a href="#section-13.2.1" class="xref">13.2.1</a>.  <a href="#name-sending-ack-frames" class="xref">Sending ACK Frames</a><a href="#section-toc.1-1.13.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2.2.2">
+                    <p id="section-toc.1-1.13.2.2.2.2.1"><a href="#section-13.2.2" class="xref">13.2.2</a>.  <a href="#name-acknowledgement-frequency" class="xref">Acknowledgement Frequency</a><a href="#section-toc.1-1.13.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2.2.3">
+                    <p id="section-toc.1-1.13.2.2.2.3.1"><a href="#section-13.2.3" class="xref">13.2.3</a>.  <a href="#name-managing-ack-ranges" class="xref">Managing ACK Ranges</a><a href="#section-toc.1-1.13.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2.2.4">
+                    <p id="section-toc.1-1.13.2.2.2.4.1"><a href="#section-13.2.4" class="xref">13.2.4</a>.  <a href="#name-receiver-tracking-of-ack-fr" class="xref">Receiver Tracking of ACK Frames</a><a href="#section-toc.1-1.13.2.2.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2.2.5">
+                    <p id="section-toc.1-1.13.2.2.2.5.1"><a href="#section-13.2.5" class="xref">13.2.5</a>.  <a href="#name-limiting-ack-ranges" class="xref">Limiting ACK Ranges</a><a href="#section-toc.1-1.13.2.2.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2.2.6">
+                    <p id="section-toc.1-1.13.2.2.2.6.1"><a href="#section-13.2.6" class="xref">13.2.6</a>.  <a href="#name-measuring-and-reporting-hos" class="xref">Measuring and Reporting Host Delay</a><a href="#section-toc.1-1.13.2.2.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2.2.7">
+                    <p id="section-toc.1-1.13.2.2.2.7.1"><a href="#section-13.2.7" class="xref">13.2.7</a>.  <a href="#name-ack-frames-and-packet-prote" class="xref">ACK Frames and Packet Protection</a><a href="#section-toc.1-1.13.2.2.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2.2.8">
+                    <p id="section-toc.1-1.13.2.2.2.8.1"><a href="#section-13.2.8" class="xref">13.2.8</a>.  <a href="#name-padding-frames-consume-cong" class="xref">PADDING Frames Consume Congestion Window</a><a href="#section-toc.1-1.13.2.2.2.8.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.3">
+                <p id="section-toc.1-1.13.2.3.1"><a href="#section-13.3" class="xref">13.3</a>.  <a href="#name-retransmission-of-informati" class="xref">Retransmission of Information</a><a href="#section-toc.1-1.13.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.4">
+                <p id="section-toc.1-1.13.2.4.1"><a href="#section-13.4" class="xref">13.4</a>.  <a href="#name-explicit-congestion-notific" class="xref">Explicit Congestion Notification</a><a href="#section-toc.1-1.13.2.4.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.4.2.1">
+                    <p id="section-toc.1-1.13.2.4.2.1.1"><a href="#section-13.4.1" class="xref">13.4.1</a>.  <a href="#name-ecn-counts" class="xref">ECN Counts</a><a href="#section-toc.1-1.13.2.4.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.4.2.2">
+                    <p id="section-toc.1-1.13.2.4.2.2.1"><a href="#section-13.4.2" class="xref">13.4.2</a>.  <a href="#name-ecn-validation" class="xref">ECN Validation</a><a href="#section-toc.1-1.13.2.4.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.14">
+            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-packet-size" class="xref">Packet Size</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.14.2.1">
+                <p id="section-toc.1-1.14.2.1.1"><a href="#section-14.1" class="xref">14.1</a>.  <a href="#name-path-maximum-transmission-u" class="xref">Path Maximum Transmission Unit (PMTU)</a><a href="#section-toc.1-1.14.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.14.2.2">
+                <p id="section-toc.1-1.14.2.2.1"><a href="#section-14.2" class="xref">14.2</a>.  <a href="#name-icmp-packet-too-big-message" class="xref">ICMP Packet Too Big Messages</a><a href="#section-toc.1-1.14.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.14.2.3">
+                <p id="section-toc.1-1.14.2.3.1"><a href="#section-14.3" class="xref">14.3</a>.  <a href="#name-datagram-packetization-laye" class="xref">Datagram Packetization Layer PMTU Discovery</a><a href="#section-toc.1-1.14.2.3.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.14.2.3.2.1">
+                    <p id="section-toc.1-1.14.2.3.2.1.1"><a href="#section-14.3.1" class="xref">14.3.1</a>.  <a href="#name-pmtu-probes-containing-sour" class="xref">PMTU Probes Containing Source Connection ID</a><a href="#section-toc.1-1.14.2.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.15">
+            <p id="section-toc.1-1.15.1"><a href="#section-15" class="xref">15</a>. <a href="#name-versions" class="xref">Versions</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.16">
+            <p id="section-toc.1-1.16.1"><a href="#section-16" class="xref">16</a>. <a href="#name-variable-length-integer-enc" class="xref">Variable-Length Integer Encoding</a><a href="#section-toc.1-1.16.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.17">
+            <p id="section-toc.1-1.17.1"><a href="#section-17" class="xref">17</a>. <a href="#name-packet-formats" class="xref">Packet Formats</a><a href="#section-toc.1-1.17.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.1">
+                <p id="section-toc.1-1.17.2.1.1"><a href="#section-17.1" class="xref">17.1</a>.  <a href="#name-packet-number-encoding-and-" class="xref">Packet Number Encoding and Decoding</a><a href="#section-toc.1-1.17.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.2">
+                <p id="section-toc.1-1.17.2.2.1"><a href="#section-17.2" class="xref">17.2</a>.  <a href="#name-long-header-packets" class="xref">Long Header Packets</a><a href="#section-toc.1-1.17.2.2.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.2.2.1">
+                    <p id="section-toc.1-1.17.2.2.2.1.1"><a href="#section-17.2.1" class="xref">17.2.1</a>.  <a href="#name-version-negotiation-packet" class="xref">Version Negotiation Packet</a><a href="#section-toc.1-1.17.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.2.2.2">
+                    <p id="section-toc.1-1.17.2.2.2.2.1"><a href="#section-17.2.2" class="xref">17.2.2</a>.  <a href="#name-initial-packet" class="xref">Initial Packet</a><a href="#section-toc.1-1.17.2.2.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.2.2.3">
+                    <p id="section-toc.1-1.17.2.2.2.3.1"><a href="#section-17.2.3" class="xref">17.2.3</a>.  <a href="#name-0-rtt" class="xref">0-RTT</a><a href="#section-toc.1-1.17.2.2.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.2.2.4">
+                    <p id="section-toc.1-1.17.2.2.2.4.1"><a href="#section-17.2.4" class="xref">17.2.4</a>.  <a href="#name-handshake-packet" class="xref">Handshake Packet</a><a href="#section-toc.1-1.17.2.2.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.2.2.5">
+                    <p id="section-toc.1-1.17.2.2.2.5.1"><a href="#section-17.2.5" class="xref">17.2.5</a>.  <a href="#name-retry-packet" class="xref">Retry Packet</a><a href="#section-toc.1-1.17.2.2.2.5.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.3">
+                <p id="section-toc.1-1.17.2.3.1"><a href="#section-17.3" class="xref">17.3</a>.  <a href="#name-short-header-packets" class="xref">Short Header Packets</a><a href="#section-toc.1-1.17.2.3.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.17.2.3.2.1">
+                    <p id="section-toc.1-1.17.2.3.2.1.1"><a href="#section-17.3.1" class="xref">17.3.1</a>.  <a href="#name-latency-spin-bit" class="xref">Latency Spin Bit</a><a href="#section-toc.1-1.17.2.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.18">
+            <p id="section-toc.1-1.18.1"><a href="#section-18" class="xref">18</a>. <a href="#name-transport-parameter-encodin" class="xref">Transport Parameter Encoding</a><a href="#section-toc.1-1.18.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.18.2.1">
+                <p id="section-toc.1-1.18.2.1.1"><a href="#section-18.1" class="xref">18.1</a>.  <a href="#name-reserved-transport-paramete" class="xref">Reserved Transport Parameters</a><a href="#section-toc.1-1.18.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.18.2.2">
+                <p id="section-toc.1-1.18.2.2.1"><a href="#section-18.2" class="xref">18.2</a>.  <a href="#name-transport-parameter-definit" class="xref">Transport Parameter Definitions</a><a href="#section-toc.1-1.18.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.19">
+            <p id="section-toc.1-1.19.1"><a href="#section-19" class="xref">19</a>. <a href="#name-frame-types-and-formats" class="xref">Frame Types and Formats</a><a href="#section-toc.1-1.19.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.1">
+                <p id="section-toc.1-1.19.2.1.1"><a href="#section-19.1" class="xref">19.1</a>.  <a href="#name-padding-frame" class="xref">PADDING Frame</a><a href="#section-toc.1-1.19.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.2">
+                <p id="section-toc.1-1.19.2.2.1"><a href="#section-19.2" class="xref">19.2</a>.  <a href="#name-ping-frame" class="xref">PING Frame</a><a href="#section-toc.1-1.19.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.3">
+                <p id="section-toc.1-1.19.2.3.1"><a href="#section-19.3" class="xref">19.3</a>.  <a href="#name-ack-frames" class="xref">ACK Frames</a><a href="#section-toc.1-1.19.2.3.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.3.2.1">
+                    <p id="section-toc.1-1.19.2.3.2.1.1"><a href="#section-19.3.1" class="xref">19.3.1</a>.  <a href="#name-ack-ranges" class="xref">ACK Ranges</a><a href="#section-toc.1-1.19.2.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.3.2.2">
+                    <p id="section-toc.1-1.19.2.3.2.2.1"><a href="#section-19.3.2" class="xref">19.3.2</a>.  <a href="#name-ecn-counts-2" class="xref">ECN Counts</a><a href="#section-toc.1-1.19.2.3.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.4">
+                <p id="section-toc.1-1.19.2.4.1"><a href="#section-19.4" class="xref">19.4</a>.  <a href="#name-reset_stream-frame" class="xref">RESET_STREAM Frame</a><a href="#section-toc.1-1.19.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.5">
+                <p id="section-toc.1-1.19.2.5.1"><a href="#section-19.5" class="xref">19.5</a>.  <a href="#name-stop_sending-frame" class="xref">STOP_SENDING Frame</a><a href="#section-toc.1-1.19.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.6">
+                <p id="section-toc.1-1.19.2.6.1"><a href="#section-19.6" class="xref">19.6</a>.  <a href="#name-crypto-frame" class="xref">CRYPTO Frame</a><a href="#section-toc.1-1.19.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.7">
+                <p id="section-toc.1-1.19.2.7.1"><a href="#section-19.7" class="xref">19.7</a>.  <a href="#name-new_token-frame" class="xref">NEW_TOKEN Frame</a><a href="#section-toc.1-1.19.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.8">
+                <p id="section-toc.1-1.19.2.8.1"><a href="#section-19.8" class="xref">19.8</a>.  <a href="#name-stream-frames" class="xref">STREAM Frames</a><a href="#section-toc.1-1.19.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.9">
+                <p id="section-toc.1-1.19.2.9.1"><a href="#section-19.9" class="xref">19.9</a>.  <a href="#name-max_data-frame" class="xref">MAX_DATA Frame</a><a href="#section-toc.1-1.19.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.10">
+                <p id="section-toc.1-1.19.2.10.1"><a href="#section-19.10" class="xref">19.10</a>. <a href="#name-max_stream_data-frame" class="xref">MAX_STREAM_DATA Frame</a><a href="#section-toc.1-1.19.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.11">
+                <p id="section-toc.1-1.19.2.11.1"><a href="#section-19.11" class="xref">19.11</a>. <a href="#name-max_streams-frames" class="xref">MAX_STREAMS Frames</a><a href="#section-toc.1-1.19.2.11.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.12">
+                <p id="section-toc.1-1.19.2.12.1"><a href="#section-19.12" class="xref">19.12</a>. <a href="#name-data_blocked-frame" class="xref">DATA_BLOCKED Frame</a><a href="#section-toc.1-1.19.2.12.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.13">
+                <p id="section-toc.1-1.19.2.13.1"><a href="#section-19.13" class="xref">19.13</a>. <a href="#name-stream_data_blocked-frame" class="xref">STREAM_DATA_BLOCKED Frame</a><a href="#section-toc.1-1.19.2.13.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.14">
+                <p id="section-toc.1-1.19.2.14.1"><a href="#section-19.14" class="xref">19.14</a>. <a href="#name-streams_blocked-frames" class="xref">STREAMS_BLOCKED Frames</a><a href="#section-toc.1-1.19.2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.15">
+                <p id="section-toc.1-1.19.2.15.1"><a href="#section-19.15" class="xref">19.15</a>. <a href="#name-new_connection_id-frame" class="xref">NEW_CONNECTION_ID Frame</a><a href="#section-toc.1-1.19.2.15.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.16">
+                <p id="section-toc.1-1.19.2.16.1"><a href="#section-19.16" class="xref">19.16</a>. <a href="#name-retire_connection_id-frame" class="xref">RETIRE_CONNECTION_ID Frame</a><a href="#section-toc.1-1.19.2.16.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.17">
+                <p id="section-toc.1-1.19.2.17.1"><a href="#section-19.17" class="xref">19.17</a>. <a href="#name-path_challenge-frame" class="xref">PATH_CHALLENGE Frame</a><a href="#section-toc.1-1.19.2.17.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.18">
+                <p id="section-toc.1-1.19.2.18.1"><a href="#section-19.18" class="xref">19.18</a>. <a href="#name-path_response-frame" class="xref">PATH_RESPONSE Frame</a><a href="#section-toc.1-1.19.2.18.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.19">
+                <p id="section-toc.1-1.19.2.19.1"><a href="#section-19.19" class="xref">19.19</a>. <a href="#name-connection_close-frames" class="xref">CONNECTION_CLOSE Frames</a><a href="#section-toc.1-1.19.2.19.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.20">
+                <p id="section-toc.1-1.19.2.20.1"><a href="#section-19.20" class="xref">19.20</a>. <a href="#name-handshake_done-frame" class="xref">HANDSHAKE_DONE frame</a><a href="#section-toc.1-1.19.2.20.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.19.2.21">
+                <p id="section-toc.1-1.19.2.21.1"><a href="#section-19.21" class="xref">19.21</a>. <a href="#name-extension-frames" class="xref">Extension Frames</a><a href="#section-toc.1-1.19.2.21.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.20">
+            <p id="section-toc.1-1.20.1"><a href="#section-20" class="xref">20</a>. <a href="#name-transport-error-codes" class="xref">Transport Error Codes</a><a href="#section-toc.1-1.20.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.20.2.1">
+                <p id="section-toc.1-1.20.2.1.1"><a href="#section-20.1" class="xref">20.1</a>.  <a href="#name-application-protocol-error-" class="xref">Application Protocol Error Codes</a><a href="#section-toc.1-1.20.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.21">
+            <p id="section-toc.1-1.21.1"><a href="#section-21" class="xref">21</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.21.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.1">
+                <p id="section-toc.1-1.21.2.1.1"><a href="#section-21.1" class="xref">21.1</a>.  <a href="#name-handshake-denial-of-service" class="xref">Handshake Denial of Service</a><a href="#section-toc.1-1.21.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.2">
+                <p id="section-toc.1-1.21.2.2.1"><a href="#section-21.2" class="xref">21.2</a>.  <a href="#name-amplification-attack" class="xref">Amplification Attack</a><a href="#section-toc.1-1.21.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.3">
+                <p id="section-toc.1-1.21.2.3.1"><a href="#section-21.3" class="xref">21.3</a>.  <a href="#name-optimistic-ack-attack" class="xref">Optimistic ACK Attack</a><a href="#section-toc.1-1.21.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.4">
+                <p id="section-toc.1-1.21.2.4.1"><a href="#section-21.4" class="xref">21.4</a>.  <a href="#name-slowloris-attacks" class="xref">Slowloris Attacks</a><a href="#section-toc.1-1.21.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.5">
+                <p id="section-toc.1-1.21.2.5.1"><a href="#section-21.5" class="xref">21.5</a>.  <a href="#name-stream-fragmentation-and-re" class="xref">Stream Fragmentation and Reassembly Attacks</a><a href="#section-toc.1-1.21.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.6">
+                <p id="section-toc.1-1.21.2.6.1"><a href="#section-21.6" class="xref">21.6</a>.  <a href="#name-stream-commitment-attack" class="xref">Stream Commitment Attack</a><a href="#section-toc.1-1.21.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.7">
+                <p id="section-toc.1-1.21.2.7.1"><a href="#section-21.7" class="xref">21.7</a>.  <a href="#name-peer-denial-of-service" class="xref">Peer Denial of Service</a><a href="#section-toc.1-1.21.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.8">
+                <p id="section-toc.1-1.21.2.8.1"><a href="#section-21.8" class="xref">21.8</a>.  <a href="#name-explicit-congestion-notifica" class="xref">Explicit Congestion Notification Attacks</a><a href="#section-toc.1-1.21.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.9">
+                <p id="section-toc.1-1.21.2.9.1"><a href="#section-21.9" class="xref">21.9</a>.  <a href="#name-stateless-reset-oracle" class="xref">Stateless Reset Oracle</a><a href="#section-toc.1-1.21.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.10">
+                <p id="section-toc.1-1.21.2.10.1"><a href="#section-21.10" class="xref">21.10</a>. <a href="#name-version-downgrade" class="xref">Version Downgrade</a><a href="#section-toc.1-1.21.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.11">
+                <p id="section-toc.1-1.21.2.11.1"><a href="#section-21.11" class="xref">21.11</a>. <a href="#name-targeted-attacks-by-routing" class="xref">Targeted Attacks by Routing</a><a href="#section-toc.1-1.21.2.11.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.12">
+                <p id="section-toc.1-1.21.2.12.1"><a href="#section-21.12" class="xref">21.12</a>. <a href="#name-overview-of-security-proper" class="xref">Overview of Security Properties</a><a href="#section-toc.1-1.21.2.12.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.12.2.1">
+                    <p id="section-toc.1-1.21.2.12.2.1.1"><a href="#section-21.12.1" class="xref">21.12.1</a>.  <a href="#name-handshake" class="xref">Handshake</a><a href="#section-toc.1-1.21.2.12.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.12.2.2">
+                    <p id="section-toc.1-1.21.2.12.2.2.1"><a href="#section-21.12.2" class="xref">21.12.2</a>.  <a href="#name-protected-packets-2" class="xref">Protected Packets</a><a href="#section-toc.1-1.21.2.12.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.21.2.12.2.3">
+                    <p id="section-toc.1-1.21.2.12.2.3.1"><a href="#section-21.12.3" class="xref">21.12.3</a>.  <a href="#name-connection-migration-2" class="xref">Connection Migration</a><a href="#section-toc.1-1.21.2.12.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.22">
+            <p id="section-toc.1-1.22.1"><a href="#section-22" class="xref">22</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.22.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.22.2.1">
+                <p id="section-toc.1-1.22.2.1.1"><a href="#section-22.1" class="xref">22.1</a>.  <a href="#name-registration-policies-for-q" class="xref">Registration Policies for QUIC Registries</a><a href="#section-toc.1-1.22.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.22.2.1.2.1">
+                    <p id="section-toc.1-1.22.2.1.2.1.1"><a href="#section-22.1.1" class="xref">22.1.1</a>.  <a href="#name-provisional-registrations" class="xref">Provisional Registrations</a><a href="#section-toc.1-1.22.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.22.2.1.2.2">
+                    <p id="section-toc.1-1.22.2.1.2.2.1"><a href="#section-22.1.2" class="xref">22.1.2</a>.  <a href="#name-selecting-codepoints" class="xref">Selecting Codepoints</a><a href="#section-toc.1-1.22.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.22.2.1.2.3">
+                    <p id="section-toc.1-1.22.2.1.2.3.1"><a href="#section-22.1.3" class="xref">22.1.3</a>.  <a href="#name-reclaiming-provisional-code" class="xref">Reclaiming Provisional Codepoints</a><a href="#section-toc.1-1.22.2.1.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.22.2.1.2.4">
+                    <p id="section-toc.1-1.22.2.1.2.4.1"><a href="#section-22.1.4" class="xref">22.1.4</a>.  <a href="#name-permanent-registrations" class="xref">Permanent Registrations</a><a href="#section-toc.1-1.22.2.1.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.22.2.2">
+                <p id="section-toc.1-1.22.2.2.1"><a href="#section-22.2" class="xref">22.2</a>.  <a href="#name-quic-transport-parameter-re" class="xref">QUIC Transport Parameter Registry</a><a href="#section-toc.1-1.22.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.22.2.3">
+                <p id="section-toc.1-1.22.2.3.1"><a href="#section-22.3" class="xref">22.3</a>.  <a href="#name-quic-frame-type-registry" class="xref">QUIC Frame Type Registry</a><a href="#section-toc.1-1.22.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.22.2.4">
+                <p id="section-toc.1-1.22.2.4.1"><a href="#section-22.4" class="xref">22.4</a>.  <a href="#name-quic-transport-error-codes-" class="xref">QUIC Transport Error Codes Registry</a><a href="#section-toc.1-1.22.2.4.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.23">
+            <p id="section-toc.1-1.23.1"><a href="#section-23" class="xref">23</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.23.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.23.2.1">
+                <p id="section-toc.1-1.23.2.1.1"><a href="#section-23.1" class="xref">23.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.23.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.23.2.2">
+                <p id="section-toc.1-1.23.2.2.1"><a href="#section-23.2" class="xref">23.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.23.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.24">
+            <p id="section-toc.1-1.24.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-sample-packet-number-decodi" class="xref">Sample Packet Number Decoding Algorithm</a><a href="#section-toc.1-1.24.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.25">
+            <p id="section-toc.1-1.25.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-sample-ecn-validation-algor" class="xref">Sample ECN Validation Algorithm</a><a href="#section-toc.1-1.25.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.26">
+            <p id="section-toc.1-1.26.1"><a href="#section-appendix.c" class="xref">Appendix C</a>.  <a href="#name-change-log" class="xref">Change Log</a><a href="#section-toc.1-1.26.1" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty toc">
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.1">
+                <p id="section-toc.1-1.26.2.1.1"><a href="#section-c.1" class="xref">C.1</a>.  <a href="#name-since-draft-ietf-quic-trans" class="xref">Since draft-ietf-quic-transport-27</a><a href="#section-toc.1-1.26.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.2">
+                <p id="section-toc.1-1.26.2.2.1"><a href="#section-c.2" class="xref">C.2</a>.  <a href="#name-since-draft-ietf-quic-transp" class="xref">Since draft-ietf-quic-transport-26</a><a href="#section-toc.1-1.26.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.3">
+                <p id="section-toc.1-1.26.2.3.1"><a href="#section-c.3" class="xref">C.3</a>.  <a href="#name-since-draft-ietf-quic-transpo" class="xref">Since draft-ietf-quic-transport-25</a><a href="#section-toc.1-1.26.2.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.4">
+                <p id="section-toc.1-1.26.2.4.1"><a href="#section-c.4" class="xref">C.4</a>.  <a href="#name-since-draft-ietf-quic-transpor" class="xref">Since draft-ietf-quic-transport-24</a><a href="#section-toc.1-1.26.2.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.5">
+                <p id="section-toc.1-1.26.2.5.1"><a href="#section-c.5" class="xref">C.5</a>.  <a href="#name-since-draft-ietf-quic-transport" class="xref">Since draft-ietf-quic-transport-23</a><a href="#section-toc.1-1.26.2.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.6">
+                <p id="section-toc.1-1.26.2.6.1"><a href="#section-c.6" class="xref">C.6</a>.  <a href="#name-since-draft-ietf-quic-transport-" class="xref">Since draft-ietf-quic-transport-22</a><a href="#section-toc.1-1.26.2.6.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.7">
+                <p id="section-toc.1-1.26.2.7.1"><a href="#section-c.7" class="xref">C.7</a>.  <a href="#name-since-draft-ietf-quic-transport-2" class="xref">Since draft-ietf-quic-transport-21</a><a href="#section-toc.1-1.26.2.7.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.8">
+                <p id="section-toc.1-1.26.2.8.1"><a href="#section-c.8" class="xref">C.8</a>.  <a href="#name-since-draft-ietf-quic-transport-20" class="xref">Since draft-ietf-quic-transport-20</a><a href="#section-toc.1-1.26.2.8.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.9">
+                <p id="section-toc.1-1.26.2.9.1"><a href="#section-c.9" class="xref">C.9</a>.  <a href="#name-since-draft-ietf-quic-transport-1" class="xref">Since draft-ietf-quic-transport-19</a><a href="#section-toc.1-1.26.2.9.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.10">
+                <p id="section-toc.1-1.26.2.10.1"><a href="#section-c.10" class="xref">C.10</a>. <a href="#name-since-draft-ietf-quic-transport-18" class="xref">Since draft-ietf-quic-transport-18</a><a href="#section-toc.1-1.26.2.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.11">
+                <p id="section-toc.1-1.26.2.11.1"><a href="#section-c.11" class="xref">C.11</a>. <a href="#name-since-draft-ietf-quic-transport-17" class="xref">Since draft-ietf-quic-transport-17</a><a href="#section-toc.1-1.26.2.11.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.12">
+                <p id="section-toc.1-1.26.2.12.1"><a href="#section-c.12" class="xref">C.12</a>. <a href="#name-since-draft-ietf-quic-transport-16" class="xref">Since draft-ietf-quic-transport-16</a><a href="#section-toc.1-1.26.2.12.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.13">
+                <p id="section-toc.1-1.26.2.13.1"><a href="#section-c.13" class="xref">C.13</a>. <a href="#name-since-draft-ietf-quic-transport-15" class="xref">Since draft-ietf-quic-transport-15</a><a href="#section-toc.1-1.26.2.13.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.14">
+                <p id="section-toc.1-1.26.2.14.1"><a href="#section-c.14" class="xref">C.14</a>. <a href="#name-since-draft-ietf-quic-transport-14" class="xref">Since draft-ietf-quic-transport-14</a><a href="#section-toc.1-1.26.2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.15">
+                <p id="section-toc.1-1.26.2.15.1"><a href="#section-c.15" class="xref">C.15</a>. <a href="#name-since-draft-ietf-quic-transport-13" class="xref">Since draft-ietf-quic-transport-13</a><a href="#section-toc.1-1.26.2.15.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.16">
+                <p id="section-toc.1-1.26.2.16.1"><a href="#section-c.16" class="xref">C.16</a>. <a href="#name-since-draft-ietf-quic-transport-12" class="xref">Since draft-ietf-quic-transport-12</a><a href="#section-toc.1-1.26.2.16.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.17">
+                <p id="section-toc.1-1.26.2.17.1"><a href="#section-c.17" class="xref">C.17</a>. <a href="#name-since-draft-ietf-quic-transport-11" class="xref">Since draft-ietf-quic-transport-11</a><a href="#section-toc.1-1.26.2.17.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.18">
+                <p id="section-toc.1-1.26.2.18.1"><a href="#section-c.18" class="xref">C.18</a>. <a href="#name-since-draft-ietf-quic-transport-10" class="xref">Since draft-ietf-quic-transport-10</a><a href="#section-toc.1-1.26.2.18.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.19">
+                <p id="section-toc.1-1.26.2.19.1"><a href="#section-c.19" class="xref">C.19</a>. <a href="#name-since-draft-ietf-quic-transport-0" class="xref">Since draft-ietf-quic-transport-09</a><a href="#section-toc.1-1.26.2.19.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.20">
+                <p id="section-toc.1-1.26.2.20.1"><a href="#section-c.20" class="xref">C.20</a>. <a href="#name-since-draft-ietf-quic-transport-08" class="xref">Since draft-ietf-quic-transport-08</a><a href="#section-toc.1-1.26.2.20.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.21">
+                <p id="section-toc.1-1.26.2.21.1"><a href="#section-c.21" class="xref">C.21</a>. <a href="#name-since-draft-ietf-quic-transport-07" class="xref">Since draft-ietf-quic-transport-07</a><a href="#section-toc.1-1.26.2.21.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.22">
+                <p id="section-toc.1-1.26.2.22.1"><a href="#section-c.22" class="xref">C.22</a>. <a href="#name-since-draft-ietf-quic-transport-06" class="xref">Since draft-ietf-quic-transport-06</a><a href="#section-toc.1-1.26.2.22.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.23">
+                <p id="section-toc.1-1.26.2.23.1"><a href="#section-c.23" class="xref">C.23</a>. <a href="#name-since-draft-ietf-quic-transport-05" class="xref">Since draft-ietf-quic-transport-05</a><a href="#section-toc.1-1.26.2.23.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.24">
+                <p id="section-toc.1-1.26.2.24.1"><a href="#section-c.24" class="xref">C.24</a>. <a href="#name-since-draft-ietf-quic-transport-04" class="xref">Since draft-ietf-quic-transport-04</a><a href="#section-toc.1-1.26.2.24.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.25">
+                <p id="section-toc.1-1.26.2.25.1"><a href="#section-c.25" class="xref">C.25</a>. <a href="#name-since-draft-ietf-quic-transport-03" class="xref">Since draft-ietf-quic-transport-03</a><a href="#section-toc.1-1.26.2.25.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.26">
+                <p id="section-toc.1-1.26.2.26.1"><a href="#section-c.26" class="xref">C.26</a>. <a href="#name-since-draft-ietf-quic-transport-02" class="xref">Since draft-ietf-quic-transport-02</a><a href="#section-toc.1-1.26.2.26.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.27">
+                <p id="section-toc.1-1.26.2.27.1"><a href="#section-c.27" class="xref">C.27</a>. <a href="#name-since-draft-ietf-quic-transport-01" class="xref">Since draft-ietf-quic-transport-01</a><a href="#section-toc.1-1.26.2.27.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.28">
+                <p id="section-toc.1-1.26.2.28.1"><a href="#section-c.28" class="xref">C.28</a>. <a href="#name-since-draft-ietf-quic-transport-00" class="xref">Since draft-ietf-quic-transport-00</a><a href="#section-toc.1-1.26.2.28.1" class="pilcrow">¶</a></p>
+</li>
+<li class="compact ulEmpty toc" id="section-toc.1-1.26.2.29">
+                <p id="section-toc.1-1.26.2.29.1"><a href="#section-c.29" class="xref">C.29</a>. <a href="#name-since-draft-hamilton-quic-t" class="xref">Since draft-hamilton-quic-transport-protocol-01</a><a href="#section-toc.1-1.26.2.29.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.27">
+            <p id="section-toc.1-1.27.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.27.1" class="pilcrow">¶</a></p>
+</li>
+<li class="ulEmpty compact toc" id="section-toc.1-1.28">
+            <p id="section-toc.1-1.28.1"><a href="#section-appendix.e" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.28.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</nav>
+</section>
+</div>
+<div id="introduction">
+<section id="section-1">
+      <h2 id="name-introduction">
+<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
+      </h2>
+<p id="section-1-1">QUIC is a multiplexed and secure general-purpose transport protocol that
+provides:<a href="#section-1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-1-2.1">Stream multiplexing<a href="#section-1-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1-2.2">Stream and connection-level flow control<a href="#section-1-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1-2.3">Low-latency connection establishment<a href="#section-1-2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1-2.4">Connection migration and resilience to NAT rebinding<a href="#section-1-2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1-2.5">Authenticated and encrypted header and payload<a href="#section-1-2.5" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-1-3">QUIC uses UDP as a substrate to avoid requiring changes to legacy client
+operating systems and middleboxes.  QUIC authenticates all of its headers and
+encrypts most of the data it exchanges, including its signaling, to avoid
+incurring a dependency on middleboxes.<a href="#section-1-3" class="pilcrow">¶</a></p>
+<div id="document-structure">
+<section id="section-1.1">
+        <h3 id="name-document-structure">
+<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-document-structure" class="section-name selfRef">Document Structure</a>
+        </h3>
+<p id="section-1.1-1">This document describes the core QUIC protocol and is structured as follows:<a href="#section-1.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-1.1-2.1">
+            <p id="section-1.1-2.1.1">Streams are the basic service abstraction that QUIC provides.<a href="#section-1.1-2.1.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-1.1-2.1.2.1">
+                <a href="#streams" class="xref">Section 2</a> describes core concepts related to streams,<a href="#section-1.1-2.1.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.1.2.2">
+                <a href="#stream-states" class="xref">Section 3</a> provides a reference model for stream states, and<a href="#section-1.1-2.1.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.1.2.3">
+                <a href="#flow-control" class="xref">Section 4</a> outlines the operation of flow control.<a href="#section-1.1-2.1.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-1.1-2.2">
+            <p id="section-1.1-2.2.1">Connections are the context in which QUIC endpoints communicate.<a href="#section-1.1-2.2.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-1.1-2.2.2.1">
+                <a href="#connections" class="xref">Section 5</a> describes core concepts related to connections,<a href="#section-1.1-2.2.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.2.2.2">
+                <a href="#version-negotiation" class="xref">Section 6</a> describes version negotiation,<a href="#section-1.1-2.2.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.2.2.3">
+                <a href="#handshake" class="xref">Section 7</a> details the process for establishing connections,<a href="#section-1.1-2.2.2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.2.2.4">
+                <a href="#address-validation" class="xref">Section 8</a> specifies critical denial of service mitigation
+mechanisms,<a href="#section-1.1-2.2.2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.2.2.5">
+                <a href="#migration" class="xref">Section 9</a> describes how endpoints migrate a connection to a new
+network path,<a href="#section-1.1-2.2.2.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.2.2.6">
+                <a href="#termination" class="xref">Section 10</a> lists the options for terminating an open connection, and<a href="#section-1.1-2.2.2.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.2.2.7">
+                <a href="#error-handling" class="xref">Section 11</a> provides general guidance for error handling.<a href="#section-1.1-2.2.2.7" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-1.1-2.3">
+            <p id="section-1.1-2.3.1">Packets and frames are the basic unit used by QUIC to communicate.<a href="#section-1.1-2.3.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-1.1-2.3.2.1">
+                <a href="#packets-frames" class="xref">Section 12</a> describes concepts related to packets and frames,<a href="#section-1.1-2.3.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.3.2.2">
+                <a href="#packetization" class="xref">Section 13</a> defines models for the transmission, retransmission, and
+acknowledgement of data, and<a href="#section-1.1-2.3.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.3.2.3">
+                <a href="#packet-size" class="xref">Section 14</a> specifies rules for managing the size of packets.<a href="#section-1.1-2.3.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-1.1-2.4">
+            <p id="section-1.1-2.4.1">Finally, encoding details of QUIC protocol elements are described in:<a href="#section-1.1-2.4.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-1.1-2.4.2.1">
+                <a href="#versions" class="xref">Section 15</a> (Versions),<a href="#section-1.1-2.4.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.4.2.2">
+                <a href="#integer-encoding" class="xref">Section 16</a> (Integer Encoding),<a href="#section-1.1-2.4.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.4.2.3">
+                <a href="#packet-formats" class="xref">Section 17</a> (Packet Headers),<a href="#section-1.1-2.4.2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.4.2.4">
+                <a href="#transport-parameter-encoding" class="xref">Section 18</a> (Transport Parameters),<a href="#section-1.1-2.4.2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.4.2.5">
+                <a href="#frame-formats" class="xref">Section 19</a> (Frames), and<a href="#section-1.1-2.4.2.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-1.1-2.4.2.6">
+                <a href="#error-codes" class="xref">Section 20</a> (Errors).<a href="#section-1.1-2.4.2.6" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+</ul>
+<p id="section-1.1-3">Accompanying documents describe QUIC's loss detection and congestion control
+<span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>, and the use of TLS for key negotiation <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
+<p id="section-1.1-4">This document defines QUIC version 1, which conforms to the protocol invariants
+in <span>[<a href="#QUIC-INVARIANTS" class="xref">QUIC-INVARIANTS</a>]</span>.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
+<p id="section-1.1-5">To refer to QUIC version 1, cite this document.  References to the limited
+set of version-independent properties of QUIC can cite <span>[<a href="#QUIC-INVARIANTS" class="xref">QUIC-INVARIANTS</a>]</span>.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="terms-and-definitions">
+<section id="section-1.2">
+        <h3 id="name-terms-and-definitions">
+<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-terms-and-definitions" class="section-name selfRef">Terms and Definitions</a>
+        </h3>
+<p id="section-1.2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
+"MAY", and "OPTIONAL" in this document are to be interpreted as
+described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they
+appear in all capitals, as shown here.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
+<p id="section-1.2-2">Commonly used terms in the document are described below.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-1.2-3">
+          <dt id="section-1.2-3.1">QUIC:</dt>
+<dd id="section-1.2-3.2">
+  The transport protocol described by this document. QUIC is a name, not an
+acronym.<a href="#section-1.2-3.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.3">QUIC packet:</dt>
+<dd id="section-1.2-3.4">
+  A complete processable unit of QUIC that can be encapsulated in a UDP
+datagram.  Multiple QUIC packets can be encapsulated in a single UDP datagram.<a href="#section-1.2-3.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.5">Ack-eliciting Packet:</dt>
+<dd id="section-1.2-3.6">
+  A QUIC packet that contains frames other than ACK, PADDING, and
+CONNECTION_CLOSE. These cause a recipient to send an acknowledgment; see
+<a href="#sending-acknowledgements" class="xref">Section 13.2.1</a>.<a href="#section-1.2-3.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.7">Out-of-order packet:</dt>
+<dd id="section-1.2-3.8">
+  A packet that does not increase the largest received packet number for its
+packet number space (<a href="#packet-numbers" class="xref">Section 12.3</a>) by exactly one. A packet can arrive
+out of order if it is delayed, if earlier packets are lost or delayed, or if
+the sender intentionally skips a packet number.<a href="#section-1.2-3.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.9">Endpoint:</dt>
+<dd id="section-1.2-3.10">
+  An entity that can participate in a QUIC connection by generating,
+receiving, and processing QUIC packets. There are only two types of endpoint
+in QUIC: client and server.<a href="#section-1.2-3.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.11">Client:</dt>
+<dd id="section-1.2-3.12">
+  The endpoint initiating a QUIC connection.<a href="#section-1.2-3.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.13">Server:</dt>
+<dd id="section-1.2-3.14">
+  The endpoint accepting incoming QUIC connections.<a href="#section-1.2-3.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.15">Address:</dt>
+<dd id="section-1.2-3.16">
+  When used without qualification, the tuple of IP version, IP address, UDP
+protocol, and UDP port number that represents one end of a network path.<a href="#section-1.2-3.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.17">Connection ID:</dt>
+<dd id="section-1.2-3.18">
+  An opaque identifier that is used to identify a QUIC connection at an
+endpoint.  Each endpoint sets a value for its peer to include in packets sent
+towards the endpoint.<a href="#section-1.2-3.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.19">Stream:</dt>
+<dd id="section-1.2-3.20">
+  A unidirectional or bidirectional channel of ordered bytes within a QUIC
+connection. A QUIC connection can carry multiple simultaneous streams.<a href="#section-1.2-3.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.2-3.21">Application:</dt>
+<dd id="section-1.2-3.22">
+  An entity that uses QUIC to send and receive data.<a href="#section-1.2-3.22" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="notational-conventions">
+<section id="section-1.3">
+        <h3 id="name-notational-conventions">
+<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-notational-conventions" class="section-name selfRef">Notational Conventions</a>
+        </h3>
+<p id="section-1.3-1">Packet and frame diagrams in this document use a bespoke format. The purpose of
+this format is to summarize, not define, protocol elements. Prose defines the
+complete semantics and details of structures.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
+<p id="section-1.3-2">Complex fields are named and then followed by a list of fields surrounded by a
+pair of matching braces. Each field in this list is separated by commas.<a href="#section-1.3-2" class="pilcrow">¶</a></p>
+<p id="section-1.3-3">Individual fields include length information, plus indications about fixed
+value, optionality, or repetitions. Individual fields use the following
+notational conventions, with all lengths in bits:<a href="#section-1.3-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-1.3-4">
+          <dt id="section-1.3-4.1">x (A):</dt>
+<dd id="section-1.3-4.2">
+  Indicates that x is A bits long<a href="#section-1.3-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.3-4.3">x (i):</dt>
+<dd id="section-1.3-4.4">
+  Indicates that x uses the variable-length encoding in <a href="#integer-encoding" class="xref">Section 16</a><a href="#section-1.3-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.3-4.5">x (A..B):</dt>
+<dd id="section-1.3-4.6">
+  Indicates that x can be any length from A to B; A can be omitted to indicate
+a minimum of zero bits and B can be omitted to indicate no set upper limit;
+values in this format always end on an octet boundary<a href="#section-1.3-4.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.3-4.7">x (?) = C:</dt>
+<dd id="section-1.3-4.8">
+  Indicates that x has a fixed value of C<a href="#section-1.3-4.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.3-4.9">x (?) = C..D:</dt>
+<dd id="section-1.3-4.10">
+  Indicates that x has a value in the range from C to D, inclusive<a href="#section-1.3-4.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.3-4.11">[x (E)]:</dt>
+<dd id="section-1.3-4.12">
+  Indicates that x is optional (and has length of E)<a href="#section-1.3-4.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-1.3-4.13">x (E) ...:</dt>
+<dd id="section-1.3-4.14">
+  Indicates that x is repeated zero or more times (and that each instance is
+length E)<a href="#section-1.3-4.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-1.3-5">By convention, individual fields reference a complex field by using the name of
+the complex field.<a href="#section-1.3-5" class="pilcrow">¶</a></p>
+<p id="section-1.3-6">For example:<a href="#section-1.3-6" class="pilcrow">¶</a></p>
+<span id="name-example-format"></span><div id="fig-ex-format">
+<figure id="figure-1">
+          <div class="artwork art-text alignLeft" id="section-1.3-7.1">
+<pre>
+Example Structure {
+  One-bit Field (1),
+  7-bit Field with Fixed Value (7) = 61,
+  Field with Variable-Length Integer (i),
+  Arbitrary-Length Field (..),
+  Variable-Length Field (8..24),
+  Field With Minimum Length (16..),
+  Field With Maximum Length (..128),
+  [Optional Field (64)],
+  Repeated Field (8) ...,
+}
+</pre>
+</div>
+<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
+<a href="#name-example-format" class="selfRef">Example Format</a>
+          </figcaption></figure>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="streams">
+<section id="section-2">
+      <h2 id="name-streams">
+<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-streams" class="section-name selfRef">Streams</a>
+      </h2>
+<p id="section-2-1">Streams in QUIC provide a lightweight, ordered byte-stream abstraction to an
+application. Streams can be unidirectional or bidirectional.  An alternative
+view of QUIC unidirectional streams is a "message" abstraction of practically
+unlimited length.<a href="#section-2-1" class="pilcrow">¶</a></p>
+<p id="section-2-2">Streams can be created by sending data. Other processes associated with stream
+management - ending, cancelling, and managing flow control - are all designed to
+impose minimal overheads. For instance, a single STREAM frame (<a href="#frame-stream" class="xref">Section 19.8</a>)
+can open, carry data for, and close a stream. Streams can also be long-lived and
+can last the entire duration of a connection.<a href="#section-2-2" class="pilcrow">¶</a></p>
+<p id="section-2-3">Streams can be created by either endpoint, can concurrently send data
+interleaved with other streams, and can be cancelled. QUIC does not provide any
+means of ensuring ordering between bytes on different streams.<a href="#section-2-3" class="pilcrow">¶</a></p>
+<p id="section-2-4">QUIC allows for an arbitrary number of streams to operate concurrently and for
+an arbitrary amount of data to be sent on any stream, subject to flow control
+constraints and stream limits; see <a href="#flow-control" class="xref">Section 4</a>.<a href="#section-2-4" class="pilcrow">¶</a></p>
+<div id="stream-id">
+<section id="section-2.1">
+        <h3 id="name-stream-types-and-identifier">
+<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-stream-types-and-identifier" class="section-name selfRef">Stream Types and Identifiers</a>
+        </h3>
+<p id="section-2.1-1">Streams can be unidirectional or bidirectional.  Unidirectional streams carry
+data in one direction: from the initiator of the stream to its peer.
+Bidirectional streams allow for data to be sent in both directions.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
+<p id="section-2.1-2">Streams are identified within a connection by a numeric value, referred to as
+the stream ID.  A stream ID is a 62-bit integer (0 to 2^62-1) that is unique for
+all streams on a connection.  Stream IDs are encoded as variable-length
+integers; see <a href="#integer-encoding" class="xref">Section 16</a>.  A QUIC endpoint MUST NOT reuse a stream ID
+within a connection.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
+<p id="section-2.1-3">The least significant bit (0x1) of the stream ID identifies the initiator of the
+stream.  Client-initiated streams have even-numbered stream IDs (with the bit
+set to 0), and server-initiated streams have odd-numbered stream IDs (with the
+bit set to 1).<a href="#section-2.1-3" class="pilcrow">¶</a></p>
+<p id="section-2.1-4">The second least significant bit (0x2) of the stream ID distinguishes between
+bidirectional streams (with the bit set to 0) and unidirectional streams (with
+the bit set to 1).<a href="#section-2.1-4" class="pilcrow">¶</a></p>
+<p id="section-2.1-5">The least significant two bits from a stream ID therefore identify a stream as
+one of four types, as summarized in <a href="#stream-id-types" class="xref">Table 1</a>.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
+<span id="name-stream-id-types"></span><div id="stream-id-types">
+<table class="center" id="table-1">
+          <caption>
+<a href="#table-1" class="selfRef">Table 1</a>:
+<a href="#name-stream-id-types" class="selfRef">Stream ID Types</a>
+          </caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Bits</th>
+              <th class="text-left" rowspan="1" colspan="1">Stream Type</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x0</td>
+              <td class="text-left" rowspan="1" colspan="1">Client-Initiated, Bidirectional</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x1</td>
+              <td class="text-left" rowspan="1" colspan="1">Server-Initiated, Bidirectional</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x2</td>
+              <td class="text-left" rowspan="1" colspan="1">Client-Initiated, Unidirectional</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x3</td>
+              <td class="text-left" rowspan="1" colspan="1">Server-Initiated, Unidirectional</td>
+            </tr>
+          </tbody>
+        </table>
+</div>
+<p id="section-2.1-7">Within each type, streams are created with numerically increasing stream IDs.  A
+stream ID that is used out of order results in all streams of that type with
+lower-numbered stream IDs also being opened.<a href="#section-2.1-7" class="pilcrow">¶</a></p>
+<p id="section-2.1-8">The first bidirectional stream opened by the client has a stream ID of 0.<a href="#section-2.1-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="sending-and-receiving-data">
+<section id="section-2.2">
+        <h3 id="name-sending-and-receiving-data">
+<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-sending-and-receiving-data" class="section-name selfRef">Sending and Receiving Data</a>
+        </h3>
+<p id="section-2.2-1">STREAM frames (<a href="#frame-stream" class="xref">Section 19.8</a>) encapsulate data sent by an application. An
+endpoint uses the Stream ID and Offset fields in STREAM frames to place data in
+order.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
+<p id="section-2.2-2">Endpoints MUST be able to deliver stream data to an application as an ordered
+byte-stream.  Delivering an ordered byte-stream requires that an endpoint buffer
+any data that is received out of order, up to the advertised flow control limit.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
+<p id="section-2.2-3">QUIC makes no specific allowances for delivery of stream data out of
+order. However, implementations MAY choose to offer the ability to deliver data
+out of order to a receiving application.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
+<p id="section-2.2-4">An endpoint could receive data for a stream at the same stream offset multiple
+times.  Data that has already been received can be discarded.  The data at a
+given offset MUST NOT change if it is sent multiple times; an endpoint MAY treat
+receipt of different data at the same offset within a stream as a connection
+error of type PROTOCOL_VIOLATION.<a href="#section-2.2-4" class="pilcrow">¶</a></p>
+<p id="section-2.2-5">Streams are an ordered byte-stream abstraction with no other structure visible
+to QUIC.  STREAM frame boundaries are not expected to be preserved when
+data is transmitted, retransmitted after packet loss, or delivered to the
+application at a receiver.<a href="#section-2.2-5" class="pilcrow">¶</a></p>
+<p id="section-2.2-6">An endpoint MUST NOT send data on any stream without ensuring that it is within
+the flow control limits set by its peer.  Flow control is described in detail in
+<a href="#flow-control" class="xref">Section 4</a>.<a href="#section-2.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-prioritization">
+<section id="section-2.3">
+        <h3 id="name-stream-prioritization">
+<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-stream-prioritization" class="section-name selfRef">Stream Prioritization</a>
+        </h3>
+<p id="section-2.3-1">Stream multiplexing can have a significant effect on application performance if
+resources allocated to streams are correctly prioritized.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
+<p id="section-2.3-2">QUIC does not provide a mechanism for exchanging prioritization information.
+Instead, it relies on receiving priority information from the application that
+uses QUIC.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
+<p id="section-2.3-3">A QUIC implementation SHOULD provide ways in which an application can indicate
+the relative priority of streams.  When deciding which streams to dedicate
+resources to, the implementation SHOULD use the information provided by the
+application.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-operations">
+<section id="section-2.4">
+        <h3 id="name-required-operations-on-stre">
+<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-required-operations-on-stre" class="section-name selfRef">Required Operations on Streams</a>
+        </h3>
+<p id="section-2.4-1">There are certain operations which an application MUST be able to perform when
+interacting with QUIC streams.  This document does not specify an API, but
+any implementation of this version of QUIC MUST expose the ability to perform
+the operations described in this section on a QUIC stream.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
+<p id="section-2.4-2">On the sending part of a stream, application protocols need to be able to:<a href="#section-2.4-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-2.4-3.1">write data, understanding when stream flow control credit
+(<a href="#data-flow-control" class="xref">Section 4.1</a>) has successfully been reserved to send the written
+data;<a href="#section-2.4-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.4-3.2">end the stream (clean termination), resulting in a STREAM frame
+(<a href="#frame-stream" class="xref">Section 19.8</a>) with the FIN bit set; and<a href="#section-2.4-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.4-3.3">reset the stream (abrupt termination), resulting in a RESET_STREAM frame
+(<a href="#frame-reset-stream" class="xref">Section 19.4</a>), if the stream was not already in a terminal state.<a href="#section-2.4-3.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-2.4-4">On the receiving part of a stream, application protocols need to be able to:<a href="#section-2.4-4" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-2.4-5.1">read data; and<a href="#section-2.4-5.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-2.4-5.2">abort reading of the stream and request closure, possibly resulting in a
+STOP_SENDING frame (<a href="#frame-stop-sending" class="xref">Section 19.5</a>).<a href="#section-2.4-5.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-2.4-6">Applications also need to be informed of state changes on streams, including
+when the peer has opened or reset a stream, when a peer aborts reading on a
+stream, when new data is available, and when data can or cannot be written to
+the stream due to flow control.<a href="#section-2.4-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="stream-states">
+<section id="section-3">
+      <h2 id="name-stream-states">
+<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-stream-states" class="section-name selfRef">Stream States</a>
+      </h2>
+<p id="section-3-1">This section describes streams in terms of their send or receive components.
+Two state machines are described: one for the streams on which an endpoint
+transmits data (<a href="#stream-send-states" class="xref">Section 3.1</a>), and another for streams on which an
+endpoint receives data (<a href="#stream-recv-states" class="xref">Section 3.2</a>).<a href="#section-3-1" class="pilcrow">¶</a></p>
+<p id="section-3-2">Unidirectional streams use the applicable state machine directly.  Bidirectional
+streams use both state machines.  For the most part, the use of these state
+machines is the same whether the stream is unidirectional or bidirectional.  The
+conditions for opening a stream are slightly more complex for a bidirectional
+stream because the opening of either send or receive sides causes the stream
+to open in both directions.<a href="#section-3-2" class="pilcrow">¶</a></p>
+<p id="section-3-3">An endpoint MUST open streams of the same type in increasing order of stream ID.<a href="#section-3-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-3-4">
+        <dt id="section-3-4.1">Note:</dt>
+<dd id="section-3-4.2">
+  These states are largely informative.  This document uses stream states to
+describe rules for when and how different types of frames can be sent and the
+reactions that are expected when different types of frames are received.
+Though these state machines are intended to be useful in implementing QUIC,
+these states aren't intended to constrain implementations.  An implementation
+can define a different state machine as long as its behavior is consistent
+with an implementation that implements these states.<a href="#section-3-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<div id="stream-send-states">
+<section id="section-3.1">
+        <h3 id="name-sending-stream-states">
+<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-sending-stream-states" class="section-name selfRef">Sending Stream States</a>
+        </h3>
+<p id="section-3.1-1"><a href="#fig-stream-send-states" class="xref">Figure 2</a> shows the states for the part of a stream that sends
+data to a peer.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+<span id="name-states-for-sending-parts-of"></span><div id="fig-stream-send-states">
+<figure id="figure-2">
+          <div class="artwork art-text alignLeft" id="section-3.1-2.1">
+<pre>
+       o
+       | Create Stream (Sending)
+       | Peer Creates Bidirectional Stream
+       v
+   +-------+
+   | Ready | Send RESET_STREAM
+   |       |-----------------------.
+   +-------+                       |
+       |                           |
+       | Send STREAM /             |
+       |      STREAM_DATA_BLOCKED  |
+       |                           |
+       | Peer Creates              |
+       |      Bidirectional Stream |
+       v                           |
+   +-------+                       |
+   | Send  | Send RESET_STREAM     |
+   |       |----------------------&gt;|
+   +-------+                       |
+       |                           |
+       | Send STREAM + FIN         |
+       v                           v
+   +-------+                   +-------+
+   | Data  | Send RESET_STREAM | Reset |
+   | Sent  |------------------&gt;| Sent  |
+   +-------+                   +-------+
+       |                           |
+       | Recv All ACKs             | Recv ACK
+       v                           v
+   +-------+                   +-------+
+   | Data  |                   | Reset |
+   | Recvd |                   | Recvd |
+   +-------+                   +-------+
+</pre>
+</div>
+<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
+<a href="#name-states-for-sending-parts-of" class="selfRef">States for Sending Parts of Streams</a>
+          </figcaption></figure>
+</div>
+<p id="section-3.1-3">The sending part of stream that the endpoint initiates (types 0
+and 2 for clients, 1 and 3 for servers) is opened by the application.  The
+"Ready" state represents a newly created stream that is able to accept data from
+the application.  Stream data might be buffered in this state in preparation for
+sending.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
+<p id="section-3.1-4">Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a sending part of a
+stream to enter the "Send" state.  An implementation might choose to defer
+allocating a stream ID to a stream until it sends the first STREAM frame and
+enters this state, which can allow for better stream prioritization.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
+<p id="section-3.1-5">The sending part of a bidirectional stream initiated by a peer (type 0 for a
+server, type 1 for a client) starts in the "Ready" state when the receiving part
+is created.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
+<p id="section-3.1-6">In the "Send" state, an endpoint transmits - and retransmits as necessary -
+stream data in STREAM frames.  The endpoint respects the flow control limits set
+by its peer, and continues to accept and process MAX_STREAM_DATA frames.  An
+endpoint in the "Send" state generates STREAM_DATA_BLOCKED frames if it is
+blocked from sending by stream or connection flow control limits
+<a href="#data-flow-control" class="xref">Section 4.1</a>.<a href="#section-3.1-6" class="pilcrow">¶</a></p>
+<p id="section-3.1-7">After the application indicates that all stream data has been sent and a STREAM
+frame containing the FIN bit is sent, the sending part of the stream enters the
+"Data Sent" state.  From this state, the endpoint only retransmits stream data
+as necessary.  The endpoint does not need to check flow control limits or send
+STREAM_DATA_BLOCKED frames for a stream in this state.  MAX_STREAM_DATA frames
+might be received until the peer receives the final stream offset. The endpoint
+can safely ignore any MAX_STREAM_DATA frames it receives from its peer for a
+stream in this state.<a href="#section-3.1-7" class="pilcrow">¶</a></p>
+<p id="section-3.1-8">Once all stream data has been successfully acknowledged, the sending part of the
+stream enters the "Data Recvd" state, which is a terminal state.<a href="#section-3.1-8" class="pilcrow">¶</a></p>
+<p id="section-3.1-9">From any of the "Ready", "Send", or "Data Sent" states, an application can
+signal that it wishes to abandon transmission of stream data. Alternatively, an
+endpoint might receive a STOP_SENDING frame from its peer.  In either case, the
+endpoint sends a RESET_STREAM frame, which causes the stream to enter the "Reset
+Sent" state.<a href="#section-3.1-9" class="pilcrow">¶</a></p>
+<p id="section-3.1-10">An endpoint MAY send a RESET_STREAM as the first frame that mentions a stream;
+this causes the sending part of that stream to open and then immediately
+transition to the "Reset Sent" state.<a href="#section-3.1-10" class="pilcrow">¶</a></p>
+<p id="section-3.1-11">Once a packet containing a RESET_STREAM has been acknowledged, the sending part
+of the stream enters the "Reset Recvd" state, which is a terminal state.<a href="#section-3.1-11" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-recv-states">
+<section id="section-3.2">
+        <h3 id="name-receiving-stream-states">
+<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-receiving-stream-states" class="section-name selfRef">Receiving Stream States</a>
+        </h3>
+<p id="section-3.2-1"><a href="#fig-stream-recv-states" class="xref">Figure 3</a> shows the states for the part of a stream that
+receives data from a peer.  The states for a receiving part of a stream mirror
+only some of the states of the sending part of the stream at the peer.  The
+receiving part of a stream does not track states on the sending part that cannot
+be observed, such as the "Ready" state.  Instead, the receiving part of a stream
+tracks the delivery of data to the application, some of which cannot be observed
+by the sender.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
+<span id="name-states-for-receiving-parts-"></span><div id="fig-stream-recv-states">
+<figure id="figure-3">
+          <div class="artwork art-text alignLeft" id="section-3.2-2.1">
+<pre>
+       o
+       | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
+       | Create Bidirectional Stream (Sending)
+       | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)
+       | Create Higher-Numbered Stream
+       v
+   +-------+
+   | Recv  | Recv RESET_STREAM
+   |       |-----------------------.
+   +-------+                       |
+       |                           |
+       | Recv STREAM + FIN         |
+       v                           |
+   +-------+                       |
+   | Size  | Recv RESET_STREAM     |
+   | Known |----------------------&gt;|
+   +-------+                       |
+       |                           |
+       | Recv All Data             |
+       v                           v
+   +-------+ Recv RESET_STREAM +-------+
+   | Data  |--- (optional) ---&gt;| Reset |
+   | Recvd |  Recv All Data    | Recvd |
+   +-------+&lt;-- (optional) ----+-------+
+       |                           |
+       | App Read All Data         | App Read RST
+       v                           v
+   +-------+                   +-------+
+   | Data  |                   | Reset |
+   | Read  |                   | Read  |
+   +-------+                   +-------+
+</pre>
+</div>
+<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
+<a href="#name-states-for-receiving-parts-" class="selfRef">States for Receiving Parts of Streams</a>
+          </figcaption></figure>
+</div>
+<p id="section-3.2-3">The receiving part of a stream initiated by a peer (types 1 and 3 for a client,
+or 0 and 2 for a server) is created when the first STREAM, STREAM_DATA_BLOCKED,
+or RESET_STREAM is received for that stream.  For bidirectional streams
+initiated by a peer, receipt of a MAX_STREAM_DATA or STOP_SENDING frame for the
+sending part of the stream also creates the receiving part.  The initial state
+for the receiving part of stream is "Recv".<a href="#section-3.2-3" class="pilcrow">¶</a></p>
+<p id="section-3.2-4">The receiving part of a stream enters the "Recv" state when the sending part of
+a bidirectional stream initiated by the endpoint (type 0 for a client, type 1
+for a server) enters the "Ready" state.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
+<p id="section-3.2-5">An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or STOP_SENDING
+frame is received from the peer for that stream.  Receiving a MAX_STREAM_DATA
+frame for an unopened stream indicates that the remote peer has opened the
+stream and is providing flow control credit.  Receiving a STOP_SENDING frame for
+an unopened stream indicates that the remote peer no longer wishes to receive
+data on this stream.  Either frame might arrive before a STREAM or
+STREAM_DATA_BLOCKED frame if packets are lost or reordered.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
+<p id="section-3.2-6">Before a stream is created, all streams of the same type with lower-numbered
+stream IDs MUST be created.  This ensures that the creation order for streams is
+consistent on both endpoints.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
+<p id="section-3.2-7">In the "Recv" state, the endpoint receives STREAM and STREAM_DATA_BLOCKED
+frames.  Incoming data is buffered and can be reassembled into the correct order
+for delivery to the application.  As data is consumed by the application and
+buffer space becomes available, the endpoint sends MAX_STREAM_DATA frames to
+allow the peer to send more data.<a href="#section-3.2-7" class="pilcrow">¶</a></p>
+<p id="section-3.2-8">When a STREAM frame with a FIN bit is received, the final size of the stream is
+known; see <a href="#final-size" class="xref">Section 4.4</a>.  The receiving part of the stream then enters the
+"Size Known" state.  In this state, the endpoint no longer needs to send
+MAX_STREAM_DATA frames, it only receives any retransmissions of stream data.<a href="#section-3.2-8" class="pilcrow">¶</a></p>
+<p id="section-3.2-9">Once all data for the stream has been received, the receiving part enters the
+"Data Recvd" state.  This might happen as a result of receiving the same STREAM
+frame that causes the transition to "Size Known".  After all data has been
+received, any STREAM or STREAM_DATA_BLOCKED frames for the stream can be
+discarded.<a href="#section-3.2-9" class="pilcrow">¶</a></p>
+<p id="section-3.2-10">The "Data Recvd" state persists until stream data has been delivered to the
+application.  Once stream data has been delivered, the stream enters the "Data
+Read" state, which is a terminal state.<a href="#section-3.2-10" class="pilcrow">¶</a></p>
+<p id="section-3.2-11">Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states causes the
+stream to enter the "Reset Recvd" state.  This might cause the delivery of
+stream data to the application to be interrupted.<a href="#section-3.2-11" class="pilcrow">¶</a></p>
+<p id="section-3.2-12">It is possible that all stream data is received when a RESET_STREAM is received
+(that is, from the "Data Recvd" state).  Similarly, it is possible for remaining
+stream data to arrive after receiving a RESET_STREAM frame (the "Reset Recvd"
+state).  An implementation is free to manage this situation as it chooses.<a href="#section-3.2-12" class="pilcrow">¶</a></p>
+<p id="section-3.2-13">Sending RESET_STREAM means that an endpoint cannot guarantee delivery of stream
+data; however there is no requirement that stream data not be delivered if a
+RESET_STREAM is received.  An implementation MAY interrupt delivery of stream
+data, discard any data that was not consumed, and signal the receipt of the
+RESET_STREAM.  A RESET_STREAM signal might be suppressed or withheld if stream
+data is completely received and is buffered to be read by the application.  If
+the RESET_STREAM is suppressed, the receiving part of the stream remains in
+"Data Recvd".<a href="#section-3.2-13" class="pilcrow">¶</a></p>
+<p id="section-3.2-14">Once the application receives the signal indicating that the stream
+was reset, the receiving part of the stream transitions to the "Reset Read"
+state, which is a terminal state.<a href="#section-3.2-14" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="permitted-frame-types">
+<section id="section-3.3">
+        <h3 id="name-permitted-frame-types">
+<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-permitted-frame-types" class="section-name selfRef">Permitted Frame Types</a>
+        </h3>
+<p id="section-3.3-1">The sender of a stream sends just three frame types that affect the state of a
+stream at either sender or receiver: STREAM (<a href="#frame-stream" class="xref">Section 19.8</a>),
+STREAM_DATA_BLOCKED (<a href="#frame-stream-data-blocked" class="xref">Section 19.13</a>), and RESET_STREAM
+(<a href="#frame-reset-stream" class="xref">Section 19.4</a>).<a href="#section-3.3-1" class="pilcrow">¶</a></p>
+<p id="section-3.3-2">A sender MUST NOT send any of these frames from a terminal state ("Data Recvd"
+or "Reset Recvd").  A sender MUST NOT send STREAM or STREAM_DATA_BLOCKED after
+sending a RESET_STREAM; that is, in the terminal states and in the "Reset Sent"
+state.  A receiver could receive any of these three frames in any state, due to
+the possibility of delayed delivery of packets carrying them.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
+<p id="section-3.3-3">The receiver of a stream sends MAX_STREAM_DATA (<a href="#frame-max-stream-data" class="xref">Section 19.10</a>) and
+STOP_SENDING frames (<a href="#frame-stop-sending" class="xref">Section 19.5</a>).<a href="#section-3.3-3" class="pilcrow">¶</a></p>
+<p id="section-3.3-4">The receiver only sends MAX_STREAM_DATA in the "Recv" state.  A receiver can
+send STOP_SENDING in any state where it has not received a RESET_STREAM frame;
+that is states other than "Reset Recvd" or "Reset Read".  However there is
+little value in sending a STOP_SENDING frame in the "Data Recvd" state, since
+all stream data has been received.  A sender could receive either of these two
+frames in any state as a result of delayed delivery of packets.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-bidi-states">
+<section id="section-3.4">
+        <h3 id="name-bidirectional-stream-states">
+<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-bidirectional-stream-states" class="section-name selfRef">Bidirectional Stream States</a>
+        </h3>
+<p id="section-3.4-1">A bidirectional stream is composed of sending and receiving parts.
+Implementations may represent states of the bidirectional stream as composites
+of sending and receiving stream states.  The simplest model presents the stream
+as "open" when either sending or receiving parts are in a non-terminal state and
+"closed" when both sending and receiving streams are in terminal states.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
+<p id="section-3.4-2"><a href="#stream-bidi-mapping" class="xref">Table 2</a> shows a more complex mapping of bidirectional stream
+states that loosely correspond to the stream states in HTTP/2
+<span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>.  This shows that multiple states on sending or receiving
+parts of streams are mapped to the same composite state.  Note that this is just
+one possibility for such a mapping; this mapping requires that data is
+acknowledged before the transition to a "closed" or "half-closed" state.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
+<span id="name-possible-mapping-of-stream-"></span><div id="stream-bidi-mapping">
+<table class="center" id="table-2">
+          <caption>
+<a href="#table-2" class="selfRef">Table 2</a>:
+<a href="#name-possible-mapping-of-stream-" class="selfRef">Possible Mapping of Stream States to HTTP/2</a>
+          </caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Sending Part</th>
+              <th class="text-left" rowspan="1" colspan="1">Receiving Part</th>
+              <th class="text-left" rowspan="1" colspan="1">Composite State</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">No Stream/Ready</td>
+              <td class="text-left" rowspan="1" colspan="1">No Stream/Recv *1</td>
+              <td class="text-left" rowspan="1" colspan="1">idle</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Ready/Send/Data Sent</td>
+              <td class="text-left" rowspan="1" colspan="1">Recv/Size Known</td>
+              <td class="text-left" rowspan="1" colspan="1">open</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Ready/Send/Data Sent</td>
+              <td class="text-left" rowspan="1" colspan="1">Data Recvd/Data Read</td>
+              <td class="text-left" rowspan="1" colspan="1">half-closed (remote)</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Ready/Send/Data Sent</td>
+              <td class="text-left" rowspan="1" colspan="1">Reset Recvd/Reset Read</td>
+              <td class="text-left" rowspan="1" colspan="1">half-closed (remote)</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Data Recvd</td>
+              <td class="text-left" rowspan="1" colspan="1">Recv/Size Known</td>
+              <td class="text-left" rowspan="1" colspan="1">half-closed (local)</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Reset Sent/Reset Recvd</td>
+              <td class="text-left" rowspan="1" colspan="1">Recv/Size Known</td>
+              <td class="text-left" rowspan="1" colspan="1">half-closed (local)</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Reset Sent/Reset Recvd</td>
+              <td class="text-left" rowspan="1" colspan="1">Data Recvd/Data Read</td>
+              <td class="text-left" rowspan="1" colspan="1">closed</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Reset Sent/Reset Recvd</td>
+              <td class="text-left" rowspan="1" colspan="1">Reset Recvd/Reset Read</td>
+              <td class="text-left" rowspan="1" colspan="1">closed</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Data Recvd</td>
+              <td class="text-left" rowspan="1" colspan="1">Data Recvd/Data Read</td>
+              <td class="text-left" rowspan="1" colspan="1">closed</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">Data Recvd</td>
+              <td class="text-left" rowspan="1" colspan="1">Reset Recvd/Reset Read</td>
+              <td class="text-left" rowspan="1" colspan="1">closed</td>
+            </tr>
+          </tbody>
+        </table>
+</div>
+<dl class="dlParallel" id="section-3.4-4">
+          <dt id="section-3.4-4.1">Note (*1):</dt>
+<dd id="section-3.4-4.2">
+  A stream is considered "idle" if it has not yet been created, or if the
+receiving part of the stream is in the "Recv" state without yet having
+received any frames.<a href="#section-3.4-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="solicited-state-transitions">
+<section id="section-3.5">
+        <h3 id="name-solicited-state-transitions">
+<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-solicited-state-transitions" class="section-name selfRef">Solicited State Transitions</a>
+        </h3>
+<p id="section-3.5-1">If an application is no longer interested in the data it is receiving on a
+stream, it can abort reading the stream and specify an application error code.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
+<p id="section-3.5-2">If the stream is in the "Recv" or "Size Known" states, the transport SHOULD
+signal this by sending a STOP_SENDING frame to prompt closure of the stream in
+the opposite direction.  This typically indicates that the receiving application
+is no longer reading data it receives from the stream, but it is not a guarantee
+that incoming data will be ignored.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
+<p id="section-3.5-3">STREAM frames received after sending STOP_SENDING are still counted toward
+connection and stream flow control, even though these frames can be discarded
+upon receipt.<a href="#section-3.5-3" class="pilcrow">¶</a></p>
+<p id="section-3.5-4">A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM
+frame.  An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM
+frame if the stream is in the Ready or Send state.  If the stream is in the Data
+Sent state and any outstanding data is declared lost, an endpoint SHOULD send a
+RESET_STREAM frame in lieu of a retransmission.<a href="#section-3.5-4" class="pilcrow">¶</a></p>
+<p id="section-3.5-5">An endpoint SHOULD copy the error code from the STOP_SENDING frame to the
+RESET_STREAM frame it sends, but MAY use any application error code.  The
+endpoint that sends a STOP_SENDING frame MAY ignore the error code carried in
+any RESET_STREAM frame it receives.<a href="#section-3.5-5" class="pilcrow">¶</a></p>
+<p id="section-3.5-6">If the STOP_SENDING frame is received on a stream that is already in the
+"Data Sent" state, an endpoint that wishes to cease retransmission of
+previously-sent STREAM frames on that stream MUST first send a RESET_STREAM
+frame.<a href="#section-3.5-6" class="pilcrow">¶</a></p>
+<p id="section-3.5-7">STOP_SENDING SHOULD only be sent for a stream that has not been reset by the
+peer. STOP_SENDING is most useful for streams in the "Recv" or "Size Known"
+states.<a href="#section-3.5-7" class="pilcrow">¶</a></p>
+<p id="section-3.5-8">An endpoint is expected to send another STOP_SENDING frame if a packet
+containing a previous STOP_SENDING is lost.  However, once either all stream
+data or a RESET_STREAM frame has been received for the stream - that is, the
+stream is in any state other than "Recv" or "Size Known" - sending a
+STOP_SENDING frame is unnecessary.<a href="#section-3.5-8" class="pilcrow">¶</a></p>
+<p id="section-3.5-9">An endpoint that wishes to terminate both directions of a bidirectional stream
+can terminate one direction by sending a RESET_STREAM, and it can encourage
+prompt termination in the opposite direction by sending a STOP_SENDING frame.<a href="#section-3.5-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="flow-control">
+<section id="section-4">
+      <h2 id="name-flow-control">
+<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-flow-control" class="section-name selfRef">Flow Control</a>
+      </h2>
+<p id="section-4-1">It is necessary to limit the amount of data that a receiver could buffer, to
+prevent a fast sender from overwhelming a slow receiver, or to prevent a
+malicious sender from consuming a large amount of memory at a receiver.  To
+enable a receiver to limit memory commitment to a connection and to apply back
+pressure on the sender, streams are flow controlled both individually and as an
+aggregate.  A QUIC receiver controls the maximum amount of data the sender can
+send on a stream at any time, as described in <a href="#data-flow-control" class="xref">Section 4.1</a> and
+<a href="#fc-credit" class="xref">Section 4.2</a><a href="#section-4-1" class="pilcrow">¶</a></p>
+<p id="section-4-2">Similarly, to limit concurrency within a connection, a QUIC endpoint controls
+the maximum cumulative number of streams that its peer can initiate, as
+described in <a href="#controlling-concurrency" class="xref">Section 4.5</a>.<a href="#section-4-2" class="pilcrow">¶</a></p>
+<p id="section-4-3">Data sent in CRYPTO frames is not flow controlled in the same way as stream
+data.  QUIC relies on the cryptographic protocol implementation to avoid
+excessive buffering of data; see <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.  The implementation SHOULD
+provide an interface to QUIC to tell it about its buffering limits so that there
+is not excessive buffering at multiple layers.<a href="#section-4-3" class="pilcrow">¶</a></p>
+<div id="data-flow-control">
+<section id="section-4.1">
+        <h3 id="name-data-flow-control">
+<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-data-flow-control" class="section-name selfRef">Data Flow Control</a>
+        </h3>
+<p id="section-4.1-1">QUIC employs a credit-based flow-control scheme similar to that in HTTP/2
+<span>[<a href="#HTTP2" class="xref">HTTP2</a>]</span>, where a receiver advertises the number of bytes it is prepared to
+receive on a given stream and for the entire connection.  This leads to two
+levels of data flow control in QUIC:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-4.1-2.1">Stream flow control, which prevents a single stream from consuming the entire
+receive buffer for a connection by limiting the amount of data that can be
+sent on any stream.<a href="#section-4.1-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-4.1-2.2">Connection flow control, which prevents senders from exceeding a receiver's
+buffer capacity for the connection, by limiting the total bytes of stream data
+sent in STREAM frames on all streams.<a href="#section-4.1-2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-4.1-3">A receiver sets initial credits for all streams by sending transport parameters
+during the handshake (<a href="#transport-parameters" class="xref">Section 7.4</a>).  A receiver sends
+MAX_STREAM_DATA (<a href="#frame-max-stream-data" class="xref">Section 19.10</a>) or MAX_DATA (<a href="#frame-max-data" class="xref">Section 19.9</a>)
+frames to the sender to advertise additional credit.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
+<p id="section-4.1-4">A receiver advertises credit for a stream by sending a MAX_STREAM_DATA frame
+with the Stream ID field set appropriately.  A MAX_STREAM_DATA frame indicates
+the maximum absolute byte offset of a stream.  A receiver could use the current
+offset of data consumed to determine the flow control offset to be advertised.
+A receiver MAY send MAX_STREAM_DATA frames in multiple packets in order to make
+sure that the sender receives an update before running out of flow control
+credit, even if one of the packets is lost.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
+<p id="section-4.1-5">A receiver advertises credit for a connection by sending a MAX_DATA frame, which
+indicates the maximum of the sum of the absolute byte offsets of all streams.  A
+receiver maintains a cumulative sum of bytes received on all streams, which is
+used to check for flow control violations. A receiver might use a sum of bytes
+consumed on all streams to determine the maximum data limit to be advertised.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
+<p id="section-4.1-6">A receiver can advertise a larger offset by sending MAX_STREAM_DATA or MAX_DATA
+frames.  Once a receiver advertises an offset, it MAY advertise a smaller
+offset, but this has no effect.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
+<p id="section-4.1-7">A receiver MUST close the connection with a FLOW_CONTROL_ERROR error
+(<a href="#error-handling" class="xref">Section 11</a>) if the sender violates the advertised connection or stream
+data limits.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
+<p id="section-4.1-8">A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do not increase
+flow control limits.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
+<p id="section-4.1-9">If a sender runs out of flow control credit, it will be unable to send new data
+and is considered blocked.  A sender SHOULD send a STREAM_DATA_BLOCKED or
+DATA_BLOCKED frame to indicate it has data to write but is blocked by flow
+control limits.  If a sender is blocked for a period longer than the idle
+timeout (<a href="#idle-timeout" class="xref">Section 10.2</a>), the connection might be closed even when data is
+available for transmission.  To keep the connection from closing, a sender that
+is flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED or
+DATA_BLOCKED frame when it has no ack-eliciting packets in flight.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="fc-credit">
+<section id="section-4.2">
+        <h3 id="name-flow-credit-increments">
+<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-flow-credit-increments" class="section-name selfRef">Flow Credit Increments</a>
+        </h3>
+<p id="section-4.2-1">Implementations decide when and how much credit to advertise in MAX_STREAM_DATA
+and MAX_DATA frames, but this section offers a few considerations.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.2-2">To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or MAX_DATA
+frame multiple times within a round trip or send it early enough to allow for
+recovery from loss of the frame.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
+<p id="section-4.2-3">Control frames contribute to connection overhead. Therefore, frequently sending
+MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable.  On the
+other hand, if updates are less frequent, larger increments to limits are
+necessary to avoid blocking a sender, requiring larger resource commitments at
+the receiver.  There is a trade-off between resource commitment and overhead
+when determining how large a limit is advertised.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
+<p id="section-4.2-4">A receiver can use an autotuning mechanism to tune the frequency and amount of
+advertised additional credit based on a round-trip time estimate and the rate at
+which the receiving application consumes data, similar to common TCP
+implementations.  As an optimization, an endpoint could send frames related to
+flow control only when there are other frames to send or when a peer is blocked,
+ensuring that flow control does not cause extra packets to be sent.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
+<p id="section-4.2-5">A blocked sender is not required to send STREAM_DATA_BLOCKED or DATA_BLOCKED
+frames. Therefore, a receiver MUST NOT wait for a STREAM_DATA_BLOCKED or
+DATA_BLOCKED frame before sending a MAX_STREAM_DATA or MAX_DATA frame; doing so
+could result in the sender being blocked for the rest of the connection. Even if
+the sender sends these frames, waiting for them will result in the sender being
+blocked for at least an entire round trip.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
+<p id="section-4.2-6">When a sender receives credit after being blocked, it might be able to send a
+large amount of data in response, resulting in short-term congestion; see
+Section 6.9 in <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span> for a discussion of how a sender can avoid this
+congestion.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-cancellation">
+<section id="section-4.3">
+        <h3 id="name-handling-stream-cancellatio">
+<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-handling-stream-cancellatio" class="section-name selfRef">Handling Stream Cancellation</a>
+        </h3>
+<p id="section-4.3-1">Endpoints need to eventually agree on the amount of flow control credit that has
+been consumed, to avoid either exceeding flow control limits or deadlocking.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+<p id="section-4.3-2">On receipt of a RESET_STREAM frame, an endpoint will tear down state for the
+matching stream and ignore further data arriving on that stream.  Without the
+offset included in RESET_STREAM, the two endpoints could disagree on
+the number of bytes that count towards connection flow control.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
+<p id="section-4.3-3">To remedy this issue, a RESET_STREAM frame (<a href="#frame-reset-stream" class="xref">Section 19.4</a>) includes the
+final size of data sent on the stream.  On receiving a RESET_STREAM frame, a
+receiver definitively knows how many bytes were sent on that stream before the
+RESET_STREAM frame, and the receiver MUST use the final size of the stream to
+account for all bytes sent on the stream in its connection level flow
+controller.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
+<p id="section-4.3-4">RESET_STREAM terminates one direction of a stream abruptly.  For a bidirectional
+stream, RESET_STREAM has no effect on data flow in the opposite direction.  Both
+endpoints MUST maintain flow control state for the stream in the unterminated
+direction until that direction enters a terminal state, or until one of the
+endpoints sends CONNECTION_CLOSE.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="final-size">
+<section id="section-4.4">
+        <h3 id="name-stream-final-size">
+<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-stream-final-size" class="section-name selfRef">Stream Final Size</a>
+        </h3>
+<p id="section-4.4-1">The final size is the amount of flow control credit that is consumed by a
+stream.  Assuming that every contiguous byte on the stream was sent once, the
+final size is the number of bytes sent.  More generally, this is one higher
+than the offset of the byte with the largest offset sent on the stream, or zero
+if no bytes were sent.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
+<p id="section-4.4-2">For a stream that is reset, the final size is carried explicitly in a
+RESET_STREAM frame.  Otherwise, the final size is the offset plus the length of
+a STREAM frame marked with a FIN flag, or 0 in the case of incoming
+unidirectional streams.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
+<p id="section-4.4-3">An endpoint will know the final size for a stream when the receiving part of the
+stream enters the "Size Known" or "Reset Recvd" state (<a href="#stream-states" class="xref">Section 3</a>).<a href="#section-4.4-3" class="pilcrow">¶</a></p>
+<p id="section-4.4-4">An endpoint MUST NOT send data on a stream at or beyond the final size.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
+<p id="section-4.4-5">Once a final size for a stream is known, it cannot change.  If a RESET_STREAM or
+STREAM frame is received indicating a change in the final size for the stream,
+an endpoint SHOULD respond with a FINAL_SIZE_ERROR error; see
+<a href="#error-handling" class="xref">Section 11</a>.  A receiver SHOULD treat receipt of data at or beyond the
+final size as a FINAL_SIZE_ERROR error, even after a stream is closed.
+Generating these errors is not mandatory, but only because requiring that an
+endpoint generate these errors also means that the endpoint needs to maintain
+the final size state for closed streams, which could mean a significant state
+commitment.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="controlling-concurrency">
+<section id="section-4.5">
+        <h3 id="name-controlling-concurrency">
+<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-controlling-concurrency" class="section-name selfRef">Controlling Concurrency</a>
+        </h3>
+<p id="section-4.5-1">An endpoint limits the cumulative number of incoming streams a peer can open.
+Only streams with a stream ID less than (max_stream * 4 +
+initial_stream_id_for_type) can be opened; see <a href="#long-packet-types" class="xref">Table 5</a>.  Initial
+limits are set in the transport parameters (see
+<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>) and subsequently limits are advertised
+using MAX_STREAMS frames (<a href="#frame-max-streams" class="xref">Section 19.11</a>). Separate limits apply to
+unidirectional and bidirectional streams.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
+<p id="section-4.5-2">If a max_streams transport parameter or MAX_STREAMS frame is received with a
+value greater than 2^60, this would allow a maximum stream ID that cannot be
+expressed as a variable-length integer; see <a href="#integer-encoding" class="xref">Section 16</a>.
+If either is received, the connection MUST be closed immediately with a
+connection error of type STREAM_LIMIT_ERROR; see <a href="#immediate-close" class="xref">Section 10.3</a>.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
+<p id="section-4.5-3">Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that
+receives a frame with a stream ID exceeding the limit it has sent MUST treat
+this as a connection error of type STREAM_LIMIT_ERROR (<a href="#error-handling" class="xref">Section 11</a>).<a href="#section-4.5-3" class="pilcrow">¶</a></p>
+<p id="section-4.5-4">Once a receiver advertises a stream limit using the MAX_STREAMS frame,
+advertising a smaller limit has no effect.  A receiver MUST ignore any
+MAX_STREAMS frame that does not increase the stream limit.<a href="#section-4.5-4" class="pilcrow">¶</a></p>
+<p id="section-4.5-5">As with stream and connection flow control, this document leaves when and how
+many streams to advertise to a peer via MAX_STREAMS to implementations.
+Implementations might choose to increase limits as streams close to keep the
+number of streams available to peers roughly consistent.<a href="#section-4.5-5" class="pilcrow">¶</a></p>
+<p id="section-4.5-6">An endpoint that is unable to open a new stream due to the peer's limits SHOULD
+send a STREAMS_BLOCKED frame (<a href="#frame-streams-blocked" class="xref">Section 19.14</a>).  This signal is
+considered useful for debugging. An endpoint MUST NOT wait to receive this
+signal before advertising additional credit, since doing so will mean that the
+peer will be blocked for at least an entire round trip, and potentially for
+longer if the peer chooses to not send STREAMS_BLOCKED frames.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="connections">
+<section id="section-5">
+      <h2 id="name-connections">
+<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-connections" class="section-name selfRef">Connections</a>
+      </h2>
+<p id="section-5-1">QUIC's connection establishment combines version negotiation with the
+cryptographic and transport handshakes to reduce connection establishment
+latency, as described in <a href="#handshake" class="xref">Section 7</a>.  Once established, a connection
+may migrate to a different IP or port at either endpoint as
+described in <a href="#migration" class="xref">Section 9</a>.  Finally, a connection may be terminated by either
+endpoint, as described in <a href="#termination" class="xref">Section 10</a>.<a href="#section-5-1" class="pilcrow">¶</a></p>
+<div id="connection-id">
+<section id="section-5.1">
+        <h3 id="name-connection-id">
+<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-connection-id" class="section-name selfRef">Connection ID</a>
+        </h3>
+<p id="section-5.1-1">Each connection possesses a set of connection identifiers, or connection IDs,
+each of which can identify the connection.  Connection IDs are independently
+selected by endpoints; each endpoint selects the connection IDs that its peer
+uses.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.1-2">The primary function of a connection ID is to ensure that changes in addressing
+at lower protocol layers (UDP, IP) don't cause packets for a QUIC
+connection to be delivered to the wrong endpoint.  Each endpoint selects
+connection IDs using an implementation-specific (and perhaps
+deployment-specific) method which will allow packets with that connection ID to
+be routed back to the endpoint and identified by the endpoint upon receipt.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.1-3">Connection IDs MUST NOT contain any information that can be used by an external
+observer (that is, one that does not cooperate with the issuer) to correlate
+them with other connection IDs for the same connection.  As a trivial example,
+this means the same connection ID MUST NOT be issued more than once on the same
+connection.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
+<p id="section-5.1-4">Packets with long headers include Source Connection ID and Destination
+Connection ID fields.  These fields are used to set the connection IDs for new
+connections; see <a href="#negotiating-connection-ids" class="xref">Section 7.2</a> for details.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
+<p id="section-5.1-5">Packets with short headers (<a href="#short-header" class="xref">Section 17.3</a>) only include the Destination
+Connection ID and omit the explicit length.  The length of the Destination
+Connection ID field is expected to be known to endpoints.  Endpoints using a
+load balancer that routes based on connection ID could agree with the load
+balancer on a fixed length for connection IDs, or agree on an encoding scheme.
+A fixed portion could encode an explicit length, which allows the entire
+connection ID to vary in length and still be used by the load balancer.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
+<p id="section-5.1-6">A Version Negotiation (<a href="#packet-version" class="xref">Section 17.2.1</a>) packet echoes the connection IDs
+selected by the client, both to ensure correct routing toward the client and to
+allow the client to validate that the packet is in response to an Initial
+packet.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
+<p id="section-5.1-7">A zero-length connection ID can be used when a connection ID is not needed to
+route to the correct endpoint. However, multiplexing connections on the same
+local IP address and port while using zero-length connection IDs will cause
+failures in the presence of peer connection migration, NAT rebinding, and client
+port reuse; and therefore MUST NOT be done unless an endpoint is certain that
+those protocol features are not in use.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
+<p id="section-5.1-8">When an endpoint uses a non-zero-length connection ID, it needs to ensure that
+the peer has a supply of connection IDs from which to choose for packets sent to
+the endpoint.  These connection IDs are supplied by the endpoint using the
+NEW_CONNECTION_ID frame (<a href="#frame-new-connection-id" class="xref">Section 19.15</a>).<a href="#section-5.1-8" class="pilcrow">¶</a></p>
+<div id="issue-cid">
+<section id="section-5.1.1">
+          <h4 id="name-issuing-connection-ids">
+<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-issuing-connection-ids" class="section-name selfRef">Issuing Connection IDs</a>
+          </h4>
+<p id="section-5.1.1-1">Each Connection ID has an associated sequence number to assist in deduplicating
+messages.  The initial connection ID issued by an endpoint is sent in the Source
+Connection ID field of the long packet header (<a href="#long-header" class="xref">Section 17.2</a>) during the
+handshake.  The sequence number of the initial connection ID is 0.  If the
+preferred_address transport parameter is sent, the sequence number of the
+supplied connection ID is 1.<a href="#section-5.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.1.1-2">Additional connection IDs are communicated to the peer using NEW_CONNECTION_ID
+frames (<a href="#frame-new-connection-id" class="xref">Section 19.15</a>).  The sequence number on each newly-issued
+connection ID MUST increase by 1.  The connection ID randomly selected by the
+client in the Initial packet and any connection ID provided by a Retry packet
+are not assigned sequence numbers unless a server opts to retain them as its
+initial connection ID.<a href="#section-5.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.1.1-3">When an endpoint issues a connection ID, it MUST accept packets that carry this
+connection ID for the duration of the connection or until its peer invalidates
+the connection ID via a RETIRE_CONNECTION_ID frame
+(<a href="#frame-retire-connection-id" class="xref">Section 19.16</a>).  Connection IDs that are issued and not
+retired are considered active; any active connection ID is valid for use with
+the current connection at any time, in any packet type.  This includes the
+connection ID issued by the server via the preferred_address transport
+parameter.<a href="#section-5.1.1-3" class="pilcrow">¶</a></p>
+<p id="section-5.1.1-4">An endpoint SHOULD ensure that its peer has a sufficient number of available and
+unused connection IDs.  Endpoints advertise the number of active connection IDs
+they are willing to maintain using the active_connection_id_limit transport
+parameter.  An endpoint MUST NOT provide more connection IDs than the peer's
+limit.  An endpoint MAY send connection IDs that temporarily exceed a peer's
+limit if the NEW_CONNECTION_ID frame also requires the retirement of any excess,
+by including a sufficiently large value in the Retire Prior To field.<a href="#section-5.1.1-4" class="pilcrow">¶</a></p>
+<p id="section-5.1.1-5">A NEW_CONNECTION_ID frame might cause an endpoint to add some active connection
+IDs and retire others based on the value of the Retire Prior To field.  After
+processing a NEW_CONNECTION_ID frame and adding and retiring active connection
+IDs, if the number of active connection IDs exceeds the value advertised in its
+active_connection_id_limit transport parameter, an endpoint MUST close the
+connection with an error of type CONNECTION_ID_LIMIT_ERROR.<a href="#section-5.1.1-5" class="pilcrow">¶</a></p>
+<p id="section-5.1.1-6">An endpoint SHOULD supply a new connection ID when the peer retires a connection
+ID.  If an endpoint provided fewer connection IDs than the peer's
+active_connection_id_limit, it MAY supply a new connection ID when it receives a
+packet with a previously unused connection ID.  An endpoint MAY limit the
+frequency or the total number of connection IDs issued for each connection to
+avoid the risk of running out of connection IDs; see <a href="#reset-token" class="xref">Section 10.4.2</a>.  An
+endpoint MAY also limit the issuance of connection IDs to reduce the amount of
+per-path state it maintains, such as path validation status, as its peer
+might interact with it over as many paths as there are issued connection
+IDs.<a href="#section-5.1.1-6" class="pilcrow">¶</a></p>
+<p id="section-5.1.1-7">An endpoint that initiates migration and requires non-zero-length connection IDs
+SHOULD ensure that the pool of connection IDs available to its peer allows the
+peer to use a new connection ID on migration, as the peer will close the
+connection if the pool is exhausted.<a href="#section-5.1.1-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="retire-cid">
+<section id="section-5.1.2">
+          <h4 id="name-consuming-and-retiring-conn">
+<a href="#section-5.1.2" class="section-number selfRef">5.1.2. </a><a href="#name-consuming-and-retiring-conn" class="section-name selfRef">Consuming and Retiring Connection IDs</a>
+          </h4>
+<p id="section-5.1.2-1">An endpoint can change the connection ID it uses for a peer to another available
+one at any time during the connection.  An endpoint consumes connection IDs in
+response to a migrating peer; see <a href="#migration-linkability" class="xref">Section 9.5</a> for more.<a href="#section-5.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.1.2-2">An endpoint maintains a set of connection IDs received from its peer, any of
+which it can use when sending packets.  When the endpoint wishes to remove a
+connection ID from use, it sends a RETIRE_CONNECTION_ID frame to its peer.
+Sending a RETIRE_CONNECTION_ID frame indicates that the connection ID will not
+be used again and requests that the peer replace it with a new connection ID
+using a NEW_CONNECTION_ID frame.<a href="#section-5.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-5.1.2-3">As discussed in <a href="#migration-linkability" class="xref">Section 9.5</a>, endpoints limit the use of a
+connection ID to packets sent from a single local address to a single
+destination address.  Endpoints SHOULD retire connection IDs when they are no
+longer actively using either the local or destination address for which the
+connection ID was used.<a href="#section-5.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.1.2-4">An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.<a href="#section-5.1.2-4" class="pilcrow">¶</a></p>
+<p id="section-5.1.2-5">Upon receipt of an increased Retire Prior To field, the peer MUST stop using
+the corresponding connection IDs and retire them with RETIRE_CONNECTION_ID
+frames before adding the newly provided connection ID to the set of active
+connection IDs. This ordering allows an endpoint to replace all active
+connection IDs without the possibility of a peer having no available connection
+IDs and without exceeding the limit the peer sets in the
+active_connection_id_limit transport parameter; see
+<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>. Failure to cease using the connection IDs
+when requested can result in connection failures, as the issuing endpoint might
+be unable to continue using the connection IDs with the active connection.<a href="#section-5.1.2-5" class="pilcrow">¶</a></p>
+<p id="section-5.1.2-6">An endpoint SHOULD limit the number of connection IDs it has retired locally and
+have not yet been acknowledged. An endpoint SHOULD allow for sending and
+tracking a number of RETIRE_CONNECTION_ID frames of at least twice the
+active_connection_id limit. An endpoint MUST NOT forget a connection ID without
+retiring it, though it MAY choose to treat having connection IDs in need of
+retirement that exceed this limit as a connection error of type
+CONNECTION_ID_LIMIT_ERROR.<a href="#section-5.1.2-6" class="pilcrow">¶</a></p>
+<p id="section-5.1.2-7">Endpoints SHOULD NOT issue updates of the Retire Prior To field before receiving
+RETIRE_CONNECTION_ID frames that retire all connection IDs indicated by the
+previous Retire Prior To value.<a href="#section-5.1.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="packet-handling">
+<section id="section-5.2">
+        <h3 id="name-matching-packets-to-connect">
+<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-matching-packets-to-connect" class="section-name selfRef">Matching Packets to Connections</a>
+        </h3>
+<p id="section-5.2-1">Incoming packets are classified on receipt.  Packets can either be associated
+with an existing connection, or - for servers - potentially create a new
+connection.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.2-2">Endpoints try to associate a packet with an existing connection. If the packet
+has a non-zero-length Destination Connection ID corresponding to an existing
+connection, QUIC processes that packet accordingly. Note that more than one
+connection ID can be associated with a connection; see <a href="#connection-id" class="xref">Section 5.1</a>.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
+<p id="section-5.2-3">If the Destination Connection ID is zero length and the addressing information
+in the packet matches the addressing information the endpoint uses to identify a
+connection with a zero-length connection ID, QUIC processes the packet as part
+of that connection.  An endpoint can use just destination IP and port or both
+source and destination addresses for identification, though this makes
+connections fragile as described in <a href="#connection-id" class="xref">Section 5.1</a>.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.2-4">Endpoints can send a Stateless Reset (<a href="#stateless-reset" class="xref">Section 10.4</a>) for any packets that
+cannot be attributed to an existing connection. A stateless reset allows a peer
+to more quickly identify when a connection becomes unusable.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
+<p id="section-5.2-5">Packets that are matched to an existing connection are discarded if the packets
+are inconsistent with the state of that connection.  For example, packets are
+discarded if they indicate a different protocol version than that of the
+connection, or if the removal of packet protection is unsuccessful once the
+expected keys are available.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
+<p id="section-5.2-6">Invalid packets without packet protection, such as Initial, Retry, or Version
+Negotiation, MAY be discarded.  An endpoint MUST generate a connection error if
+it commits changes to state before discovering an error.<a href="#section-5.2-6" class="pilcrow">¶</a></p>
+<div id="client-pkt-handling">
+<section id="section-5.2.1">
+          <h4 id="name-client-packet-handling">
+<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-client-packet-handling" class="section-name selfRef">Client Packet Handling</a>
+          </h4>
+<p id="section-5.2.1-1">Valid packets sent to clients always include a Destination Connection ID that
+matches a value the client selects.  Clients that choose to receive
+zero-length connection IDs can use the local address and port to identify a
+connection.  Packets that don't match an existing connection are discarded.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-2">Due to packet reordering or loss, a client might receive packets for a
+connection that are encrypted with a key it has not yet computed. The client MAY
+drop these packets, or MAY buffer them in anticipation of later packets that
+allow it to compute the key.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-3">If a client receives a packet that has an unsupported version, it MUST discard
+that packet.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="server-pkt-handling">
+<section id="section-5.2.2">
+          <h4 id="name-server-packet-handling">
+<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-server-packet-handling" class="section-name selfRef">Server Packet Handling</a>
+          </h4>
+<p id="section-5.2.2-1">If a server receives a packet that has an unsupported version, but the packet is
+sufficiently large to initiate a new connection for any version supported by the
+server, it SHOULD send a Version Negotiation packet as described in
+<a href="#send-vn" class="xref">Section 6.1</a>. Servers MAY rate control these packets to avoid storms of Version
+Negotiation packets.  Otherwise, servers MUST drop packets that specify
+unsupported versions.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-2">The first packet for an unsupported version can use different semantics and
+encodings for any version-specific field.  In particular, different packet
+protection keys might be used for different versions.  Servers that do not
+support a particular version are unlikely to be able to decrypt the payload of
+the packet.  Servers SHOULD NOT attempt to decode or decrypt a packet from an
+unknown version, but instead send a Version Negotiation packet, provided that
+the packet is sufficiently long.<a href="#section-5.2.2-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-3">Packets with a supported version, or no version field, are matched to a
+connection using the connection ID or - for packets with zero-length connection
+IDs - the local address and port.  If the packet doesn't match an existing
+connection, the server continues below.<a href="#section-5.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-4">If the packet is an Initial packet fully conforming with the specification, the
+server proceeds with the handshake (<a href="#handshake" class="xref">Section 7</a>). This commits the server to
+the version that the client selected.<a href="#section-5.2.2-4" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-5">If a server refuses to accept a new connection, it SHOULD send an Initial packet
+containing a CONNECTION_CLOSE frame with error code CONNECTION_REFUSED.<a href="#section-5.2.2-5" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-6">If the packet is a 0-RTT packet, the server MAY buffer a limited number of these
+packets in anticipation of a late-arriving Initial packet. Clients are not able
+to send Handshake packets prior to receiving a server response, so servers
+SHOULD ignore any such packets.<a href="#section-5.2.2-6" class="pilcrow">¶</a></p>
+<p id="section-5.2.2-7">Servers MUST drop incoming packets under all other circumstances.<a href="#section-5.2.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="considerations-for-simple-load-balancers">
+<section id="section-5.2.3">
+          <h4 id="name-considerations-for-simple-l">
+<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-considerations-for-simple-l" class="section-name selfRef">Considerations for Simple Load Balancers</a>
+          </h4>
+<p id="section-5.2.3-1">A server deployment could load balance among servers using only source and
+destination IP addresses and ports. Changes to the client's IP address or port
+could result in packets being forwarded to the wrong server. Such a server
+deployment could use one of the following methods for connection continuity
+when a client's address changes.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.2.3-2.1">Servers could use an out-of-band mechanism to forward packets to the correct
+server based on Connection ID.<a href="#section-5.2.3-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.2.3-2.2">If servers can use a dedicated server IP address or port, other than the one
+that the client initially connects to, they could use the preferred_address
+transport parameter to request that clients move connections to that dedicated
+address. Note that clients could choose not to use the preferred address.<a href="#section-5.2.3-2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-5.2.3-3">A server in a deployment that does not implement a solution to
+maintain connection continuity during connection migration
+SHOULD disallow migration using the disable_active_migration transport
+parameter.<a href="#section-5.2.3-3" class="pilcrow">¶</a></p>
+<p id="section-5.2.3-4">Server deployments that use this simple form of load balancing MUST avoid the
+creation of a stateless reset oracle; see <a href="#reset-oracle" class="xref">Section 21.9</a>.<a href="#section-5.2.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="connection-lifecycle">
+<section id="section-5.3">
+        <h3 id="name-life-of-a-quic-connection">
+<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-life-of-a-quic-connection" class="section-name selfRef">Life of a QUIC Connection</a>
+        </h3>
+<p id="section-5.3-1">A QUIC connection is a stateful interaction between a client and server, the
+primary purpose of which is to support the exchange of data by an application
+protocol.  Streams (<a href="#streams" class="xref">Section 2</a>) are the primary means by which an application
+protocol exchanges information.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
+<p id="section-5.3-2">Each connection starts with a handshake phase, during which client and server
+establish a shared secret using the cryptographic handshake protocol
+<span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span> and negotiate the application protocol.  The handshake
+(<a href="#handshake" class="xref">Section 7</a>) confirms that both endpoints are willing to communicate
+(<a href="#validate-handshake" class="xref">Section 8.1</a>) and establishes parameters for the connection
+(<a href="#transport-parameters" class="xref">Section 7.4</a>).<a href="#section-5.3-2" class="pilcrow">¶</a></p>
+<p id="section-5.3-3">An application protocol can also operate in a limited fashion during the
+handshake phase.  0-RTT allows application messages to be sent by a client
+before receiving any messages from the server.  However, 0-RTT lacks certain key
+security guarantees. In particular, there is no protection against replay
+attacks in 0-RTT; see <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.  Separately, a server can also send
+application data to a client before it receives the final cryptographic
+handshake messages that allow it to confirm the identity and liveness of the
+client.  These capabilities allow an application protocol to offer the option to
+trade some security guarantees for reduced latency.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
+<p id="section-5.3-4">The use of connection IDs (<a href="#connection-id" class="xref">Section 5.1</a>) allows connections to migrate to a
+new network path, both as a direct choice of an endpoint and when forced by a
+change in a middlebox.  <a href="#migration" class="xref">Section 9</a> describes mitigations for the security and
+privacy issues associated with migration.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
+<p id="section-5.3-5">For connections that are no longer needed or desired, there are several ways for
+a client and server to terminate a connection (<a href="#termination" class="xref">Section 10</a>).<a href="#section-5.3-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="required-operations-on-connections">
+<section id="section-5.4">
+        <h3 id="name-required-operations-on-conn">
+<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-required-operations-on-conn" class="section-name selfRef">Required Operations on Connections</a>
+        </h3>
+<p id="section-5.4-1">There are certain operations which an application MUST be able to perform when
+interacting with the QUIC transport.  This document does not specify an API, but
+any implementation of this version of QUIC MUST expose the ability to perform
+the operations described in this section on a QUIC connection.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
+<p id="section-5.4-2">When implementing the client role, applications need to be able to:<a href="#section-5.4-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.4-3.1">open a connection, which begins the exchange described in <a href="#handshake" class="xref">Section 7</a>;<a href="#section-5.4-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.4-3.2">enable 0-RTT when available; and<a href="#section-5.4-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.4-3.3">be informed when 0-RTT has been accepted or rejected by a server.<a href="#section-5.4-3.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-5.4-4">When implementing the server role, applications need to be able to:<a href="#section-5.4-4" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.4-5.1">listen for incoming connections, which prepares for the exchange described in
+<a href="#handshake" class="xref">Section 7</a>;<a href="#section-5.4-5.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.4-5.2">if Early Data is supported, embed application-controlled data in the TLS
+resumption ticket sent to the client; and<a href="#section-5.4-5.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.4-5.3">if Early Data is supported, retrieve application-controlled data from the
+client's resumption ticket and enable rejecting Early Data based on that
+information.<a href="#section-5.4-5.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-5.4-6">In either role, applications need to be able to:<a href="#section-5.4-6" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-5.4-7.1">configure minimum values for the initial number of permitted streams of each
+type, as communicated in the transport parameters (<a href="#transport-parameters" class="xref">Section 7.4</a>);<a href="#section-5.4-7.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.4-7.2">control resource allocation of various types, including flow control and the
+number of permitted streams of each type;<a href="#section-5.4-7.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.4-7.3">identify whether the handshake has completed successfully or is still ongoing;<a href="#section-5.4-7.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.4-7.4">keep a connection from silently closing, either by generating PING frames
+(<a href="#frame-ping" class="xref">Section 19.2</a>) or by requesting that the transport send additional frames
+before the idle timeout expires (<a href="#idle-timeout" class="xref">Section 10.2</a>); and<a href="#section-5.4-7.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-5.4-7.5">immediately close (<a href="#immediate-close" class="xref">Section 10.3</a>) the connection.<a href="#section-5.4-7.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+</section>
+</div>
+<div id="version-negotiation">
+<section id="section-6">
+      <h2 id="name-version-negotiation">
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-version-negotiation" class="section-name selfRef">Version Negotiation</a>
+      </h2>
+<p id="section-6-1">Version negotiation ensures that client and server agree to a QUIC version
+that is mutually supported. A server sends a Version Negotiation packet in
+response to each packet that might initiate a new connection; see
+<a href="#packet-handling" class="xref">Section 5.2</a> for details.<a href="#section-6-1" class="pilcrow">¶</a></p>
+<p id="section-6-2">The size of the first packet sent by a client will determine whether a server
+sends a Version Negotiation packet. Clients that support multiple QUIC versions
+SHOULD pad the first packet they send to the largest of the minimum packet sizes
+across all versions they support. This ensures that the server responds if there
+is a mutually supported version.<a href="#section-6-2" class="pilcrow">¶</a></p>
+<div id="send-vn">
+<section id="section-6.1">
+        <h3 id="name-sending-version-negotiation">
+<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-sending-version-negotiation" class="section-name selfRef">Sending Version Negotiation Packets</a>
+        </h3>
+<p id="section-6.1-1">If the version selected by the client is not acceptable to the server, the
+server responds with a Version Negotiation packet; see <a href="#packet-version" class="xref">Section 17.2.1</a>.  This
+includes a list of versions that the server will accept.  An endpoint MUST NOT
+send a Version Negotiation packet in response to receiving a Version Negotiation
+packet.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
+<p id="section-6.1-2">This system allows a server to process packets with unsupported versions without
+retaining state.  Though either the Initial packet or the Version Negotiation
+packet that is sent in response could be lost, the client will send new packets
+until it successfully receives a response or it abandons the connection attempt.
+As a result, the client discards all state for the connection and does not send
+any more packets on the connection.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
+<p id="section-6.1-3">A server MAY limit the number of Version Negotiation packets it sends.  For
+instance, a server that is able to recognize packets as 0-RTT might choose not
+to send Version Negotiation packets in response to 0-RTT packets with the
+expectation that it will eventually receive an Initial packet.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="handle-vn">
+<section id="section-6.2">
+        <h3 id="name-handling-version-negotiatio">
+<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-handling-version-negotiatio" class="section-name selfRef">Handling Version Negotiation Packets</a>
+        </h3>
+<p id="section-6.2-1">Version Negotiation packets are designed to allow future versions of QUIC to
+negotiate the version in use between endpoints.  Future versions of QUIC might
+change how implementations that support multiple versions of QUIC react to
+Version Negotiation packets when attempting to establish a connection using this
+version.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
+<p id="section-6.2-2">A client that supports only this version of QUIC MUST abandon the current
+connection attempt if it receives a Version Negotiation packet, with the
+following two exceptions. A client MUST discard any Version Negotiation packet
+if it has received and successfully processed any other packet, including an
+earlier Version Negotiation packet. A client MUST discard a Version Negotiation
+packet that lists the QUIC version selected by the client.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.2-3">How to perform version negotiation is left as future work defined by future
+versions of QUIC.  In particular, that future work will ensure robustness
+against version downgrade attacks; see <a href="#version-downgrade" class="xref">Section 21.10</a>.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
+<div id="version-negotiation-between-draft-versions">
+<section id="section-6.2.1">
+          <h4 id="name-version-negotiation-between">
+<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-version-negotiation-between" class="section-name selfRef">Version Negotiation Between Draft Versions</a>
+          </h4>
+<p id="section-6.2.1-1">[[RFC editor: please remove this section before publication.]]<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-2">When a draft implementation receives a Version Negotiation packet, it MAY use
+it to attempt a new connection with one of the versions listed in the packet,
+instead of abandoning the current connection attempt; see <a href="#handle-vn" class="xref">Section 6.2</a>.<a href="#section-6.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-3">The client MUST check that the Destination and Source Connection ID fields
+match the Source and Destination Connection ID fields in a packet that the
+client sent.  If this check fails, the packet MUST be discarded.<a href="#section-6.2.1-3" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-4">Once the Version Negotiation packet is determined to be valid, the client then
+selects an acceptable protocol version from the list provided by the server.
+The client then attempts to create a new connection using that version. The new
+connection MUST use a new random Destination Connection ID different from the
+one it had previously sent.<a href="#section-6.2.1-4" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-5">Note that this mechanism does not protect against downgrade attacks and
+MUST NOT be used outside of draft implementations.<a href="#section-6.2.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="using-reserved-versions">
+<section id="section-6.3">
+        <h3 id="name-using-reserved-versions">
+<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-using-reserved-versions" class="section-name selfRef">Using Reserved Versions</a>
+        </h3>
+<p id="section-6.3-1">For a server to use a new version in the future, clients need to correctly
+handle unsupported versions. Some version numbers (0x?a?a?a?a as defined in
+<a href="#versions" class="xref">Section 15</a>) are reserved for inclusion in fields that contain version
+numbers.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
+<p id="section-6.3-2">Endpoints MAY add reserved versions to any field where unknown or unsupported
+versions are ignored to test that a peer correctly ignores the value. For
+instance, an endpoint could include a reserved version in a Version Negotiation
+packet; see <a href="#packet-version" class="xref">Section 17.2.1</a>. Endpoints MAY send packets with a reserved
+version to test that a peer correctly discards the packet.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="handshake">
+<section id="section-7">
+      <h2 id="name-cryptographic-and-transport">
+<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-cryptographic-and-transport" class="section-name selfRef">Cryptographic and Transport Handshake</a>
+      </h2>
+<p id="section-7-1">QUIC relies on a combined cryptographic and transport handshake to minimize
+connection establishment latency.  QUIC uses the CRYPTO frame <a href="#frame-crypto" class="xref">Section 19.6</a>
+to transmit the cryptographic handshake.  Version 0x00000001 of QUIC uses TLS as
+described in <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>; a different QUIC version number could indicate that a
+different cryptographic handshake protocol is in use.<a href="#section-7-1" class="pilcrow">¶</a></p>
+<p id="section-7-2">QUIC provides reliable, ordered delivery of the cryptographic handshake
+data. QUIC packet protection is used to encrypt as much of the handshake
+protocol as possible. The cryptographic handshake MUST provide the following
+properties:<a href="#section-7-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-7-3.1">
+          <p id="section-7-3.1.1">authenticated key exchange, where<a href="#section-7-3.1.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-7-3.1.2.1">a server is always authenticated,<a href="#section-7-3.1.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7-3.1.2.2">a client is optionally authenticated,<a href="#section-7-3.1.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7-3.1.2.3">every connection produces distinct and unrelated keys,<a href="#section-7-3.1.2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7-3.1.2.4">keying material is usable for packet protection for both 0-RTT and 1-RTT
+packets, and<a href="#section-7-3.1.2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7-3.1.2.5">1-RTT keys have forward secrecy<a href="#section-7-3.1.2.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-7-3.2">authenticated values for transport parameters of both endpoints, and
+confidentiality protection for server transport parameters (see
+<a href="#transport-parameters" class="xref">Section 7.4</a>)<a href="#section-7-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7-3.3">authenticated negotiation of an application protocol (TLS uses ALPN
+<span>[<a href="#RFC7301" class="xref">RFC7301</a>]</span> for this purpose)<a href="#section-7-3.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-7-4">An endpoint can verify support for Explicit Congestion Notification (ECN) in the
+first packets it sends, as described in <a href="#ecn-validation" class="xref">Section 13.4.2</a>.<a href="#section-7-4" class="pilcrow">¶</a></p>
+<p id="section-7-5">The CRYPTO frame can be sent in different packet number spaces
+(<a href="#packet-numbers" class="xref">Section 12.3</a>).  The sequence numbers used by CRYPTO frames to ensure
+ordered delivery of cryptographic handshake data start from zero in each
+packet number space.<a href="#section-7-5" class="pilcrow">¶</a></p>
+<p id="section-7-6">Endpoints MUST explicitly negotiate an application protocol.  This avoids
+situations where there is a disagreement about the protocol that is in use.<a href="#section-7-6" class="pilcrow">¶</a></p>
+<div id="example-handshake-flows">
+<section id="section-7.1">
+        <h3 id="name-example-handshake-flows">
+<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-example-handshake-flows" class="section-name selfRef">Example Handshake Flows</a>
+        </h3>
+<p id="section-7.1-1">Details of how TLS is integrated with QUIC are provided in <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>, but
+some examples are provided here.  An extension of this exchange to support
+client address validation is shown in <a href="#validate-retry" class="xref">Section 8.1.2</a>.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
+<p id="section-7.1-2">Once any address validation exchanges are complete, the
+cryptographic handshake is used to agree on cryptographic keys.  The
+cryptographic handshake is carried in Initial (<a href="#packet-initial" class="xref">Section 17.2.2</a>) and Handshake
+(<a href="#packet-handshake" class="xref">Section 17.2.4</a>) packets.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
+<p id="section-7.1-3"><a href="#tls-1rtt-handshake" class="xref">Figure 4</a> provides an overview of the 1-RTT handshake.  Each line
+shows a QUIC packet with the packet type and packet number shown first, followed
+by the frames that are typically contained in those packets. So, for instance
+the first packet is of type Initial, with packet number 0, and contains a CRYPTO
+frame carrying the ClientHello.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
+<p id="section-7.1-4">Note that multiple QUIC packets - even of different packet types - can be
+coalesced into a single UDP datagram; see <a href="#packet-coalesce" class="xref">Section 12.2</a>). As a result,
+this handshake may consist of as few as 4 UDP datagrams, or any number more.
+For instance, the server's first flight contains Initial packets,
+Handshake packets, and "0.5-RTT data" in 1-RTT packets with a short header.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
+<span id="name-example-1-rtt-handshake"></span><div id="tls-1rtt-handshake">
+<figure id="figure-4">
+          <div class="artwork art-text alignLeft" id="section-7.1-5.1">
+<pre>
+Client                                                  Server
+
+Initial[0]: CRYPTO[CH] -&gt;
+
+                                 Initial[0]: CRYPTO[SH] ACK[0]
+                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
+                                 &lt;- 1-RTT[0]: STREAM[1, "..."]
+
+Initial[1]: ACK[0]
+Handshake[0]: CRYPTO[FIN], ACK[0]
+1-RTT[0]: STREAM[0, "..."], ACK[0] -&gt;
+
+                                          Handshake[1]: ACK[0]
+                         &lt;- 1-RTT[1]: STREAM[3, "..."], ACK[0]
+</pre>
+</div>
+<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
+<a href="#name-example-1-rtt-handshake" class="selfRef">Example 1-RTT Handshake</a>
+          </figcaption></figure>
+</div>
+<p id="section-7.1-6"><a href="#tls-0rtt-handshake" class="xref">Figure 5</a> shows an example of a connection with a 0-RTT handshake
+and a single packet of 0-RTT data. Note that as described in
+<a href="#packet-numbers" class="xref">Section 12.3</a>, the server acknowledges 0-RTT data in 1-RTT packets, and
+the client sends 1-RTT packets in the same packet number space.<a href="#section-7.1-6" class="pilcrow">¶</a></p>
+<span id="name-example-0-rtt-handshake"></span><div id="tls-0rtt-handshake">
+<figure id="figure-5">
+          <div class="artwork art-text alignLeft" id="section-7.1-7.1">
+<pre>
+Client                                                  Server
+
+Initial[0]: CRYPTO[CH]
+0-RTT[0]: STREAM[0, "..."] -&gt;
+
+                                 Initial[0]: CRYPTO[SH] ACK[0]
+                                  Handshake[0] CRYPTO[EE, FIN]
+                          &lt;- 1-RTT[0]: STREAM[1, "..."] ACK[0]
+
+Initial[1]: ACK[0]
+Handshake[0]: CRYPTO[FIN], ACK[0]
+1-RTT[1]: STREAM[0, "..."] ACK[0] -&gt;
+
+                                          Handshake[1]: ACK[0]
+                         &lt;- 1-RTT[1]: STREAM[3, "..."], ACK[1]
+</pre>
+</div>
+<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
+<a href="#name-example-0-rtt-handshake" class="selfRef">Example 0-RTT Handshake</a>
+          </figcaption></figure>
+</div>
+</section>
+</div>
+<div id="negotiating-connection-ids">
+<section id="section-7.2">
+        <h3 id="name-negotiating-connection-ids">
+<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-negotiating-connection-ids" class="section-name selfRef">Negotiating Connection IDs</a>
+        </h3>
+<p id="section-7.2-1">A connection ID is used to ensure consistent routing of packets, as described in
+<a href="#connection-id" class="xref">Section 5.1</a>.  The long header contains two connection IDs: the Destination
+Connection ID is chosen by the recipient of the packet and is used to provide
+consistent routing; the Source Connection ID is used to set the Destination
+Connection ID used by the peer.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
+<p id="section-7.2-2">During the handshake, packets with the long header (<a href="#long-header" class="xref">Section 17.2</a>) are used to
+establish the connection IDs in each direction. Each endpoint uses the Source
+Connection ID field to specify the connection ID that is used in the Destination
+Connection ID field of packets being sent to them. Upon receiving a packet, each
+endpoint sets the Destination Connection ID it sends to match the value of the
+Source Connection ID that it receives.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
+<p id="section-7.2-3">When an Initial packet is sent by a client that has not previously received an
+Initial or Retry packet from the server, the client populates the Destination
+Connection ID field with an unpredictable value.  This Destination Connection ID
+MUST be at least 8 bytes in length.  Until a packet is received from the server,
+the client MUST use the same Destination Connection ID value on all packets in
+this connection. This Destination Connection ID is used to determine packet
+protection keys for Initial packets.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
+<p id="section-7.2-4">The client populates the Source Connection ID field with a value of its choosing
+and sets the SCID Length field to indicate the length.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
+<p id="section-7.2-5">The first flight of 0-RTT packets use the same Destination Connection ID and
+Source Connection ID values as the client's first Initial packet.<a href="#section-7.2-5" class="pilcrow">¶</a></p>
+<p id="section-7.2-6">Upon first receiving an Initial or Retry packet from the server, the client uses
+the Source Connection ID supplied by the server as the Destination Connection ID
+for subsequent packets, including any 0-RTT packets.  This means that a client
+might have to change the connection ID it sets in the Destination Connection ID
+field twice during connection establishment: once in response to a Retry, and
+once in response to an Initial packet from the server. Once a client has
+received a valid Initial packet from the server, it MUST discard any subsequent
+packet it receives with a different Source Connection ID.<a href="#section-7.2-6" class="pilcrow">¶</a></p>
+<p id="section-7.2-7">A client MUST change the Destination Connection ID it uses for sending packets
+in response to only the first received Initial or Retry packet.  A server MUST
+set the Destination Connection ID it uses for sending packets based on the first
+received Initial packet. Any further changes to the Destination Connection ID
+are only permitted if the values are taken from any received
+NEW_CONNECTION_ID frames; if subsequent Initial packets include a different
+Source Connection ID, they MUST be discarded.  This avoids unpredictable
+outcomes that might otherwise result from stateless processing of multiple
+Initial packets with different Source Connection IDs.<a href="#section-7.2-7" class="pilcrow">¶</a></p>
+<p id="section-7.2-8">The Destination Connection ID that an endpoint sends can change over the
+lifetime of a connection, especially in response to connection migration
+(<a href="#migration" class="xref">Section 9</a>); see <a href="#issue-cid" class="xref">Section 5.1.1</a> for details.<a href="#section-7.2-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="cid-auth">
+<section id="section-7.3">
+        <h3 id="name-authenticating-connection-i">
+<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-authenticating-connection-i" class="section-name selfRef">Authenticating Connection IDs</a>
+        </h3>
+<p id="section-7.3-1">The choice each endpoint makes about connection IDs during the handshake is
+authenticated by including all values in transport parameters; see
+<a href="#transport-parameters" class="xref">Section 7.4</a>. This ensures that all connection IDs used for the
+handshake are also authenticated by the cryptographic handshake.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
+<p id="section-7.3-2">Each endpoint includes the value of the Source Connection ID field from the
+first Initial packet it sent in the initial_source_connection_id transport
+parameter; see <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>. A server includes the
+Destination Connection ID field from the first Initial packet it received from
+the client in the original_destination_connection_id transport parameter; if
+the server sent a Retry packet this refers to the first Initial packet received
+before sending the Retry packet. If it sends a Retry packet, a server also
+includes the Source Connection ID field from the Retry packet in the
+retry_source_connection_id transport parameter.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
+<p id="section-7.3-3">The values provided by a peer for these transport parameters MUST match the
+values that an endpoint used in the Destination and Source Connection ID fields
+of Initial packets that it sent. Including connection ID values in transport
+parameters and verifying them ensures that that an attacker cannot influence
+the choice of connection ID for a successful connection by injecting packets
+carrying attacker-chosen connection IDs during the handshake. An endpoint MUST
+treat any of the following as a connection error of type PROTOCOL_VIOLATION:<a href="#section-7.3-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-7.3-4.1">absence of the initial_source_connection_id transport parameter from either
+endpoint,<a href="#section-7.3-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.3-4.2">absence of the original_destination_connection_id transport parameter from
+the server,<a href="#section-7.3-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.3-4.3">absence of the retry_source_connection_id transport parameter from the server
+after receiving a Retry packet,<a href="#section-7.3-4.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.3-4.4">presence of the retry_source_connection_id transport parameter when no Retry
+packet was received, or<a href="#section-7.3-4.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.3-4.5">a mismatch between values received from a peer in these transport parameters
+and the value sent in the corresponding Destination or Source Connection ID
+fields of Initial packets.<a href="#section-7.3-4.5" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-7.3-5">If a zero-length connection ID is selected, the corresponding transport
+parameter is included with a zero-length value.<a href="#section-7.3-5" class="pilcrow">¶</a></p>
+<p id="section-7.3-6"><a href="#fig-auth-cid" class="xref">Figure 6</a> shows the connection IDs that are used in a complete
+handshake. The exchange of Initial packets is shown, plus the later exchange of
+1-RTT packets that includes the connection ID established during the handshake.<a href="#section-7.3-6" class="pilcrow">¶</a></p>
+<span id="name-use-of-connection-ids-in-a-"></span><div id="fig-auth-cid">
+<figure id="figure-6">
+          <div class="artwork art-text alignLeft" id="section-7.3-7.1">
+<pre>
+Client                                                  Server
+
+Initial: DCID=S1, SCID=C1 -&gt;
+                                  &lt;- Initial: DCID=C1, SCID=S3
+                             ...
+1-RTT: DCID=S3 -&gt;
+                                             &lt;- 1-RTT: DCID=C1
+</pre>
+</div>
+<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
+<a href="#name-use-of-connection-ids-in-a-" class="selfRef">Use of Connection IDs in a Handshake</a>
+          </figcaption></figure>
+</div>
+<p id="section-7.3-8"><a href="#fig-auth-cid-retry" class="xref">Figure 7</a> shows a similar handshake that includes a Retry packet.<a href="#section-7.3-8" class="pilcrow">¶</a></p>
+<span id="name-use-of-connection-ids-in-a-h"></span><div id="fig-auth-cid-retry">
+<figure id="figure-7">
+          <div class="artwork art-text alignLeft" id="section-7.3-9.1">
+<pre>
+Client                                                  Server
+
+Initial: DCID=S1, SCID=C1 -&gt;
+                                    &lt;- Retry: DCID=C1, SCID=S2
+Initial: DCID=S2, SCID=C1 -&gt;
+                                  &lt;- Initial: DCID=C1, SCID=S3
+                             ...
+1-RTT: DCID=S3 -&gt;
+                                             &lt;- 1-RTT: DCID=C1
+</pre>
+</div>
+<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
+<a href="#name-use-of-connection-ids-in-a-h" class="selfRef">Use of Connection IDs in a Handshake with Retry</a>
+          </figcaption></figure>
+</div>
+<p id="section-7.3-10">For the handshakes in <a href="#fig-auth-cid" class="xref">Figure 6</a> and <a href="#fig-auth-cid-retry" class="xref">Figure 7</a> the client
+sets the value of the initial_source_connection_id transport parameter to <code>C1</code>.
+In <a href="#fig-auth-cid-retry" class="xref">Figure 7</a>, the server sets original_destination_connection_id
+to <code>S1</code>, retry_source_connection_id to <code>S2</code>, and initial_source_connection_id
+to <code>S3</code>. In <a href="#fig-auth-cid" class="xref">Figure 6</a>, the server sets
+original_destination_connection_id to <code>S1</code>, initial_source_connection_id to
+<code>S3</code>, and does not include retry_source_connection_id. Each endpoint validates
+the transport parameters set by their peer, including the client confirming
+that retry_source_connection_id is absent if no Retry packet was processed.<a href="#section-7.3-10" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="transport-parameters">
+<section id="section-7.4">
+        <h3 id="name-transport-parameters">
+<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-transport-parameters" class="section-name selfRef">Transport Parameters</a>
+        </h3>
+<p id="section-7.4-1">During connection establishment, both endpoints make authenticated declarations
+of their transport parameters.  Endpoints are required to comply with the
+restrictions implied by these parameters; the description of each parameter
+includes rules for its handling.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
+<p id="section-7.4-2">Transport parameters are declarations that are made unilaterally by each
+endpoint.  Each endpoint can choose values for transport parameters independent
+of the values chosen by its peer.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
+<p id="section-7.4-3">The encoding of the transport parameters is detailed in
+<a href="#transport-parameter-encoding" class="xref">Section 18</a>.<a href="#section-7.4-3" class="pilcrow">¶</a></p>
+<p id="section-7.4-4">QUIC includes the encoded transport parameters in the cryptographic handshake.
+Once the handshake completes, the transport parameters declared by the peer are
+available.  Each endpoint validates the value provided by its peer.<a href="#section-7.4-4" class="pilcrow">¶</a></p>
+<p id="section-7.4-5">Definitions for each of the defined transport parameters are included in
+<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>.<a href="#section-7.4-5" class="pilcrow">¶</a></p>
+<p id="section-7.4-6">An endpoint MUST treat receipt of a transport parameter with an invalid value as
+a connection error of type TRANSPORT_PARAMETER_ERROR.<a href="#section-7.4-6" class="pilcrow">¶</a></p>
+<p id="section-7.4-7">An endpoint MUST NOT send a parameter more than once in a given transport
+parameters extension.  An endpoint SHOULD treat receipt of duplicate transport
+parameters as a connection error of type TRANSPORT_PARAMETER_ERROR.<a href="#section-7.4-7" class="pilcrow">¶</a></p>
+<p id="section-7.4-8">Endpoints use transport parameters to authenticate the negotiation of
+connection IDs during the handshake; see <a href="#cid-auth" class="xref">Section 7.3</a>.<a href="#section-7.4-8" class="pilcrow">¶</a></p>
+<div id="zerortt-parameters">
+<section id="section-7.4.1">
+          <h4 id="name-values-of-transport-paramet">
+<a href="#section-7.4.1" class="section-number selfRef">7.4.1. </a><a href="#name-values-of-transport-paramet" class="section-name selfRef">Values of Transport Parameters for 0-RTT</a>
+          </h4>
+<p id="section-7.4.1-1">Both endpoints store the value of the server transport parameters from
+a connection and apply them to any 0-RTT packets that are sent in
+subsequent connections to that peer, except for transport parameters that
+are explicitly excluded. Remembered transport parameters apply to the new
+connection until the handshake completes and the client starts sending
+1-RTT packets. Once the handshake completes, the client uses the transport
+parameters established in the handshake.<a href="#section-7.4.1-1" class="pilcrow">¶</a></p>
+<p id="section-7.4.1-2">The definition of new transport parameters (<a href="#new-transport-parameters" class="xref">Section 7.4.2</a>) MUST
+specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A client need
+not store a transport parameter it cannot process.<a href="#section-7.4.1-2" class="pilcrow">¶</a></p>
+<p id="section-7.4.1-3">A client MUST NOT use remembered values for the following parameters:
+ack_delay_exponent, max_ack_delay, initial_source_connection_id,
+original_destination_connection_id, preferred_address,
+retry_source_connection_id, and stateless_reset_token. The client MUST use the
+server's new values in the handshake instead, and absent new values from the
+server, the default value.<a href="#section-7.4.1-3" class="pilcrow">¶</a></p>
+<p id="section-7.4.1-4">A client that attempts to send 0-RTT data MUST remember all other transport
+parameters used by the server. The server can remember these transport
+parameters, or store an integrity-protected copy of the values in the ticket
+and recover the information when accepting 0-RTT data. A server uses the
+transport parameters in determining whether to accept 0-RTT data.<a href="#section-7.4.1-4" class="pilcrow">¶</a></p>
+<p id="section-7.4.1-5">If 0-RTT data is accepted by the server, the server MUST NOT reduce any
+limits or alter any values that might be violated by the client with its
+0-RTT data.  In particular, a server that accepts 0-RTT data MUST NOT set
+values for the following parameters (<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>)
+that are smaller than the remembered value of the parameters.<a href="#section-7.4.1-5" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-7.4.1-6.1">active_connection_id_limit<a href="#section-7.4.1-6.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.4.1-6.2">initial_max_data<a href="#section-7.4.1-6.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.4.1-6.3">initial_max_stream_data_bidi_local<a href="#section-7.4.1-6.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.4.1-6.4">initial_max_stream_data_bidi_remote<a href="#section-7.4.1-6.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.4.1-6.5">initial_max_stream_data_uni<a href="#section-7.4.1-6.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.4.1-6.6">initial_max_streams_bidi<a href="#section-7.4.1-6.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-7.4.1-6.7">initial_max_streams_uni<a href="#section-7.4.1-6.7" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-7.4.1-7">Omitting or setting a zero value for certain transport parameters can result in
+0-RTT data being enabled, but not usable.  The applicable subset of transport
+parameters that permit sending of application data SHOULD be set to non-zero
+values for 0-RTT.  This includes initial_max_data and either
+initial_max_streams_bidi and initial_max_stream_data_bidi_remote, or
+initial_max_streams_uni and initial_max_stream_data_uni.<a href="#section-7.4.1-7" class="pilcrow">¶</a></p>
+<p id="section-7.4.1-8">A server MUST either reject 0-RTT data or abort a handshake if the implied
+values for transport parameters cannot be supported.<a href="#section-7.4.1-8" class="pilcrow">¶</a></p>
+<p id="section-7.4.1-9">When sending frames in 0-RTT packets, a client MUST only use remembered
+transport parameters; importantly, it MUST NOT use updated values that it learns
+from the server's updated transport parameters or from frames received in 1-RTT
+packets.  Updated values of transport parameters from the handshake apply only
+to 1-RTT packets.  For instance, flow control limits from remembered transport
+parameters apply to all 0-RTT packets even if those values are increased by the
+handshake or by frames sent in 1-RTT packets.  A server MAY treat use of updated
+transport parameters in 0-RTT as a connection error of type PROTOCOL_VIOLATION.<a href="#section-7.4.1-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="new-transport-parameters">
+<section id="section-7.4.2">
+          <h4 id="name-new-transport-parameters">
+<a href="#section-7.4.2" class="section-number selfRef">7.4.2. </a><a href="#name-new-transport-parameters" class="section-name selfRef">New Transport Parameters</a>
+          </h4>
+<p id="section-7.4.2-1">New transport parameters can be used to negotiate new protocol behavior.  An
+endpoint MUST ignore transport parameters that it does not support.  Absence of
+a transport parameter therefore disables any optional protocol feature that is
+negotiated using the parameter.  As described in <a href="#transport-parameter-grease" class="xref">Section 18.1</a>,
+some identifiers are reserved in order to exercise this requirement.<a href="#section-7.4.2-1" class="pilcrow">¶</a></p>
+<p id="section-7.4.2-2">New transport parameters can be registered according to the rules in
+<a href="#iana-transport-parameters" class="xref">Section 22.2</a>.<a href="#section-7.4.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="cryptographic-message-buffering">
+<section id="section-7.5">
+        <h3 id="name-cryptographic-message-buffe">
+<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-cryptographic-message-buffe" class="section-name selfRef">Cryptographic Message Buffering</a>
+        </h3>
+<p id="section-7.5-1">Implementations need to maintain a buffer of CRYPTO data received out of order.
+Because there is no flow control of CRYPTO frames, an endpoint could
+potentially force its peer to buffer an unbounded amount of data.<a href="#section-7.5-1" class="pilcrow">¶</a></p>
+<p id="section-7.5-2">Implementations MUST support buffering at least 4096 bytes of data received in
+CRYPTO frames out of order. Endpoints MAY choose to allow more data to be
+buffered during the handshake. A larger limit during the handshake could allow
+for larger keys or credentials to be exchanged. An endpoint's buffer size does
+not need to remain constant during the life of the connection.<a href="#section-7.5-2" class="pilcrow">¶</a></p>
+<p id="section-7.5-3">Being unable to buffer CRYPTO frames during the handshake can lead to a
+connection failure. If an endpoint's buffer is exceeded during the handshake, it
+can expand its buffer temporarily to complete the handshake. If an endpoint
+does not expand its buffer, it MUST close the connection with a
+CRYPTO_BUFFER_EXCEEDED error code.<a href="#section-7.5-3" class="pilcrow">¶</a></p>
+<p id="section-7.5-4">Once the handshake completes, if an endpoint is unable to buffer all data in a
+CRYPTO frame, it MAY discard that CRYPTO frame and all CRYPTO frames received in
+the future, or it MAY close the connection with a CRYPTO_BUFFER_EXCEEDED error
+code. Packets containing discarded CRYPTO frames MUST be acknowledged because
+the packet has been received and processed by the transport even though the
+CRYPTO frame was discarded.<a href="#section-7.5-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="address-validation">
+<section id="section-8">
+      <h2 id="name-address-validation">
+<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-address-validation" class="section-name selfRef">Address Validation</a>
+      </h2>
+<p id="section-8-1">Address validation is used by QUIC to avoid being used for a traffic
+amplification attack.  In such an attack, a packet is sent to a server with
+spoofed source address information that identifies a victim.  If a server
+generates more or larger packets in response to that packet, the attacker can
+use the server to send more data toward the victim than it would be able to send
+on its own.<a href="#section-8-1" class="pilcrow">¶</a></p>
+<p id="section-8-2">The primary defense against amplification attack is verifying that an endpoint
+is able to receive packets at the transport address that it claims.  Address
+validation is performed both during connection establishment (see
+<a href="#validate-handshake" class="xref">Section 8.1</a>) and during connection migration (see
+<a href="#migrate-validate" class="xref">Section 8.2</a>).<a href="#section-8-2" class="pilcrow">¶</a></p>
+<div id="validate-handshake">
+<section id="section-8.1">
+        <h3 id="name-address-validation-during-c">
+<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-address-validation-during-c" class="section-name selfRef">Address Validation During Connection Establishment</a>
+        </h3>
+<p id="section-8.1-1">Connection establishment implicitly provides address validation for both
+endpoints.  In particular, receipt of a packet protected with Handshake keys
+confirms that the client received the Initial packet from the server.  Once the
+server has successfully processed a Handshake packet from the client, it can
+consider the client address to have been validated.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
+<p id="section-8.1-2">Prior to validating the client address, servers MUST NOT send more than three
+times as many bytes as the number of bytes they have received.  This limits the
+magnitude of any amplification attack that can be mounted using spoofed source
+addresses.  For the purposes of avoiding amplification prior to address
+validation, servers MUST count all of the payload bytes received in datagrams
+that are uniquely attributed to a single connection. This includes datagrams
+that contain packets that are successfully processed and datagrams that contain
+packets that are all discarded.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
+<p id="section-8.1-3">Clients MUST ensure that UDP datagrams containing Initial packets have UDP
+payloads of at least 1200 bytes, adding padding to packets in the datagram as
+necessary. Sending padded datagrams ensures that the server is not overly
+constrained by the amplification restriction.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
+<p id="section-8.1-4">Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets. A deadlock
+could occur when the server reaches its anti-amplification limit and the client
+has received acknowledgements for all the data it has sent.  In this case, when
+the client has no reason to send additional packets, the server will be unable
+to send more data because it has not validated the client's address. To prevent
+this deadlock, clients MUST send a packet on a probe timeout
+(PTO, see Section 5.3 of <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>). Specifically, the client MUST send
+an Initial packet in a UDP datagram of at least 1200 bytes if it does not have
+Handshake keys, and otherwise send a Handshake packet.<a href="#section-8.1-4" class="pilcrow">¶</a></p>
+<p id="section-8.1-5">A server might wish to validate the client address before starting the
+cryptographic handshake. QUIC uses a token in the Initial packet to provide
+address validation prior to completing the handshake. This token is delivered to
+the client during connection establishment with a Retry packet (see
+<a href="#validate-retry" class="xref">Section 8.1.2</a>) or in a previous connection using the NEW_TOKEN frame (see
+<a href="#validate-future" class="xref">Section 8.1.3</a>).<a href="#section-8.1-5" class="pilcrow">¶</a></p>
+<p id="section-8.1-6">In addition to sending limits imposed prior to address validation, servers are
+also constrained in what they can send by the limits set by the congestion
+controller.  Clients are only constrained by the congestion controller.<a href="#section-8.1-6" class="pilcrow">¶</a></p>
+<div id="token-construction">
+<section id="section-8.1.1">
+          <h4 id="name-token-construction">
+<a href="#section-8.1.1" class="section-number selfRef">8.1.1. </a><a href="#name-token-construction" class="section-name selfRef">Token Construction</a>
+          </h4>
+<p id="section-8.1.1-1">A token sent in a NEW_TOKEN frames or a Retry packet MUST be constructed in a
+way that allows the server to identify how it was provided to a client.  These
+tokens are carried in the same field, but require different handling from
+servers.<a href="#section-8.1.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="validate-retry">
+<section id="section-8.1.2">
+          <h4 id="name-address-validation-using-re">
+<a href="#section-8.1.2" class="section-number selfRef">8.1.2. </a><a href="#name-address-validation-using-re" class="section-name selfRef">Address Validation using Retry Packets</a>
+          </h4>
+<p id="section-8.1.2-1">Upon receiving the client's Initial packet, the server can request address
+validation by sending a Retry packet (<a href="#packet-retry" class="xref">Section 17.2.5</a>) containing a token. This
+token MUST be repeated by the client in all Initial packets it sends for that
+connection after it receives the Retry packet.  In response to processing an
+Initial containing a token, a server can either abort the connection or permit
+it to proceed.<a href="#section-8.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-8.1.2-2">As long as it is not possible for an attacker to generate a valid token for
+its own address (see <a href="#token-integrity" class="xref">Section 8.1.4</a>) and the client is able to return
+that token, it proves to the server that it received the token.<a href="#section-8.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-8.1.2-3">A server can also use a Retry packet to defer the state and processing costs of
+connection establishment. Requiring the server to provide a different
+connection ID, along with the original_destination_connection_id transport
+parameter defined in <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>, forces the server to
+demonstrate that it, or an entity it cooperates with, received the original
+Initial packet from the client. Providing a different connection ID also grants
+a server some control over how subsequent packets are routed. This can be used
+to direct connections to a different server instance.<a href="#section-8.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-8.1.2-4">If a server receives a client Initial that can be unprotected but contains an
+invalid Retry token, it knows the client will not accept another Retry token.
+The server can discard such a packet and allow the client to time out to
+detect handshake failure, but that could impose a significant latency penalty on
+the client.  Instead, the server SHOULD immediately close (<a href="#immediate-close" class="xref">Section 10.3</a>)
+the connection with an INVALID_TOKEN error.  Note that a server has not
+established any state for the connection at this point and so does not enter the
+closing period.<a href="#section-8.1.2-4" class="pilcrow">¶</a></p>
+<p id="section-8.1.2-5">A flow showing the use of a Retry packet is shown in <a href="#fig-retry" class="xref">Figure 8</a>.<a href="#section-8.1.2-5" class="pilcrow">¶</a></p>
+<span id="name-example-handshake-with-retr"></span><div id="fig-retry">
+<figure id="figure-8">
+            <div class="artwork art-text alignLeft" id="section-8.1.2-6.1">
+<pre>
+Client                                                  Server
+
+Initial[0]: CRYPTO[CH] -&gt;
+
+                                                &lt;- Retry+Token
+
+Initial+Token[1]: CRYPTO[CH] -&gt;
+
+                                 Initial[0]: CRYPTO[SH] ACK[1]
+                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
+                                 &lt;- 1-RTT[0]: STREAM[1, "..."]
+</pre>
+</div>
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
+<a href="#name-example-handshake-with-retr" class="selfRef">Example Handshake with Retry</a>
+            </figcaption></figure>
+</div>
+</section>
+</div>
+<div id="validate-future">
+<section id="section-8.1.3">
+          <h4 id="name-address-validation-for-futu">
+<a href="#section-8.1.3" class="section-number selfRef">8.1.3. </a><a href="#name-address-validation-for-futu" class="section-name selfRef">Address Validation for Future Connections</a>
+          </h4>
+<p id="section-8.1.3-1">A server MAY provide clients with an address validation token during one
+connection that can be used on a subsequent connection.  Address validation is
+especially important with 0-RTT because a server potentially sends a significant
+amount of data to a client in response to 0-RTT data.<a href="#section-8.1.3-1" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-2">The server uses the NEW_TOKEN frame <a href="#frame-new-token" class="xref">Section 19.7</a> to provide the client
+with an address validation token that can be used to validate future
+connections.  The client includes this token in Initial packets to provide
+address validation in a future connection.  The client MUST include the token in
+all Initial packets it sends, unless a Retry replaces the token with a newer
+one.  The client MUST NOT use the token provided in a Retry for future
+connections. Servers MAY discard any Initial packet that does not carry the
+expected token.<a href="#section-8.1.3-2" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-3">Unlike the token that is created for a Retry packet, which is used immediately,
+the token sent in the NEW_TOKEN frame might be used after some period of
+time has passed.  Thus, a token SHOULD have an expiration time, which could
+be either an explicit expiration time or an issued timestamp that can be
+used to dynamically calculate the expiration time.  A server can store the
+expiration time or include it in an encrypted form in the token.<a href="#section-8.1.3-3" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-4">A token issued with NEW_TOKEN MUST NOT include information that would allow
+values to be linked by an observer to the connection on which it was
+issued, unless the values are encrypted.  For example, it cannot include the
+previous connection ID or addressing information.  A server MUST ensure that
+every NEW_TOKEN frame it sends is unique across all clients, with the exception
+of those sent to repair losses of previously sent NEW_TOKEN frames.  Information
+that allows the server to distinguish between tokens from Retry and NEW_TOKEN
+MAY be accessible to entities other than the server.<a href="#section-8.1.3-4" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-5">It is unlikely that the client port number is the same on two different
+connections; validating the port is therefore unlikely to be successful.<a href="#section-8.1.3-5" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-6">A token received in a NEW_TOKEN frame is applicable to any server that the
+connection is considered authoritative for (e.g., server names included in the
+certificate).  When connecting to a server for which the client retains an
+applicable and unused token, it SHOULD include that token in the Token field of
+its Initial packet.  Including a token might allow the server to validate the
+client address without an additional round trip.  A client MUST NOT include a
+token that is not applicable to the server that it is connecting to, unless the
+client has the knowledge that the server that issued the token and the server
+the client is connecting to are jointly managing the tokens.  A client MAY use a
+token from any previous connection to that server.<a href="#section-8.1.3-6" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-7">A token allows a server to correlate activity between the connection where the
+token was issued and any connection where it is used.  Clients that want to
+break continuity of identity with a server MAY discard tokens provided using the
+NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used
+immediately during the connection attempt and cannot be used in subsequent
+connection attempts.<a href="#section-8.1.3-7" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-8">A client SHOULD NOT reuse a NEW_TOKEN token for different connection attempts.
+Reusing a token allows connections to be linked by entities on the network path;
+see <a href="#migration-linkability" class="xref">Section 9.5</a>.<a href="#section-8.1.3-8" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-9">Clients might receive multiple tokens on a single connection.  Aside from
+preventing linkability, any token can be used in any connection attempt.
+Servers can send additional tokens to either enable address validation for
+multiple connection attempts or to replace older tokens that might become
+invalid.  For a client, this ambiguity means that sending the most recent unused
+token is most likely to be effective.  Though saving and using older tokens has
+no negative consequences, clients can regard older tokens as being less likely
+be useful to the server for address validation.<a href="#section-8.1.3-9" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-10">When a server receives an Initial packet with an address validation token, it
+MUST attempt to validate the token, unless it has already completed address
+validation.  If the token is invalid then the server SHOULD proceed as if
+the client did not have a validated address, including potentially sending
+a Retry. If the validation succeeds, the server SHOULD then allow the
+handshake to proceed.<a href="#section-8.1.3-10" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-8.1.3-11">
+            <dt id="section-8.1.3-11.1">Note:</dt>
+<dd id="section-8.1.3-11.2">
+  The rationale for treating the client as unvalidated rather than discarding
+the packet is that the client might have received the token in a previous
+connection using the NEW_TOKEN frame, and if the server has lost state, it
+might be unable to validate the token at all, leading to connection failure if
+the packet is discarded.  A server SHOULD encode tokens provided with
+NEW_TOKEN frames and Retry packets differently, and validate the latter more
+strictly.<a href="#section-8.1.3-11.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-8.1.3-12">In a stateless design, a server can use encrypted and authenticated tokens to
+pass information to clients that the server can later recover and use to
+validate a client address.  Tokens are not integrated into the cryptographic
+handshake and so they are not authenticated.  For instance, a client might be
+able to reuse a token.  To avoid attacks that exploit this property, a server
+can limit its use of tokens to only the information needed to validate client
+addresses.<a href="#section-8.1.3-12" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-13">Clients MAY use tokens obtained on one connection for any connection attempt
+using the same version.  When selecting a token to use, clients do not need to
+consider other properties of the connection that is being attempted, including
+the choice of possible application protocols, session tickets, or other
+connection properties.<a href="#section-8.1.3-13" class="pilcrow">¶</a></p>
+<p id="section-8.1.3-14">Attackers could replay tokens to use servers as amplifiers in DDoS attacks. To
+protect against such attacks, servers SHOULD ensure that tokens sent in Retry
+packets are only accepted for a short time. Tokens that are provided in
+NEW_TOKEN frames (<a href="#frame-new-token" class="xref">Section 19.7</a>) need to be valid for longer, but
+SHOULD NOT be accepted multiple times in a short period. Servers are encouraged
+to allow tokens to be used only once, if possible.<a href="#section-8.1.3-14" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="token-integrity">
+<section id="section-8.1.4">
+          <h4 id="name-address-validation-token-in">
+<a href="#section-8.1.4" class="section-number selfRef">8.1.4. </a><a href="#name-address-validation-token-in" class="section-name selfRef">Address Validation Token Integrity</a>
+          </h4>
+<p id="section-8.1.4-1">An address validation token MUST be difficult to guess.  Including a large
+enough random value in the token would be sufficient, but this depends on the
+server remembering the value it sends to clients.<a href="#section-8.1.4-1" class="pilcrow">¶</a></p>
+<p id="section-8.1.4-2">A token-based scheme allows the server to offload any state associated with
+validation to the client.  For this design to work, the token MUST be covered by
+integrity protection against modification or falsification by clients.  Without
+integrity protection, malicious clients could generate or guess values for
+tokens that would be accepted by the server.  Only the server requires access to
+the integrity protection key for tokens.<a href="#section-8.1.4-2" class="pilcrow">¶</a></p>
+<p id="section-8.1.4-3">There is no need for a single well-defined format for the token because the
+server that generates the token also consumes it.  Tokens sent in Retry packets
+SHOULD include information that allows the server to verify that the source IP
+address and port in client packets remain constant.<a href="#section-8.1.4-3" class="pilcrow">¶</a></p>
+<p id="section-8.1.4-4">Tokens sent in NEW_TOKEN frames MUST include information that allows the server
+to verify that the client IP address has not changed from when the token was
+issued. Servers can use tokens from NEW_TOKEN in deciding not to send a Retry
+packet, even if the client address has changed. If the client IP address has
+changed, the server MUST adhere to the anti-amplification limits found in
+<a href="#validate-handshake" class="xref">Section 8.1</a>.  Note that in the presence of NAT, this requirement
+might be insufficient to protect other hosts that share the NAT from
+amplification attack.<a href="#section-8.1.4-4" class="pilcrow">¶</a></p>
+<p id="section-8.1.4-5">Servers MUST ensure that replay of tokens is prevented or limited.  For
+instance, servers might limit the time over which a token is accepted.  Tokens
+provided in NEW_TOKEN frames might need to allow longer validity periods.
+Tokens MAY include additional information about clients to further narrow
+applicability or reuse.<a href="#section-8.1.4-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="migrate-validate">
+<section id="section-8.2">
+        <h3 id="name-path-validation">
+<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-path-validation" class="section-name selfRef">Path Validation</a>
+        </h3>
+<p id="section-8.2-1">Path validation is used during connection migration (see <a href="#migration" class="xref">Section 9</a> and
+<a href="#preferred-address" class="xref">Section 9.6</a>) by the migrating endpoint to verify reachability of a
+peer from a new local address.  In path validation, endpoints test reachability
+between a specific local address and a specific peer address, where an address
+is the two-tuple of IP address and port.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
+<p id="section-8.2-2">Path validation tests that packets (PATH_CHALLENGE) can be both sent to and
+received (PATH_RESPONSE) from a peer on the path.  Importantly, it validates
+that the packets received from the migrating endpoint do not carry a spoofed
+source address.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
+<p id="section-8.2-3">Path validation can be used at any time by either endpoint.  For instance, an
+endpoint might check that a peer is still in possession of its address after a
+period of quiescence.<a href="#section-8.2-3" class="pilcrow">¶</a></p>
+<p id="section-8.2-4">Path validation is not designed as a NAT traversal mechanism. Though the
+mechanism described here might be effective for the creation of NAT bindings
+that support NAT traversal, the expectation is that one or other peer is able to
+receive packets without first having sent a packet on that path. Effective NAT
+traversal needs additional synchronization mechanisms that are not provided
+here.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
+<p id="section-8.2-5">An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that are used for
+path validation with other frames.  In particular, an endpoint may pad a packet
+carrying a PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a
+PATH_RESPONSE with its own PATH_CHALLENGE.<a href="#section-8.2-5" class="pilcrow">¶</a></p>
+<p id="section-8.2-6">When probing a new path, an endpoint might want to ensure that its peer has an
+unused connection ID available for responses. The endpoint can send
+NEW_CONNECTION_ID and PATH_CHALLENGE frames in the same packet. This ensures
+that an unused connection ID will be available to the peer when sending a
+response.<a href="#section-8.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="initiating-path-validation">
+<section id="section-8.3">
+        <h3 id="name-initiating-path-validation">
+<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-initiating-path-validation" class="section-name selfRef">Initiating Path Validation</a>
+        </h3>
+<p id="section-8.3-1">To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing
+a random payload on the path to be validated.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
+<p id="section-8.3-2">An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet
+loss. However, an endpoint SHOULD NOT send multiple PATH_CHALLENGE frames in a
+single packet.  An endpoint SHOULD NOT send a PATH_CHALLENGE more frequently
+than it would an Initial packet, ensuring that connection migration is no more
+load on a new path than establishing a new connection.<a href="#section-8.3-2" class="pilcrow">¶</a></p>
+<p id="section-8.3-3">The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame so that
+it can associate the peer's response with the corresponding PATH_CHALLENGE.<a href="#section-8.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="path-validation-responses">
+<section id="section-8.4">
+        <h3 id="name-path-validation-responses">
+<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-path-validation-responses" class="section-name selfRef">Path Validation Responses</a>
+        </h3>
+<p id="section-8.4-1">On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by
+echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.<a href="#section-8.4-1" class="pilcrow">¶</a></p>
+<p id="section-8.4-2">An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one
+PATH_CHALLENGE frame; see <a href="#retransmission-of-information" class="xref">Section 13.3</a>.  The peer is
+expected to send more PATH_CHALLENGE frames as necessary to evoke additional
+PATH_RESPONSE frames.<a href="#section-8.4-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="successful-path-validation">
+<section id="section-8.5">
+        <h3 id="name-successful-path-validation">
+<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-successful-path-validation" class="section-name selfRef">Successful Path Validation</a>
+        </h3>
+<p id="section-8.5-1">A new address is considered valid when a PATH_RESPONSE frame is received that
+contains the data that was sent in a previous PATH_CHALLENGE. Receipt of an
+acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate
+validation, since the acknowledgment can be spoofed by a malicious peer.<a href="#section-8.5-1" class="pilcrow">¶</a></p>
+<p id="section-8.5-2">Note that receipt on a different local address does not result in path
+validation failure, as it might be a result of a forwarded packet (see
+<a href="#off-path-forward" class="xref">Section 9.3.3</a>) or misrouting. It is possible that a valid PATH_RESPONSE
+might be received in the future.<a href="#section-8.5-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="failed-path-validation">
+<section id="section-8.6">
+        <h3 id="name-failed-path-validation">
+<a href="#section-8.6" class="section-number selfRef">8.6. </a><a href="#name-failed-path-validation" class="section-name selfRef">Failed Path Validation</a>
+        </h3>
+<p id="section-8.6-1">Path validation only fails when the endpoint attempting to validate the path
+abandons its attempt to validate the path.<a href="#section-8.6-1" class="pilcrow">¶</a></p>
+<p id="section-8.6-2">Endpoints SHOULD abandon path validation based on a timer. When setting this
+timer, implementations are cautioned that the new path could have a longer
+round-trip time than the original.  A value of three times the larger of the
+current Probe Timeout (PTO) or the initial timeout (that is, 2*kInitialRtt) as
+defined in <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span> is RECOMMENDED.  That is:<a href="#section-8.6-2" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-8.6-3">
+<pre>
+   validation_timeout = max(3*PTO, 6*kInitialRtt)
+</pre><a href="#section-8.6-3" class="pilcrow">¶</a>
+</div>
+<p id="section-8.6-4">Note that the endpoint might receive packets containing other frames on the new
+path, but a PATH_RESPONSE frame with appropriate data is required for path
+validation to succeed.<a href="#section-8.6-4" class="pilcrow">¶</a></p>
+<p id="section-8.6-5">When an endpoint abandons path validation, it determines that the path is
+unusable.  This does not necessarily imply a failure of the connection -
+endpoints can continue sending packets over other paths as appropriate.  If no
+paths are available, an endpoint can wait for a new path to become available or
+close the connection.<a href="#section-8.6-5" class="pilcrow">¶</a></p>
+<p id="section-8.6-6">A path validation might be abandoned for other reasons besides
+failure. Primarily, this happens if a connection migration to a new path is
+initiated while a path validation on the old path is in progress.<a href="#section-8.6-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="migration">
+<section id="section-9">
+      <h2 id="name-connection-migration">
+<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-connection-migration" class="section-name selfRef">Connection Migration</a>
+      </h2>
+<p id="section-9-1">The use of a connection ID allows connections to survive changes to endpoint
+addresses (IP address and port), such as those caused by an
+endpoint migrating to a new network.  This section describes the process by
+which an endpoint migrates to a new address.<a href="#section-9-1" class="pilcrow">¶</a></p>
+<p id="section-9-2">The design of QUIC relies on endpoints retaining a stable address for the
+duration of the handshake.  An endpoint MUST NOT initiate connection migration
+before the handshake is confirmed, as defined in section 4.1.2 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-9-2" class="pilcrow">¶</a></p>
+<p id="section-9-3">An endpoint also MUST NOT send packets from a different local address, actively
+initiating migration, if the peer sent the disable_active_migration transport
+parameter during the handshake. An endpoint which has sent this transport
+parameter, but detects that a peer has nonetheless migrated to a different
+network MUST either drop the incoming packets on that path without generating a
+stateless reset or proceed with path validation and allow the peer to migrate.
+Generating a stateless reset or closing the connection would allow third parties
+in the network to cause connections to close by spoofing or otherwise
+manipulating observed traffic.<a href="#section-9-3" class="pilcrow">¶</a></p>
+<p id="section-9-4">Not all changes of peer address are intentional, or active, migrations. The peer
+could experience NAT rebinding: a change of address due to a middlebox, usually
+a NAT, allocating a new outgoing port or even a new outgoing IP address for a
+flow.  An endpoint MUST perform path validation (<a href="#migrate-validate" class="xref">Section 8.2</a>) if it
+detects any change to a peer's address, unless it has previously validated that
+address.<a href="#section-9-4" class="pilcrow">¶</a></p>
+<p id="section-9-5">When an endpoint has no validated path on which to send packets, it MAY discard
+connection state.  An endpoint capable of connection migration MAY wait for a
+new path to become available before discarding connection state.<a href="#section-9-5" class="pilcrow">¶</a></p>
+<p id="section-9-6">This document limits migration of connections to new client addresses, except as
+described in <a href="#preferred-address" class="xref">Section 9.6</a>. Clients are responsible for initiating all
+migrations.  Servers do not send non-probing packets (see <a href="#probing" class="xref">Section 9.1</a>) toward a
+client address until they see a non-probing packet from that address.  If a
+client receives packets from an unknown server address, the client MUST discard
+these packets.<a href="#section-9-6" class="pilcrow">¶</a></p>
+<div id="probing">
+<section id="section-9.1">
+        <h3 id="name-probing-a-new-path">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-probing-a-new-path" class="section-name selfRef">Probing a New Path</a>
+        </h3>
+<p id="section-9.1-1">An endpoint MAY probe for peer reachability from a new local address using path
+validation <a href="#migrate-validate" class="xref">Section 8.2</a> prior to migrating the connection to the new
+local address.  Failure of path validation simply means that the new path is not
+usable for this connection.  Failure to validate a path does not cause the
+connection to end unless there are no valid alternative paths available.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
+<p id="section-9.1-2">An endpoint uses a new connection ID for probes sent from a new local address;
+see <a href="#migration-linkability" class="xref">Section 9.5</a> for further discussion. An endpoint that uses
+a new local address needs to ensure that at least one new connection ID is
+available at the peer. That can be achieved by including a NEW_CONNECTION_ID
+frame in the probe.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
+<p id="section-9.1-3">Receiving a PATH_CHALLENGE frame from a peer indicates that the peer is probing
+for reachability on a path. An endpoint sends a PATH_RESPONSE in response as per
+<a href="#migrate-validate" class="xref">Section 8.2</a>.<a href="#section-9.1-3" class="pilcrow">¶</a></p>
+<p id="section-9.1-4">PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames are
+"probing frames", and all other frames are "non-probing frames".  A packet
+containing only probing frames is a "probing packet", and a packet containing
+any other frame is a "non-probing packet".<a href="#section-9.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="initiating-migration">
+<section id="section-9.2">
+        <h3 id="name-initiating-connection-migra">
+<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-initiating-connection-migra" class="section-name selfRef">Initiating Connection Migration</a>
+        </h3>
+<p id="section-9.2-1">An endpoint can migrate a connection to a new local address by sending packets
+containing non-probing frames from that address.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
+<p id="section-9.2-2">Each endpoint validates its peer's address during connection establishment.
+Therefore, a migrating endpoint can send to its peer knowing that the peer is
+willing to receive at the peer's current address. Thus an endpoint can migrate
+to a new local address without first validating the peer's address.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
+<p id="section-9.2-3">When migrating, the new path might not support the endpoint's current sending
+rate. Therefore, the endpoint resets its congestion controller, as described in
+<a href="#migration-cc" class="xref">Section 9.4</a>.<a href="#section-9.2-3" class="pilcrow">¶</a></p>
+<p id="section-9.2-4">The new path might not have the same ECN capability. Therefore, the endpoint
+verifies ECN capability as described in <a href="#ecn" class="xref">Section 13.4</a>.<a href="#section-9.2-4" class="pilcrow">¶</a></p>
+<p id="section-9.2-5">Receiving acknowledgments for data sent on the new path serves as proof of the
+peer's reachability from the new address.  Note that since acknowledgments may
+be received on any path, return reachability on the new path is not established.
+To establish return reachability on the new path, an endpoint MAY concurrently
+initiate path validation <a href="#migrate-validate" class="xref">Section 8.2</a> on the new path or it MAY choose
+to wait for the peer to send the next non-probing frame to its new address.<a href="#section-9.2-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="migration-response">
+<section id="section-9.3">
+        <h3 id="name-responding-to-connection-mi">
+<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-responding-to-connection-mi" class="section-name selfRef">Responding to Connection Migration</a>
+        </h3>
+<p id="section-9.3-1">Receiving a packet from a new peer address containing a non-probing frame
+indicates that the peer has migrated to that address.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
+<p id="section-9.3-2">In response to such a packet, an endpoint MUST start sending subsequent packets
+to the new peer address and MUST initiate path validation (<a href="#migrate-validate" class="xref">Section 8.2</a>)
+to verify the peer's ownership of the unvalidated address.<a href="#section-9.3-2" class="pilcrow">¶</a></p>
+<p id="section-9.3-3">An endpoint MAY send data to an unvalidated peer address, but it MUST protect
+against potential attacks as described in <a href="#address-spoofing" class="xref">Section 9.3.1</a> and
+<a href="#on-path-spoofing" class="xref">Section 9.3.2</a>.  An endpoint MAY skip validation of a peer address if that
+address has been seen recently.  In particular, if an endpoint returns to a
+previously-validated path after detecting some form of spurious migration,
+skipping address validation and restoring loss detection and congestion state
+can reduce the performance impact of the attack.<a href="#section-9.3-3" class="pilcrow">¶</a></p>
+<p id="section-9.3-4">An endpoint only changes the address that it sends packets to in response to the
+highest-numbered non-probing packet. This ensures that an endpoint does not send
+packets to an old peer address in the case that it receives reordered packets.<a href="#section-9.3-4" class="pilcrow">¶</a></p>
+<p id="section-9.3-5">After changing the address to which it sends non-probing packets, an endpoint
+could abandon any path validation for other addresses.<a href="#section-9.3-5" class="pilcrow">¶</a></p>
+<p id="section-9.3-6">Receiving a packet from a new peer address might be the result of a NAT
+rebinding at the peer.<a href="#section-9.3-6" class="pilcrow">¶</a></p>
+<p id="section-9.3-7">After verifying a new client address, the server SHOULD send new address
+validation tokens (<a href="#address-validation" class="xref">Section 8</a>) to the client.<a href="#section-9.3-7" class="pilcrow">¶</a></p>
+<div id="address-spoofing">
+<section id="section-9.3.1">
+          <h4 id="name-peer-address-spoofing">
+<a href="#section-9.3.1" class="section-number selfRef">9.3.1. </a><a href="#name-peer-address-spoofing" class="section-name selfRef">Peer Address Spoofing</a>
+          </h4>
+<p id="section-9.3.1-1">It is possible that a peer is spoofing its source address to cause an endpoint
+to send excessive amounts of data to an unwilling host.  If the endpoint sends
+significantly more data than the spoofing peer, connection migration might be
+used to amplify the volume of data that an attacker can generate toward a
+victim.<a href="#section-9.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-9.3.1-2">As described in <a href="#migration-response" class="xref">Section 9.3</a>, an endpoint is required to validate a
+peer's new address to confirm the peer's possession of the new address.  Until a
+peer's address is deemed valid, an endpoint MUST limit the rate at which it
+sends data to this address.  The endpoint MUST NOT send more than a minimum
+congestion window's worth of data per estimated round-trip time (kMinimumWindow,
+as defined in <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>).  In the absence of this limit, an endpoint
+risks being used for a denial of service attack against an unsuspecting victim.
+Note that since the endpoint will not have any round-trip time measurements to
+this address, the estimate SHOULD be the default initial value; see
+<span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>.<a href="#section-9.3.1-2" class="pilcrow">¶</a></p>
+<p id="section-9.3.1-3">If an endpoint skips validation of a peer address as described in
+<a href="#migration-response" class="xref">Section 9.3</a>, it does not need to limit its sending rate.<a href="#section-9.3.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="on-path-spoofing">
+<section id="section-9.3.2">
+          <h4 id="name-on-path-address-spoofing">
+<a href="#section-9.3.2" class="section-number selfRef">9.3.2. </a><a href="#name-on-path-address-spoofing" class="section-name selfRef">On-Path Address Spoofing</a>
+          </h4>
+<p id="section-9.3.2-1">An on-path attacker could cause a spurious connection migration by copying and
+forwarding a packet with a spoofed address such that it arrives before the
+original packet.  The packet with the spoofed address will be seen to come from
+a migrating connection, and the original packet will be seen as a duplicate and
+dropped. After a spurious migration, validation of the source address will fail
+because the entity at the source address does not have the necessary
+cryptographic keys to read or respond to the PATH_CHALLENGE frame that is sent
+to it even if it wanted to.<a href="#section-9.3.2-1" class="pilcrow">¶</a></p>
+<p id="section-9.3.2-2">To protect the connection from failing due to such a spurious migration, an
+endpoint MUST revert to using the last validated peer address when validation of
+a new peer address fails.<a href="#section-9.3.2-2" class="pilcrow">¶</a></p>
+<p id="section-9.3.2-3">If an endpoint has no state about the last validated peer address, it MUST close
+the connection silently by discarding all connection state. This results in new
+packets on the connection being handled generically. For instance, an endpoint
+MAY send a stateless reset in response to any further incoming packets.<a href="#section-9.3.2-3" class="pilcrow">¶</a></p>
+<p id="section-9.3.2-4">Note that receipt of packets with higher packet numbers from the legitimate peer
+address will trigger another connection migration.  This will cause the
+validation of the address of the spurious migration to be abandoned.<a href="#section-9.3.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="off-path-forward">
+<section id="section-9.3.3">
+          <h4 id="name-off-path-packet-forwarding">
+<a href="#section-9.3.3" class="section-number selfRef">9.3.3. </a><a href="#name-off-path-packet-forwarding" class="section-name selfRef">Off-Path Packet Forwarding</a>
+          </h4>
+<p id="section-9.3.3-1">An off-path attacker that can observe packets might forward copies of genuine
+packets to endpoints.  If the copied packet arrives before the genuine packet,
+this will appear as a NAT rebinding.  Any genuine packet will be discarded as a
+duplicate.  If the attacker is able to continue forwarding packets, it might be
+able to cause migration to a path via the attacker.  This places the attacker on
+path, giving it the ability to observe or drop all subsequent packets.<a href="#section-9.3.3-1" class="pilcrow">¶</a></p>
+<p id="section-9.3.3-2">Unlike the attack described in <a href="#on-path-spoofing" class="xref">Section 9.3.2</a>, the attacker can ensure
+that the new path is successfully validated.<a href="#section-9.3.3-2" class="pilcrow">¶</a></p>
+<p id="section-9.3.3-3">This style of attack relies on the attacker using a path that is approximately
+as fast as the direct path between endpoints.  The attack is more reliable if
+relatively few packets are sent or if packet loss coincides with the attempted
+attack.<a href="#section-9.3.3-3" class="pilcrow">¶</a></p>
+<p id="section-9.3.3-4">A non-probing packet received on the original path that increases the maximum
+received packet number will cause the endpoint to move back to that path.
+Eliciting packets on this path increases the likelihood that the attack is
+unsuccessful.  Therefore, mitigation of this attack relies on triggering the
+exchange of packets.<a href="#section-9.3.3-4" class="pilcrow">¶</a></p>
+<p id="section-9.3.3-5">In response to an apparent migration, endpoints MUST validate the previously
+active path using a PATH_CHALLENGE frame.  This induces the sending of new
+packets on that path.  If the path is no longer viable, the validation attempt
+will time out and fail; if the path is viable, but no longer desired, the
+validation will succeed, but only results in probing packets being sent on the
+path.<a href="#section-9.3.3-5" class="pilcrow">¶</a></p>
+<p id="section-9.3.3-6">An endpoint that receives a PATH_CHALLENGE on an active path SHOULD send a
+non-probing packet in response.  If the non-probing packet arrives before any
+copy made by an attacker, this results in the connection being migrated back to
+the original path.  Any subsequent migration to another path restarts this
+entire process.<a href="#section-9.3.3-6" class="pilcrow">¶</a></p>
+<p id="section-9.3.3-7">This defense is imperfect, but this is not considered a serious problem. If the
+path via the attack is reliably faster than the original path despite multiple
+attempts to use that original path, it is not possible to distinguish between
+attack and an improvement in routing.<a href="#section-9.3.3-7" class="pilcrow">¶</a></p>
+<p id="section-9.3.3-8">An endpoint could also use heuristics to improve detection of this style of
+attack.  For instance, NAT rebinding is improbable if packets were recently
+received on the old path, similarly rebinding is rare on IPv6 paths.  Endpoints
+can also look for duplicated packets.  Conversely, a change in connection ID is
+more likely to indicate an intentional migration rather than an attack.<a href="#section-9.3.3-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="migration-cc">
+<section id="section-9.4">
+        <h3 id="name-loss-detection-and-congesti">
+<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-loss-detection-and-congesti" class="section-name selfRef">Loss Detection and Congestion Control</a>
+        </h3>
+<p id="section-9.4-1">The capacity available on the new path might not be the same as the old path.
+Packets sent on the old path MUST NOT contribute to congestion control or RTT
+estimation for the new path.<a href="#section-9.4-1" class="pilcrow">¶</a></p>
+<p id="section-9.4-2">On confirming a peer's ownership of its new address, an endpoint MUST
+immediately reset the congestion controller and round-trip time estimator for
+the new path to initial values (see Sections A.3 and B.3 in <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>)
+unless it has knowledge that a previous send rate or round-trip time estimate is
+valid for the new path.  For instance, an endpoint might infer that a change in
+only the client's port number is indicative of a NAT rebinding, meaning that the
+new path is likely to have similar bandwidth and round-trip time. However, this
+determination will be imperfect.  If the determination is incorrect, the
+congestion controller and the RTT estimator are expected to adapt to the new
+path.  Generally, implementations are advised to be cautious when using previous
+values on a new path.<a href="#section-9.4-2" class="pilcrow">¶</a></p>
+<p id="section-9.4-3">There may be apparent reordering at the receiver when an endpoint sends data and
+probes from/to multiple addresses during the migration period, since the two
+resulting paths may have different round-trip times.  A receiver of packets on
+multiple paths will still send ACK frames covering all received packets.<a href="#section-9.4-3" class="pilcrow">¶</a></p>
+<p id="section-9.4-4">While multiple paths might be used during connection migration, a single
+congestion control context and a single loss recovery context (as described in
+<span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>) may be adequate.  For instance, an endpoint might delay
+switching to a new congestion control context until it is confirmed that an old
+path is no longer needed (such as the case in <a href="#off-path-forward" class="xref">Section 9.3.3</a>).<a href="#section-9.4-4" class="pilcrow">¶</a></p>
+<p id="section-9.4-5">A sender can make exceptions for probe packets so that their loss detection is
+independent and does not unduly cause the congestion controller to reduce its
+sending rate.  An endpoint might set a separate timer when a PATH_CHALLENGE is
+sent, which is cancelled if the corresponding PATH_RESPONSE is received. If
+the timer fires before the PATH_RESPONSE is received, the endpoint might send a
+new PATH_CHALLENGE, and restart the timer for a longer period of time.
+This timer SHOULD be set as described in Section 5.3 of <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span> and
+MUST NOT be more aggressive.<a href="#section-9.4-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="migration-linkability">
+<section id="section-9.5">
+        <h3 id="name-privacy-implications-of-con">
+<a href="#section-9.5" class="section-number selfRef">9.5. </a><a href="#name-privacy-implications-of-con" class="section-name selfRef">Privacy Implications of Connection Migration</a>
+        </h3>
+<p id="section-9.5-1">Using a stable connection ID on multiple network paths allows a passive observer
+to correlate activity between those paths.  An endpoint that moves between
+networks might not wish to have their activity correlated by any entity other
+than their peer, so different connection IDs are used when sending from
+different local addresses, as discussed in <a href="#connection-id" class="xref">Section 5.1</a>.  For this to be
+effective endpoints need to ensure that connection IDs they provide cannot be
+linked by any other entity.<a href="#section-9.5-1" class="pilcrow">¶</a></p>
+<p id="section-9.5-2">At any time, endpoints MAY change the Destination Connection ID they send to a
+value that has not been used on another path.<a href="#section-9.5-2" class="pilcrow">¶</a></p>
+<p id="section-9.5-3">An endpoint MUST NOT reuse a connection ID when sending from more than one local
+address, for example when initiating connection migration as described in
+<a href="#initiating-migration" class="xref">Section 9.2</a> or when probing a new network path as described in
+<a href="#probing" class="xref">Section 9.1</a>.<a href="#section-9.5-3" class="pilcrow">¶</a></p>
+<p id="section-9.5-4">Similarly, an endpoint MUST NOT reuse a connection ID when sending to more than
+one destination address.  Due to network changes outside the control of its
+peer, an endpoint might receive packets from a new source address with the same
+destination connection ID, in which case it MAY continue to use the current
+connection ID with the new remote address while still sending from the same
+local address.<a href="#section-9.5-4" class="pilcrow">¶</a></p>
+<p id="section-9.5-5">These requirements regarding connection ID reuse apply only to the sending of
+packets, as unintentional changes in path without a change in connection ID are
+possible.  For example, after a period of network inactivity, NAT rebinding
+might cause packets to be sent on a new path when the client resumes sending.
+An endpoint responds to such an event as described in <a href="#migration-response" class="xref">Section 9.3</a>.<a href="#section-9.5-5" class="pilcrow">¶</a></p>
+<p id="section-9.5-6">Using different connection IDs for packets sent in both directions on each new
+network path eliminates the use of the connection ID for linking packets from
+the same connection across different network paths.  Header protection ensures
+that packet numbers cannot be used to correlate activity.  This does not prevent
+other properties of packets, such as timing and size, from being used to
+correlate activity.<a href="#section-9.5-6" class="pilcrow">¶</a></p>
+<p id="section-9.5-7">An endpoint SHOULD NOT initiate migration with a peer that has requested a
+zero-length connection ID, because traffic over the new path might be trivially
+linkable to traffic over the old one.  If the server is able to route packets
+with a zero-length connection ID to the right connection, it means that the
+server is using other information to demultiplex packets.  For example, a server
+might provide a unique address to every client, for instance using HTTP
+alternative services <span>[<a href="#ALTSVC" class="xref">ALTSVC</a>]</span>.  Information that might allow correct
+routing of packets across multiple network paths will also allow activity on
+those paths to be linked by entities other than the peer.<a href="#section-9.5-7" class="pilcrow">¶</a></p>
+<p id="section-9.5-8">A client might wish to reduce linkability by employing a new connection ID and
+source UDP port when sending traffic after a period of inactivity.  Changing the
+UDP port from which it sends packets at the same time might cause the packet to
+appear as a connection migration. This ensures that the mechanisms that support
+migration are exercised even for clients that don't experience NAT rebindings or
+genuine migrations.  Changing port number can cause a peer to reset its
+congestion state (see <a href="#migration-cc" class="xref">Section 9.4</a>), so the port SHOULD only be changed
+infrequently.<a href="#section-9.5-8" class="pilcrow">¶</a></p>
+<p id="section-9.5-9">An endpoint that exhausts available connection IDs cannot probe new paths or
+initiate migration, nor can it respond to probes or attempts by its peer to
+migrate.  To ensure that migration is possible and packets sent on different
+paths cannot be correlated, endpoints SHOULD provide new connection IDs before
+peers migrate; see <a href="#issue-cid" class="xref">Section 5.1.1</a>.  If a peer might have exhausted available
+connection IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in
+all packets sent on a new network path.<a href="#section-9.5-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="preferred-address">
+<section id="section-9.6">
+        <h3 id="name-servers-preferred-address">
+<a href="#section-9.6" class="section-number selfRef">9.6. </a><a href="#name-servers-preferred-address" class="section-name selfRef">Server's Preferred Address</a>
+        </h3>
+<p id="section-9.6-1">QUIC allows servers to accept connections on one IP address and attempt to
+transfer these connections to a more preferred address shortly after the
+handshake.  This is particularly useful when clients initially connect to an
+address shared by multiple servers but would prefer to use a unicast address to
+ensure connection stability. This section describes the protocol for migrating a
+connection to a preferred server address.<a href="#section-9.6-1" class="pilcrow">¶</a></p>
+<p id="section-9.6-2">Migrating a connection to a new server address mid-connection is left for future
+work. If a client receives packets from a new server address not indicated by
+the preferred_address transport parameter, the client SHOULD discard these
+packets.<a href="#section-9.6-2" class="pilcrow">¶</a></p>
+<div id="communicating-a-preferred-address">
+<section id="section-9.6.1">
+          <h4 id="name-communicating-a-preferred-a">
+<a href="#section-9.6.1" class="section-number selfRef">9.6.1. </a><a href="#name-communicating-a-preferred-a" class="section-name selfRef">Communicating a Preferred Address</a>
+          </h4>
+<p id="section-9.6.1-1">A server conveys a preferred address by including the preferred_address
+transport parameter in the TLS handshake.<a href="#section-9.6.1-1" class="pilcrow">¶</a></p>
+<p id="section-9.6.1-2">Servers MAY communicate a preferred address of each address family (IPv4 and
+IPv6) to allow clients to pick the one most suited to their network attachment.<a href="#section-9.6.1-2" class="pilcrow">¶</a></p>
+<p id="section-9.6.1-3">Once the handshake is confirmed, the client SHOULD select one of the two
+server's preferred addresses and initiate path validation (see
+<a href="#migrate-validate" class="xref">Section 8.2</a>) of that address using any previously unused active
+connection ID, taken from either the preferred_address transport parameter or
+a NEW_CONNECTION_ID frame.<a href="#section-9.6.1-3" class="pilcrow">¶</a></p>
+<p id="section-9.6.1-4">If path validation succeeds, the client SHOULD immediately begin sending all
+future packets to the new server address using the new connection ID and
+discontinue use of the old server address.  If path validation fails, the client
+MUST continue sending all future packets to the server's original IP address.<a href="#section-9.6.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="responding-to-connection-migration">
+<section id="section-9.6.2">
+          <h4 id="name-responding-to-connection-mig">
+<a href="#section-9.6.2" class="section-number selfRef">9.6.2. </a><a href="#name-responding-to-connection-mig" class="section-name selfRef">Responding to Connection Migration</a>
+          </h4>
+<p id="section-9.6.2-1">A server might receive a packet addressed to its preferred IP address at any
+time after it accepts a connection.  If this packet contains a PATH_CHALLENGE
+frame, the server sends a PATH_RESPONSE frame as per <a href="#migrate-validate" class="xref">Section 8.2</a>.  The
+server MUST send other non-probing frames from its original address until it
+receives a non-probing packet from the client at its preferred address and until
+the server has validated the new path.<a href="#section-9.6.2-1" class="pilcrow">¶</a></p>
+<p id="section-9.6.2-2">The server MUST probe on the path toward the client from its preferred address.
+This helps to guard against spurious migration initiated by an attacker.<a href="#section-9.6.2-2" class="pilcrow">¶</a></p>
+<p id="section-9.6.2-3">Once the server has completed its path validation and has received a non-probing
+packet with a new largest packet number on its preferred address, the server
+begins sending non-probing packets to the client exclusively from its preferred
+IP address.  It SHOULD drop packets for this connection received on the old IP
+address, but MAY continue to process delayed packets.<a href="#section-9.6.2-3" class="pilcrow">¶</a></p>
+<p id="section-9.6.2-4">The addresses that a server provides in the preferred_address transport
+parameter are only valid for the connection in which they are provided. A
+client MUST NOT use these for other connections, including connections that are
+resumed from the current connection.<a href="#section-9.6.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="interaction-of-client-migration-and-preferred-address">
+<section id="section-9.6.3">
+          <h4 id="name-interaction-of-client-migra">
+<a href="#section-9.6.3" class="section-number selfRef">9.6.3. </a><a href="#name-interaction-of-client-migra" class="section-name selfRef">Interaction of Client Migration and Preferred Address</a>
+          </h4>
+<p id="section-9.6.3-1">A client might need to perform a connection migration before it has migrated to
+the server's preferred address.  In this case, the client SHOULD perform path
+validation to both the original and preferred server address from the client's
+new address concurrently.<a href="#section-9.6.3-1" class="pilcrow">¶</a></p>
+<p id="section-9.6.3-2">If path validation of the server's preferred address succeeds, the client MUST
+abandon validation of the original address and migrate to using the server's
+preferred address.  If path validation of the server's preferred address fails
+but validation of the server's original address succeeds, the client MAY migrate
+to its new address and continue sending to the server's original address.<a href="#section-9.6.3-2" class="pilcrow">¶</a></p>
+<p id="section-9.6.3-3">If the connection to the server's preferred address is not from the same client
+address, the server MUST protect against potential attacks as described in
+<a href="#address-spoofing" class="xref">Section 9.3.1</a> and <a href="#on-path-spoofing" class="xref">Section 9.3.2</a>.  In addition to intentional
+simultaneous migration, this might also occur because the client's access
+network used a different NAT binding for the server's preferred address.<a href="#section-9.6.3-3" class="pilcrow">¶</a></p>
+<p id="section-9.6.3-4">Servers SHOULD initiate path validation to the client's new address upon
+receiving a probe packet from a different address.  Servers MUST NOT send more
+than a minimum congestion window's worth of non-probing packets to the new
+address before path validation is complete.<a href="#section-9.6.3-4" class="pilcrow">¶</a></p>
+<p id="section-9.6.3-5">A client that migrates to a new address SHOULD use a preferred address from the
+same address family for the server.<a href="#section-9.6.3-5" class="pilcrow">¶</a></p>
+<p id="section-9.6.3-6">The connection ID provided in the preferred_address transport parameter is not
+specific to the addresses that are provided. This connection ID is provided to
+ensure that the client has a connection ID available for migration, but the
+client MAY use this connection ID on any path.<a href="#section-9.6.3-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="ipv6-flow-label">
+<section id="section-9.7">
+        <h3 id="name-use-of-ipv6-flow-label-and-">
+<a href="#section-9.7" class="section-number selfRef">9.7. </a><a href="#name-use-of-ipv6-flow-label-and-" class="section-name selfRef">Use of IPv6 Flow-Label and Migration</a>
+        </h3>
+<p id="section-9.7-1">Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
+in compliance with <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>, unless the local API does not allow
+setting IPv6 flow labels.<a href="#section-9.7-1" class="pilcrow">¶</a></p>
+<p id="section-9.7-2">The IPv6 flow label SHOULD be a pseudo-random function of the source and
+destination addresses, source and destination UDP ports, and the destination
+CID.  The flow label generation MUST be designed to minimize the chances of
+linkability with a previously used flow label, as this would enable correlating
+activity on multiple paths; see <a href="#migration-linkability" class="xref">Section 9.5</a>.<a href="#section-9.7-2" class="pilcrow">¶</a></p>
+<p id="section-9.7-3">A possible implementation is to compute the flow label as a cryptographic hash
+function of the source and destination addresses, source and destination
+UDP ports, destination CID, and a local secret.<a href="#section-9.7-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="termination">
+<section id="section-10">
+      <h2 id="name-connection-termination">
+<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-connection-termination" class="section-name selfRef">Connection Termination</a>
+      </h2>
+<p id="section-10-1">An established QUIC connection can be terminated in one of three ways:<a href="#section-10-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-10-2.1">idle timeout (<a href="#idle-timeout" class="xref">Section 10.2</a>)<a href="#section-10-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-10-2.2">immediate close (<a href="#immediate-close" class="xref">Section 10.3</a>)<a href="#section-10-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-10-2.3">stateless reset (<a href="#stateless-reset" class="xref">Section 10.4</a>)<a href="#section-10-2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-10-3">An endpoint MAY discard connection state if it does not have a validated path on
+which it can send packets; see <a href="#migrate-validate" class="xref">Section 8.2</a>.<a href="#section-10-3" class="pilcrow">¶</a></p>
+<div id="draining">
+<section id="section-10.1">
+        <h3 id="name-closing-and-draining-connec">
+<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-closing-and-draining-connec" class="section-name selfRef">Closing and Draining Connection States</a>
+        </h3>
+<p id="section-10.1-1">The closing and draining connection states exist to ensure that connections
+close cleanly and that delayed or reordered packets are properly discarded.
+These states SHOULD persist for at least three times the current Probe Timeout
+(PTO) interval as defined in <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
+<p id="section-10.1-2">An endpoint enters a closing period after initiating an immediate close;
+<a href="#immediate-close" class="xref">Section 10.3</a>.  While closing, an endpoint MUST NOT send packets unless
+they contain a CONNECTION_CLOSE frame; see <a href="#immediate-close" class="xref">Section 10.3</a> for details.  An
+endpoint retains only enough information to generate a packet containing a
+CONNECTION_CLOSE frame and to identify packets as belonging to the connection.
+The endpoint's selected connection ID and the QUIC version are sufficient
+information to identify packets for a closing connection; an endpoint can
+discard all other connection state. An endpoint MAY retain packet protection
+keys for incoming packets to allow it to read and process a CONNECTION_CLOSE
+frame.<a href="#section-10.1-2" class="pilcrow">¶</a></p>
+<p id="section-10.1-3">The draining state is entered once an endpoint receives a signal that its peer
+is closing or draining.  While otherwise identical to the closing state, an
+endpoint in the draining state MUST NOT send any packets.  Retaining packet
+protection keys is unnecessary once a connection is in the draining state.<a href="#section-10.1-3" class="pilcrow">¶</a></p>
+<p id="section-10.1-4">An endpoint MAY transition from the closing period to the draining period if it
+receives a CONNECTION_CLOSE frame or stateless reset, both of which indicate
+that the peer is also closing or draining.  The draining period SHOULD end when
+the closing period would have ended.  In other words, the endpoint can use the
+same end time, but cease retransmission of the closing packet.<a href="#section-10.1-4" class="pilcrow">¶</a></p>
+<p id="section-10.1-5">Disposing of connection state prior to the end of the closing or draining period
+could cause delayed or reordered packets to generate an unnecessary stateless
+reset. Endpoints that have some alternative means to ensure that late-arriving
+packets on the connection do not induce a response, such as those that are able
+to close the UDP socket, MAY use an abbreviated draining period which can allow
+for faster resource recovery.  Servers that retain an open socket for accepting
+new connections SHOULD NOT exit the closing or draining period early.<a href="#section-10.1-5" class="pilcrow">¶</a></p>
+<p id="section-10.1-6">Once the closing or draining period has ended, an endpoint SHOULD discard all
+connection state.  This results in new packets on the connection being handled
+generically.  For instance, an endpoint MAY send a stateless reset in response
+to any further incoming packets.<a href="#section-10.1-6" class="pilcrow">¶</a></p>
+<p id="section-10.1-7">The draining and closing periods do not apply when a stateless reset
+(<a href="#stateless-reset" class="xref">Section 10.4</a>) is sent.<a href="#section-10.1-7" class="pilcrow">¶</a></p>
+<p id="section-10.1-8">An endpoint is not expected to handle key updates when it is closing or
+draining.  A key update might prevent the endpoint from moving from the closing
+state to draining, but it otherwise has no impact.<a href="#section-10.1-8" class="pilcrow">¶</a></p>
+<p id="section-10.1-9">While in the closing period, an endpoint could receive packets from a new source
+address, indicating a connection migration; <a href="#migration" class="xref">Section 9</a>. An endpoint in the
+closing state MUST strictly limit the number of packets it sends to this new
+address until the address is validated; see <a href="#migrate-validate" class="xref">Section 8.2</a>. A server in
+the closing state MAY instead choose to discard packets received from a new
+source address.<a href="#section-10.1-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="idle-timeout">
+<section id="section-10.2">
+        <h3 id="name-idle-timeout">
+<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-idle-timeout" class="section-name selfRef">Idle Timeout</a>
+        </h3>
+<p id="section-10.2-1">If a max_idle_timeout is specified by either peer in its transport parameters
+(<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>), the connection is silently closed
+and its state is discarded when it remains idle for longer than the minimum of
+both peers max_idle_timeout values and three times the current Probe Timeout
+(PTO).<a href="#section-10.2-1" class="pilcrow">¶</a></p>
+<p id="section-10.2-2">Each endpoint advertises a max_idle_timeout, but the effective value
+at an endpoint is computed as the minimum of the two advertised values. By
+announcing a max_idle_timeout, an endpoint commits to initiating an immediate
+close (<a href="#immediate-close" class="xref">Section 10.3</a>) if it abandons the connection prior to the effective
+value.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
+<p id="section-10.2-3">An endpoint restarts its idle timer when a packet from its peer is received and
+processed successfully. An endpoint also restarts its idle timer when sending an
+ack-eliciting packet if no other ack-eliciting packets have been sent since last
+receiving and processing a packet. Restarting this timer when sending a packet
+ensures that connections are not closed after new activity is initiated.<a href="#section-10.2-3" class="pilcrow">¶</a></p>
+<p id="section-10.2-4">An endpoint might need to send ack-eliciting packets to avoid an idle timeout
+if it is expecting response data, but does not have or is unable to send
+application data.<a href="#section-10.2-4" class="pilcrow">¶</a></p>
+<p id="section-10.2-5">An endpoint that sends packets close to the effective timeout risks having
+them be discarded at the peer, since the peer might enter its draining state
+before these packets arrive. An endpoint can send a PING or another
+ack-eliciting frame to test the connection for liveness if the peer could
+time out soon, such as within a PTO; see Section 6.6 of <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>.
+This is especially useful if any available application data cannot be safely
+retried. Note that the application determines what data is safe to retry.<a href="#section-10.2-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="immediate-close">
+<section id="section-10.3">
+        <h3 id="name-immediate-close">
+<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-immediate-close" class="section-name selfRef">Immediate Close</a>
+        </h3>
+<p id="section-10.3-1">An endpoint sends a CONNECTION_CLOSE frame (<a href="#frame-connection-close" class="xref">Section 19.19</a>) to
+terminate the connection immediately.  A CONNECTION_CLOSE frame causes all
+streams to immediately become closed; open streams can be assumed to be
+implicitly reset.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
+<p id="section-10.3-2">After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the
+closing state.<a href="#section-10.3-2" class="pilcrow">¶</a></p>
+<p id="section-10.3-3">During the closing period, an endpoint that sends a CONNECTION_CLOSE frame
+SHOULD respond to any incoming packet that can be decrypted with another packet
+containing a CONNECTION_CLOSE frame.  Such an endpoint SHOULD limit the number
+of packets it generates containing a CONNECTION_CLOSE frame.  For instance, an
+endpoint could wait for a progressively increasing number of received packets or
+amount of time before responding to a received packet.<a href="#section-10.3-3" class="pilcrow">¶</a></p>
+<p id="section-10.3-4">An endpoint is allowed to drop the packet protection keys when entering the
+closing period (<a href="#draining" class="xref">Section 10.1</a>) and send a packet containing a CONNECTION_CLOSE in
+response to any UDP datagram that is received.  However, an endpoint without the
+packet protection keys cannot identify and discard invalid packets.  To avoid
+creating an unwitting amplification attack, such endpoints MUST reduce the
+frequency with which it sends packets containing a CONNECTION_CLOSE frame.  To
+minimize the state that an endpoint maintains for a closing connection,
+endpoints MAY send the exact same packet.<a href="#section-10.3-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-10.3-5">
+          <dt id="section-10.3-5.1">Note:</dt>
+<dd id="section-10.3-5.2">
+  Allowing retransmission of a closing packet contradicts other advice in this
+document that recommends the creation of new packet numbers for every packet.
+Sending new packet numbers is primarily of advantage to loss recovery and
+congestion control, which are not expected to be relevant for a closed
+connection.  Retransmitting the final packet requires less state.<a href="#section-10.3-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-10.3-6">New packets from unverified addresses could be used to create an amplification
+attack; see <a href="#address-validation" class="xref">Section 8</a>.  To avoid this, endpoints MUST either limit
+transmission of CONNECTION_CLOSE frames to validated addresses or drop packets
+without response if the response would be more than three times larger than the
+received packet.<a href="#section-10.3-6" class="pilcrow">¶</a></p>
+<p id="section-10.3-7">After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state.
+An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet
+containing a CONNECTION_CLOSE frame before entering the draining state, using a
+CONNECTION_CLOSE frame and a NO_ERROR code if appropriate.  An endpoint MUST NOT
+send further packets, which could result in a constant exchange of
+CONNECTION_CLOSE frames until the closing period on either peer ended.<a href="#section-10.3-7" class="pilcrow">¶</a></p>
+<p id="section-10.3-8">An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a
+graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which
+the application requests that the connection be closed.  The application
+protocol can use a CONNECTION_CLOSE frame with an appropriate error code to
+signal closure.<a href="#section-10.3-8" class="pilcrow">¶</a></p>
+<div id="immediate-close-hs">
+<section id="section-10.3.1">
+          <h4 id="name-immediate-close-during-the-">
+<a href="#section-10.3.1" class="section-number selfRef">10.3.1. </a><a href="#name-immediate-close-during-the-" class="section-name selfRef">Immediate Close During the Handshake</a>
+          </h4>
+<p id="section-10.3.1-1">When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process
+the frame.  Generally, this means sending the frame in a packet with the highest
+level of packet protection to avoid the packet being discarded.  After the
+handshake is confirmed (see Section 4.1.2 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>), an endpoint MUST
+send any CONNECTION_CLOSE frames in a 1-RTT packet.  However, prior to
+confirming the handshake, it is possible that more advanced packet protection
+keys are not available to the peer, so another CONNECTION_CLOSE frame MAY be
+sent in a packet that uses a lower packet protection level.  More specifically:<a href="#section-10.3.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-10.3.1-2.1">A client will always know whether the server has Handshake keys (see
+<a href="#discard-initial" class="xref">Section 17.2.2.1</a>), but it is possible that a server does not know whether
+the client has Handshake keys.  Under these circumstances, a server SHOULD
+send a CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure
+that at least one of them is processable by the client.<a href="#section-10.3.1-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-10.3.1-2.2">A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be assured of
+the server has accepted 0-RTT and so sending a CONNECTION_CLOSE frame in an
+Initial packet makes it more likely that the server can receive the close
+signal, even if the application error code might not be received.<a href="#section-10.3.1-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-10.3.1-2.3">Prior to confirming the handshake, a peer might be unable to process 1-RTT
+packets, so an endpoint SHOULD send CONNECTION_CLOSE in both Handshake and
+1-RTT packets.  A server SHOULD also send CONNECTION_CLOSE in an Initial
+packet.<a href="#section-10.3.1-2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-10.3.1-3">Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake packet could
+expose application state or be used to alter application state. A
+CONNECTION_CLOSE of type 0x1d MUST be replaced by a CONNECTION_CLOSE of type
+0x1c when sending the frame in Initial or Handshake packets. Otherwise,
+information about the application state might be revealed. Endpoints MUST clear
+the value of the Reason Phrase field and SHOULD use the APPLICATION_ERROR code
+when converting to a CONNECTION_CLOSE of type 0x1c.<a href="#section-10.3.1-3" class="pilcrow">¶</a></p>
+<p id="section-10.3.1-4">CONNECTION_CLOSE frames sent in multiple packet types can be coalesced into a
+single UDP datagram; see <a href="#packet-coalesce" class="xref">Section 12.2</a>.<a href="#section-10.3.1-4" class="pilcrow">¶</a></p>
+<p id="section-10.3.1-5">An endpoint might send a CONNECTION_CLOSE frame in an Initial packet or in
+response to unauthenticated information received in Initial or Handshake
+packets.  Such an immediate close might expose legitimate connections to a
+denial of service.  QUIC does not include defensive measures for on-path attacks
+during the handshake; see <a href="#handshake-dos" class="xref">Section 21.1</a>.  However, at the cost of reducing
+feedback about errors for legitimate peers, some forms of denial of service can
+be made more difficult for an attacker if endpoints discard illegal packets
+rather than terminating a connection with CONNECTION_CLOSE.  For this reason,
+endpoints MAY discard packets rather than immediately close if errors are
+detected in packets that lack authentication.<a href="#section-10.3.1-5" class="pilcrow">¶</a></p>
+<p id="section-10.3.1-6">An endpoint that has not established state, such as a server that detects an
+error in an Initial packet, does not enter the closing state.  An endpoint that
+has no state for the connection does not enter a closing or draining period on
+sending a CONNECTION_CLOSE frame.<a href="#section-10.3.1-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="stateless-reset">
+<section id="section-10.4">
+        <h3 id="name-stateless-reset">
+<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-stateless-reset" class="section-name selfRef">Stateless Reset</a>
+        </h3>
+<p id="section-10.4-1">A stateless reset is provided as an option of last resort for an endpoint that
+does not have access to the state of a connection.  A crash or outage might
+result in peers continuing to send data to an endpoint that is unable to
+properly continue the connection.  An endpoint MAY send a stateless reset in
+response to receiving a packet that it cannot associate with an active
+connection.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
+<p id="section-10.4-2">A stateless reset is not appropriate for signaling error conditions.  An
+endpoint that wishes to communicate a fatal connection error MUST use a
+CONNECTION_CLOSE frame if it has sufficient state to do so.<a href="#section-10.4-2" class="pilcrow">¶</a></p>
+<p id="section-10.4-3">To support this process, a token is sent by endpoints.  The token is carried in
+the Stateless Reset Token field of a NEW_CONNECTION_ID frame.  Servers can also
+specify a stateless_reset_token transport parameter during the handshake that
+applies to the connection ID that it selected during the handshake; clients
+cannot use this transport parameter because their transport parameters don't
+have confidentiality protection.  These tokens are protected by encryption, so
+only client and server know their value.  Tokens are invalidated when their
+associated connection ID is retired via a RETIRE_CONNECTION_ID frame
+(<a href="#frame-retire-connection-id" class="xref">Section 19.16</a>).<a href="#section-10.4-3" class="pilcrow">¶</a></p>
+<p id="section-10.4-4">An endpoint that receives packets that it cannot process sends a packet in the
+following layout:<a href="#section-10.4-4" class="pilcrow">¶</a></p>
+<span id="name-stateless-reset-packet"></span><div id="fig-stateless-reset">
+<figure id="figure-9">
+          <div class="artwork art-text alignLeft" id="section-10.4-5.1">
+<pre>
+Stateless Reset {
+  Fixed Bits (2) = 1,
+  Unpredictable Bits (38..),
+  Stateless Reset Token (128),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
+<a href="#name-stateless-reset-packet" class="selfRef">Stateless Reset Packet</a>
+          </figcaption></figure>
+</div>
+<p id="section-10.4-6">This design ensures that a stateless reset packet is - to the extent possible -
+indistinguishable from a regular packet with a short header.<a href="#section-10.4-6" class="pilcrow">¶</a></p>
+<p id="section-10.4-7">A stateless reset uses an entire UDP datagram, starting with the first two bits
+of the packet header.  The remainder of the first byte and an arbitrary number
+of bytes following it that are set to unpredictable values.  The last 16 bytes
+of the datagram contain a Stateless Reset Token.<a href="#section-10.4-7" class="pilcrow">¶</a></p>
+<p id="section-10.4-8">To entities other than its intended recipient, a stateless reset will appear to
+be a packet with a short header.  For the stateless reset to appear as a valid
+QUIC packet, the Unpredictable Bits field needs to include at least 38 bits of
+data (or 5 bytes, less the two fixed bits).<a href="#section-10.4-8" class="pilcrow">¶</a></p>
+<p id="section-10.4-9">A minimum size of 21 bytes does not guarantee that a stateless reset is
+difficult to distinguish from other packets if the recipient requires the use of
+a connection ID.  To prevent a resulting stateless reset from being trivially
+distinguishable from a valid packet, all packets sent by an endpoint SHOULD be
+padded to at least 22 bytes longer than the minimum connection ID that the
+endpoint might use.  An endpoint that sends a stateless reset in response to a
+packet that is 43 bytes or less in length SHOULD send a stateless reset that is
+one byte shorter than the packet it responds to.<a href="#section-10.4-9" class="pilcrow">¶</a></p>
+<p id="section-10.4-10">These values assume that the Stateless Reset Token is the same length as the
+minimum expansion of the packet protection AEAD.  Additional unpredictable bytes
+are necessary if the endpoint could have negotiated a packet protection scheme
+with a larger minimum expansion.<a href="#section-10.4-10" class="pilcrow">¶</a></p>
+<p id="section-10.4-11">An endpoint MUST NOT send a stateless reset that is three times or more larger
+than the packet it receives to avoid being used for amplification.
+<a href="#reset-looping" class="xref">Section 10.4.3</a> describes additional limits on stateless reset size.<a href="#section-10.4-11" class="pilcrow">¶</a></p>
+<p id="section-10.4-12">Endpoints MUST discard packets that are too small to be valid QUIC packets.
+With the set of AEAD functions defined in <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>, packets that are smaller
+than 21 bytes are never valid.<a href="#section-10.4-12" class="pilcrow">¶</a></p>
+<p id="section-10.4-13">Endpoints MUST send stateless reset packets formatted as a packet with a short
+header.  However, endpoints MUST treat any packet ending in a valid stateless
+reset token as a stateless reset, as other QUIC versions might allow the use of
+a long header.<a href="#section-10.4-13" class="pilcrow">¶</a></p>
+<p id="section-10.4-14">An endpoint MAY send a stateless reset in response to a packet with a long
+header.  Sending a stateless reset is not effective prior to the stateless reset
+token being available to a peer.  In this QUIC version, packets with a long
+header are only used during connection establishment.   Because the stateless
+reset token is not available until connection establishment is complete or near
+completion, ignoring an unknown packet with a long header might be as effective
+as sending a stateless reset.<a href="#section-10.4-14" class="pilcrow">¶</a></p>
+<p id="section-10.4-15">An endpoint cannot determine the Source Connection ID from a packet with a short
+header, therefore it cannot set the Destination Connection ID in the stateless
+reset packet.  The Destination Connection ID will therefore differ from the
+value used in previous packets.  A random Destination Connection ID makes the
+connection ID appear to be the result of moving to a new connection ID that was
+provided using a NEW_CONNECTION_ID frame (<a href="#frame-new-connection-id" class="xref">Section 19.15</a>).<a href="#section-10.4-15" class="pilcrow">¶</a></p>
+<p id="section-10.4-16">Using a randomized connection ID results in two problems:<a href="#section-10.4-16" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-10.4-17.1">The packet might not reach the peer.  If the Destination Connection ID is
+critical for routing toward the peer, then this packet could be incorrectly
+routed.  This might also trigger another Stateless Reset in response; see
+<a href="#reset-looping" class="xref">Section 10.4.3</a>.  A Stateless Reset that is not correctly routed is
+an ineffective error detection and recovery mechanism.  In this
+case, endpoints will need to rely on other methods - such as timers - to
+detect that the connection has failed.<a href="#section-10.4-17.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-10.4-17.2">The randomly generated connection ID can be used by entities other than the
+peer to identify this as a potential stateless reset.  An endpoint that
+occasionally uses different connection IDs might introduce some uncertainty
+about this.<a href="#section-10.4-17.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-10.4-18">This stateless reset design is specific to QUIC version 1.  An endpoint that
+supports multiple versions of QUIC needs to generate a stateless reset that will
+be accepted by peers that support any version that the endpoint might support
+(or might have supported prior to losing state).  Designers of new versions of
+QUIC need to be aware of this and either reuse this design, or use a portion of
+the packet other than the last 16 bytes for carrying data.<a href="#section-10.4-18" class="pilcrow">¶</a></p>
+<div id="detecting-a-stateless-reset">
+<section id="section-10.4.1">
+          <h4 id="name-detecting-a-stateless-reset">
+<a href="#section-10.4.1" class="section-number selfRef">10.4.1. </a><a href="#name-detecting-a-stateless-reset" class="section-name selfRef">Detecting a Stateless Reset</a>
+          </h4>
+<p id="section-10.4.1-1">An endpoint detects a potential stateless reset using the trailing 16 bytes of
+the UDP datagram.  An endpoint remembers all Stateless Reset Tokens associated
+with the connection IDs and remote addresses for datagrams it has recently sent.
+This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the
+server's transport parameters but excludes Stateless Reset Tokens associated
+with connection IDs that are either unused or retired.  The endpoint identifies
+a received datagram as a stateless reset by comparing the last 16 bytes of the
+datagram with all Stateless Reset Tokens associated with the remote address on
+which the datagram was received.<a href="#section-10.4.1-1" class="pilcrow">¶</a></p>
+<p id="section-10.4.1-2">This comparison can be performed for every inbound datagram.  Endpoints MAY skip
+this check if any packet from a datagram is successfully processed.  However,
+the comparison MUST be performed when the first packet in an incoming datagram
+either cannot be associated with a connection, or cannot be decrypted.<a href="#section-10.4.1-2" class="pilcrow">¶</a></p>
+<p id="section-10.4.1-3">An endpoint MUST NOT check for any Stateless Reset Tokens associated with
+connection IDs it has not used or for connection IDs that have been retired.<a href="#section-10.4.1-3" class="pilcrow">¶</a></p>
+<p id="section-10.4.1-4">When comparing a datagram to Stateless Reset Token values, endpoints MUST
+perform the comparison without leaking information about the value of the token.
+For example, performing this comparison in constant time protects the value of
+individual Stateless Reset Tokens from information leakage through timing side
+channels.  Another approach would be to store and compare the transformed values
+of Stateless Reset Tokens instead of the raw token values, where the
+transformation is defined as a cryptographically-secure pseudo-random function
+using a secret key (e.g., block cipher, HMAC <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span>). An endpoint is not
+expected to protect information about whether a packet was successfully
+decrypted, or the number of valid Stateless Reset Tokens.<a href="#section-10.4.1-4" class="pilcrow">¶</a></p>
+<p id="section-10.4.1-5">If the last 16 bytes of the datagram are identical in value to a Stateless Reset
+Token, the endpoint MUST enter the draining period and not send any further
+packets on this connection.<a href="#section-10.4.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="reset-token">
+<section id="section-10.4.2">
+          <h4 id="name-calculating-a-stateless-res">
+<a href="#section-10.4.2" class="section-number selfRef">10.4.2. </a><a href="#name-calculating-a-stateless-res" class="section-name selfRef">Calculating a Stateless Reset Token</a>
+          </h4>
+<p id="section-10.4.2-1">The stateless reset token MUST be difficult to guess.  In order to create a
+Stateless Reset Token, an endpoint could randomly generate <span>[<a href="#RFC4086" class="xref">RFC4086</a>]</span> a secret
+for every connection that it creates.  However, this presents a coordination
+problem when there are multiple instances in a cluster or a storage problem for
+an endpoint that might lose state.  Stateless reset specifically exists to
+handle the case where state is lost, so this approach is suboptimal.<a href="#section-10.4.2-1" class="pilcrow">¶</a></p>
+<p id="section-10.4.2-2">A single static key can be used across all connections to the same endpoint by
+generating the proof using a second iteration of a preimage-resistant function
+that takes a static key and the connection ID chosen by the endpoint (see
+<a href="#connection-id" class="xref">Section 5.1</a>) as input.  An endpoint could use HMAC <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span> (for
+example, HMAC(static_key, connection_id)) or HKDF <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span> (for example,
+using the static key as input keying material, with the connection ID as salt).
+The output of this function is truncated to 16 bytes to produce the Stateless
+Reset Token for that connection.<a href="#section-10.4.2-2" class="pilcrow">¶</a></p>
+<p id="section-10.4.2-3">An endpoint that loses state can use the same method to generate a valid
+Stateless Reset Token.  The connection ID comes from the packet that the
+endpoint receives.<a href="#section-10.4.2-3" class="pilcrow">¶</a></p>
+<p id="section-10.4.2-4">This design relies on the peer always sending a connection ID in its packets so
+that the endpoint can use the connection ID from a packet to reset the
+connection.  An endpoint that uses this design MUST either use the same
+connection ID length for all connections or encode the length of the connection
+ID such that it can be recovered without state.  In addition, it cannot provide
+a zero-length connection ID.<a href="#section-10.4.2-4" class="pilcrow">¶</a></p>
+<p id="section-10.4.2-5">Revealing the Stateless Reset Token allows any entity to terminate the
+connection, so a value can only be used once.  This method for choosing the
+Stateless Reset Token means that the combination of connection ID and static key
+MUST NOT be used for another connection.  A denial of service attack is possible
+if the same connection ID is used by instances that share a static key, or if an
+attacker can cause a packet to be routed to an instance that has no state but
+the same static key; see <a href="#reset-oracle" class="xref">Section 21.9</a>.  A connection ID from a connection
+that is reset by revealing the Stateless Reset Token MUST NOT be reused for new
+connections at nodes that share a static key.<a href="#section-10.4.2-5" class="pilcrow">¶</a></p>
+<p id="section-10.4.2-6">The same Stateless Reset Token MUST NOT be used for multiple connection IDs.
+Endpoints are not required to compare new values against all previous values,
+but a duplicate value MAY be treated as a connection error of type
+PROTOCOL_VIOLATION.<a href="#section-10.4.2-6" class="pilcrow">¶</a></p>
+<p id="section-10.4.2-7">Note that Stateless Reset packets do not have any cryptographic protection.<a href="#section-10.4.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="reset-looping">
+<section id="section-10.4.3">
+          <h4 id="name-looping">
+<a href="#section-10.4.3" class="section-number selfRef">10.4.3. </a><a href="#name-looping" class="section-name selfRef">Looping</a>
+          </h4>
+<p id="section-10.4.3-1">The design of a Stateless Reset is such that without knowing the stateless reset
+token it is indistinguishable from a valid packet.  For instance, if a server
+sends a Stateless Reset to another server it might receive another Stateless
+Reset in response, which could lead to an infinite exchange.<a href="#section-10.4.3-1" class="pilcrow">¶</a></p>
+<p id="section-10.4.3-2">An endpoint MUST ensure that every Stateless Reset that it sends is smaller than
+the packet which triggered it, unless it maintains state sufficient to prevent
+looping.  In the event of a loop, this results in packets eventually being too
+small to trigger a response.<a href="#section-10.4.3-2" class="pilcrow">¶</a></p>
+<p id="section-10.4.3-3">An endpoint can remember the number of Stateless Reset packets that it has sent
+and stop generating new Stateless Reset packets once a limit is reached.  Using
+separate limits for different remote addresses will ensure that Stateless Reset
+packets can be used to close connections when other peers or connections have
+exhausted limits.<a href="#section-10.4.3-3" class="pilcrow">¶</a></p>
+<p id="section-10.4.3-4">Reducing the size of a Stateless Reset below 41 bytes means that the packet
+could reveal to an observer that it is a Stateless Reset, depending upon the
+length of the peer's connection IDs.  Conversely, refusing to send a Stateless
+Reset in response to a small packet might result in Stateless Reset not being
+useful in detecting cases of broken connections where only very small packets
+are sent; such failures might only be detected by other means, such as timers.<a href="#section-10.4.3-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="error-handling">
+<section id="section-11">
+      <h2 id="name-error-handling">
+<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-error-handling" class="section-name selfRef">Error Handling</a>
+      </h2>
+<p id="section-11-1">An endpoint that detects an error SHOULD signal the existence of that error to
+its peer.  Both transport-level and application-level errors can affect an
+entire connection; see <a href="#connection-errors" class="xref">Section 11.1</a>.  Only application-level
+errors can be isolated to a single stream; see <a href="#stream-errors" class="xref">Section 11.2</a>.<a href="#section-11-1" class="pilcrow">¶</a></p>
+<p id="section-11-2">The most appropriate error code (<a href="#error-codes" class="xref">Section 20</a>) SHOULD be included in the
+frame that signals the error.  Where this specification identifies error
+conditions, it also identifies the error code that is used; though these are
+worded as requirements, different implementation strategies might lead to
+different errors being reported.  In particular, an endpoint MAY use any
+applicable error code when it detects an error condition; a generic error code
+(such as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place of
+specific error codes.<a href="#section-11-2" class="pilcrow">¶</a></p>
+<p id="section-11-3">A stateless reset (<a href="#stateless-reset" class="xref">Section 10.4</a>) is not suitable for any error that can
+be signaled with a CONNECTION_CLOSE or RESET_STREAM frame.  A stateless reset
+MUST NOT be used by an endpoint that has the state necessary to send a frame on
+the connection.<a href="#section-11-3" class="pilcrow">¶</a></p>
+<div id="connection-errors">
+<section id="section-11.1">
+        <h3 id="name-connection-errors">
+<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-connection-errors" class="section-name selfRef">Connection Errors</a>
+        </h3>
+<p id="section-11.1-1">Errors that result in the connection being unusable, such as an obvious
+violation of protocol semantics or corruption of state that affects an entire
+connection, MUST be signaled using a CONNECTION_CLOSE frame
+(<a href="#frame-connection-close" class="xref">Section 19.19</a>). An endpoint MAY close the connection in this
+manner even if the error only affects a single stream.<a href="#section-11.1-1" class="pilcrow">¶</a></p>
+<p id="section-11.1-2">Application protocols can signal application-specific protocol errors using the
+application-specific variant of the CONNECTION_CLOSE frame.  Errors that are
+specific to the transport, including all those described in this document, are
+carried in the QUIC-specific variant of the CONNECTION_CLOSE frame.<a href="#section-11.1-2" class="pilcrow">¶</a></p>
+<p id="section-11.1-3">A CONNECTION_CLOSE frame could be sent in a packet that is lost.  An endpoint
+SHOULD be prepared to retransmit a packet containing a CONNECTION_CLOSE frame if
+it receives more packets on a terminated connection. Limiting the number of
+retransmissions and the time over which this final packet is sent limits the
+effort expended on terminated connections.<a href="#section-11.1-3" class="pilcrow">¶</a></p>
+<p id="section-11.1-4">An endpoint that chooses not to retransmit packets containing a CONNECTION_CLOSE
+frame risks a peer missing the first such packet.  The only mechanism available
+to an endpoint that continues to receive data for a terminated connection is to
+use the stateless reset process (<a href="#stateless-reset" class="xref">Section 10.4</a>).<a href="#section-11.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-errors">
+<section id="section-11.2">
+        <h3 id="name-stream-errors">
+<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-stream-errors" class="section-name selfRef">Stream Errors</a>
+        </h3>
+<p id="section-11.2-1">If an application-level error affects a single stream, but otherwise leaves the
+connection in a recoverable state, the endpoint can send a RESET_STREAM frame
+(<a href="#frame-reset-stream" class="xref">Section 19.4</a>) with an appropriate error code to terminate just the
+affected stream.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
+<p id="section-11.2-2">Resetting a stream without the involvement of the application protocol could
+cause the application protocol to enter an unrecoverable state.  RESET_STREAM
+MUST only be instigated by the application protocol that uses QUIC.<a href="#section-11.2-2" class="pilcrow">¶</a></p>
+<p id="section-11.2-3">The semantics of the application error code carried in RESET_STREAM are
+defined by the application protocol.  Only the application protocol is able to
+cause a stream to be terminated.  A local instance of the application protocol
+uses a direct API call and a remote instance uses the STOP_SENDING frame, which
+triggers an automatic RESET_STREAM.<a href="#section-11.2-3" class="pilcrow">¶</a></p>
+<p id="section-11.2-4">Application protocols SHOULD define rules for handling streams that are
+prematurely cancelled by either endpoint.<a href="#section-11.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="packets-frames">
+<section id="section-12">
+      <h2 id="name-packets-and-frames">
+<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-packets-and-frames" class="section-name selfRef">Packets and Frames</a>
+      </h2>
+<p id="section-12-1">QUIC endpoints communicate by exchanging packets. Packets have confidentiality
+and integrity protection; see <a href="#packet-protected" class="xref">Section 12.1</a>. Packets are carried in UDP
+datagrams; see <a href="#packet-coalesce" class="xref">Section 12.2</a>.<a href="#section-12-1" class="pilcrow">¶</a></p>
+<p id="section-12-2">This version of QUIC uses the long packet header during connection
+establishment; see <a href="#long-header" class="xref">Section 17.2</a>.  Packets with the long header are Initial
+(<a href="#packet-initial" class="xref">Section 17.2.2</a>), 0-RTT (<a href="#packet-0rtt" class="xref">Section 17.2.3</a>), Handshake (<a href="#packet-handshake" class="xref">Section 17.2.4</a>),
+and Retry (<a href="#packet-retry" class="xref">Section 17.2.5</a>).  Version negotiation uses a version-independent
+packet with a long header; see <a href="#packet-version" class="xref">Section 17.2.1</a>.<a href="#section-12-2" class="pilcrow">¶</a></p>
+<p id="section-12-3">Packets with the short header are designed for minimal overhead and are used
+after a connection is established and 1-RTT keys are available; see
+<a href="#short-header" class="xref">Section 17.3</a>.<a href="#section-12-3" class="pilcrow">¶</a></p>
+<div id="packet-protected">
+<section id="section-12.1">
+        <h3 id="name-protected-packets">
+<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-protected-packets" class="section-name selfRef">Protected Packets</a>
+        </h3>
+<p id="section-12.1-1">All QUIC packets except Version Negotiation packets use authenticated
+encryption with additional data (AEAD) <span>[<a href="#RFC5116" class="xref">RFC5116</a>]</span> to provide confidentiality
+and integrity protection.  Retry packets use AEAD to provide integrity
+protection.  Details of packet protection are found in <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>; this
+section includes an overview of the process.<a href="#section-12.1-1" class="pilcrow">¶</a></p>
+<p id="section-12.1-2">Initial packets are protected using keys that are statically derived. This
+packet protection is not effective confidentiality protection.  Initial
+protection only exists to ensure that the sender of the packet is on the network
+path. Any entity that receives the Initial packet from a client can recover the
+keys necessary to remove packet protection or to generate packets that will be
+successfully authenticated.<a href="#section-12.1-2" class="pilcrow">¶</a></p>
+<p id="section-12.1-3">All other packets are protected with keys derived from the cryptographic
+handshake. The type of the packet from the long header or key phase from the
+short header are used to identify which encryption keys are used. Packets
+protected with 0-RTT and 1-RTT keys are expected to have confidentiality and
+data origin authentication; the cryptographic handshake ensures that only the
+communicating endpoints receive the corresponding keys.<a href="#section-12.1-3" class="pilcrow">¶</a></p>
+<p id="section-12.1-4">The packet number field contains a packet number, which has additional
+confidentiality protection that is applied after packet protection is applied;
+see <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span> for details.  The underlying packet number increases with each
+packet sent in a given packet number space; see <a href="#packet-numbers" class="xref">Section 12.3</a> for details.<a href="#section-12.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="packet-coalesce">
+<section id="section-12.2">
+        <h3 id="name-coalescing-packets">
+<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-coalescing-packets" class="section-name selfRef">Coalescing Packets</a>
+        </h3>
+<p id="section-12.2-1">Initial (<a href="#packet-initial" class="xref">Section 17.2.2</a>), 0-RTT (<a href="#packet-0rtt" class="xref">Section 17.2.3</a>), and Handshake
+(<a href="#packet-handshake" class="xref">Section 17.2.4</a>) packets contain a Length field, which determines the end
+of the packet.  The length includes both the Packet Number and Payload
+fields, both of which are confidentiality protected and initially of unknown
+length. The length of the Payload field is learned once header protection is
+removed.<a href="#section-12.2-1" class="pilcrow">¶</a></p>
+<p id="section-12.2-2">Using the Length field, a sender can coalesce multiple QUIC packets into one UDP
+datagram.  This can reduce the number of UDP datagrams needed to complete the
+cryptographic handshake and start sending data.  This can also be used to
+construct PMTU probes; see <a href="#pmtu-probes-src-cid" class="xref">Section 14.3.1</a>.  Receivers MUST be able to
+process coalesced packets.<a href="#section-12.2-2" class="pilcrow">¶</a></p>
+<p id="section-12.2-3">Coalescing packets in order of increasing encryption levels (Initial, 0-RTT,
+Handshake, 1-RTT; see Section 4.1.4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>) makes it more likely the
+receiver will be able to process all the packets in a single pass. A packet
+with a short header does not include a length, so it can only be the last
+packet included in a UDP datagram. An endpoint SHOULD NOT coalesce multiple
+packets at the same encryption level.<a href="#section-12.2-3" class="pilcrow">¶</a></p>
+<p id="section-12.2-4">Senders MUST NOT coalesce QUIC packets for different connections into a single
+UDP datagram. Receivers SHOULD ignore any subsequent packets with a different
+Destination Connection ID than the first packet in the datagram.<a href="#section-12.2-4" class="pilcrow">¶</a></p>
+<p id="section-12.2-5">Every QUIC packet that is coalesced into a single UDP datagram is separate and
+complete.  The receiver of coalesced QUIC packets MUST individually process each
+QUIC packet and separately acknowledge them, as if they were received as the
+payload of different UDP datagrams.  For example, if decryption fails (because
+the keys are not available or any other reason), the receiver MAY either discard
+or buffer the packet for later processing and MUST attempt to process the
+remaining packets.<a href="#section-12.2-5" class="pilcrow">¶</a></p>
+<p id="section-12.2-6">Retry packets (<a href="#packet-retry" class="xref">Section 17.2.5</a>), Version Negotiation packets
+(<a href="#packet-version" class="xref">Section 17.2.1</a>), and packets with a short header (<a href="#short-header" class="xref">Section 17.3</a>) do not
+contain a Length field and so cannot be followed by other packets in the same
+UDP datagram.  Note also that there is no situation where a Retry or Version
+Negotiation packet is coalesced with another packet.<a href="#section-12.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="packet-numbers">
+<section id="section-12.3">
+        <h3 id="name-packet-numbers">
+<a href="#section-12.3" class="section-number selfRef">12.3. </a><a href="#name-packet-numbers" class="section-name selfRef">Packet Numbers</a>
+        </h3>
+<p id="section-12.3-1">The packet number is an integer in the range 0 to 2^62-1.  This number is used
+in determining the cryptographic nonce for packet protection.  Each endpoint
+maintains a separate packet number for sending and receiving.<a href="#section-12.3-1" class="pilcrow">¶</a></p>
+<p id="section-12.3-2">Packet numbers are limited to this range because they need to be representable
+in whole in the Largest Acknowledged field of an ACK frame (<a href="#frame-ack" class="xref">Section 19.3</a>).
+When present in a long or short header however, packet numbers are reduced and
+encoded in 1 to 4 bytes; see <a href="#packet-encoding" class="xref">Section 17.1</a>.<a href="#section-12.3-2" class="pilcrow">¶</a></p>
+<p id="section-12.3-3">Version Negotiation (<a href="#packet-version" class="xref">Section 17.2.1</a>) and Retry (<a href="#packet-retry" class="xref">Section 17.2.5</a>) packets
+do not include a packet number.<a href="#section-12.3-3" class="pilcrow">¶</a></p>
+<p id="section-12.3-4">Packet numbers are divided into 3 spaces in QUIC:<a href="#section-12.3-4" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-12.3-5.1">Initial space: All Initial packets (<a href="#packet-initial" class="xref">Section 17.2.2</a>) are in this space.<a href="#section-12.3-5.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-12.3-5.2">Handshake space: All Handshake packets (<a href="#packet-handshake" class="xref">Section 17.2.4</a>) are in this
+space.<a href="#section-12.3-5.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-12.3-5.3">Application data space: All 0-RTT and 1-RTT encrypted packets
+(<a href="#packet-protected" class="xref">Section 12.1</a>) are in this space.<a href="#section-12.3-5.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-12.3-6">As described in <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>, each packet type uses different protection keys.<a href="#section-12.3-6" class="pilcrow">¶</a></p>
+<p id="section-12.3-7">Conceptually, a packet number space is the context in which a packet can be
+processed and acknowledged.  Initial packets can only be sent with Initial
+packet protection keys and acknowledged in packets which are also Initial
+packets.  Similarly, Handshake packets are sent at the Handshake encryption
+level and can only be acknowledged in Handshake packets.<a href="#section-12.3-7" class="pilcrow">¶</a></p>
+<p id="section-12.3-8">This enforces cryptographic separation between the data sent in the different
+packet sequence number spaces.  Packet numbers in each space start at packet
+number 0.  Subsequent packets sent in the same packet number space MUST increase
+the packet number by at least one.<a href="#section-12.3-8" class="pilcrow">¶</a></p>
+<p id="section-12.3-9">0-RTT and 1-RTT data exist in the same packet number space to make loss recovery
+algorithms easier to implement between the two packet types.<a href="#section-12.3-9" class="pilcrow">¶</a></p>
+<p id="section-12.3-10">A QUIC endpoint MUST NOT reuse a packet number within the same packet number
+space in one connection.  If the packet number for sending reaches 2^62 - 1, the
+sender MUST close the connection without sending a CONNECTION_CLOSE frame or any
+further packets; an endpoint MAY send a Stateless Reset (<a href="#stateless-reset" class="xref">Section 10.4</a>) in
+response to further packets that it receives.<a href="#section-12.3-10" class="pilcrow">¶</a></p>
+<p id="section-12.3-11">A receiver MUST discard a newly unprotected packet unless it is certain that it
+has not processed another packet with the same packet number from the same
+packet number space. Duplicate suppression MUST happen after removing packet
+protection for the reasons described in Section 9.3 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-12.3-11" class="pilcrow">¶</a></p>
+<p id="section-12.3-12">Endpoints that track all individual packets for the purposes of detecting
+duplicates are at risk of accumulating excessive state.  The data required for
+detecting duplicates can be limited by maintaining a minimum packet number below
+which all packets are immediately dropped.  Any minimum needs to account for
+large variations in round trip time, which includes the possibility that a peer
+might probe network paths with a much larger round trip times; see
+<a href="#migration" class="xref">Section 9</a>.<a href="#section-12.3-12" class="pilcrow">¶</a></p>
+<p id="section-12.3-13">Packet number encoding at a sender and decoding at a receiver are described in
+<a href="#packet-encoding" class="xref">Section 17.1</a>.<a href="#section-12.3-13" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frames">
+<section id="section-12.4">
+        <h3 id="name-frames-and-frame-types">
+<a href="#section-12.4" class="section-number selfRef">12.4. </a><a href="#name-frames-and-frame-types" class="section-name selfRef">Frames and Frame Types</a>
+        </h3>
+<p id="section-12.4-1">The payload of QUIC packets, after removing packet protection, consists of a
+sequence of complete frames, as shown in <a href="#packet-frames" class="xref">Figure 10</a>.  Version
+Negotiation, Stateless Reset, and Retry packets do not contain frames.<a href="#section-12.4-1" class="pilcrow">¶</a></p>
+<span id="name-quic-payload"></span><div id="packet-frames">
+<figure id="figure-10">
+          <div class="artwork art-text alignLeft" id="section-12.4-2.1">
+<pre>
+Packet Payload {
+  Frame (..) ...,
+}
+</pre>
+</div>
+<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
+<a href="#name-quic-payload" class="selfRef">QUIC Payload</a>
+          </figcaption></figure>
+</div>
+<p id="section-12.4-3">The payload of a packet that contains frames MUST contain at least one frame,
+and MAY contain multiple frames and multiple frame types.  Frames always fit
+within a single QUIC packet and cannot span multiple packets.<a href="#section-12.4-3" class="pilcrow">¶</a></p>
+<p id="section-12.4-4">Each frame begins with a Frame Type, indicating its type, followed by
+additional type-dependent fields:<a href="#section-12.4-4" class="pilcrow">¶</a></p>
+<span id="name-generic-frame-layout"></span><div id="frame-layout">
+<figure id="figure-11">
+          <div class="artwork art-text alignLeft" id="section-12.4-5.1">
+<pre>
+Frame {
+  Frame Type (i),
+  Type-Dependent Fields (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
+<a href="#name-generic-frame-layout" class="selfRef">Generic Frame Layout</a>
+          </figcaption></figure>
+</div>
+<p id="section-12.4-6">The frame types defined in this specification are listed in <a href="#frame-types" class="xref">Table 3</a>.
+The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and
+CONNECTION_CLOSE frames is used to carry other frame-specific flags. For all
+other frames, the Frame Type field simply identifies the frame.  These
+frames are explained in more detail in <a href="#frame-formats" class="xref">Section 19</a>.<a href="#section-12.4-6" class="pilcrow">¶</a></p>
+<span id="name-frame-types"></span><div id="frame-types">
+<table class="center" id="table-3">
+          <caption>
+<a href="#table-3" class="selfRef">Table 3</a>:
+<a href="#name-frame-types" class="selfRef">Frame Types</a>
+          </caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Type Value</th>
+              <th class="text-left" rowspan="1" colspan="1">Frame Type Name</th>
+              <th class="text-left" rowspan="1" colspan="1">Definition</th>
+              <th class="text-left" rowspan="1" colspan="1">Packets</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x00</td>
+              <td class="text-left" rowspan="1" colspan="1">PADDING</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-padding" class="xref">Section 19.1</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">IH01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x01</td>
+              <td class="text-left" rowspan="1" colspan="1">PING</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-ping" class="xref">Section 19.2</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">IH01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x02 - 0x03</td>
+              <td class="text-left" rowspan="1" colspan="1">ACK</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-ack" class="xref">Section 19.3</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">IH_1</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x04</td>
+              <td class="text-left" rowspan="1" colspan="1">RESET_STREAM</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-reset-stream" class="xref">Section 19.4</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x05</td>
+              <td class="text-left" rowspan="1" colspan="1">STOP_SENDING</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-stop-sending" class="xref">Section 19.5</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x06</td>
+              <td class="text-left" rowspan="1" colspan="1">CRYPTO</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-crypto" class="xref">Section 19.6</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">IH_1</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x07</td>
+              <td class="text-left" rowspan="1" colspan="1">NEW_TOKEN</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-new-token" class="xref">Section 19.7</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">___1</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x08 - 0x0f</td>
+              <td class="text-left" rowspan="1" colspan="1">STREAM</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-stream" class="xref">Section 19.8</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x10</td>
+              <td class="text-left" rowspan="1" colspan="1">MAX_DATA</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-max-data" class="xref">Section 19.9</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x11</td>
+              <td class="text-left" rowspan="1" colspan="1">MAX_STREAM_DATA</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-max-stream-data" class="xref">Section 19.10</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x12 - 0x13</td>
+              <td class="text-left" rowspan="1" colspan="1">MAX_STREAMS</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-max-streams" class="xref">Section 19.11</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x14</td>
+              <td class="text-left" rowspan="1" colspan="1">DATA_BLOCKED</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-data-blocked" class="xref">Section 19.12</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x15</td>
+              <td class="text-left" rowspan="1" colspan="1">STREAM_DATA_BLOCKED</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-stream-data-blocked" class="xref">Section 19.13</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x16 - 0x17</td>
+              <td class="text-left" rowspan="1" colspan="1">STREAMS_BLOCKED</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-streams-blocked" class="xref">Section 19.14</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x18</td>
+              <td class="text-left" rowspan="1" colspan="1">NEW_CONNECTION_ID</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-new-connection-id" class="xref">Section 19.15</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x19</td>
+              <td class="text-left" rowspan="1" colspan="1">RETIRE_CONNECTION_ID</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-retire-connection-id" class="xref">Section 19.16</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x1a</td>
+              <td class="text-left" rowspan="1" colspan="1">PATH_CHALLENGE</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-path-challenge" class="xref">Section 19.17</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x1b</td>
+              <td class="text-left" rowspan="1" colspan="1">PATH_RESPONSE</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-path-response" class="xref">Section 19.18</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">__01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x1c - 0x1d</td>
+              <td class="text-left" rowspan="1" colspan="1">CONNECTION_CLOSE</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-connection-close" class="xref">Section 19.19</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">ih01</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x1e</td>
+              <td class="text-left" rowspan="1" colspan="1">HANDSHAKE_DONE</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#frame-handshake-done" class="xref">Section 19.20</a>
+</td>
+              <td class="text-left" rowspan="1" colspan="1">___1</td>
+            </tr>
+          </tbody>
+        </table>
+</div>
+<p id="section-12.4-8">The "Packets" column in <a href="#frame-types" class="xref">Table 3</a> does not form part of the IANA registry;
+see <a href="#iana-frames" class="xref">Section 22.3</a>.  This column lists the types of packets that each frame
+type could appear in, indicated by the following characters:<a href="#section-12.4-8" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-12.4-9">
+          <dt id="section-12.4-9.1">I:</dt>
+<dd id="section-12.4-9.2">
+  Initial (<a href="#packet-initial" class="xref">Section 17.2.2</a>)<a href="#section-12.4-9.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-12.4-9.3">H:</dt>
+<dd id="section-12.4-9.4">
+  Handshake (<a href="#packet-handshake" class="xref">Section 17.2.4</a>)<a href="#section-12.4-9.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-12.4-9.5">0:</dt>
+<dd id="section-12.4-9.6">
+  0-RTT (<a href="#packet-0rtt" class="xref">Section 17.2.3</a>)<a href="#section-12.4-9.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-12.4-9.7">1:</dt>
+<dd id="section-12.4-9.8">
+  1-RTT (<a href="#short-header" class="xref">Section 17.3</a>)<a href="#section-12.4-9.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-12.4-9.9">ih:</dt>
+<dd id="section-12.4-9.10">
+  A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial or Handshake
+packets.<a href="#section-12.4-9.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-12.4-10">Section 4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span> provides more detail about these restrictions.  Note
+that all frames can appear in 1-RTT packets.<a href="#section-12.4-10" class="pilcrow">¶</a></p>
+<p id="section-12.4-11">An endpoint MUST treat the receipt of a frame of unknown type as a connection
+error of type FRAME_ENCODING_ERROR.<a href="#section-12.4-11" class="pilcrow">¶</a></p>
+<p id="section-12.4-12">All QUIC frames are idempotent in this version of QUIC.  That is, a valid
+frame does not cause undesirable side effects or errors when received more
+than once.<a href="#section-12.4-12" class="pilcrow">¶</a></p>
+<p id="section-12.4-13">The Frame Type field uses a variable length integer encoding (see
+<a href="#integer-encoding" class="xref">Section 16</a>) with one exception.  To ensure simple and efficient
+implementations of frame parsing, a frame type MUST use the shortest possible
+encoding.  For frame types defined in this document, this means a single-byte
+encoding, even though it is possible to encode these values as a two-, four-
+or eight-byte variable length integer.  For instance, though 0x4001 is
+a legitimate two-byte encoding for a variable-length integer with a value
+of 1, PING frames are always encoded as a single byte with the value 0x01.
+This rule applies to all current and future QUIC frame types.  An endpoint
+MAY treat the receipt of a frame type that uses a longer encoding than
+necessary as a connection error of type PROTOCOL_VIOLATION.<a href="#section-12.4-13" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="packetization">
+<section id="section-13">
+      <h2 id="name-packetization-and-reliabili">
+<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-packetization-and-reliabili" class="section-name selfRef">Packetization and Reliability</a>
+      </h2>
+<p id="section-13-1">A sender bundles one or more frames in a QUIC packet; see <a href="#frames" class="xref">Section 12.4</a>.<a href="#section-13-1" class="pilcrow">¶</a></p>
+<p id="section-13-2">A sender can minimize per-packet bandwidth and computational costs by bundling
+as many frames as possible within a QUIC packet.  A sender MAY wait for a short
+period of time to bundle multiple frames before sending a packet that is not
+maximally packed, to avoid sending out large numbers of small packets.  An
+implementation MAY use knowledge about application sending behavior or
+heuristics to determine whether and for how long to wait.  This waiting period
+is an implementation decision, and an implementation should be careful to delay
+conservatively, since any delay is likely to increase application-visible
+latency.<a href="#section-13-2" class="pilcrow">¶</a></p>
+<p id="section-13-3">Stream multiplexing is achieved by interleaving STREAM frames from multiple
+streams into one or more QUIC packets.  A single QUIC packet can include
+multiple STREAM frames from one or more streams.<a href="#section-13-3" class="pilcrow">¶</a></p>
+<p id="section-13-4">One of the benefits of QUIC is avoidance of head-of-line blocking across
+multiple streams.  When a packet loss occurs, only streams with data in that
+packet are blocked waiting for a retransmission to be received, while other
+streams can continue making progress.  Note that when data from multiple streams
+is bundled into a single QUIC packet, loss of that packet blocks all those
+streams from making progress.  Implementations are advised to bundle as few
+streams as necessary in outgoing packets without losing transmission efficiency
+to underfilled packets.<a href="#section-13-4" class="pilcrow">¶</a></p>
+<div id="processing">
+<section id="section-13.1">
+        <h3 id="name-packet-processing">
+<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-packet-processing" class="section-name selfRef">Packet Processing</a>
+        </h3>
+<p id="section-13.1-1">A packet MUST NOT be acknowledged until packet protection has been successfully
+removed and all frames contained in the packet have been processed.  For STREAM
+frames, this means the data has been enqueued in preparation to be received by
+the application protocol, but it does not require that data is delivered and
+consumed.<a href="#section-13.1-1" class="pilcrow">¶</a></p>
+<p id="section-13.1-2">Once the packet has been fully processed, a receiver acknowledges receipt by
+sending one or more ACK frames containing the packet number of the received
+packet.<a href="#section-13.1-2" class="pilcrow">¶</a></p>
+<p id="section-13.1-3">An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not
+send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect
+the condition.<a href="#section-13.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="generating-acks">
+<section id="section-13.2">
+        <h3 id="name-generating-acknowledgements">
+<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-generating-acknowledgements" class="section-name selfRef">Generating Acknowledgements</a>
+        </h3>
+<p id="section-13.2-1">Endpoints acknowledge all packets they receive and process. However, only
+ack-eliciting packets cause an ACK frame to be sent within the maximum ack
+delay.  Packets that are not ack-eliciting are only acknowledged when an ACK
+frame is sent for other reasons.<a href="#section-13.2-1" class="pilcrow">¶</a></p>
+<p id="section-13.2-2">When sending a packet for any reason, an endpoint SHOULD attempt to bundle an
+ACK frame if one has not been sent recently. Doing so helps with timely loss
+detection at the peer.<a href="#section-13.2-2" class="pilcrow">¶</a></p>
+<p id="section-13.2-3">In general, frequent feedback from a receiver improves loss and congestion
+response, but this has to be balanced against excessive load generated by a
+receiver that sends an ACK frame in response to every ack-eliciting packet.  The
+guidance offered below seeks to strike this balance.<a href="#section-13.2-3" class="pilcrow">¶</a></p>
+<div id="sending-acknowledgements">
+<section id="section-13.2.1">
+          <h4 id="name-sending-ack-frames">
+<a href="#section-13.2.1" class="section-number selfRef">13.2.1. </a><a href="#name-sending-ack-frames" class="section-name selfRef">Sending ACK Frames</a>
+          </h4>
+<p id="section-13.2.1-1">Every packet SHOULD be acknowledged at least once, and ack-eliciting packets
+MUST be acknowledged at least once within the maximum ack delay. An endpoint
+communicates its maximum delay using the max_ack_delay transport parameter; see
+<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>.  max_ack_delay declares an explicit
+contract: an endpoint promises to never intentionally delay acknowledgments of
+an ack-eliciting packet by more than the indicated value. If it does, any excess
+accrues to the RTT estimate and could result in spurious or delayed
+retransmissions from the peer. For Initial and Handshake packets, a
+max_ack_delay of 0 is used. The sender uses the receiver's max_ack_delay value
+in determining timeouts for timer-based retransmission, as detailed in Section
+5.2.1 of <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>.<a href="#section-13.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-13.2.1-2">Since packets containing only ACK frames are not congestion controlled, an
+endpoint MUST NOT send more than one such packet in response to receiving an
+ack-eliciting packet.<a href="#section-13.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-13.2.1-3">An endpoint MUST NOT send a non-ack-eliciting packet in response to a
+non-ack-eliciting packet, even if there are packet gaps which precede the
+received packet. This avoids an infinite feedback loop of acknowledgements,
+which could prevent the connection from ever becoming idle.  Non-ack-eliciting
+packets are eventually acknowledged when the endpoint sends an ACK frame in
+response to other events.<a href="#section-13.2.1-3" class="pilcrow">¶</a></p>
+<p id="section-13.2.1-4">In order to assist loss detection at the sender, an endpoint SHOULD send an ACK
+frame immediately on receiving an ack-eliciting packet that is out of order. The
+endpoint SHOULD NOT continue sending ACK frames immediately unless more
+ack-eliciting packets are received out of order.  If every subsequent
+ack-eliciting packet arrives out of order, then an ACK frame SHOULD be sent
+immediately for every received ack-eliciting packet.<a href="#section-13.2.1-4" class="pilcrow">¶</a></p>
+<p id="section-13.2.1-5">Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in
+the IP header SHOULD be acknowledged immediately, to reduce the peer's response
+time to congestion events.<a href="#section-13.2.1-5" class="pilcrow">¶</a></p>
+<p id="section-13.2.1-6">The algorithms in <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span> are expected to be resilient to receivers
+that do not follow guidance offered above. However, an implementer should only
+deviate from these requirements after careful consideration of the performance
+implications of doing so.<a href="#section-13.2.1-6" class="pilcrow">¶</a></p>
+<p id="section-13.2.1-7">An endpoint that is only sending ACK frames will not receive acknowledgments
+from its peer unless those acknowledgements are included in packets with
+ack-eliciting frames.  An endpoint SHOULD bundle ACK frames with other frames
+when there are new ack-eliciting packets to acknowledge.  When only
+non-ack-eliciting packets need to be acknowledged, an endpoint MAY wait until an
+ack-eliciting packet has been received to bundle an ACK frame with outgoing
+frames.<a href="#section-13.2.1-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="acknowledgement-frequency">
+<section id="section-13.2.2">
+          <h4 id="name-acknowledgement-frequency">
+<a href="#section-13.2.2" class="section-number selfRef">13.2.2. </a><a href="#name-acknowledgement-frequency" class="section-name selfRef">Acknowledgement Frequency</a>
+          </h4>
+<p id="section-13.2.2-1">A receiver determines how frequently to send acknowledgements in response to
+ack-eliciting packets. This determination involves a tradeoff.<a href="#section-13.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-13.2.2-2">Endpoints rely on timely acknowledgment to detect loss; see Section 5 of
+<span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>. Window-based congestion controllers, such as the one in
+Section 6 of <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>, rely on acknowledgments to manage their
+congestion window. In both cases, delaying acknowledgments can adversely affect
+performance.<a href="#section-13.2.2-2" class="pilcrow">¶</a></p>
+<p id="section-13.2.2-3">On the other hand, reducing the frequency of packets that carry only
+acknowledgements reduces packet transmission and processing cost at both
+endpoints. It can also improve connection throughput on severely asymmetric
+links; see Section 3 of <span>[<a href="#RFC3449" class="xref">RFC3449</a>]</span>.<a href="#section-13.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-13.2.2-4">A receiver SHOULD send an ACK frame after receiving at least two ack-eliciting
+packets. This recommendation is general in nature and consistent with
+recommendations for TCP endpoint behavior <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>. Knowledge of network
+conditions, knowledge of the peer's congestion controller, or further research
+and experimentation might suggest alternative acknowledgment strategies with
+better performance characteristics.<a href="#section-13.2.2-4" class="pilcrow">¶</a></p>
+<p id="section-13.2.2-5">A receiver MAY process multiple available packets before determining whether to
+send an ACK frame in response.<a href="#section-13.2.2-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="managing-ack-ranges">
+<section id="section-13.2.3">
+          <h4 id="name-managing-ack-ranges">
+<a href="#section-13.2.3" class="section-number selfRef">13.2.3. </a><a href="#name-managing-ack-ranges" class="section-name selfRef">Managing ACK Ranges</a>
+          </h4>
+<p id="section-13.2.3-1">When an ACK frame is sent, one or more ranges of acknowledged packets are
+included.  Including older packets reduces the chance of spurious retransmits
+caused by losing previously sent ACK frames, at the cost of larger ACK frames.<a href="#section-13.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-13.2.3-2">ACK frames SHOULD always acknowledge the most recently received packets, and the
+more out-of-order the packets are, the more important it is to send an updated
+ACK frame quickly, to prevent the peer from declaring a packet as lost and
+spuriously retransmitting the frames it contains.  An ACK frame is expected
+to fit within a single QUIC packet.  If it does not, then older ranges
+(those with the smallest packet numbers) are omitted.<a href="#section-13.2.3-2" class="pilcrow">¶</a></p>
+<p id="section-13.2.3-3"><a href="#ack-tracking" class="xref">Section 13.2.4</a> and <a href="#ack-limiting" class="xref">Section 13.2.5</a> describe an exemplary approach for
+determining what packets to acknowledge in each ACK frame.  Though the goal of
+these algorithms is to generate an acknowledgment for every packet that is
+processed, it is still possible for acknowledgments to be lost.  A sender cannot
+expect to receive an acknowledgment for every packet that the receiver
+processes.<a href="#section-13.2.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="ack-tracking">
+<section id="section-13.2.4">
+          <h4 id="name-receiver-tracking-of-ack-fr">
+<a href="#section-13.2.4" class="section-number selfRef">13.2.4. </a><a href="#name-receiver-tracking-of-ack-fr" class="section-name selfRef">Receiver Tracking of ACK Frames</a>
+          </h4>
+<p id="section-13.2.4-1">When a packet containing an ACK frame is sent, the largest acknowledged in that
+frame may be saved.  When a packet containing an ACK frame is acknowledged, the
+receiver can stop acknowledging packets less than or equal to the largest
+acknowledged in the sent ACK frame.<a href="#section-13.2.4-1" class="pilcrow">¶</a></p>
+<p id="section-13.2.4-2">In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT
+of reordering. In cases with ACK frame loss and reordering, this approach does
+not guarantee that every acknowledgement is seen by the sender before it is no
+longer included in the ACK frame. Packets could be received out of order and
+all subsequent ACK frames containing them could be lost. In this case, the
+loss recovery algorithm could cause spurious retransmits, but the sender will
+continue making forward progress.<a href="#section-13.2.4-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="ack-limiting">
+<section id="section-13.2.5">
+          <h4 id="name-limiting-ack-ranges">
+<a href="#section-13.2.5" class="section-number selfRef">13.2.5. </a><a href="#name-limiting-ack-ranges" class="section-name selfRef">Limiting ACK Ranges</a>
+          </h4>
+<p id="section-13.2.5-1">A receiver limits the number of ACK Ranges (<a href="#ack-ranges" class="xref">Section 19.3.1</a>) it remembers and
+sends in ACK frames, both to limit the size of ACK frames and to avoid resource
+exhaustion. After receiving acknowledgments for an ACK frame, the receiver
+SHOULD stop tracking those acknowledged ACK Ranges.<a href="#section-13.2.5-1" class="pilcrow">¶</a></p>
+<p id="section-13.2.5-2">It is possible that retaining many ACK Ranges could cause an ACK frame to become
+too large. A receiver can discard unacknowledged ACK Ranges to limit ACK frame
+size, at the cost of increased retransmissions from the sender. This is
+necessary if an ACK frame would be too large to fit in a packet, however
+receivers MAY also limit ACK frame size further to preserve space for other
+frames.<a href="#section-13.2.5-2" class="pilcrow">¶</a></p>
+<p id="section-13.2.5-3">A receiver MUST retain an ACK Range unless it can ensure that it will not
+subsequently accept packets with numbers in that range. Maintaining a minimum
+packet number that increases as ranges are discarded is one way to achieve this
+with minimal state.<a href="#section-13.2.5-3" class="pilcrow">¶</a></p>
+<p id="section-13.2.5-4">Receivers can discard all ACK Ranges, but they MUST retain the largest packet
+number that has been successfully processed as that is used to recover packet
+numbers from subsequent packets; see <a href="#packet-encoding" class="xref">Section 17.1</a>.<a href="#section-13.2.5-4" class="pilcrow">¶</a></p>
+<p id="section-13.2.5-5">A receiver SHOULD include an ACK Range containing the largest received packet
+number in every ACK frame. The Largest Acknowledged field is used in ECN
+validation at a sender and including a lower value than what was included in a
+previous ACK frame could cause ECN to be unnecessarily disabled; see
+<a href="#ecn-validation" class="xref">Section 13.4.2</a>.<a href="#section-13.2.5-5" class="pilcrow">¶</a></p>
+<p id="section-13.2.5-6">A receiver that sends only non-ack-eliciting packets, such as ACK frames, might
+not receive an acknowledgement for a long period of time.  This could cause the
+receiver to maintain state for a large number of ACK frames for a long period of
+time, and ACK frames it sends could be unnecessarily large.  In such a case, a
+receiver could bundle a PING or other small ack-eliciting frame occasionally,
+such as once per round trip, to elicit an ACK from the peer.<a href="#section-13.2.5-6" class="pilcrow">¶</a></p>
+<p id="section-13.2.5-7">A receiver MUST NOT bundle an ack-eliciting frame with all packets that would
+otherwise be non-ack-eliciting, to avoid an infinite feedback loop of
+acknowledgements.<a href="#section-13.2.5-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="host-delay">
+<section id="section-13.2.6">
+          <h4 id="name-measuring-and-reporting-hos">
+<a href="#section-13.2.6" class="section-number selfRef">13.2.6. </a><a href="#name-measuring-and-reporting-hos" class="section-name selfRef">Measuring and Reporting Host Delay</a>
+          </h4>
+<p id="section-13.2.6-1">An endpoint measures the delays intentionally introduced between the time the
+packet with the largest packet number is received and the time an acknowledgment
+is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK
+frame; see <a href="#frame-ack" class="xref">Section 19.3</a>.  This allows the receiver of the ACK to adjust for any
+intentional delays, which is important for getting a better estimate of the path
+RTT when acknowledgments are delayed.  A packet might be held in the OS kernel
+or elsewhere on the host before being processed.  An endpoint MUST NOT include
+delays that it does not control when populating the Ack Delay field in an ACK
+frame.<a href="#section-13.2.6-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="ack-frames-and-packet-protection">
+<section id="section-13.2.7">
+          <h4 id="name-ack-frames-and-packet-prote">
+<a href="#section-13.2.7" class="section-number selfRef">13.2.7. </a><a href="#name-ack-frames-and-packet-prote" class="section-name selfRef">ACK Frames and Packet Protection</a>
+          </h4>
+<p id="section-13.2.7-1">ACK frames MUST only be carried in a packet that has the same packet number
+space as the packet being ACKed; see <a href="#packet-protected" class="xref">Section 12.1</a>.  For instance,
+packets that are protected with 1-RTT keys MUST be acknowledged in packets that
+are also protected with 1-RTT keys.<a href="#section-13.2.7-1" class="pilcrow">¶</a></p>
+<p id="section-13.2.7-2">Packets that a client sends with 0-RTT packet protection MUST be acknowledged by
+the server in packets protected by 1-RTT keys.  This can mean that the client is
+unable to use these acknowledgments if the server cryptographic handshake
+messages are delayed or lost.  Note that the same limitation applies to other
+data sent by the server protected by the 1-RTT keys.<a href="#section-13.2.7-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="padding-frames-consume-congestion-window">
+<section id="section-13.2.8">
+          <h4 id="name-padding-frames-consume-cong">
+<a href="#section-13.2.8" class="section-number selfRef">13.2.8. </a><a href="#name-padding-frames-consume-cong" class="section-name selfRef">PADDING Frames Consume Congestion Window</a>
+          </h4>
+<p id="section-13.2.8-1">Packets containing PADDING frames are considered to be in flight for congestion
+control purposes <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>. Packets containing only PADDING frames
+therefore consume congestion window but do not generate acknowledgments that
+will open the congestion window. To avoid a deadlock, a sender SHOULD ensure
+that other frames are sent periodically in addition to PADDING frames to elicit
+acknowledgments from the receiver.<a href="#section-13.2.8-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="retransmission-of-information">
+<section id="section-13.3">
+        <h3 id="name-retransmission-of-informati">
+<a href="#section-13.3" class="section-number selfRef">13.3. </a><a href="#name-retransmission-of-informati" class="section-name selfRef">Retransmission of Information</a>
+        </h3>
+<p id="section-13.3-1">QUIC packets that are determined to be lost are not retransmitted whole. The
+same applies to the frames that are contained within lost packets. Instead, the
+information that might be carried in frames is sent again in new frames as
+needed.<a href="#section-13.3-1" class="pilcrow">¶</a></p>
+<p id="section-13.3-2">New frames and packets are used to carry information that is determined to have
+been lost.  In general, information is sent again when a packet containing that
+information is determined to be lost and sending ceases when a packet
+containing that information is acknowledged.<a href="#section-13.3-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-13.3-3.1">Data sent in CRYPTO frames is retransmitted according to the rules in
+<span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>, until all data has been acknowledged.  Data in CRYPTO
+frames for Initial and Handshake packets is discarded when keys for the
+corresponding packet number space are discarded.<a href="#section-13.3-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.2">Application data sent in STREAM frames is retransmitted in new STREAM frames
+unless the endpoint has sent a RESET_STREAM for that stream.  Once an endpoint
+sends a RESET_STREAM frame, no further STREAM frames are needed.<a href="#section-13.3-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.3">ACK frames carry the most recent set of acknowledgements and the Ack Delay
+from the largest acknowledged packet, as described in
+<a href="#sending-acknowledgements" class="xref">Section 13.2.1</a>. Delaying the transmission of packets
+containing ACK frames or sending old ACK frames can cause the peer to
+generate an inflated RTT sample or unnecessarily disable ECN.<a href="#section-13.3-3.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.4">Cancellation of stream transmission, as carried in a RESET_STREAM frame, is
+sent until acknowledged or until all stream data is acknowledged by the peer
+(that is, either the "Reset Recvd" or "Data Recvd" state is reached on the
+sending part of the stream). The content of a RESET_STREAM frame MUST NOT
+change when it is sent again.<a href="#section-13.3-3.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.5">Similarly, a request to cancel stream transmission, as encoded in a
+STOP_SENDING frame, is sent until the receiving part of the stream enters
+either a "Data Recvd" or "Reset Recvd" state; see
+<a href="#solicited-state-transitions" class="xref">Section 3.5</a>.<a href="#section-13.3-3.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.6">Connection close signals, including packets that contain CONNECTION_CLOSE
+frames, are not sent again when packet loss is detected, but as described in
+<a href="#termination" class="xref">Section 10</a>.<a href="#section-13.3-3.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.7">The current connection maximum data is sent in MAX_DATA frames. An updated
+value is sent in a MAX_DATA frame if the packet containing the most recently
+sent MAX_DATA frame is declared lost, or when the endpoint decides to update
+the limit.  Care is necessary to avoid sending this frame too often as the
+limit can increase frequently and cause an unnecessarily large number of
+MAX_DATA frames to be sent.<a href="#section-13.3-3.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.8">The current maximum stream data offset is sent in MAX_STREAM_DATA frames.
+Like MAX_DATA, an updated value is sent when the packet containing the most
+recent MAX_STREAM_DATA frame for a stream is lost or when the limit is
+updated, with care taken to prevent the frame from being sent too often. An
+endpoint SHOULD stop sending MAX_STREAM_DATA frames when the receiving part of
+the stream enters a "Size Known" state.<a href="#section-13.3-3.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.9">The limit on streams of a given type is sent in MAX_STREAMS frames.  Like
+MAX_DATA, an updated value is sent when a packet containing the most recent
+MAX_STREAMS for a stream type frame is declared lost or when the limit is
+updated, with care taken to prevent the frame from being sent too often.<a href="#section-13.3-3.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.10">Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, and
+STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection scope,
+STREAM_DATA_BLOCKED frames have stream scope, and STREAMS_BLOCKED frames are
+scoped to a specific stream type. New frames are sent if packets containing
+the most recent frame for a scope is lost, but only while the endpoint is
+blocked on the corresponding limit. These frames always include the limit that
+is causing blocking at the time that they are transmitted.<a href="#section-13.3-3.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.11">A liveness or path validation check using PATH_CHALLENGE frames is sent
+periodically until a matching PATH_RESPONSE frame is received or until there
+is no remaining need for liveness or path validation checking. PATH_CHALLENGE
+frames include a different payload each time they are sent.<a href="#section-13.3-3.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.12">Responses to path validation using PATH_RESPONSE frames are sent just once.
+The peer is expected to send more PATH_CHALLENGE frames as necessary to evoke
+additional PATH_RESPONSE frames.<a href="#section-13.3-3.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.13">New connection IDs are sent in NEW_CONNECTION_ID frames and retransmitted if
+the packet containing them is lost.  Retransmissions of this frame carry the
+same sequence number value.  Likewise, retired connection IDs are sent in
+RETIRE_CONNECTION_ID frames and retransmitted if the packet containing them is
+lost.<a href="#section-13.3-3.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.14">NEW_TOKEN frames are retransmitted if the packet containing them is lost.  No
+special support is made for detecting reordered and duplicated NEW_TOKEN
+frames other than a direct comparison of the frame contents.<a href="#section-13.3-3.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.15">PING and PADDING frames contain no information, so lost PING or PADDING frames
+do not require repair.<a href="#section-13.3-3.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.3-3.16">The HANDSHAKE_DONE frame MUST be retransmitted until it is acknowledged.<a href="#section-13.3-3.16" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-13.3-4">Endpoints SHOULD prioritize retransmission of data over sending new data, unless
+priorities specified by the application indicate otherwise; see
+<a href="#stream-prioritization" class="xref">Section 2.3</a>.<a href="#section-13.3-4" class="pilcrow">¶</a></p>
+<p id="section-13.3-5">Even though a sender is encouraged to assemble frames containing up-to-date
+information every time it sends a packet, it is not forbidden to retransmit
+copies of frames from lost packets.  A sender that retransmits copies of frames
+needs to handle decreases in available payload size due to change in packet
+number length, connection ID length, and path MTU.  A receiver MUST accept
+packets containing an outdated frame, such as a MAX_DATA frame carrying a
+smaller maximum data than one found in an older packet.<a href="#section-13.3-5" class="pilcrow">¶</a></p>
+<p id="section-13.3-6">Upon detecting losses, a sender MUST take appropriate congestion control action.
+The details of loss detection and congestion control are described in
+<span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>.<a href="#section-13.3-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="ecn">
+<section id="section-13.4">
+        <h3 id="name-explicit-congestion-notific">
+<a href="#section-13.4" class="section-number selfRef">13.4. </a><a href="#name-explicit-congestion-notific" class="section-name selfRef">Explicit Congestion Notification</a>
+        </h3>
+<p id="section-13.4-1">QUIC endpoints can use Explicit Congestion Notification (ECN) <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span> to
+detect and respond to network congestion.  ECN allows a network node to indicate
+congestion in the network by setting a codepoint in the IP header of a packet
+instead of dropping it.  Endpoints react to congestion by reducing their sending
+rate in response, as described in <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>.<a href="#section-13.4-1" class="pilcrow">¶</a></p>
+<p id="section-13.4-2">To use ECN, QUIC endpoints first determine whether a path supports ECN marking
+and the peer is able to access the ECN codepoint in the IP header.  A network
+path does not support ECN if ECN marked packets get dropped or ECN markings are
+rewritten on the path. An endpoint validates the use of ECN on the path, both
+during connection establishment and when migrating to a new path
+(<a href="#migration" class="xref">Section 9</a>).<a href="#section-13.4-2" class="pilcrow">¶</a></p>
+<div id="ecn-counts">
+<section id="section-13.4.1">
+          <h4 id="name-ecn-counts">
+<a href="#section-13.4.1" class="section-number selfRef">13.4.1. </a><a href="#name-ecn-counts" class="section-name selfRef">ECN Counts</a>
+          </h4>
+<p id="section-13.4.1-1">On receiving a QUIC packet with an ECT or CE codepoint, an ECN-enabled endpoint
+that can access the ECN codepoints from the enclosing IP packet increases the
+corresponding ECT(0), ECT(1), or CE count, and includes these counts in
+subsequent ACK frames; see <a href="#generating-acks" class="xref">Section 13.2</a> and <a href="#frame-ack" class="xref">Section 19.3</a>.  Note that
+this requires being able to read the ECN codepoints from the enclosing IP
+packet, which is not possible on all platforms.<a href="#section-13.4.1-1" class="pilcrow">¶</a></p>
+<p id="section-13.4.1-2">A packet detected by a receiver as a duplicate does not affect the receiver's
+local ECN codepoint counts; see (<a href="#security-ecn" class="xref">Section 21.8</a>) for relevant security
+concerns.<a href="#section-13.4.1-2" class="pilcrow">¶</a></p>
+<p id="section-13.4.1-3">If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP
+packet header, it responds per <a href="#generating-acks" class="xref">Section 13.2</a> with an ACK frame without
+increasing any ECN counts.  If an endpoint does not implement ECN
+support or does not have access to received ECN codepoints, it does not increase
+ECN counts.<a href="#section-13.4.1-3" class="pilcrow">¶</a></p>
+<p id="section-13.4.1-4">Coalesced packets (see <a href="#packet-coalesce" class="xref">Section 12.2</a>) mean that several packets can share
+the same IP header.  The ECN counter for the ECN codepoint received in the
+associated IP header are incremented once for each QUIC packet, not per
+enclosing IP packet or UDP datagram.<a href="#section-13.4.1-4" class="pilcrow">¶</a></p>
+<p id="section-13.4.1-5">Each packet number space maintains separate acknowledgement state and separate
+ECN counts.  For example, if one each of an Initial, 0-RTT, Handshake, and 1-RTT
+QUIC packet are coalesced, the corresponding counts for the Initial and
+Handshake packet number space will be incremented by one and the counts for the
+1-RTT packet number space will be increased by two.<a href="#section-13.4.1-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="ecn-validation">
+<section id="section-13.4.2">
+          <h4 id="name-ecn-validation">
+<a href="#section-13.4.2" class="section-number selfRef">13.4.2. </a><a href="#name-ecn-validation" class="section-name selfRef">ECN Validation</a>
+          </h4>
+<p id="section-13.4.2-1">It is possible for faulty network devices to corrupt or erroneously drop packets
+with ECN markings.  To provide robust connectivity in the presence of such
+devices, each endpoint independently validates ECN counts and disables ECN if
+errors are detected.<a href="#section-13.4.2-1" class="pilcrow">¶</a></p>
+<p id="section-13.4.2-2">Endpoints validate ECN for packets sent on each network path independently.  An
+endpoint thus validates ECN on new connection establishment, when switching to a
+new server preferred address, and on active connection migration to a new path.
+<a href="#ecn-alg" class="xref">Appendix B</a> describes one possible algorithm for testing paths for ECN support.<a href="#section-13.4.2-2" class="pilcrow">¶</a></p>
+<p id="section-13.4.2-3">Even if an endpoint does not use ECN markings on packets it transmits, the
+endpoint MUST provide feedback about ECN markings received from the peer if they
+are accessible.  Failing to report ECN counts will cause the peer to disable ECN
+marking.<a href="#section-13.4.2-3" class="pilcrow">¶</a></p>
+<div id="sending-ecn-markings">
+<section id="section-13.4.2.1">
+            <h5 id="name-sending-ecn-markings">
+<a href="#section-13.4.2.1" class="section-number selfRef">13.4.2.1. </a><a href="#name-sending-ecn-markings" class="section-name selfRef">Sending ECN Markings</a>
+            </h5>
+<p id="section-13.4.2.1-1">To start ECN validation, an endpoint SHOULD do the following when sending
+packets on a new path to a peer:<a href="#section-13.4.2.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-13.4.2.1-2.1">Set the ECT(0) codepoint in the IP header of early outgoing packets sent on a
+new path to the peer <span>[<a href="#RFC8311" class="xref">RFC8311</a>]</span>.<a href="#section-13.4.2.1-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.4.2.1-2.2">If all packets that were sent with the ECT(0) codepoint are eventually deemed
+lost <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>, validation is deemed to have failed.<a href="#section-13.4.2.1-2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-13.4.2.1-3">To reduce the chances of misinterpreting congestive loss as packets dropped by a
+faulty network element, an endpoint could set the ECT(0) codepoint in the first
+ten outgoing packets on a path, or for a period of three RTTs, whichever occurs
+first.<a href="#section-13.4.2.1-3" class="pilcrow">¶</a></p>
+<p id="section-13.4.2.1-4">Implementations MAY experiment with and use other strategies for use of ECN.
+Other methods of probing paths for ECN support are possible, as are different
+marking strategies.  Implementations can also use the ECT(1) codepoint, as
+specified in <span>[<a href="#RFC8311" class="xref">RFC8311</a>]</span>.<a href="#section-13.4.2.1-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="ecn-ack">
+<section id="section-13.4.2.2">
+            <h5 id="name-receiving-ack-frames">
+<a href="#section-13.4.2.2" class="section-number selfRef">13.4.2.2. </a><a href="#name-receiving-ack-frames" class="section-name selfRef">Receiving ACK Frames</a>
+            </h5>
+<p id="section-13.4.2.2-1">An endpoint that sets ECT(0) or ECT(1) codepoints on packets it transmits MUST
+use the following steps on receiving an ACK frame to validate ECN.<a href="#section-13.4.2.2-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-13.4.2.2-2.1">If this ACK frame newly acknowledges a packet that the endpoint sent with
+either ECT(0) or ECT(1) codepoints set, and if no ECN feedback is present in
+the ACK frame, validation fails.  This step protects against both a network
+element that zeroes out ECN bits and a peer that is unable to access ECN
+markings, since the peer could respond without ECN feedback in these cases.<a href="#section-13.4.2.2-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.4.2.2-2.2">For validation to succeed, the total increase in ECT(0), ECT(1), and CE counts
+MUST be no smaller than the total number of QUIC packets sent with an ECT
+codepoint that are newly acknowledged in this ACK frame.  This step detects
+any network remarking from ECT(0), ECT(1), or CE codepoints to Not-ECT.<a href="#section-13.4.2.2-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-13.4.2.2-2.3">Any increase in either ECT(0) or ECT(1) counts, plus any increase in the CE
+count, MUST be no smaller than the number of packets sent with the
+corresponding ECT codepoint that are newly acknowledged in this ACK frame.
+This step detects any erroneous network remarking from ECT(0) to ECT(1) (or
+vice versa).<a href="#section-13.4.2.2-2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-13.4.2.2-3">Processing ECN counts out of order can result in validation failure.  An
+endpoint SHOULD NOT perform this validation if this ACK frame does not advance
+the largest packet number acknowledged in this connection.<a href="#section-13.4.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-13.4.2.2-4">An endpoint could miss acknowledgements for a packet when ACK frames are lost.
+It is therefore possible for the total increase in ECT(0), ECT(1), and CE counts
+to be greater than the number of packets acknowledged in an ACK frame.  When
+this happens, and if validation succeeds, the local reference counts MUST be
+increased to match the counts in the ACK frame.<a href="#section-13.4.2.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="validation-outcomes">
+<section id="section-13.4.2.3">
+            <h5 id="name-validation-outcomes">
+<a href="#section-13.4.2.3" class="section-number selfRef">13.4.2.3. </a><a href="#name-validation-outcomes" class="section-name selfRef">Validation Outcomes</a>
+            </h5>
+<p id="section-13.4.2.3-1">If validation fails, then the endpoint stops sending ECN markings in subsequent
+IP packets with the expectation that either the network path or the peer does
+not support ECN.<a href="#section-13.4.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-13.4.2.3-2">Upon successful validation, an endpoint can continue to set ECT codepoints in
+subsequent packets with the expectation that the path is ECN-capable.  Network
+routing and path elements can change mid-connection however; an endpoint MUST
+disable ECN if validation fails at any point in the connection.<a href="#section-13.4.2.3-2" class="pilcrow">¶</a></p>
+<p id="section-13.4.2.3-3">Even if validation fails, an endpoint MAY revalidate ECN on the same path at any
+later time in the connection.<a href="#section-13.4.2.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="packet-size">
+<section id="section-14">
+      <h2 id="name-packet-size">
+<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-packet-size" class="section-name selfRef">Packet Size</a>
+      </h2>
+<p id="section-14-1">The QUIC packet size includes the QUIC header and protected payload, but not the
+UDP or IP header.<a href="#section-14-1" class="pilcrow">¶</a></p>
+<p id="section-14-2">A client MUST expand the payload of all UDP datagrams carrying Initial packets
+to at least 1200 bytes, by adding PADDING frames to the Initial packet or by
+coalescing the Initial packet; see <a href="#packet-coalesce" class="xref">Section 12.2</a>.  Sending a UDP datagram
+of this size ensures that the network path from the client to the server
+supports a reasonable Maximum Transmission Unit (MTU).  Padding datagrams also
+helps reduce the amplitude of amplification attacks caused by server responses
+toward an unverified client address; see <a href="#address-validation" class="xref">Section 8</a>.<a href="#section-14-2" class="pilcrow">¶</a></p>
+<p id="section-14-3">Enforcement of the max_udp_payload_size transport parameter
+(<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>) might act as an additional limit on
+packet size. Exceeding this limit can be avoided once the value is known.
+However, prior to learning the value of the transport parameter, endpoints risk
+datagrams being lost if they send packets larger than 1200 bytes.<a href="#section-14-3" class="pilcrow">¶</a></p>
+<p id="section-14-4">Datagrams containing Initial packets MAY exceed 1200 bytes if the client
+believes that the network path and peer both support the size that it chooses.<a href="#section-14-4" class="pilcrow">¶</a></p>
+<p id="section-14-5">UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4
+<span>[<a href="#IPv4" class="xref">IPv4</a>]</span>, the DF bit MUST be set to prevent fragmentation on the path.<a href="#section-14-5" class="pilcrow">¶</a></p>
+<p id="section-14-6">A server MUST discard an Initial packet that is carried in a UDP datagram with
+a payload that is less than 1200 bytes. A server MAY also immediately close the
+connection by sending a CONNECTION_CLOSE frame with an error code of
+PROTOCOL_VIOLATION; see <a href="#immediate-close-hs" class="xref">Section 10.3.1</a>.<a href="#section-14-6" class="pilcrow">¶</a></p>
+<p id="section-14-7">The server MUST also limit the number of bytes it sends before validating the
+address of the client; see <a href="#address-validation" class="xref">Section 8</a>.<a href="#section-14-7" class="pilcrow">¶</a></p>
+<div id="path-maximum-transmission-unit-pmtu">
+<section id="section-14.1">
+        <h3 id="name-path-maximum-transmission-u">
+<a href="#section-14.1" class="section-number selfRef">14.1. </a><a href="#name-path-maximum-transmission-u" class="section-name selfRef">Path Maximum Transmission Unit (PMTU)</a>
+        </h3>
+<p id="section-14.1-1">The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP
+packet including the IP header, UDP header, and UDP payload.  The UDP payload
+includes the QUIC packet header, protected payload, and any authentication
+fields.  The PMTU can depend on path characteristics, and can therefore change
+over time.  The largest UDP payload an endpoint sends at any given time is
+referred to as the endpoint's maximum packet size.<a href="#section-14.1-1" class="pilcrow">¶</a></p>
+<p id="section-14.1-2">QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 minimum size
+<span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span> and is also supported by most modern IPv4 networks.  All QUIC
+packets (except for PMTU probe packets) SHOULD be sized to fit within the
+maximum packet size to avoid the packet being fragmented or dropped
+<span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>.<a href="#section-14.1-2" class="pilcrow">¶</a></p>
+<p id="section-14.1-3">An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery
+(<span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>) or implement Path MTU Discovery
+(PMTUD) <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span> to determine whether the path to a destination
+will support a desired message size without fragmentation.<a href="#section-14.1-3" class="pilcrow">¶</a></p>
+<p id="section-14.1-4">In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
+larger than 1280 bytes. Assuming the minimum IP header size, this results in a
+QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. A QUIC
+implementation MAY be more conservative in computing the QUIC maximum packet
+size to allow for unknown tunnel overheads or IP header options/extensions.<a href="#section-14.1-4" class="pilcrow">¶</a></p>
+<p id="section-14.1-5">Each pair of local and remote addresses could have a different PMTU.  QUIC
+implementations that implement any kind of PMTU discovery therefore SHOULD
+maintain a maximum packet size for each combination of local and remote IP
+addresses.<a href="#section-14.1-5" class="pilcrow">¶</a></p>
+<p id="section-14.1-6">If a QUIC endpoint determines that the PMTU between any pair of local and remote
+IP addresses has fallen below the size needed to support the smallest allowed
+maximum packet size, it MUST immediately cease sending QUIC packets, except for
+PMTU probe packets, on the affected path.  An endpoint MAY terminate the
+connection if an alternative path cannot be found.<a href="#section-14.1-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="icmp-pmtud">
+<section id="section-14.2">
+        <h3 id="name-icmp-packet-too-big-message">
+<a href="#section-14.2" class="section-number selfRef">14.2. </a><a href="#name-icmp-packet-too-big-message" class="section-name selfRef">ICMP Packet Too Big Messages</a>
+        </h3>
+<p id="section-14.2-1">PMTU discovery <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span> relies on reception of ICMP messages
+(e.g., IPv6 Packet Too Big messages) that indicate when a packet is dropped
+because it is larger than the local router MTU. DPLPMTUD can also optionally use
+these messages.  This use of ICMP messages is potentially vulnerable to off-path
+attacks that successfully guess the addresses used on the path and reduce the
+PMTU to a bandwidth-inefficient value.<a href="#section-14.2-1" class="pilcrow">¶</a></p>
+<p id="section-14.2-2">An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below
+1280 bytes.<a href="#section-14.2-2" class="pilcrow">¶</a></p>
+<p id="section-14.2-3">The requirements for generating ICMP (<span>[<a href="#RFC1812" class="xref">RFC1812</a>]</span>, <span>[<a href="#RFC4443" class="xref">RFC4443</a>]</span>) state that the
+quoted packet should contain as much of the original packet as possible without
+exceeding the minimum MTU for the IP version.  The size of the quoted packet can
+actually be smaller, or the information unintelligible, as described in Section
+1.1 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>.<a href="#section-14.2-3" class="pilcrow">¶</a></p>
+<p id="section-14.2-4">QUIC endpoints SHOULD validate ICMP messages to protect from off-path injection
+as specified in <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span> and Section 5.2 of <span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span>. This validation
+SHOULD use the quoted packet supplied in the payload of an ICMP message to
+associate the message with a corresponding transport connection <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>.<a href="#section-14.2-4" class="pilcrow">¶</a></p>
+<p id="section-14.2-5">ICMP message validation MUST include matching IP addresses and UDP ports
+<span>[<a href="#RFC8085" class="xref">RFC8085</a>]</span> and, when possible, connection IDs to an active QUIC session.<a href="#section-14.2-5" class="pilcrow">¶</a></p>
+<p id="section-14.2-6">The endpoint SHOULD ignore all ICMP messages that fail validation.<a href="#section-14.2-6" class="pilcrow">¶</a></p>
+<p id="section-14.2-7">An endpoint MUST NOT increase PMTU based on ICMP messages; see Section 3, clause
+6 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>.  Any reduction in the QUIC maximum packet size in response
+to ICMP messages MAY be provisional until QUIC's loss detection algorithm
+determines that the quoted packet has actually been lost.<a href="#section-14.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="datagram-packetization-layer-pmtu-discovery">
+<section id="section-14.3">
+        <h3 id="name-datagram-packetization-laye">
+<a href="#section-14.3" class="section-number selfRef">14.3. </a><a href="#name-datagram-packetization-laye" class="section-name selfRef">Datagram Packetization Layer PMTU Discovery</a>
+        </h3>
+<p id="section-14.3-1">Section 6.3 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span> provides considerations for implementing Datagram
+Packetization Layer PMTUD (DPLPMTUD) with QUIC.<a href="#section-14.3-1" class="pilcrow">¶</a></p>
+<p id="section-14.3-2">When implementing the algorithm in Section 5 of <span>[<a href="#DPLPMTUD" class="xref">DPLPMTUD</a>]</span>, the initial
+value of BASE_PMTU SHOULD be consistent with the minimum QUIC packet size (1232
+bytes for IPv6 and 1252 bytes for IPv4).<a href="#section-14.3-2" class="pilcrow">¶</a></p>
+<p id="section-14.3-3">PING and PADDING frames can be used to generate PMTU probe packets. These frames
+might not be retransmitted if a probe packet containing them is lost.  However,
+these frames do consume congestion window, which could delay the transmission of
+subsequent application data.<a href="#section-14.3-3" class="pilcrow">¶</a></p>
+<p id="section-14.3-4">A PING frame can be included in a PMTU probe to ensure that a valid probe is
+acknowledged.<a href="#section-14.3-4" class="pilcrow">¶</a></p>
+<p id="section-14.3-5">The considerations for processing ICMP messages in the previous section also
+apply if these messages are used by DPLPMTUD.<a href="#section-14.3-5" class="pilcrow">¶</a></p>
+<div id="pmtu-probes-src-cid">
+<section id="section-14.3.1">
+          <h4 id="name-pmtu-probes-containing-sour">
+<a href="#section-14.3.1" class="section-number selfRef">14.3.1. </a><a href="#name-pmtu-probes-containing-sour" class="section-name selfRef">PMTU Probes Containing Source Connection ID</a>
+          </h4>
+<p id="section-14.3.1-1">Endpoints that rely on the destination connection ID for routing incoming QUIC
+packets are likely to require that the connection ID be included in PMTU probe
+packets to route any resulting ICMP messages (<a href="#icmp-pmtud" class="xref">Section 14.2</a>) back to the
+correct endpoint.  However, only long header packets (<a href="#long-header" class="xref">Section 17.2</a>) contain
+source connection IDs, and long header packets are not decrypted or acknowledged
+by the peer once the handshake is complete.<a href="#section-14.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-14.3.1-2">One way to construct a probe for the path MTU is to coalesce (see
+<a href="#packet-coalesce" class="xref">Section 12.2</a>) a Handshake packet (<a href="#packet-handshake" class="xref">Section 17.2.4</a>) with a short
+header packet in a single UDP datagram.  If the UDP datagram reaches the
+endpoint, the Handshake packet will be ignored, but the short header packet will
+be acknowledged.  If the UDP datagram causes an ICMP message to be sent, the
+first part of the datagram will be quoted in that message.  If the source
+connection ID is within the quoted portion of the UDP datagram, that could be
+used for routing.<a href="#section-14.3.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="versions">
+<section id="section-15">
+      <h2 id="name-versions">
+<a href="#section-15" class="section-number selfRef">15. </a><a href="#name-versions" class="section-name selfRef">Versions</a>
+      </h2>
+<p id="section-15-1">QUIC versions are identified using a 32-bit unsigned number.<a href="#section-15-1" class="pilcrow">¶</a></p>
+<p id="section-15-2">The version 0x00000000 is reserved to represent version negotiation.  This
+version of the specification is identified by the number 0x00000001.<a href="#section-15-2" class="pilcrow">¶</a></p>
+<p id="section-15-3">Other versions of QUIC might have different properties to this version.  The
+properties of QUIC that are guaranteed to be consistent across all versions of
+the protocol are described in <span>[<a href="#QUIC-INVARIANTS" class="xref">QUIC-INVARIANTS</a>]</span>.<a href="#section-15-3" class="pilcrow">¶</a></p>
+<p id="section-15-4">Version 0x00000001 of QUIC uses TLS as a cryptographic handshake protocol, as
+described in <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-15-4" class="pilcrow">¶</a></p>
+<p id="section-15-5">Versions with the most significant 16 bits of the version number cleared are
+reserved for use in future IETF consensus documents.<a href="#section-15-5" class="pilcrow">¶</a></p>
+<p id="section-15-6">Versions that follow the pattern 0x?a?a?a?a are reserved for use in forcing
+version negotiation to be exercised.  That is, any version number where the low
+four bits of all bytes is 1010 (in binary).  A client or server MAY advertise
+support for any of these reserved versions.<a href="#section-15-6" class="pilcrow">¶</a></p>
+<p id="section-15-7">Reserved version numbers will never represent a real protocol; a client MAY use
+one of these version numbers with the expectation that the server will initiate
+version negotiation; a server MAY advertise support for one of these versions
+and can expect that clients ignore the value.<a href="#section-15-7" class="pilcrow">¶</a></p>
+<p id="section-15-8">[[RFC editor: please remove the remainder of this section before
+publication.]]<a href="#section-15-8" class="pilcrow">¶</a></p>
+<p id="section-15-9">The version number for the final version of this specification (0x00000001), is
+reserved for the version of the protocol that is published as an RFC.<a href="#section-15-9" class="pilcrow">¶</a></p>
+<p id="section-15-10">Version numbers used to identify IETF drafts are created by adding the draft
+number to 0xff000000.  For example, draft-ietf-quic-transport-13 would be
+identified as 0xff00000D.<a href="#section-15-10" class="pilcrow">¶</a></p>
+<p id="section-15-11">Implementors are encouraged to register version numbers of QUIC that they are
+using for private experimentation on the GitHub wiki at
+<span><a href="https://github.com/quicwg/base-drafts/wiki/QUIC-Versions">https://github.com/quicwg/base-drafts/wiki/QUIC-Versions</a></span>.<a href="#section-15-11" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="integer-encoding">
+<section id="section-16">
+      <h2 id="name-variable-length-integer-enc">
+<a href="#section-16" class="section-number selfRef">16. </a><a href="#name-variable-length-integer-enc" class="section-name selfRef">Variable-Length Integer Encoding</a>
+      </h2>
+<p id="section-16-1">QUIC packets and frames commonly use a variable-length encoding for non-negative
+integer values.  This encoding ensures that smaller integer values need fewer
+bytes to encode.<a href="#section-16-1" class="pilcrow">¶</a></p>
+<p id="section-16-2">The QUIC variable-length integer encoding reserves the two most significant bits
+of the first byte to encode the base 2 logarithm of the integer encoding length
+in bytes.  The integer value is encoded on the remaining bits, in network byte
+order.<a href="#section-16-2" class="pilcrow">¶</a></p>
+<p id="section-16-3">This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6,
+14, 30, or 62 bit values respectively.  <a href="#integer-summary" class="xref">Table 4</a> summarizes the
+encoding properties.<a href="#section-16-3" class="pilcrow">¶</a></p>
+<span id="name-summary-of-integer-encoding"></span><div id="integer-summary">
+<table class="center" id="table-4">
+        <caption>
+<a href="#table-4" class="selfRef">Table 4</a>:
+<a href="#name-summary-of-integer-encoding" class="selfRef">Summary of Integer Encodings</a>
+        </caption>
+<thead>
+          <tr>
+            <th class="text-left" rowspan="1" colspan="1">2Bit</th>
+            <th class="text-left" rowspan="1" colspan="1">Length</th>
+            <th class="text-left" rowspan="1" colspan="1">Usable Bits</th>
+            <th class="text-left" rowspan="1" colspan="1">Range</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">00</td>
+            <td class="text-left" rowspan="1" colspan="1">1</td>
+            <td class="text-left" rowspan="1" colspan="1">6</td>
+            <td class="text-left" rowspan="1" colspan="1">0-63</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">01</td>
+            <td class="text-left" rowspan="1" colspan="1">2</td>
+            <td class="text-left" rowspan="1" colspan="1">14</td>
+            <td class="text-left" rowspan="1" colspan="1">0-16383</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">10</td>
+            <td class="text-left" rowspan="1" colspan="1">4</td>
+            <td class="text-left" rowspan="1" colspan="1">30</td>
+            <td class="text-left" rowspan="1" colspan="1">0-1073741823</td>
+          </tr>
+          <tr>
+            <td class="text-left" rowspan="1" colspan="1">11</td>
+            <td class="text-left" rowspan="1" colspan="1">8</td>
+            <td class="text-left" rowspan="1" colspan="1">62</td>
+            <td class="text-left" rowspan="1" colspan="1">0-4611686018427387903</td>
+          </tr>
+        </tbody>
+      </table>
+</div>
+<p id="section-16-5">For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in hexadecimal)
+decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e
+7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the
+single byte 25 decodes to 37 (as does the two byte sequence 40 25).<a href="#section-16-5" class="pilcrow">¶</a></p>
+<p id="section-16-6">Error codes (<a href="#error-codes" class="xref">Section 20</a>) and versions (<a href="#versions" class="xref">Section 15</a>) are described using
+integers, but do not use this encoding.<a href="#section-16-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="packet-formats">
+<section id="section-17">
+      <h2 id="name-packet-formats">
+<a href="#section-17" class="section-number selfRef">17. </a><a href="#name-packet-formats" class="section-name selfRef">Packet Formats</a>
+      </h2>
+<p id="section-17-1">All numeric values are encoded in network byte order (that is, big-endian) and
+all field sizes are in bits.  Hexadecimal notation is used for describing the
+value of fields.<a href="#section-17-1" class="pilcrow">¶</a></p>
+<div id="packet-encoding">
+<section id="section-17.1">
+        <h3 id="name-packet-number-encoding-and-">
+<a href="#section-17.1" class="section-number selfRef">17.1. </a><a href="#name-packet-number-encoding-and-" class="section-name selfRef">Packet Number Encoding and Decoding</a>
+        </h3>
+<p id="section-17.1-1">Packet numbers are integers in the range 0 to 2^62-1 (<a href="#packet-numbers" class="xref">Section 12.3</a>).  When
+present in long or short packet headers, they are encoded in 1 to 4 bytes.  The
+number of bits required to represent the packet number is reduced by including
+the least significant bits of the packet number.<a href="#section-17.1-1" class="pilcrow">¶</a></p>
+<p id="section-17.1-2">The encoded packet number is protected as described in Section 5.4 of
+<span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-17.1-2" class="pilcrow">¶</a></p>
+<p id="section-17.1-3">The sender MUST use a packet number size able to represent more than twice as
+large a range than the difference between the largest acknowledged packet and
+packet number being sent.  A peer receiving the packet will then correctly
+decode the packet number, unless the packet is delayed in transit such that it
+arrives after many higher-numbered packets have been received.  An endpoint
+SHOULD use a large enough packet number encoding to allow the packet number to
+be recovered even if the packet arrives after packets that are sent afterwards.<a href="#section-17.1-3" class="pilcrow">¶</a></p>
+<p id="section-17.1-4">As a result, the size of the packet number encoding is at least one bit more
+than the base-2 logarithm of the number of contiguous unacknowledged packet
+numbers, including the new packet.<a href="#section-17.1-4" class="pilcrow">¶</a></p>
+<p id="section-17.1-5">For example, if an endpoint has received an acknowledgment for packet 0xabe8bc,
+sending a packet with a number of 0xac5c02 requires a packet number encoding
+with 16 bits or more; whereas the 24-bit packet number encoding is needed to
+send a packet with a number of 0xace8fe.<a href="#section-17.1-5" class="pilcrow">¶</a></p>
+<p id="section-17.1-6">At a receiver, protection of the packet number is removed prior to recovering
+the full packet number. The full packet number is then reconstructed based on
+the number of significant bits present, the value of those bits, and the largest
+packet number received on a successfully authenticated packet. Recovering the
+full packet number is necessary to successfully remove packet protection.<a href="#section-17.1-6" class="pilcrow">¶</a></p>
+<p id="section-17.1-7">Once header protection is removed, the packet number is decoded by finding the
+packet number value that is closest to the next expected packet.  The next
+expected packet is the highest received packet number plus one.  For example, if
+the highest successfully authenticated packet had a packet number of 0xa82f30ea,
+then a packet containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32.
+Example pseudo-code for packet number decoding can be found in
+<a href="#sample-packet-number-decoding" class="xref">Appendix A</a>.<a href="#section-17.1-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="long-header">
+<section id="section-17.2">
+        <h3 id="name-long-header-packets">
+<a href="#section-17.2" class="section-number selfRef">17.2. </a><a href="#name-long-header-packets" class="section-name selfRef">Long Header Packets</a>
+        </h3>
+<span id="name-long-header-packet-format"></span><div id="fig-long-header">
+<figure id="figure-12">
+          <div class="artwork art-text alignLeft" id="section-17.2-1.1">
+<pre>
+Long Header Packet {
+  Header Form (1) = 1,
+  Fixed Bit (1) = 1,
+  Long Packet Type (2),
+  Type-Specific Bits (4),
+  Version (32),
+  DCID Length (8),
+  Destination Connection ID (0..160),
+  SCID Length (8),
+  Source Connection ID (0..160),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
+<a href="#name-long-header-packet-format" class="selfRef">Long Header Packet Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-17.2-2">Long headers are used for packets that are sent prior to the establishment
+of 1-RTT keys. Once 1-RTT keys are available,
+a sender switches to sending packets using the short header
+(<a href="#short-header" class="xref">Section 17.3</a>).  The long form allows for special packets - such as the
+Version Negotiation packet - to be represented in this uniform fixed-length
+packet format. Packets that use the long header contain the following fields:<a href="#section-17.2-2" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-17.2-3">
+          <dt id="section-17.2-3.1">Header Form:</dt>
+<dd id="section-17.2-3.2">
+  The most significant bit (0x80) of byte 0 (the first byte) is set to 1 for
+long headers.<a href="#section-17.2-3.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-3.3">Fixed Bit:</dt>
+<dd id="section-17.2-3.4">
+  The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value
+for this bit are not valid packets in this version and MUST be discarded.<a href="#section-17.2-3.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-3.5">Long Packet Type:</dt>
+<dd id="section-17.2-3.6">
+  The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.
+Packet types are listed in <a href="#long-packet-types" class="xref">Table 5</a>.<a href="#section-17.2-3.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-3.7">Type-Specific Bits:</dt>
+<dd id="section-17.2-3.8">
+  The lower four bits (those with a mask of 0x0f) of byte 0 are type-specific.<a href="#section-17.2-3.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-3.9">Version:</dt>
+<dd id="section-17.2-3.10">
+  The QUIC Version is a 32-bit field that follows the first byte.  This field
+indicates which version of QUIC is in use and determines how the rest of the
+protocol fields are interpreted.<a href="#section-17.2-3.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-3.11">DCID Length:</dt>
+<dd id="section-17.2-3.12">
+  The byte following the version contains the length in bytes of the Destination
+Connection ID field that follows it.  This length is encoded as an 8-bit
+unsigned integer.  In QUIC version 1, this value MUST NOT exceed 20.
+Endpoints that receive a version 1 long header with a value larger than
+20 MUST drop the packet. Servers SHOULD be able to read longer connection IDs
+from other QUIC versions in order to properly form a version negotiation
+packet.<a href="#section-17.2-3.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-3.13">Destination Connection ID:</dt>
+<dd id="section-17.2-3.14">
+  The Destination Connection ID field follows the DCID Length field and is
+between 0 and 20 bytes in length. <a href="#negotiating-connection-ids" class="xref">Section 7.2</a> describes
+the use of this field in more detail.<a href="#section-17.2-3.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-3.15">SCID Length:</dt>
+<dd id="section-17.2-3.16">
+  The byte following the Destination Connection ID contains the length in bytes
+of the Source Connection ID field that follows it.  This length is encoded as
+a 8-bit unsigned integer.  In QUIC version 1, this value MUST NOT exceed 20
+bytes. Endpoints that receive a version 1 long header with a value larger than
+20 MUST drop the packet. Servers SHOULD be able to read longer connection IDs
+from other QUIC versions in order to properly form a version negotiation
+packet.<a href="#section-17.2-3.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-3.17">Source Connection ID:</dt>
+<dd id="section-17.2-3.18">
+  The Source Connection ID field follows the SCID Length field and is between 0
+and 20 bytes in length. <a href="#negotiating-connection-ids" class="xref">Section 7.2</a> describes the use of
+this field in more detail.<a href="#section-17.2-3.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-17.2-4">In this version of QUIC, the following packet types with the long header are
+defined:<a href="#section-17.2-4" class="pilcrow">¶</a></p>
+<span id="name-long-header-packet-types"></span><div id="long-packet-types">
+<table class="center" id="table-5">
+          <caption>
+<a href="#table-5" class="selfRef">Table 5</a>:
+<a href="#name-long-header-packet-types" class="selfRef">Long Header Packet Types</a>
+          </caption>
+<thead>
+            <tr>
+              <th class="text-right" rowspan="1" colspan="1">Type</th>
+              <th class="text-left" rowspan="1" colspan="1">Name</th>
+              <th class="text-left" rowspan="1" colspan="1">Section</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-right" rowspan="1" colspan="1">0x0</td>
+              <td class="text-left" rowspan="1" colspan="1">Initial</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#packet-initial" class="xref">Section 17.2.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-right" rowspan="1" colspan="1">0x1</td>
+              <td class="text-left" rowspan="1" colspan="1">0-RTT</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#packet-0rtt" class="xref">Section 17.2.3</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-right" rowspan="1" colspan="1">0x2</td>
+              <td class="text-left" rowspan="1" colspan="1">Handshake</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#packet-handshake" class="xref">Section 17.2.4</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-right" rowspan="1" colspan="1">0x3</td>
+              <td class="text-left" rowspan="1" colspan="1">Retry</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#packet-retry" class="xref">Section 17.2.5</a>
+</td>
+            </tr>
+          </tbody>
+        </table>
+</div>
+<p id="section-17.2-6">The header form bit, connection ID lengths byte, Destination and Source
+Connection ID fields, and Version fields of a long header packet are
+version-independent. The other fields in the first byte are version-specific.
+See <span>[<a href="#QUIC-INVARIANTS" class="xref">QUIC-INVARIANTS</a>]</span> for details on how packets from different versions of
+QUIC are interpreted.<a href="#section-17.2-6" class="pilcrow">¶</a></p>
+<p id="section-17.2-7">The interpretation of the fields and the payload are specific to a version and
+packet type.  While type-specific semantics for this version are described in
+the following sections, several long-header packets in this version of QUIC
+contain these additional fields:<a href="#section-17.2-7" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-17.2-8">
+          <dt id="section-17.2-8.1">Reserved Bits:</dt>
+<dd id="section-17.2-8.2">
+  Two bits (those with a mask of 0x0c) of byte 0 are reserved across multiple
+packet types.  These bits are protected using header protection; see Section
+5.4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>. The value included prior to protection MUST be set to 0.
+An endpoint MUST treat receipt of a packet that has a non-zero value for these
+bits, after removing both packet and header protection, as a connection error
+of type PROTOCOL_VIOLATION. Discarding such a packet after only removing
+header protection can expose the endpoint to attacks; see Section 9.3 of
+<span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-17.2-8.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-8.3">Packet Number Length:</dt>
+<dd id="section-17.2-8.4">
+  In packet types which contain a Packet Number field, the least significant two
+bits (those with a mask of 0x03) of byte 0 contain the length of the packet
+number, encoded as an unsigned, two-bit integer that is one less than the
+length of the packet number field in bytes.  That is, the length of the packet
+number field is the value of this field, plus one.  These bits are protected
+using header protection; see Section 5.4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-17.2-8.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-8.5">Length:</dt>
+<dd id="section-17.2-8.6">
+  The length of the remainder of the packet (that is, the Packet Number and
+Payload fields) in bytes, encoded as a variable-length integer
+(<a href="#integer-encoding" class="xref">Section 16</a>).<a href="#section-17.2-8.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2-8.7">Packet Number:</dt>
+<dd id="section-17.2-8.8">
+  The packet number field is 1 to 4 bytes long. The packet number has
+confidentiality protection separate from packet protection, as described in
+Section 5.4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>. The length of the packet number field is encoded
+in the Packet Number Length bits of byte 0; see above.<a href="#section-17.2-8.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<div id="packet-version">
+<section id="section-17.2.1">
+          <h4 id="name-version-negotiation-packet">
+<a href="#section-17.2.1" class="section-number selfRef">17.2.1. </a><a href="#name-version-negotiation-packet" class="section-name selfRef">Version Negotiation Packet</a>
+          </h4>
+<p id="section-17.2.1-1">A Version Negotiation packet is inherently not version-specific. Upon receipt by
+a client, it will be identified as a Version Negotiation packet based on the
+Version field having a value of 0.<a href="#section-17.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-2">The Version Negotiation packet is a response to a client packet that contains a
+version that is not supported by the server, and is only sent by servers.<a href="#section-17.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-3">The layout of a Version Negotiation packet is:<a href="#section-17.2.1-3" class="pilcrow">¶</a></p>
+<span id="name-version-negotiation-packet-2"></span><div id="version-negotiation-format">
+<figure id="figure-13">
+            <div class="artwork art-text alignLeft" id="section-17.2.1-4.1">
+<pre>
+Version Negotiation Packet {
+  Header Form (1) = 1,
+  Unused (7),
+  Version (32) = 0,
+  DCID Length (8),
+  Destination Connection ID (0..2040),
+  SCID Length (8),
+  Source Connection ID (0..2040),
+  Supported Version (32) ...,
+}
+</pre>
+</div>
+<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
+<a href="#name-version-negotiation-packet-2" class="selfRef">Version Negotiation Packet</a>
+            </figcaption></figure>
+</div>
+<p id="section-17.2.1-5">The value in the Unused field is selected randomly by the server.  Clients MUST
+ignore the value of this field.  Servers SHOULD set the most significant bit of
+this field (0x40) to 1 so that Version Negotiation packets appear to have the
+Fixed Bit field.<a href="#section-17.2.1-5" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-6">The Version field of a Version Negotiation packet MUST be set to 0x00000000.<a href="#section-17.2.1-6" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-7">The server MUST include the value from the Source Connection ID field of the
+packet it receives in the Destination Connection ID field.  The value for Source
+Connection ID MUST be copied from the Destination Connection ID of the received
+packet, which is initially randomly selected by a client.  Echoing both
+connection IDs gives clients some assurance that the server received the packet
+and that the Version Negotiation packet was not generated by an off-path
+attacker.<a href="#section-17.2.1-7" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-8">As future versions of QUIC may support Connection IDs larger than the version 1
+limit, Version Negotiation packets could carry Connection IDs that are longer
+than 20 bytes.<a href="#section-17.2.1-8" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-9">The remainder of the Version Negotiation packet is a list of 32-bit versions
+which the server supports.<a href="#section-17.2.1-9" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-10">A Version Negotiation packet cannot be explicitly acknowledged in an ACK frame
+by a client.  Receiving another Initial packet implicitly acknowledges a Version
+Negotiation packet.<a href="#section-17.2.1-10" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-11">The Version Negotiation packet does not include the Packet Number and Length
+fields present in other packets that use the long header form.  Consequently,
+a Version Negotiation packet consumes an entire UDP datagram.<a href="#section-17.2.1-11" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-12">A server MUST NOT send more than one Version Negotiation packet in response to a
+single UDP datagram.<a href="#section-17.2.1-12" class="pilcrow">¶</a></p>
+<p id="section-17.2.1-13">See <a href="#version-negotiation" class="xref">Section 6</a> for a description of the version negotiation
+process.<a href="#section-17.2.1-13" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="packet-initial">
+<section id="section-17.2.2">
+          <h4 id="name-initial-packet">
+<a href="#section-17.2.2" class="section-number selfRef">17.2.2. </a><a href="#name-initial-packet" class="section-name selfRef">Initial Packet</a>
+          </h4>
+<p id="section-17.2.2-1">An Initial packet uses long headers with a type value of 0x0.  It carries the
+first CRYPTO frames sent by the client and server to perform key exchange, and
+carries ACKs in either direction.<a href="#section-17.2.2-1" class="pilcrow">¶</a></p>
+<span id="name-initial-packet-2"></span><div id="initial-format">
+<figure id="figure-14">
+            <div class="artwork art-text alignLeft" id="section-17.2.2-2.1">
+<pre>
+Initial Packet {
+  Header Form (1) = 1,
+  Fixed Bit (1) = 1,
+  Long Packet Type (2) = 0,
+  Reserved Bits (2),
+  Packet Number Length (2),
+  Version (32),
+  DCID Length (8),
+  Destination Connection ID (0..160),
+  SCID Length (8),
+  Source Connection ID (0..160),
+  Token Length (i),
+  Token (..),
+  Length (i),
+  Packet Number (8..32),
+  Packet Payload (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
+<a href="#name-initial-packet-2" class="selfRef">Initial Packet</a>
+            </figcaption></figure>
+</div>
+<p id="section-17.2.2-3">The Initial packet contains a long header as well as the Length and Packet
+Number fields.  The first byte contains the Reserved and Packet Number Length
+bits.  Between the SCID and Length fields, there are two additional
+fields specific to the Initial packet.<a href="#section-17.2.2-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-17.2.2-4">
+            <dt id="section-17.2.2-4.1">Token Length:</dt>
+<dd id="section-17.2.2-4.2">
+  A variable-length integer specifying the length of the Token field, in bytes.
+This value is zero if no token is present.  Initial packets sent by the server
+MUST set the Token Length field to zero; clients that receive an Initial
+packet with a non-zero Token Length field MUST either discard the packet or
+generate a connection error of type PROTOCOL_VIOLATION.<a href="#section-17.2.2-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2.2-4.3">Token:</dt>
+<dd id="section-17.2.2-4.4">
+  The value of the token that was previously provided in a Retry packet or
+NEW_TOKEN frame.<a href="#section-17.2.2-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2.2-4.5">Packet Payload:</dt>
+<dd id="section-17.2.2-4.6">
+  The payload of the packet.<a href="#section-17.2.2-4.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-17.2.2-5">In order to prevent tampering by version-unaware middleboxes, Initial packets
+are protected with connection- and version-specific keys (Initial keys) as
+described in <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.  This protection does not provide confidentiality or
+integrity against on-path attackers, but provides some level of protection
+against off-path attackers.<a href="#section-17.2.2-5" class="pilcrow">¶</a></p>
+<p id="section-17.2.2-6">The client and server use the Initial packet type for any packet that contains
+an initial cryptographic handshake message. This includes all cases where a new
+packet containing the initial cryptographic message needs to be created, such as
+the packets sent after receiving a Retry packet (<a href="#packet-retry" class="xref">Section 17.2.5</a>).<a href="#section-17.2.2-6" class="pilcrow">¶</a></p>
+<p id="section-17.2.2-7">A server sends its first Initial packet in response to a client Initial.  A
+server may send multiple Initial packets.  The cryptographic key exchange could
+require multiple round trips or retransmissions of this data.<a href="#section-17.2.2-7" class="pilcrow">¶</a></p>
+<p id="section-17.2.2-8">The payload of an Initial packet includes a CRYPTO frame (or frames) containing
+a cryptographic handshake message, ACK frames, or both.  PING, PADDING, and
+CONNECTION_CLOSE frames are also permitted.  An endpoint that receives an
+Initial packet containing other frames can either discard the packet as spurious
+or treat it as a connection error.<a href="#section-17.2.2-8" class="pilcrow">¶</a></p>
+<p id="section-17.2.2-9">The first packet sent by a client always includes a CRYPTO frame that contains
+the start or all of the first cryptographic handshake message.  The first
+CRYPTO frame sent always begins at an offset of 0; see <a href="#handshake" class="xref">Section 7</a>.<a href="#section-17.2.2-9" class="pilcrow">¶</a></p>
+<p id="section-17.2.2-10">Note that if the server sends a HelloRetryRequest, the client will send another
+series of Initial packets.  These Initial packets will continue the
+cryptographic handshake and will contain CRYPTO frames starting at an offset
+matching the size of the CRYPTO frames sent in the first flight of Initial
+packets.<a href="#section-17.2.2-10" class="pilcrow">¶</a></p>
+<div id="discard-initial">
+<section id="section-17.2.2.1">
+            <h5 id="name-abandoning-initial-packets">
+<a href="#section-17.2.2.1" class="section-number selfRef">17.2.2.1. </a><a href="#name-abandoning-initial-packets" class="section-name selfRef">Abandoning Initial Packets</a>
+            </h5>
+<p id="section-17.2.2.1-1">A client stops both sending and processing Initial packets when it sends its
+first Handshake packet.  A server stops sending and processing Initial packets
+when it receives its first Handshake packet.  Though packets might still be in
+flight or awaiting acknowledgment, no further Initial packets need to be
+exchanged beyond this point.  Initial packet protection keys are discarded (see
+Section 4.11.1 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>) along with any loss recovery and congestion
+control state; see Section 6.5 of <span>[<a href="#QUIC-RECOVERY" class="xref">QUIC-RECOVERY</a>]</span>.<a href="#section-17.2.2.1-1" class="pilcrow">¶</a></p>
+<p id="section-17.2.2.1-2">Any data in CRYPTO frames is discarded - and no longer retransmitted - when
+Initial keys are discarded.<a href="#section-17.2.2.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="packet-0rtt">
+<section id="section-17.2.3">
+          <h4 id="name-0-rtt">
+<a href="#section-17.2.3" class="section-number selfRef">17.2.3. </a><a href="#name-0-rtt" class="section-name selfRef">0-RTT</a>
+          </h4>
+<p id="section-17.2.3-1">A 0-RTT packet uses long headers with a type value of 0x1, followed by the
+Length and Packet Number fields. The first byte contains the Reserved and Packet
+Number Length bits.  It is used to carry "early" data from the client to the
+server as part of the first flight, prior to handshake completion. As part of
+the TLS handshake, the server can accept or reject this early data.<a href="#section-17.2.3-1" class="pilcrow">¶</a></p>
+<p id="section-17.2.3-2">See Section 2.3 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span> for a discussion of 0-RTT data and its
+limitations.<a href="#section-17.2.3-2" class="pilcrow">¶</a></p>
+<span id="name-0-rtt-packet"></span><figure id="figure-15">
+            <div class="artwork art-text alignLeft" id="section-17.2.3-3.1">
+<pre>
+0-RTT Packet {
+  Header Form (1) = 1,
+  Fixed Bit (1) = 1,
+  Long Packet Type (2) = 1,
+  Reserved Bits (2),
+  Packet Number Length (2),
+  Version (32),
+  DCID Length (8),
+  Destination Connection ID (0..160),
+  SCID Length (8),
+  Source Connection ID (0..160),
+  Length (i),
+  Packet Number (8..32),
+  Packet Payload (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
+<a href="#name-0-rtt-packet" class="selfRef">0-RTT Packet</a>
+            </figcaption></figure>
+<p id="section-17.2.3-4">Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected
+packets.<a href="#section-17.2.3-4" class="pilcrow">¶</a></p>
+<p id="section-17.2.3-5">After a client receives a Retry packet, 0-RTT packets are likely to have been
+lost or discarded by the server.  A client SHOULD attempt to resend data in
+0-RTT packets after it sends a new Initial packet.<a href="#section-17.2.3-5" class="pilcrow">¶</a></p>
+<p id="section-17.2.3-6">A client MUST NOT reset the packet number it uses for 0-RTT packets, since the
+keys used to protect 0-RTT packets will not change as a result of responding to
+a Retry packet.  Sending packets with the same packet number in that case is
+likely to compromise the packet protection for all 0-RTT packets because the
+same key and nonce could be used to protect different content.<a href="#section-17.2.3-6" class="pilcrow">¶</a></p>
+<p id="section-17.2.3-7">A client only receives acknowledgments for its 0-RTT packets once the handshake
+is complete.  Consequently, a server might expect 0-RTT packets to start with a
+packet number of 0.  Therefore, in determining the length of the packet number
+encoding for 0-RTT packets, a client MUST assume that all packets up to the
+current packet number are in flight, starting from a packet number of 0.  Thus,
+0-RTT packets could need to use a longer packet number encoding.<a href="#section-17.2.3-7" class="pilcrow">¶</a></p>
+<p id="section-17.2.3-8">A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
+from the server.  This means that 0-RTT packets cannot contain any response to
+frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a
+0-RTT packet, because that can only acknowledge a 1-RTT packet.  An
+acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.<a href="#section-17.2.3-8" class="pilcrow">¶</a></p>
+<p id="section-17.2.3-9">A server SHOULD treat a violation of remembered limits as a connection error of
+an appropriate type (for instance, a FLOW_CONTROL_ERROR for exceeding stream
+data limits).<a href="#section-17.2.3-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="packet-handshake">
+<section id="section-17.2.4">
+          <h4 id="name-handshake-packet">
+<a href="#section-17.2.4" class="section-number selfRef">17.2.4. </a><a href="#name-handshake-packet" class="section-name selfRef">Handshake Packet</a>
+          </h4>
+<p id="section-17.2.4-1">A Handshake packet uses long headers with a type value of 0x2, followed by the
+Length and Packet Number fields.  The first byte contains the Reserved and
+Packet Number Length bits.  It is used to carry acknowledgments and
+cryptographic handshake messages from the server and client.<a href="#section-17.2.4-1" class="pilcrow">¶</a></p>
+<span id="name-handshake-protected-packet"></span><div id="handshake-format">
+<figure id="figure-16">
+            <div class="artwork art-text alignLeft" id="section-17.2.4-2.1">
+<pre>
+Handshake Packet {
+  Header Form (1) = 1,
+  Fixed Bit (1) = 1,
+  Long Packet Type (2) = 2,
+  Reserved Bits (2),
+  Packet Number Length (2),
+  Version (32),
+  DCID Length (8),
+  Destination Connection ID (0..160),
+  SCID Length (8),
+  Source Connection ID (0..160),
+  Length (i),
+  Packet Number (8..32),
+  Packet Payload (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
+<a href="#name-handshake-protected-packet" class="selfRef">Handshake Protected Packet</a>
+            </figcaption></figure>
+</div>
+<p id="section-17.2.4-3">Once a client has received a Handshake packet from a server, it uses Handshake
+packets to send subsequent cryptographic handshake messages and acknowledgments
+to the server.<a href="#section-17.2.4-3" class="pilcrow">¶</a></p>
+<p id="section-17.2.4-4">The Destination Connection ID field in a Handshake packet contains a connection
+ID that is chosen by the recipient of the packet; the Source Connection ID
+includes the connection ID that the sender of the packet wishes to use; see
+<a href="#negotiating-connection-ids" class="xref">Section 7.2</a>.<a href="#section-17.2.4-4" class="pilcrow">¶</a></p>
+<p id="section-17.2.4-5">Handshake packets are their own packet number space, and thus the first
+Handshake packet sent by a server contains a packet number of 0.<a href="#section-17.2.4-5" class="pilcrow">¶</a></p>
+<p id="section-17.2.4-6">The payload of this packet contains CRYPTO frames and could contain PING,
+PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE frames.
+Endpoints MUST treat receipt of Handshake packets with other frames as a
+connection error.<a href="#section-17.2.4-6" class="pilcrow">¶</a></p>
+<p id="section-17.2.4-7">Like Initial packets (see <a href="#discard-initial" class="xref">Section 17.2.2.1</a>), data in CRYPTO frames for
+Handshake packets is discarded - and no longer retransmitted - when Handshake
+protection keys are discarded.<a href="#section-17.2.4-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="packet-retry">
+<section id="section-17.2.5">
+          <h4 id="name-retry-packet">
+<a href="#section-17.2.5" class="section-number selfRef">17.2.5. </a><a href="#name-retry-packet" class="section-name selfRef">Retry Packet</a>
+          </h4>
+<p id="section-17.2.5-1">A Retry packet uses a long packet header with a type value of 0x3. It carries
+an address validation token created by the server. It is used by a server that
+wishes to perform a retry; see <a href="#validate-handshake" class="xref">Section 8.1</a>.<a href="#section-17.2.5-1" class="pilcrow">¶</a></p>
+<span id="name-retry-packet-2"></span><div id="retry-format">
+<figure id="figure-17">
+            <div class="artwork art-text alignLeft" id="section-17.2.5-2.1">
+<pre>
+Retry Packet {
+  Header Form (1) = 1,
+  Fixed Bit (1) = 1,
+  Long Packet Type (2) = 3,
+  Unused (4),
+  Version (32),
+  DCID Length (8),
+  Destination Connection ID (0..160),
+  SCID Length (8),
+  Source Connection ID (0..160),
+  Retry Token (..),
+  Retry Integrity Tag (128),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
+<a href="#name-retry-packet-2" class="selfRef">Retry Packet</a>
+            </figcaption></figure>
+</div>
+<p id="section-17.2.5-3">A Retry packet (shown in <a href="#retry-format" class="xref">Figure 17</a>) does not contain any protected
+fields. The value in the Unused field is selected randomly by the server. In
+addition to the fields from the long header, it contains these additional
+fields:<a href="#section-17.2.5-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-17.2.5-4">
+            <dt id="section-17.2.5-4.1">Retry Token:</dt>
+<dd id="section-17.2.5-4.2">
+  An opaque token that the server can use to validate the client's address.<a href="#section-17.2.5-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.2.5-4.3">Retry Integrity Tag:</dt>
+<dd id="section-17.2.5-4.4">
+  See the Retry Packet Integrity section of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-17.2.5-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<div id="sending-a-retry-packet">
+<section id="section-17.2.5.1">
+            <h5 id="name-sending-a-retry-packet">
+<a href="#section-17.2.5.1" class="section-number selfRef">17.2.5.1. </a><a href="#name-sending-a-retry-packet" class="section-name selfRef">Sending a Retry Packet</a>
+            </h5>
+<p id="section-17.2.5.1-1">The server populates the Destination Connection ID with the connection ID that
+the client included in the Source Connection ID of the Initial packet.<a href="#section-17.2.5.1-1" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.1-2">The server includes a connection ID of its choice in the Source Connection ID
+field.  This value MUST NOT be equal to the Destination Connection ID field of
+the packet sent by the client.  A client MUST discard a Retry packet that
+contains a Source Connection ID field that is identical to the Destination
+Connection ID field of its Initial packet.  The client MUST use the value from
+the Source Connection ID field of the Retry packet in the Destination Connection
+ID field of subsequent packets that it sends.<a href="#section-17.2.5.1-2" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.1-3">A server MAY send Retry packets in response to Initial and 0-RTT packets.  A
+server can either discard or buffer 0-RTT packets that it receives.  A server
+can send multiple Retry packets as it receives Initial or 0-RTT packets.  A
+server MUST NOT send more than one Retry packet in response to a single UDP
+datagram.<a href="#section-17.2.5.1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="handling-a-retry-packet">
+<section id="section-17.2.5.2">
+            <h5 id="name-handling-a-retry-packet">
+<a href="#section-17.2.5.2" class="section-number selfRef">17.2.5.2. </a><a href="#name-handling-a-retry-packet" class="section-name selfRef">Handling a Retry Packet</a>
+            </h5>
+<p id="section-17.2.5.2-1">A client MUST accept and process at most one Retry packet for each connection
+attempt.  After the client has received and processed an Initial or Retry packet
+from the server, it MUST discard any subsequent Retry packets that it receives.<a href="#section-17.2.5.2-1" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.2-2">Clients MUST discard Retry packets that have a Retry Integrity Tag that cannot
+be validated, see the Retry Packet Integrity section of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>. This
+diminishes an off-path attacker's ability to inject a Retry packet and protects
+against accidental corruption of Retry packets.  A client MUST discard a Retry
+packet with a zero-length Retry Token field.<a href="#section-17.2.5.2-2" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.2-3">The client responds to a Retry packet with an Initial packet that includes the
+provided Retry Token to continue connection establishment.<a href="#section-17.2.5.2-3" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.2-4">A client sets the Destination Connection ID field of this Initial packet to the
+value from the Source Connection ID in the Retry packet. Changing Destination
+Connection ID also results in a change to the keys used to protect the Initial
+packet. It also sets the Token field to the token provided in the Retry. The
+client MUST NOT change the Source Connection ID because the server could include
+the connection ID as part of its token validation logic; see
+<a href="#token-integrity" class="xref">Section 8.1.4</a>.<a href="#section-17.2.5.2-4" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.2-5">A Retry packet does not include a packet number and cannot be explicitly
+acknowledged by a client.<a href="#section-17.2.5.2-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="continuing-a-handshake-after-retry">
+<section id="section-17.2.5.3">
+            <h5 id="name-continuing-a-handshake-afte">
+<a href="#section-17.2.5.3" class="section-number selfRef">17.2.5.3. </a><a href="#name-continuing-a-handshake-afte" class="section-name selfRef">Continuing a Handshake After Retry</a>
+            </h5>
+<p id="section-17.2.5.3-1">The next Initial packet from the client uses the connection ID and token values
+from the Retry packet; see <a href="#negotiating-connection-ids" class="xref">Section 7.2</a>.  Aside from this,
+the Initial packet sent by the client is subject to the same restrictions as the
+first Initial packet.  A client MUST use the same cryptographic handshake
+message it includes in this packet.  A server MAY treat a packet that
+contains a different cryptographic handshake message as a connection error or
+discard it.<a href="#section-17.2.5.3-1" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.3-2">A client MAY attempt 0-RTT after receiving a Retry packet by sending 0-RTT
+packets to the connection ID provided by the server.  A client MUST NOT change
+the cryptographic handshake message it sends in response to receiving a Retry.<a href="#section-17.2.5.3-2" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.3-3">A client MUST NOT reset the packet number for any packet number space after
+processing a Retry packet; <a href="#packet-0rtt" class="xref">Section 17.2.3</a> contains more information on this.<a href="#section-17.2.5.3-3" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.3-4">A server acknowledges the use of a Retry packet for a connection using the
+retry_source_connection_id transport parameter; see
+<a href="#transport-parameter-definitions" class="xref">Section 18.2</a>.  If the server sends a Retry packet, it
+also subsequently includes the value of the Source Connection ID field from
+the Retry packet in its retry_source_connection_id transport parameter.<a href="#section-17.2.5.3-4" class="pilcrow">¶</a></p>
+<p id="section-17.2.5.3-5">If the client received and processed a Retry packet, it MUST validate that the
+retry_source_connection_id transport parameter is present and correct;
+otherwise, it MUST validate that the transport parameter is absent. A client
+MUST treat a failed validation as a connection error of type
+PROTOCOL_VIOLATION.<a href="#section-17.2.5.3-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="short-header">
+<section id="section-17.3">
+        <h3 id="name-short-header-packets">
+<a href="#section-17.3" class="section-number selfRef">17.3. </a><a href="#name-short-header-packets" class="section-name selfRef">Short Header Packets</a>
+        </h3>
+<p id="section-17.3-1">This version of QUIC defines a single packet type which uses the
+short packet header.<a href="#section-17.3-1" class="pilcrow">¶</a></p>
+<span id="name-short-header-packet-format"></span><div id="fig-short-header">
+<figure id="figure-18">
+          <div class="artwork art-text alignLeft" id="section-17.3-2.1">
+<pre>
+Short Header Packet {
+  Header Form (1) = 0,
+  Fixed Bit (1) = 1,
+  Spin Bit (1),
+  Reserved Bits (2),
+  Key Phase (1),
+  Packet Number Length (2),
+  Destination Connection ID (0..160),
+  Packet Number (8..32),
+  Packet Payload (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-18" class="selfRef">Figure 18</a>:
+<a href="#name-short-header-packet-format" class="selfRef">Short Header Packet Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-17.3-3">The short header can be used after the version and 1-RTT keys are negotiated.
+Packets that use the short header contain the following fields:<a href="#section-17.3-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-17.3-4">
+          <dt id="section-17.3-4.1">Header Form:</dt>
+<dd id="section-17.3-4.2">
+  The most significant bit (0x80) of byte 0 is set to 0 for the short header.<a href="#section-17.3-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.3-4.3">Fixed Bit:</dt>
+<dd id="section-17.3-4.4">
+  The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value
+for this bit are not valid packets in this version and MUST be discarded.<a href="#section-17.3-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.3-4.5">Spin Bit:</dt>
+<dd id="section-17.3-4.6">
+  The third most significant bit (0x20) of byte 0 is the latency spin bit, set
+as described in <a href="#spin-bit" class="xref">Section 17.3.1</a>.<a href="#section-17.3-4.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.3-4.7">Reserved Bits:</dt>
+<dd id="section-17.3-4.8">
+  The next two bits (those with a mask of 0x18) of byte 0 are reserved.  These
+bits are protected using header protection; see Section 5.4 of
+<span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.  The value included prior to protection MUST be set to 0.  An
+endpoint MUST treat receipt of a packet that has a non-zero value for these
+bits, after removing both packet and header protection, as a connection error
+of type PROTOCOL_VIOLATION. Discarding such a packet after only removing
+header protection can expose the endpoint to attacks; see Section 9.3 of
+<span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-17.3-4.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.3-4.9">Key Phase:</dt>
+<dd id="section-17.3-4.10">
+  The next bit (0x04) of byte 0 indicates the key phase, which allows a
+recipient of a packet to identify the packet protection keys that are used to
+protect the packet.  See <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span> for details.  This bit is protected
+using header protection; see Section 5.4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-17.3-4.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.3-4.11">Packet Number Length:</dt>
+<dd id="section-17.3-4.12">
+  The least significant two bits (those with a mask of 0x03) of byte 0 contain
+the length of the packet number, encoded as an unsigned, two-bit integer that
+is one less than the length of the packet number field in bytes.  That is, the
+length of the packet number field is the value of this field, plus one.  These
+bits are protected using header protection; see Section 5.4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-17.3-4.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.3-4.13">Destination Connection ID:</dt>
+<dd id="section-17.3-4.14">
+  The Destination Connection ID is a connection ID that is chosen by the
+intended recipient of the packet.  See <a href="#connection-id" class="xref">Section 5.1</a> for more details.<a href="#section-17.3-4.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.3-4.15">Packet Number:</dt>
+<dd id="section-17.3-4.16">
+  The packet number field is 1 to 4 bytes long. The packet number has
+confidentiality protection separate from packet protection, as described in
+Section 5.4 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>. The length of the packet number field is encoded
+in Packet Number Length field. See <a href="#packet-encoding" class="xref">Section 17.1</a> for details.<a href="#section-17.3-4.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-17.3-4.17">Packet Payload:</dt>
+<dd id="section-17.3-4.18">
+  Packets with a short header always include a 1-RTT protected payload.<a href="#section-17.3-4.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-17.3-5">The header form bit and the connection ID field of a short header packet are
+version-independent.  The remaining fields are specific to the selected QUIC
+version.  See <span>[<a href="#QUIC-INVARIANTS" class="xref">QUIC-INVARIANTS</a>]</span> for details on how packets from different
+versions of QUIC are interpreted.<a href="#section-17.3-5" class="pilcrow">¶</a></p>
+<div id="spin-bit">
+<section id="section-17.3.1">
+          <h4 id="name-latency-spin-bit">
+<a href="#section-17.3.1" class="section-number selfRef">17.3.1. </a><a href="#name-latency-spin-bit" class="section-name selfRef">Latency Spin Bit</a>
+          </h4>
+<p id="section-17.3.1-1">The latency spin bit enables passive latency monitoring from observation points
+on the network path throughout the duration of a connection. The spin bit is
+only present in the short packet header, since it is possible to measure the
+initial RTT of a connection by observing the handshake. Therefore, the spin bit
+is available after version negotiation and connection establishment are
+completed. On-path measurement and use of the latency spin bit is further
+discussed in <span>[<a href="#QUIC-MANAGEABILITY" class="xref">QUIC-MANAGEABILITY</a>]</span>.<a href="#section-17.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-17.3.1-2">The spin bit is an OPTIONAL feature of QUIC. A QUIC stack that chooses to
+support the spin bit MUST implement it as specified in this section.<a href="#section-17.3.1-2" class="pilcrow">¶</a></p>
+<p id="section-17.3.1-3">Each endpoint unilaterally decides if the spin bit is enabled or disabled for a
+connection. Implementations MUST allow administrators of clients and servers
+to disable the spin bit either globally or on a per-connection basis. Even when
+the spin bit is not disabled by the administrator, endpoints MUST disable their
+use of the spin bit for a random selection of at least one in every 16 network
+paths, or for one in every 16 connection IDs.  As each endpoint disables the
+spin bit independently, this ensures that the spin bit signal is disabled on
+approximately one in eight network paths.<a href="#section-17.3.1-3" class="pilcrow">¶</a></p>
+<p id="section-17.3.1-4">When the spin bit is disabled, endpoints MAY set the spin bit to any value, and
+MUST ignore any incoming value. It is RECOMMENDED that endpoints set the spin
+bit to a random value either chosen independently for each packet or chosen
+independently for each connection ID.<a href="#section-17.3.1-4" class="pilcrow">¶</a></p>
+<p id="section-17.3.1-5">If the spin bit is enabled for the connection, the endpoint maintains a spin
+value and sets the spin bit in the short header to the currently stored
+value when a packet with a short header is sent out. The spin value is
+initialized to 0 in the endpoint at connection start.  Each endpoint also
+remembers the highest packet number seen from its peer on the connection.<a href="#section-17.3.1-5" class="pilcrow">¶</a></p>
+<p id="section-17.3.1-6">When a server receives a short header packet that increments the highest
+packet number seen by the server from the client, it sets the spin value to be
+equal to the spin bit in the received packet.<a href="#section-17.3.1-6" class="pilcrow">¶</a></p>
+<p id="section-17.3.1-7">When a client receives a short header packet that increments the highest
+packet number seen by the client from the server, it sets the spin value to the
+inverse of the spin bit in the received packet.<a href="#section-17.3.1-7" class="pilcrow">¶</a></p>
+<p id="section-17.3.1-8">An endpoint resets its spin value to zero when sending the first packet of a
+given connection with a new connection ID. This reduces the risk that transient
+spin bit state can be used to link flows across connection migration or ID
+change.<a href="#section-17.3.1-8" class="pilcrow">¶</a></p>
+<p id="section-17.3.1-9">With this mechanism, the server reflects the spin value received, while the
+client 'spins' it after one RTT. On-path observers can measure the time
+between two spin bit toggle events to estimate the end-to-end RTT of a
+connection.<a href="#section-17.3.1-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="transport-parameter-encoding">
+<section id="section-18">
+      <h2 id="name-transport-parameter-encodin">
+<a href="#section-18" class="section-number selfRef">18. </a><a href="#name-transport-parameter-encodin" class="section-name selfRef">Transport Parameter Encoding</a>
+      </h2>
+<p id="section-18-1">The extension_data field of the quic_transport_parameters extension defined in
+<span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span> contains the QUIC transport parameters. They are encoded as a
+sequence of transport parameters, as shown in <a href="#transport-parameter-sequence" class="xref">Figure 19</a>:<a href="#section-18-1" class="pilcrow">¶</a></p>
+<span id="name-sequence-of-transport-param"></span><div id="transport-parameter-sequence">
+<figure id="figure-19">
+        <div class="artwork art-text alignLeft" id="section-18-2.1">
+<pre>
+Transport Parameters {
+  Transport Parameter (..) ...,
+}
+</pre>
+</div>
+<figcaption><a href="#figure-19" class="selfRef">Figure 19</a>:
+<a href="#name-sequence-of-transport-param" class="selfRef">Sequence of Transport Parameters</a>
+        </figcaption></figure>
+</div>
+<p id="section-18-3">Each transport parameter is encoded as an (identifier, length, value) tuple,
+as shown in <a href="#transport-parameter-encoding-fig" class="xref">Figure 20</a>:<a href="#section-18-3" class="pilcrow">¶</a></p>
+<span id="name-transport-parameter-encoding"></span><div id="transport-parameter-encoding-fig">
+<figure id="figure-20">
+        <div class="artwork art-text alignLeft" id="section-18-4.1">
+<pre>
+Transport Parameter {
+  Transport Parameter ID (i),
+  Transport Parameter Length (i),
+  Transport Parameter Value (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-20" class="selfRef">Figure 20</a>:
+<a href="#name-transport-parameter-encoding" class="selfRef">Transport Parameter Encoding</a>
+        </figcaption></figure>
+</div>
+<p id="section-18-5">The Transport Parameter Length field contains the length of the Transport
+Parameter Value field.<a href="#section-18-5" class="pilcrow">¶</a></p>
+<p id="section-18-6">QUIC encodes transport parameters into a sequence of bytes, which are then
+included in the cryptographic handshake.<a href="#section-18-6" class="pilcrow">¶</a></p>
+<div id="transport-parameter-grease">
+<section id="section-18.1">
+        <h3 id="name-reserved-transport-paramete">
+<a href="#section-18.1" class="section-number selfRef">18.1. </a><a href="#name-reserved-transport-paramete" class="section-name selfRef">Reserved Transport Parameters</a>
+        </h3>
+<p id="section-18.1-1">Transport parameters with an identifier of the form <code>31 * N + 27</code> for integer
+values of N are reserved to exercise the requirement that unknown transport
+parameters be ignored.  These transport parameters have no semantics, and may
+carry arbitrary values.<a href="#section-18.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="transport-parameter-definitions">
+<section id="section-18.2">
+        <h3 id="name-transport-parameter-definit">
+<a href="#section-18.2" class="section-number selfRef">18.2. </a><a href="#name-transport-parameter-definit" class="section-name selfRef">Transport Parameter Definitions</a>
+        </h3>
+<p id="section-18.2-1">This section details the transport parameters defined in this document.<a href="#section-18.2-1" class="pilcrow">¶</a></p>
+<p id="section-18.2-2">Many transport parameters listed here have integer values.  Those transport
+parameters that are identified as integers use a variable-length integer
+encoding; see <a href="#integer-encoding" class="xref">Section 16</a>.  Transport parameters have a default value
+of 0 if the transport parameter is absent unless otherwise stated.<a href="#section-18.2-2" class="pilcrow">¶</a></p>
+<p id="section-18.2-3">The following transport parameters are defined:<a href="#section-18.2-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-18.2-4">
+          <dt id="section-18.2-4.1">original_destination_connection_id (0x00):</dt>
+<dd id="section-18.2-4.2">
+  The value of the Destination Connection ID field from the first Initial packet
+sent by the client; see <a href="#cid-auth" class="xref">Section 7.3</a>.  This transport parameter is only sent
+by a server.<a href="#section-18.2-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.3">max_idle_timeout (0x01):</dt>
+<dd id="section-18.2-4.4">
+  The max idle timeout is a value in milliseconds that is encoded as an integer;
+see (<a href="#idle-timeout" class="xref">Section 10.2</a>).  Idle timeout is disabled when both endpoints omit
+this transport parameter or specify a value of 0.<a href="#section-18.2-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.5">stateless_reset_token (0x02):</dt>
+<dd id="section-18.2-4.6">
+  A stateless reset token is used in verifying a stateless reset; see
+<a href="#stateless-reset" class="xref">Section 10.4</a>.  This parameter is a sequence of 16 bytes.  This
+transport parameter MUST NOT be sent by a client, but MAY be sent by a server.
+A server that does not send this transport parameter cannot use stateless
+reset (<a href="#stateless-reset" class="xref">Section 10.4</a>) for the connection ID negotiated during the
+handshake.<a href="#section-18.2-4.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.7">max_udp_payload_size (0x03):</dt>
+<dd id="section-18.2-4.8">
+  The maximum UDP payload size parameter is an integer value that limits the
+size of UDP payloads that the endpoint is willing to receive.  UDP packets
+with payloads larger than this limit are not likely to be processed by the
+receiver.<a href="#section-18.2-4.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.9"></dt>
+<dd id="section-18.2-4.10">The default for this parameter is the maximum permitted UDP payload of 65527.
+Values below 1200 are invalid.<a href="#section-18.2-4.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.11"></dt>
+<dd id="section-18.2-4.12">This limit does act as an additional constraint on datagram size in the same
+way as the path MTU, but it is a property of the endpoint and not the path. It
+is expected that this is the space an endpoint dedicates to holding incoming
+packets.<a href="#section-18.2-4.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.13">initial_max_data (0x04):</dt>
+<dd id="section-18.2-4.14">
+  The initial maximum data parameter is an integer value that contains the
+initial value for the maximum amount of data that can be sent on the
+connection.  This is equivalent to sending a MAX_DATA (<a href="#frame-max-data" class="xref">Section 19.9</a>) for
+the connection immediately after completing the handshake.<a href="#section-18.2-4.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.15">initial_max_stream_data_bidi_local (0x05):</dt>
+<dd id="section-18.2-4.16">
+  This parameter is an integer value specifying the initial flow control limit
+for locally-initiated bidirectional streams.  This limit applies to newly
+created bidirectional streams opened by the endpoint that sends the transport
+parameter.  In client transport parameters, this applies to streams with an
+identifier with the least significant two bits set to 0x0; in server transport
+parameters, this applies to streams with the least significant two bits set to
+0x1.<a href="#section-18.2-4.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.17">initial_max_stream_data_bidi_remote (0x06):</dt>
+<dd id="section-18.2-4.18">
+  This parameter is an integer value specifying the initial flow control limit
+for peer-initiated bidirectional streams.  This limit applies to newly created
+bidirectional streams opened by the endpoint that receives the transport
+parameter.  In client transport parameters, this applies to streams with an
+identifier with the least significant two bits set to 0x1; in server transport
+parameters, this applies to streams with the least significant two bits set to
+0x0.<a href="#section-18.2-4.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.19">initial_max_stream_data_uni (0x07):</dt>
+<dd id="section-18.2-4.20">
+  This parameter is an integer value specifying the initial flow control limit
+for unidirectional streams.  This limit applies to newly created
+unidirectional streams opened by the endpoint that receives the transport
+parameter.  In client transport parameters, this applies to streams with an
+identifier with the least significant two bits set to 0x3; in server transport
+parameters, this applies to streams with the least significant two bits set to
+0x2.<a href="#section-18.2-4.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.21">initial_max_streams_bidi (0x08):</dt>
+<dd id="section-18.2-4.22">
+  The initial maximum bidirectional streams parameter is an integer value that
+contains the initial maximum number of bidirectional streams the peer may
+initiate.  If this parameter is absent or zero, the peer cannot open
+bidirectional streams until a MAX_STREAMS frame is sent.  Setting this
+parameter is equivalent to sending a MAX_STREAMS (<a href="#frame-max-streams" class="xref">Section 19.11</a>) of
+the corresponding type with the same value.<a href="#section-18.2-4.22" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.23">initial_max_streams_uni (0x09):</dt>
+<dd id="section-18.2-4.24">
+  The initial maximum unidirectional streams parameter is an integer value that
+contains the initial maximum number of unidirectional streams the peer may
+initiate.  If this parameter is absent or zero, the peer cannot open
+unidirectional streams until a MAX_STREAMS frame is sent.  Setting this
+parameter is equivalent to sending a MAX_STREAMS (<a href="#frame-max-streams" class="xref">Section 19.11</a>) of
+the corresponding type with the same value.<a href="#section-18.2-4.24" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.25">ack_delay_exponent (0x0a):</dt>
+<dd id="section-18.2-4.26">
+  The ACK delay exponent is an integer value indicating an
+exponent used to decode the ACK Delay field in the ACK frame (<a href="#frame-ack" class="xref">Section 19.3</a>).
+If this value is absent, a default value of 3 is assumed (indicating a
+multiplier of 8). Values above 20 are invalid.<a href="#section-18.2-4.26" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.27">max_ack_delay (0x0b):</dt>
+<dd id="section-18.2-4.28">
+  The maximum ACK delay is an integer value indicating the
+maximum amount of time in milliseconds by which the endpoint will delay
+sending acknowledgments.  This value SHOULD include the receiver's expected
+delays in alarms firing.  For example, if a receiver sets a timer for 5ms
+and alarms commonly fire up to 1ms late, then it should send a max_ack_delay
+of 6ms.  If this value is absent, a default of 25 milliseconds is assumed.
+Values of 2^14 or greater are invalid.<a href="#section-18.2-4.28" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.29">disable_active_migration (0x0c):</dt>
+<dd id="section-18.2-4.30">
+  The disable active migration transport parameter is included if the endpoint
+does not support active connection migration (<a href="#migration" class="xref">Section 9</a>). Peers of an
+endpoint that sets this transport parameter MUST NOT send any packets,
+including probing packets (<a href="#probing" class="xref">Section 9.1</a>), from a local address or port other
+than that used to perform the handshake.  This parameter is a zero-length
+value.<a href="#section-18.2-4.30" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.31">preferred_address (0x0d):</dt>
+<dd id="section-18.2-4.32">
+  The server's preferred address is used to effect a change in server address at
+the end of the handshake, as described in <a href="#preferred-address" class="xref">Section 9.6</a>.  The format
+of this transport parameter is shown in <a href="#fig-preferred-address" class="xref">Figure 21</a>.  This
+transport parameter is only sent by a server. Servers MAY choose to only send
+a preferred address of one address family by sending an all-zero address and
+port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
+network byte order.<a href="#section-18.2-4.32" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.33"></dt>
+<dd id="section-18.2-4.34">The Connection ID field and the Stateless Reset Token field contain an
+alternative connection ID that has a sequence number of 1; see <a href="#issue-cid" class="xref">Section 5.1.1</a>.
+Having these values bundled with the preferred address ensures that there will
+be at least one unused active connection ID when the client initiates
+migration to the preferred address.<a href="#section-18.2-4.34" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-4.35"></dt>
+<dd id="section-18.2-4.36">The Connection ID and Stateless Reset Token fields of a preferred address are
+identical in syntax and semantics to the corresponding fields of a
+NEW_CONNECTION_ID frame (<a href="#frame-new-connection-id" class="xref">Section 19.15</a>).  A server that chooses
+a zero-length connection ID MUST NOT provide a preferred address.  Similarly,
+a server MUST NOT include a zero-length connection ID in this transport
+parameter.  A client MUST treat violation of these requirements as a
+connection error of type TRANSPORT_PARAMETER_ERROR.<a href="#section-18.2-4.36" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<span id="name-preferred-address-format"></span><div id="fig-preferred-address">
+<figure id="figure-21">
+          <div class="artwork art-text alignLeft" id="section-18.2-5.1">
+<pre>
+Preferred Address {
+  IPv4 Address (32),
+  IPv4 Port (16),
+  IPv6 Address (128),
+  IPv6 Port (16),
+  CID Length (8),
+  Connection ID (..),
+  Stateless Reset Token (128),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-21" class="selfRef">Figure 21</a>:
+<a href="#name-preferred-address-format" class="selfRef">Preferred Address format</a>
+          </figcaption></figure>
+</div>
+<dl class="dlParallel" id="section-18.2-6">
+          <dt id="section-18.2-6.1">active_connection_id_limit (0x0e):</dt>
+<dd id="section-18.2-6.2">
+  The active connection ID limit is an integer value specifying the
+maximum number of connection IDs from the peer that an endpoint is willing
+to store. This value includes the connection ID received during the handshake,
+that received in the preferred_address transport parameter, and those received
+in NEW_CONNECTION_ID frames.
+The value of the active_connection_id_limit parameter MUST be at least 2.
+An endpoint that receives a value less than 2 MUST close the connection
+with an error of type TRANSPORT_PARAMETER_ERROR.
+If this transport parameter is absent, a default of 2 is assumed.  If an
+endpoint issues a zero-length connection ID, it will never send a
+NEW_CONNECTION_ID frame and therefore ignores the active_connection_id_limit
+value received from its peer.<a href="#section-18.2-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-6.3">initial_source_connection_id (0x0f):</dt>
+<dd id="section-18.2-6.4">
+  The value that the endpoint included in the Source Connection ID field of the
+first Initial packet it sends for the connection; see <a href="#cid-auth" class="xref">Section 7.3</a>.<a href="#section-18.2-6.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-18.2-6.5">retry_source_connection_id (0x10):</dt>
+<dd id="section-18.2-6.6">
+  The value that the server included in the Source Connection ID field of a
+Retry packet; see <a href="#cid-auth" class="xref">Section 7.3</a>.  This transport parameter is only sent by a
+server.<a href="#section-18.2-6.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-18.2-7">If present, transport parameters that set initial flow control limits
+(initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote, and
+initial_max_stream_data_uni) are equivalent to sending a MAX_STREAM_DATA frame
+(<a href="#frame-max-stream-data" class="xref">Section 19.10</a>) on every stream of the corresponding type
+immediately after opening.  If the transport parameter is absent, streams of
+that type start with a flow control limit of 0.<a href="#section-18.2-7" class="pilcrow">¶</a></p>
+<p id="section-18.2-8">A client MUST NOT include any server-only transport parameter:
+original_destination_connection_id, preferred_address,
+retry_source_connection_id, or stateless_reset_token. A server MUST treat
+receipt of any of these transport parameters as a connection error of type
+TRANSPORT_PARAMETER_ERROR.<a href="#section-18.2-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="frame-formats">
+<section id="section-19">
+      <h2 id="name-frame-types-and-formats">
+<a href="#section-19" class="section-number selfRef">19. </a><a href="#name-frame-types-and-formats" class="section-name selfRef">Frame Types and Formats</a>
+      </h2>
+<p id="section-19-1">As described in <a href="#frames" class="xref">Section 12.4</a>, packets contain one or more frames. This section
+describes the format and semantics of the core QUIC frame types.<a href="#section-19-1" class="pilcrow">¶</a></p>
+<div id="frame-padding">
+<section id="section-19.1">
+        <h3 id="name-padding-frame">
+<a href="#section-19.1" class="section-number selfRef">19.1. </a><a href="#name-padding-frame" class="section-name selfRef">PADDING Frame</a>
+        </h3>
+<p id="section-19.1-1">The PADDING frame (type=0x00) has no semantic value.  PADDING frames can be used
+to increase the size of a packet.  Padding can be used to increase an initial
+client packet to the minimum required size, or to provide protection against
+traffic analysis for protected packets.<a href="#section-19.1-1" class="pilcrow">¶</a></p>
+<p id="section-19.1-2">A PADDING frame has no content.  That is, a PADDING frame consists of the single
+byte that identifies the frame as a PADDING frame.<a href="#section-19.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-ping">
+<section id="section-19.2">
+        <h3 id="name-ping-frame">
+<a href="#section-19.2" class="section-number selfRef">19.2. </a><a href="#name-ping-frame" class="section-name selfRef">PING Frame</a>
+        </h3>
+<p id="section-19.2-1">Endpoints can use PING frames (type=0x01) to verify that their peers are still
+alive or to check reachability to the peer. The PING frame contains no
+additional fields.<a href="#section-19.2-1" class="pilcrow">¶</a></p>
+<p id="section-19.2-2">The receiver of a PING frame simply needs to acknowledge the packet containing
+this frame.<a href="#section-19.2-2" class="pilcrow">¶</a></p>
+<p id="section-19.2-3">The PING frame can be used to keep a connection alive when an application or
+application protocol wishes to prevent the connection from timing out. An
+application protocol SHOULD provide guidance about the conditions under which
+generating a PING is recommended.  This guidance SHOULD indicate whether it is
+the client or the server that is expected to send the PING.  Having both
+endpoints send PING frames without coordination can produce an excessive number
+of packets and poor performance.<a href="#section-19.2-3" class="pilcrow">¶</a></p>
+<p id="section-19.2-4">A connection will time out if no packets are sent or received for a period
+longer than the time negotiated using the max_idle_timeout transport parameter;
+see <a href="#termination" class="xref">Section 10</a>.  However, state in middleboxes might time out earlier than
+that.  Though REQ-5 in <span>[<a href="#RFC4787" class="xref">RFC4787</a>]</span> recommends a 2 minute timeout interval,
+experience shows that sending packets every 15 to 30 seconds is necessary to
+prevent the majority of middleboxes from losing state for UDP flows.<a href="#section-19.2-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-ack">
+<section id="section-19.3">
+        <h3 id="name-ack-frames">
+<a href="#section-19.3" class="section-number selfRef">19.3. </a><a href="#name-ack-frames" class="section-name selfRef">ACK Frames</a>
+        </h3>
+<p id="section-19.3-1">Receivers send ACK frames (types 0x02 and 0x03) to inform senders of packets
+they have received and processed. The ACK frame contains one or more ACK Ranges.
+ACK Ranges identify acknowledged packets. If the frame type is 0x03, ACK frames
+also contain the sum of QUIC packets with associated ECN marks received on the
+connection up until this point.  QUIC implementations MUST properly handle both
+types and, if they have enabled ECN for packets they send, they SHOULD use the
+information in the ECN section to manage their congestion state.<a href="#section-19.3-1" class="pilcrow">¶</a></p>
+<p id="section-19.3-2">QUIC acknowledgements are irrevocable.  Once acknowledged, a packet remains
+acknowledged, even if it does not appear in a future ACK frame.  This is unlike
+TCP SACKs (<span>[<a href="#RFC2018" class="xref">RFC2018</a>]</span>).<a href="#section-19.3-2" class="pilcrow">¶</a></p>
+<p id="section-19.3-3">Packets from different packet number spaces can be identified using the same
+numeric value. An acknowledgment for a packet needs to indicate both a packet
+number and a packet number space. This is accomplished by having each ACK frame
+only acknowledge packet numbers in the same space as the packet in which the
+ACK frame is contained.<a href="#section-19.3-3" class="pilcrow">¶</a></p>
+<p id="section-19.3-4">Version Negotiation and Retry packets cannot be acknowledged because they do not
+contain a packet number.  Rather than relying on ACK frames, these packets are
+implicitly acknowledged by the next Initial packet sent by the client.<a href="#section-19.3-4" class="pilcrow">¶</a></p>
+<p id="section-19.3-5">An ACK frame is shown in <a href="#ack-format" class="xref">Figure 22</a>.<a href="#section-19.3-5" class="pilcrow">¶</a></p>
+<span id="name-ack-frame-format"></span><div id="ack-format">
+<figure id="figure-22">
+          <div class="artwork art-text alignLeft" id="section-19.3-6.1">
+<pre>
+ACK Frame {
+  Type (i) = 0x02..0x03,
+  Largest Acknowledged (i),
+  ACK Delay (i),
+  ACK Range Count (i),
+  First ACK Range (i),
+  ACK Range (..) ...,
+  [ECN Counts (..)],
+}
+</pre>
+</div>
+<figcaption><a href="#figure-22" class="selfRef">Figure 22</a>:
+<a href="#name-ack-frame-format" class="selfRef">ACK Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.3-7">ACK frames contain the following fields:<a href="#section-19.3-7" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.3-8">
+          <dt id="section-19.3-8.1">Largest Acknowledged:</dt>
+<dd id="section-19.3-8.2">
+  A variable-length integer representing the largest packet number the peer is
+acknowledging; this is usually the largest packet number that the peer has
+received prior to generating the ACK frame.  Unlike the packet number in the
+QUIC long or short header, the value in an ACK frame is not truncated.<a href="#section-19.3-8.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.3-8.3">ACK Delay:</dt>
+<dd id="section-19.3-8.4">
+  A variable-length integer representing the time delta in microseconds between
+when this ACK was sent and when the largest acknowledged packet, as indicated
+in the Largest Acknowledged field, was received by this peer.  The value of
+the ACK Delay field is scaled by multiplying the encoded value by 2 to the
+power of the value of the ack_delay_exponent transport parameter set by the
+sender of the ACK frame; see <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>.  Scaling in
+this fashion allows for a larger range of values with a shorter encoding at
+the cost of lower resolution.  Because the receiver doesn't use the ACK Delay
+for Initial and Handshake packets, a sender SHOULD send a value of 0.<a href="#section-19.3-8.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.3-8.5">ACK Range Count:</dt>
+<dd id="section-19.3-8.6">
+  A variable-length integer specifying the number of Gap and ACK Range fields in
+the frame.<a href="#section-19.3-8.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.3-8.7">First ACK Range:</dt>
+<dd id="section-19.3-8.8">
+  A variable-length integer indicating the number of contiguous packets
+preceding the Largest Acknowledged that are being acknowledged.  The First ACK
+Range is encoded as an ACK Range; see <a href="#ack-ranges" class="xref">Section 19.3.1</a> starting from the
+Largest Acknowledged.  That is, the smallest packet acknowledged in the
+range is determined by subtracting the First ACK Range value from the Largest
+Acknowledged.<a href="#section-19.3-8.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.3-8.9">ACK Ranges:</dt>
+<dd id="section-19.3-8.10">
+  Contains additional ranges of packets which are alternately not
+acknowledged (Gap) and acknowledged (ACK Range); see <a href="#ack-ranges" class="xref">Section 19.3.1</a>.<a href="#section-19.3-8.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.3-8.11">ECN Counts:</dt>
+<dd id="section-19.3-8.12">
+  The three ECN Counts; see <a href="#ack-ecn-counts" class="xref">Section 19.3.2</a>.<a href="#section-19.3-8.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<div id="ack-ranges">
+<section id="section-19.3.1">
+          <h4 id="name-ack-ranges">
+<a href="#section-19.3.1" class="section-number selfRef">19.3.1. </a><a href="#name-ack-ranges" class="section-name selfRef">ACK Ranges</a>
+          </h4>
+<p id="section-19.3.1-1">Each ACK Range consists of alternating Gap and ACK Range values in descending
+packet number order. ACK Ranges can be repeated. The number of Gap and ACK
+Range values is determined by the ACK Range Count field; one of each value is
+present for each value in the ACK Range Count field.<a href="#section-19.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-19.3.1-2">ACK Ranges are structured as shown in <a href="#ack-range-format" class="xref">Figure 23</a>.<a href="#section-19.3.1-2" class="pilcrow">¶</a></p>
+<span id="name-ack-ranges-2"></span><div id="ack-range-format">
+<figure id="figure-23">
+            <div class="artwork art-text alignLeft" id="section-19.3.1-3.1">
+<pre>
+ACK Range {
+  Gap (i),
+  ACK Range Length (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-23" class="selfRef">Figure 23</a>:
+<a href="#name-ack-ranges-2" class="selfRef">ACK Ranges</a>
+            </figcaption></figure>
+</div>
+<p id="section-19.3.1-4">The fields that form each ACK Range are:<a href="#section-19.3.1-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.3.1-5">
+            <dt id="section-19.3.1-5.1">Gap:</dt>
+<dd id="section-19.3.1-5.2">
+  A variable-length integer indicating the number of contiguous unacknowledged
+packets preceding the packet number one lower than the smallest in the
+preceding ACK Range.<a href="#section-19.3.1-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.3.1-5.3">ACK Range Length:</dt>
+<dd id="section-19.3.1-5.4">
+  A variable-length integer indicating the number of contiguous acknowledged
+packets preceding the largest packet number, as determined by the
+preceding Gap.<a href="#section-19.3.1-5.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.3.1-6">Gap and ACK Range value use a relative integer encoding for efficiency.  Though
+each encoded value is positive, the values are subtracted, so that each ACK
+Range describes progressively lower-numbered packets.<a href="#section-19.3.1-6" class="pilcrow">¶</a></p>
+<p id="section-19.3.1-7">Each ACK Range acknowledges a contiguous range of packets by indicating the
+number of acknowledged packets that precede the largest packet number in that
+range.  A value of zero indicates that only the largest packet number is
+acknowledged.  Larger ACK Range values indicate a larger range, with
+corresponding lower values for the smallest packet number in the range.  Thus,
+given a largest packet number for the range, the smallest value is determined by
+the formula:<a href="#section-19.3.1-7" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-19.3.1-8">
+<pre>
+   smallest = largest - ack_range
+</pre><a href="#section-19.3.1-8" class="pilcrow">¶</a>
+</div>
+<p id="section-19.3.1-9">An ACK Range acknowledges all packets between the smallest packet number and the
+largest, inclusive.<a href="#section-19.3.1-9" class="pilcrow">¶</a></p>
+<p id="section-19.3.1-10">The largest value for an ACK Range is determined by cumulatively subtracting the
+size of all preceding ACK Ranges and Gaps.<a href="#section-19.3.1-10" class="pilcrow">¶</a></p>
+<p id="section-19.3.1-11">Each Gap indicates a range of packets that are not being acknowledged.  The
+number of packets in the gap is one higher than the encoded value of the Gap
+field.<a href="#section-19.3.1-11" class="pilcrow">¶</a></p>
+<p id="section-19.3.1-12">The value of the Gap field establishes the largest packet number value for the
+subsequent ACK Range using the following formula:<a href="#section-19.3.1-12" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-19.3.1-13">
+<pre>
+   largest = previous_smallest - gap - 2
+</pre><a href="#section-19.3.1-13" class="pilcrow">¶</a>
+</div>
+<p id="section-19.3.1-14">If any computed packet number is negative, an endpoint MUST generate a
+connection error of type FRAME_ENCODING_ERROR.<a href="#section-19.3.1-14" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="ack-ecn-counts">
+<section id="section-19.3.2">
+          <h4 id="name-ecn-counts-2">
+<a href="#section-19.3.2" class="section-number selfRef">19.3.2. </a><a href="#name-ecn-counts-2" class="section-name selfRef">ECN Counts</a>
+          </h4>
+<p id="section-19.3.2-1">The ACK frame uses the least significant bit (that is, type 0x03) to indicate
+ECN feedback and report receipt of QUIC packets with associated ECN codepoints
+of ECT(0), ECT(1), or CE in the packet's IP header.  ECN Counts are only present
+when the ACK frame type is 0x03.<a href="#section-19.3.2-1" class="pilcrow">¶</a></p>
+<p id="section-19.3.2-2">ECN Counts are only parsed when the ACK frame type is 0x03.  There are 3 ECN
+counts, as shown in <a href="#ecn-count-format" class="xref">Figure 24</a>.<a href="#section-19.3.2-2" class="pilcrow">¶</a></p>
+<span id="name-ecn-count-format"></span><div id="ecn-count-format">
+<figure id="figure-24">
+            <div class="artwork art-text alignLeft" id="section-19.3.2-3.1">
+<pre>
+ECN Counts {
+  ECT0 Count (i),
+  ECT1 Count (i),
+  ECN-CE Count (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-24" class="selfRef">Figure 24</a>:
+<a href="#name-ecn-count-format" class="selfRef">ECN Count Format</a>
+            </figcaption></figure>
+</div>
+<p id="section-19.3.2-4">The three ECN Counts are:<a href="#section-19.3.2-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.3.2-5">
+            <dt id="section-19.3.2-5.1">ECT0 Count:</dt>
+<dd id="section-19.3.2-5.2">
+  A variable-length integer representing the total number of packets received
+with the ECT(0) codepoint in the packet number space of the ACK frame.<a href="#section-19.3.2-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.3.2-5.3">ECT1 Count:</dt>
+<dd id="section-19.3.2-5.4">
+  A variable-length integer representing the total number of packets received
+with the ECT(1) codepoint in the packet number space of the ACK frame.<a href="#section-19.3.2-5.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.3.2-5.5">CE Count:</dt>
+<dd id="section-19.3.2-5.6">
+  A variable-length integer representing the total number of packets received
+with the CE codepoint in the packet number space of the ACK frame.<a href="#section-19.3.2-5.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.3.2-6">ECN counts are maintained separately for each packet number space.<a href="#section-19.3.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="frame-reset-stream">
+<section id="section-19.4">
+        <h3 id="name-reset_stream-frame">
+<a href="#section-19.4" class="section-number selfRef">19.4. </a><a href="#name-reset_stream-frame" class="section-name selfRef">RESET_STREAM Frame</a>
+        </h3>
+<p id="section-19.4-1">An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly terminate the
+sending part of a stream.<a href="#section-19.4-1" class="pilcrow">¶</a></p>
+<p id="section-19.4-2">After sending a RESET_STREAM, an endpoint ceases transmission and retransmission
+of STREAM frames on the identified stream.  A receiver of RESET_STREAM can
+discard any data that it already received on that stream.<a href="#section-19.4-2" class="pilcrow">¶</a></p>
+<p id="section-19.4-3">An endpoint that receives a RESET_STREAM frame for a send-only stream MUST
+terminate the connection with error STREAM_STATE_ERROR.<a href="#section-19.4-3" class="pilcrow">¶</a></p>
+<p id="section-19.4-4">The RESET_STREAM frame is shown in <a href="#fig-reset-stream" class="xref">Figure 25</a>.<a href="#section-19.4-4" class="pilcrow">¶</a></p>
+<span id="name-reset_stream-frame-format"></span><div id="fig-reset-stream">
+<figure id="figure-25">
+          <div class="artwork art-text alignLeft" id="section-19.4-5.1">
+<pre>
+RESET_STREAM Frame {
+  Type (i) = 0x04,
+  Stream ID (i),
+  Application Protocol Error Code (i),
+  Final Size (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-25" class="selfRef">Figure 25</a>:
+<a href="#name-reset_stream-frame-format" class="selfRef">RESET_STREAM Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.4-6">RESET_STREAM frames contain the following fields:<a href="#section-19.4-6" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.4-7">
+          <dt id="section-19.4-7.1">Stream ID:</dt>
+<dd id="section-19.4-7.2">
+  A variable-length integer encoding of the Stream ID of the stream being
+terminated.<a href="#section-19.4-7.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.4-7.3">Application Protocol Error Code:</dt>
+<dd id="section-19.4-7.4">
+  A variable-length integer containing the application protocol error
+code (see <a href="#app-error-codes" class="xref">Section 20.1</a>) which indicates why the stream is being
+closed.<a href="#section-19.4-7.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.4-7.5">Final Size:</dt>
+<dd id="section-19.4-7.6">
+  A variable-length integer indicating the final size of the stream by the
+RESET_STREAM sender, in unit of bytes.<a href="#section-19.4-7.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="frame-stop-sending">
+<section id="section-19.5">
+        <h3 id="name-stop_sending-frame">
+<a href="#section-19.5" class="section-number selfRef">19.5. </a><a href="#name-stop_sending-frame" class="section-name selfRef">STOP_SENDING Frame</a>
+        </h3>
+<p id="section-19.5-1">An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that incoming
+data is being discarded on receipt at application request.  STOP_SENDING
+requests that a peer cease transmission on a stream.<a href="#section-19.5-1" class="pilcrow">¶</a></p>
+<p id="section-19.5-2">A STOP_SENDING frame can be sent for streams in the Recv or Size Known states;
+see <a href="#stream-send-states" class="xref">Section 3.1</a>.  Receiving a STOP_SENDING frame for a
+locally-initiated stream that has not yet been created MUST be treated as a
+connection error of type STREAM_STATE_ERROR.  An endpoint that receives a
+STOP_SENDING frame for a receive-only stream MUST terminate the connection with
+error STREAM_STATE_ERROR.<a href="#section-19.5-2" class="pilcrow">¶</a></p>
+<p id="section-19.5-3">The STOP_SENDING frame is shown in <a href="#fig-stop-sending" class="xref">Figure 26</a>.<a href="#section-19.5-3" class="pilcrow">¶</a></p>
+<span id="name-stop_sending-frame-format"></span><div id="fig-stop-sending">
+<figure id="figure-26">
+          <div class="artwork art-text alignLeft" id="section-19.5-4.1">
+<pre>
+STOP_SENDING Frame {
+  Type (i) = 0x05,
+  Stream ID (i),
+  Application Protocol Error Code (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-26" class="selfRef">Figure 26</a>:
+<a href="#name-stop_sending-frame-format" class="selfRef">STOP_SENDING Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.5-5">STOP_SENDING frames contain the following fields:<a href="#section-19.5-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.5-6">
+          <dt id="section-19.5-6.1">Stream ID:</dt>
+<dd id="section-19.5-6.2">
+  A variable-length integer carrying the Stream ID of the stream being ignored.<a href="#section-19.5-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.5-6.3">Application Protocol Error Code:</dt>
+<dd id="section-19.5-6.4">
+  A variable-length integer containing the application-specified reason the
+sender is ignoring the stream; see <a href="#app-error-codes" class="xref">Section 20.1</a>.<a href="#section-19.5-6.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="frame-crypto">
+<section id="section-19.6">
+        <h3 id="name-crypto-frame">
+<a href="#section-19.6" class="section-number selfRef">19.6. </a><a href="#name-crypto-frame" class="section-name selfRef">CRYPTO Frame</a>
+        </h3>
+<p id="section-19.6-1">The CRYPTO frame (type=0x06) is used to transmit cryptographic handshake
+messages. It can be sent in all packet types except 0-RTT. The CRYPTO frame
+offers the cryptographic protocol an in-order stream of bytes.  CRYPTO frames
+are functionally identical to STREAM frames, except that they do not bear a
+stream identifier; they are not flow controlled; and they do not carry markers
+for optional offset, optional length, and the end of the stream.<a href="#section-19.6-1" class="pilcrow">¶</a></p>
+<p id="section-19.6-2">The CRYPTO frame is shown in <a href="#fig-crypto" class="xref">Figure 27</a>.<a href="#section-19.6-2" class="pilcrow">¶</a></p>
+<span id="name-crypto-frame-format"></span><div id="fig-crypto">
+<figure id="figure-27">
+          <div class="artwork art-text alignLeft" id="section-19.6-3.1">
+<pre>
+CRYPTO Frame {
+  Type (i) = 0x06,
+  Offset (i),
+  Length (i),
+  Crypto Data (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-27" class="selfRef">Figure 27</a>:
+<a href="#name-crypto-frame-format" class="selfRef">CRYPTO Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.6-4">CRYPTO frames contain the following fields:<a href="#section-19.6-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.6-5">
+          <dt id="section-19.6-5.1">Offset:</dt>
+<dd id="section-19.6-5.2">
+  A variable-length integer specifying the byte offset in the stream for the
+data in this CRYPTO frame.<a href="#section-19.6-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.6-5.3">Length:</dt>
+<dd id="section-19.6-5.4">
+  A variable-length integer specifying the length of the Crypto Data field in
+this CRYPTO frame.<a href="#section-19.6-5.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.6-5.5">Crypto Data:</dt>
+<dd id="section-19.6-5.6">
+  The cryptographic message data.<a href="#section-19.6-5.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.6-6">There is a separate flow of cryptographic handshake data in each encryption
+level, each of which starts at an offset of 0. This implies that each encryption
+level is treated as a separate CRYPTO stream of data.<a href="#section-19.6-6" class="pilcrow">¶</a></p>
+<p id="section-19.6-7">The largest offset delivered on a stream - the sum of the offset and data
+length - cannot exceed 2^62-1.  Receipt of a frame that exceeds this limit MUST
+be treated as a connection error of type FRAME_ENCODING_ERROR or
+CRYPTO_BUFFER_EXCEEDED.<a href="#section-19.6-7" class="pilcrow">¶</a></p>
+<p id="section-19.6-8">Unlike STREAM frames, which include a Stream ID indicating to which stream the
+data belongs, the CRYPTO frame carries data for a single stream per encryption
+level. The stream does not have an explicit end, so CRYPTO frames do not have a
+FIN bit.<a href="#section-19.6-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-new-token">
+<section id="section-19.7">
+        <h3 id="name-new_token-frame">
+<a href="#section-19.7" class="section-number selfRef">19.7. </a><a href="#name-new_token-frame" class="section-name selfRef">NEW_TOKEN Frame</a>
+        </h3>
+<p id="section-19.7-1">A server sends a NEW_TOKEN frame (type=0x07) to provide the client with a token
+to send in the header of an Initial packet for a future connection.<a href="#section-19.7-1" class="pilcrow">¶</a></p>
+<p id="section-19.7-2">The NEW_TOKEN frame is shown in <a href="#fig-new-token" class="xref">Figure 28</a>.<a href="#section-19.7-2" class="pilcrow">¶</a></p>
+<span id="name-new_token-frame-format"></span><div id="fig-new-token">
+<figure id="figure-28">
+          <div class="artwork art-text alignLeft" id="section-19.7-3.1">
+<pre>
+NEW_TOKEN Frame {
+  Type (i) = 0x07,
+  Token Length (i),
+  Token (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-28" class="selfRef">Figure 28</a>:
+<a href="#name-new_token-frame-format" class="selfRef">NEW_TOKEN Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.7-4">NEW_TOKEN frames contain the following fields:<a href="#section-19.7-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.7-5">
+          <dt id="section-19.7-5.1">Token Length:</dt>
+<dd id="section-19.7-5.2">
+  A variable-length integer specifying the length of the token in bytes.<a href="#section-19.7-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.7-5.3">Token:</dt>
+<dd id="section-19.7-5.4">
+  An opaque blob that the client may use with a future Initial packet. The token
+MUST NOT be empty.  An endpoint MUST treat receipt of a NEW_TOKEN frame with
+an empty Token field as a connection error of type FRAME_ENCODING_ERROR.<a href="#section-19.7-5.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.7-6">An endpoint might receive multiple NEW_TOKEN frames that contain the same token
+value if packets containing the frame are incorrectly determined to be lost.
+Endpoints are responsible for discarding duplicate values, which might be used
+to link connection attempts; see <a href="#validate-future" class="xref">Section 8.1.3</a>.<a href="#section-19.7-6" class="pilcrow">¶</a></p>
+<p id="section-19.7-7">Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt of a
+NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION.<a href="#section-19.7-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-stream">
+<section id="section-19.8">
+        <h3 id="name-stream-frames">
+<a href="#section-19.8" class="section-number selfRef">19.8. </a><a href="#name-stream-frames" class="section-name selfRef">STREAM Frames</a>
+        </h3>
+<p id="section-19.8-1">STREAM frames implicitly create a stream and carry stream data.  The STREAM
+frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f).  The
+value of the three low-order bits of the frame type determines the fields that
+are present in the frame.<a href="#section-19.8-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-19.8-2.1">The OFF bit (0x04) in the frame type is set to indicate that there is an
+Offset field present.  When set to 1, the Offset field is present.  When set
+to 0, the Offset field is absent and the Stream Data starts at an offset of 0
+(that is, the frame contains the first bytes of the stream, or the end of a
+stream that includes no data).<a href="#section-19.8-2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-19.8-2.2">The LEN bit (0x02) in the frame type is set to indicate that there is a Length
+field present.  If this bit is set to 0, the Length field is absent and the
+Stream Data field extends to the end of the packet.  If this bit is set to 1,
+the Length field is present.<a href="#section-19.8-2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-19.8-2.3">The FIN bit (0x01) of the frame type is set only on frames that contain the
+final size of the stream.  Setting this bit indicates that the frame
+marks the end of the stream.<a href="#section-19.8-2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-19.8-3">An endpoint MUST terminate the connection with error STREAM_STATE_ERROR if it
+receives a STREAM frame for a locally-initiated stream that has not yet been
+created, or for a send-only stream.<a href="#section-19.8-3" class="pilcrow">¶</a></p>
+<p id="section-19.8-4">The STREAM frames are shown in <a href="#fig-stream" class="xref">Figure 29</a>.<a href="#section-19.8-4" class="pilcrow">¶</a></p>
+<span id="name-stream-frame-format"></span><div id="fig-stream">
+<figure id="figure-29">
+          <div class="artwork art-text alignLeft" id="section-19.8-5.1">
+<pre>
+STREAM Frame {
+  Type (i) = 0x08..0x0f,
+  Stream ID (i),
+  [Offset (i)],
+  [Length (i)],
+  Stream Data (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-29" class="selfRef">Figure 29</a>:
+<a href="#name-stream-frame-format" class="selfRef">STREAM Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.8-6">STREAM frames contain the following fields:<a href="#section-19.8-6" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.8-7">
+          <dt id="section-19.8-7.1">Stream ID:</dt>
+<dd id="section-19.8-7.2">
+  A variable-length integer indicating the stream ID of the stream; see
+<a href="#stream-id" class="xref">Section 2.1</a>.<a href="#section-19.8-7.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.8-7.3">Offset:</dt>
+<dd id="section-19.8-7.4">
+  A variable-length integer specifying the byte offset in the stream for the
+data in this STREAM frame.  This field is present when the OFF bit is set to
+1.  When the Offset field is absent, the offset is 0.<a href="#section-19.8-7.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.8-7.5">Length:</dt>
+<dd id="section-19.8-7.6">
+  A variable-length integer specifying the length of the Stream Data field in
+this STREAM frame.  This field is present when the LEN bit is set to 1.  When
+the LEN bit is set to 0, the Stream Data field consumes all the remaining
+bytes in the packet.<a href="#section-19.8-7.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.8-7.7">Stream Data:</dt>
+<dd id="section-19.8-7.8">
+  The bytes from the designated stream to be delivered.<a href="#section-19.8-7.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.8-8">When a Stream Data field has a length of 0, the offset in the STREAM frame is
+the offset of the next byte that would be sent.<a href="#section-19.8-8" class="pilcrow">¶</a></p>
+<p id="section-19.8-9">The first byte in the stream has an offset of 0.  The largest offset delivered
+on a stream - the sum of the offset and data length - cannot exceed 2^62-1, as
+it is not possible to provide flow control credit for that data.  Receipt of a
+frame that exceeds this limit MUST be treated as a connection error of type
+FRAME_ENCODING_ERROR or FLOW_CONTROL_ERROR.<a href="#section-19.8-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-max-data">
+<section id="section-19.9">
+        <h3 id="name-max_data-frame">
+<a href="#section-19.9" class="section-number selfRef">19.9. </a><a href="#name-max_data-frame" class="section-name selfRef">MAX_DATA Frame</a>
+        </h3>
+<p id="section-19.9-1">The MAX_DATA frame (type=0x10) is used in flow control to inform the peer of
+the maximum amount of data that can be sent on the connection as a whole.<a href="#section-19.9-1" class="pilcrow">¶</a></p>
+<p id="section-19.9-2">The MAX_DATA frame is shown in <a href="#fig-max-data" class="xref">Figure 30</a>.<a href="#section-19.9-2" class="pilcrow">¶</a></p>
+<span id="name-max_data-frame-format"></span><div id="fig-max-data">
+<figure id="figure-30">
+          <div class="artwork art-text alignLeft" id="section-19.9-3.1">
+<pre>
+MAX_DATA Frame {
+  Type (i) = 0x10,
+  Maximum Data (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-30" class="selfRef">Figure 30</a>:
+<a href="#name-max_data-frame-format" class="selfRef">MAX_DATA Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.9-4">MAX_DATA frames contain the following fields:<a href="#section-19.9-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.9-5">
+          <dt id="section-19.9-5.1">Maximum Data:</dt>
+<dd id="section-19.9-5.2">
+  A variable-length integer indicating the maximum amount of data that can be
+sent on the entire connection, in units of bytes.<a href="#section-19.9-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.9-6">All data sent in STREAM frames counts toward this limit.  The sum of the largest
+received offsets on all streams - including streams in terminal states - MUST
+NOT exceed the value advertised by a receiver.  An endpoint MUST terminate a
+connection with a FLOW_CONTROL_ERROR error if it receives more data than the
+maximum data value that it has sent, unless this is a result of a change in
+the initial limits; see <a href="#zerortt-parameters" class="xref">Section 7.4.1</a>.<a href="#section-19.9-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-max-stream-data">
+<section id="section-19.10">
+        <h3 id="name-max_stream_data-frame">
+<a href="#section-19.10" class="section-number selfRef">19.10. </a><a href="#name-max_stream_data-frame" class="section-name selfRef">MAX_STREAM_DATA Frame</a>
+        </h3>
+<p id="section-19.10-1">The MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform a peer
+of the maximum amount of data that can be sent on a stream.<a href="#section-19.10-1" class="pilcrow">¶</a></p>
+<p id="section-19.10-2">A MAX_STREAM_DATA frame can be sent for streams in the Recv state; see
+<a href="#stream-send-states" class="xref">Section 3.1</a>. Receiving a MAX_STREAM_DATA frame for a
+locally-initiated stream that has not yet been created MUST be treated as a
+connection error of type STREAM_STATE_ERROR.  An endpoint that receives a
+MAX_STREAM_DATA frame for a receive-only stream MUST terminate the connection
+with error STREAM_STATE_ERROR.<a href="#section-19.10-2" class="pilcrow">¶</a></p>
+<p id="section-19.10-3">The MAX_STREAM_DATA frame is shown in <a href="#fig-max-stream-data" class="xref">Figure 31</a>.<a href="#section-19.10-3" class="pilcrow">¶</a></p>
+<span id="name-max_stream_data-frame-forma"></span><div id="fig-max-stream-data">
+<figure id="figure-31">
+          <div class="artwork art-text alignLeft" id="section-19.10-4.1">
+<pre>
+MAX_STREAM_DATA Frame {
+  Type (i) = 0x11,
+  Stream ID (i),
+  Maximum Stream Data (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-31" class="selfRef">Figure 31</a>:
+<a href="#name-max_stream_data-frame-forma" class="selfRef">MAX_STREAM_DATA Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.10-5">MAX_STREAM_DATA frames contain the following fields:<a href="#section-19.10-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.10-6">
+          <dt id="section-19.10-6.1">Stream ID:</dt>
+<dd id="section-19.10-6.2">
+  The stream ID of the stream that is affected encoded as a variable-length
+integer.<a href="#section-19.10-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.10-6.3">Maximum Stream Data:</dt>
+<dd id="section-19.10-6.4">
+  A variable-length integer indicating the maximum amount of data that can be
+sent on the identified stream, in units of bytes.<a href="#section-19.10-6.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.10-7">When counting data toward this limit, an endpoint accounts for the largest
+received offset of data that is sent or received on the stream.  Loss or
+reordering can mean that the largest received offset on a stream can be greater
+than the total size of data received on that stream.  Receiving STREAM frames
+might not increase the largest received offset.<a href="#section-19.10-7" class="pilcrow">¶</a></p>
+<p id="section-19.10-8">The data sent on a stream MUST NOT exceed the largest maximum stream data value
+advertised by the receiver.  An endpoint MUST terminate a connection with a
+FLOW_CONTROL_ERROR error if it receives more data than the largest maximum
+stream data that it has sent for the affected stream, unless this is a result of
+a change in the initial limits; see <a href="#zerortt-parameters" class="xref">Section 7.4.1</a>.<a href="#section-19.10-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-max-streams">
+<section id="section-19.11">
+        <h3 id="name-max_streams-frames">
+<a href="#section-19.11" class="section-number selfRef">19.11. </a><a href="#name-max_streams-frames" class="section-name selfRef">MAX_STREAMS Frames</a>
+        </h3>
+<p id="section-19.11-1">The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the cumulative
+number of streams of a given type it is permitted to open.  A MAX_STREAMS frame
+with a type of 0x12 applies to bidirectional streams, and a MAX_STREAMS frame
+with a type of 0x13 applies to unidirectional streams.<a href="#section-19.11-1" class="pilcrow">¶</a></p>
+<p id="section-19.11-2">The MAX_STREAMS frames are shown in <a href="#fig-max-streams" class="xref">Figure 32</a>;<a href="#section-19.11-2" class="pilcrow">¶</a></p>
+<span id="name-max_streams-frame-format"></span><div id="fig-max-streams">
+<figure id="figure-32">
+          <div class="artwork art-text alignLeft" id="section-19.11-3.1">
+<pre>
+MAX_STREAMS Frame {
+  Type (i) = 0x12..0x13,
+  Maximum Streams (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-32" class="selfRef">Figure 32</a>:
+<a href="#name-max_streams-frame-format" class="selfRef">MAX_STREAMS Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.11-4">MAX_STREAMS frames contain the following fields:<a href="#section-19.11-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.11-5">
+          <dt id="section-19.11-5.1">Maximum Streams:</dt>
+<dd id="section-19.11-5.2">
+  A count of the cumulative number of streams of the corresponding type that
+can be opened over the lifetime of the connection.  This value cannot exceed
+2^60, as it is not possible to encode stream IDs larger than 2^62-1.
+Receipt of a frame that permits opening of a stream larger than this limit
+MUST be treated as a FRAME_ENCODING_ERROR.<a href="#section-19.11-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.11-6">Loss or reordering can cause a MAX_STREAMS frame to be received which states a
+lower stream limit than an endpoint has previously received.  MAX_STREAMS frames
+which do not increase the stream limit MUST be ignored.<a href="#section-19.11-6" class="pilcrow">¶</a></p>
+<p id="section-19.11-7">An endpoint MUST NOT open more streams than permitted by the current stream
+limit set by its peer.  For instance, a server that receives a unidirectional
+stream limit of 3 is permitted to open stream 3, 7, and 11, but not stream 15.
+An endpoint MUST terminate a connection with a STREAM_LIMIT_ERROR error if a
+peer opens more streams than was permitted.<a href="#section-19.11-7" class="pilcrow">¶</a></p>
+<p id="section-19.11-8">Note that these frames (and the corresponding transport parameters) do not
+describe the number of streams that can be opened concurrently.  The limit
+includes streams that have been closed as well as those that are open.<a href="#section-19.11-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-data-blocked">
+<section id="section-19.12">
+        <h3 id="name-data_blocked-frame">
+<a href="#section-19.12" class="section-number selfRef">19.12. </a><a href="#name-data_blocked-frame" class="section-name selfRef">DATA_BLOCKED Frame</a>
+        </h3>
+<p id="section-19.12-1">A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes to send
+data, but is unable to due to connection-level flow control; see
+<a href="#flow-control" class="xref">Section 4</a>.  DATA_BLOCKED frames can be used as input to tuning of flow
+control algorithms; see <a href="#fc-credit" class="xref">Section 4.2</a>.<a href="#section-19.12-1" class="pilcrow">¶</a></p>
+<p id="section-19.12-2">The DATA_BLOCKED frame is shown in <a href="#fig-data-blocked" class="xref">Figure 33</a>.<a href="#section-19.12-2" class="pilcrow">¶</a></p>
+<span id="name-data_blocked-frame-format"></span><div id="fig-data-blocked">
+<figure id="figure-33">
+          <div class="artwork art-text alignLeft" id="section-19.12-3.1">
+<pre>
+DATA_BLOCKED Frame {
+  Type (i) = 0x14,
+  Maximum Data (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-33" class="selfRef">Figure 33</a>:
+<a href="#name-data_blocked-frame-format" class="selfRef">DATA_BLOCKED Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.12-4">DATA_BLOCKED frames contain the following fields:<a href="#section-19.12-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.12-5">
+          <dt id="section-19.12-5.1">Maximum Data:</dt>
+<dd id="section-19.12-5.2">
+  A variable-length integer indicating the connection-level limit at which
+blocking occurred.<a href="#section-19.12-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="frame-stream-data-blocked">
+<section id="section-19.13">
+        <h3 id="name-stream_data_blocked-frame">
+<a href="#section-19.13" class="section-number selfRef">19.13. </a><a href="#name-stream_data_blocked-frame" class="section-name selfRef">STREAM_DATA_BLOCKED Frame</a>
+        </h3>
+<p id="section-19.13-1">A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it wishes to
+send data, but is unable to due to stream-level flow control.  This frame is
+analogous to DATA_BLOCKED (<a href="#frame-data-blocked" class="xref">Section 19.12</a>).<a href="#section-19.13-1" class="pilcrow">¶</a></p>
+<p id="section-19.13-2">An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only stream
+MUST terminate the connection with error STREAM_STATE_ERROR.<a href="#section-19.13-2" class="pilcrow">¶</a></p>
+<p id="section-19.13-3">The STREAM_DATA_BLOCKED frame is shown in <a href="#fig-stream-data-blocked" class="xref">Figure 34</a>.<a href="#section-19.13-3" class="pilcrow">¶</a></p>
+<span id="name-stream_data_blocked-frame-f"></span><div id="fig-stream-data-blocked">
+<figure id="figure-34">
+          <div class="artwork art-text alignLeft" id="section-19.13-4.1">
+<pre>
+STREAM_DATA_BLOCKED Frame {
+  Type (i) = 0x15,
+  Stream ID (i),
+  Maximum Stream Data (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-34" class="selfRef">Figure 34</a>:
+<a href="#name-stream_data_blocked-frame-f" class="selfRef">STREAM_DATA_BLOCKED Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.13-5">STREAM_DATA_BLOCKED frames contain the following fields:<a href="#section-19.13-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.13-6">
+          <dt id="section-19.13-6.1">Stream ID:</dt>
+<dd id="section-19.13-6.2">
+  A variable-length integer indicating the stream which is flow control blocked.<a href="#section-19.13-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.13-6.3">Maximum Stream Data:</dt>
+<dd id="section-19.13-6.4">
+  A variable-length integer indicating the offset of the stream at which the
+blocking occurred.<a href="#section-19.13-6.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="frame-streams-blocked">
+<section id="section-19.14">
+        <h3 id="name-streams_blocked-frames">
+<a href="#section-19.14" class="section-number selfRef">19.14. </a><a href="#name-streams_blocked-frames" class="section-name selfRef">STREAMS_BLOCKED Frames</a>
+        </h3>
+<p id="section-19.14-1">A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when it wishes
+to open a stream, but is unable to due to the maximum stream limit set by its
+peer; see <a href="#frame-max-streams" class="xref">Section 19.11</a>.  A STREAMS_BLOCKED frame of type 0x16 is used
+to indicate reaching the bidirectional stream limit, and a STREAMS_BLOCKED frame
+of type 0x17 indicates reaching the unidirectional stream limit.<a href="#section-19.14-1" class="pilcrow">¶</a></p>
+<p id="section-19.14-2">A STREAMS_BLOCKED frame does not open the stream, but informs the peer that a
+new stream was needed and the stream limit prevented the creation of the stream.<a href="#section-19.14-2" class="pilcrow">¶</a></p>
+<p id="section-19.14-3">The STREAMS_BLOCKED frames are shown in <a href="#fig-streams-blocked" class="xref">Figure 35</a>.<a href="#section-19.14-3" class="pilcrow">¶</a></p>
+<span id="name-streams_blocked-frame-forma"></span><div id="fig-streams-blocked">
+<figure id="figure-35">
+          <div class="artwork art-text alignLeft" id="section-19.14-4.1">
+<pre>
+STREAMS_BLOCKED Frame {
+  Type (i) = 0x16..0x17,
+  Maximum Streams (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-35" class="selfRef">Figure 35</a>:
+<a href="#name-streams_blocked-frame-forma" class="selfRef">STREAMS_BLOCKED Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.14-5">STREAMS_BLOCKED frames contain the following fields:<a href="#section-19.14-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.14-6">
+          <dt id="section-19.14-6.1">Maximum Streams:</dt>
+<dd id="section-19.14-6.2">
+  A variable-length integer indicating the maximum number of streams allowed
+at the time the frame was sent.  This value cannot exceed 2^60, as it is
+not possible to encode stream IDs larger than 2^62-1.  Receipt of a frame
+that encodes a larger stream ID MUST be treated as a STREAM_LIMIT_ERROR or a
+FRAME_ENCODING_ERROR.<a href="#section-19.14-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</div>
+<div id="frame-new-connection-id">
+<section id="section-19.15">
+        <h3 id="name-new_connection_id-frame">
+<a href="#section-19.15" class="section-number selfRef">19.15. </a><a href="#name-new_connection_id-frame" class="section-name selfRef">NEW_CONNECTION_ID Frame</a>
+        </h3>
+<p id="section-19.15-1">An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide its peer with
+alternative connection IDs that can be used to break linkability when migrating
+connections; see <a href="#migration-linkability" class="xref">Section 9.5</a>.<a href="#section-19.15-1" class="pilcrow">¶</a></p>
+<p id="section-19.15-2">The NEW_CONNECTION_ID frame is shown in <a href="#fig-new-connection-id" class="xref">Figure 36</a>.<a href="#section-19.15-2" class="pilcrow">¶</a></p>
+<span id="name-new_connection_id-frame-for"></span><div id="fig-new-connection-id">
+<figure id="figure-36">
+          <div class="artwork art-text alignLeft" id="section-19.15-3.1">
+<pre>
+NEW_CONNECTION_ID Frame {
+  Type (i) = 0x18,
+  Sequence Number (i),
+  Retire Prior To (i),
+  Length (8),
+  Connection ID (8..160),
+  Stateless Reset Token (128),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-36" class="selfRef">Figure 36</a>:
+<a href="#name-new_connection_id-frame-for" class="selfRef">NEW_CONNECTION_ID Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.15-4">NEW_CONNECTION_ID frames contain the following fields:<a href="#section-19.15-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.15-5">
+          <dt id="section-19.15-5.1">Sequence Number:</dt>
+<dd id="section-19.15-5.2">
+  The sequence number assigned to the connection ID by the sender.  See
+<a href="#issue-cid" class="xref">Section 5.1.1</a>.<a href="#section-19.15-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.15-5.3">Retire Prior To:</dt>
+<dd id="section-19.15-5.4">
+  A variable-length integer indicating which connection IDs should be retired;
+see <a href="#retire-cid" class="xref">Section 5.1.2</a>.<a href="#section-19.15-5.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.15-5.5">Length:</dt>
+<dd id="section-19.15-5.6">
+  An 8-bit unsigned integer containing the length of the connection ID.  Values
+less than 1 and greater than 20 are invalid and MUST be treated as a
+connection error of type FRAME_ENCODING_ERROR.<a href="#section-19.15-5.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.15-5.7">Connection ID:</dt>
+<dd id="section-19.15-5.8">
+  A connection ID of the specified length.<a href="#section-19.15-5.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.15-5.9">Stateless Reset Token:</dt>
+<dd id="section-19.15-5.10">
+  A 128-bit value that will be used for a stateless reset when the associated
+connection ID is used; see <a href="#stateless-reset" class="xref">Section 10.4</a>.<a href="#section-19.15-5.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.15-6">An endpoint MUST NOT send this frame if it currently requires that its peer send
+packets with a zero-length Destination Connection ID.  Changing the length of a
+connection ID to or from zero-length makes it difficult to identify when the
+value of the connection ID changed.  An endpoint that is sending packets with a
+zero-length Destination Connection ID MUST treat receipt of a NEW_CONNECTION_ID
+frame as a connection error of type PROTOCOL_VIOLATION.<a href="#section-19.15-6" class="pilcrow">¶</a></p>
+<p id="section-19.15-7">Transmission errors, timeouts and retransmissions might cause the same
+NEW_CONNECTION_ID frame to be received multiple times.  Receipt of the same
+frame multiple times MUST NOT be treated as a connection error.  A receiver can
+use the sequence number supplied in the NEW_CONNECTION_ID frame to identify new
+connection IDs from old ones.<a href="#section-19.15-7" class="pilcrow">¶</a></p>
+<p id="section-19.15-8">If an endpoint receives a NEW_CONNECTION_ID frame that repeats a previously
+issued connection ID with a different Stateless Reset Token or a different
+sequence number, or if a sequence number is used for different connection
+IDs, the endpoint MAY treat that receipt as a connection error of type
+PROTOCOL_VIOLATION.<a href="#section-19.15-8" class="pilcrow">¶</a></p>
+<p id="section-19.15-9">The Retire Prior To field counts connection IDs established during connection
+setup and the preferred_address transport parameter; see <a href="#retire-cid" class="xref">Section 5.1.2</a>. The
+Retire Prior To field MUST be less than or equal to the Sequence Number field.
+Receiving a value greater than the Sequence Number MUST be treated as a
+connection error of type FRAME_ENCODING_ERROR.<a href="#section-19.15-9" class="pilcrow">¶</a></p>
+<p id="section-19.15-10">Once a sender indicates a Retire Prior To value, smaller values sent in
+subsequent NEW_CONNECTION_ID frames have no effect. A receiver MUST ignore any
+Retire Prior To fields that do not increase the largest received Retire Prior To
+value.<a href="#section-19.15-10" class="pilcrow">¶</a></p>
+<p id="section-19.15-11">An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number
+smaller than the Retire Prior To field of a previously received
+NEW_CONNECTION_ID frame MUST send a corresponding RETIRE_CONNECTION_ID frame
+that retires the newly received connection ID, unless it has already done so
+for that sequence number.<a href="#section-19.15-11" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-retire-connection-id">
+<section id="section-19.16">
+        <h3 id="name-retire_connection_id-frame">
+<a href="#section-19.16" class="section-number selfRef">19.16. </a><a href="#name-retire_connection_id-frame" class="section-name selfRef">RETIRE_CONNECTION_ID Frame</a>
+        </h3>
+<p id="section-19.16-1">An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to indicate that it
+will no longer use a connection ID that was issued by its peer. This may include
+the connection ID provided during the handshake.  Sending a RETIRE_CONNECTION_ID
+frame also serves as a request to the peer to send additional connection IDs for
+future use; see <a href="#connection-id" class="xref">Section 5.1</a>.  New connection IDs can be delivered to a
+peer using the NEW_CONNECTION_ID frame (<a href="#frame-new-connection-id" class="xref">Section 19.15</a>).<a href="#section-19.16-1" class="pilcrow">¶</a></p>
+<p id="section-19.16-2">Retiring a connection ID invalidates the stateless reset token associated with
+that connection ID.<a href="#section-19.16-2" class="pilcrow">¶</a></p>
+<p id="section-19.16-3">The RETIRE_CONNECTION_ID frame is shown in <a href="#fig-retire-connection-id" class="xref">Figure 37</a>.<a href="#section-19.16-3" class="pilcrow">¶</a></p>
+<span id="name-retire_connection_id-frame-"></span><div id="fig-retire-connection-id">
+<figure id="figure-37">
+          <div class="artwork art-text alignLeft" id="section-19.16-4.1">
+<pre>
+RETIRE_CONNECTION_ID Frame {
+  Type (i) = 0x19,
+  Sequence Number (i),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-37" class="selfRef">Figure 37</a>:
+<a href="#name-retire_connection_id-frame-" class="selfRef">RETIRE_CONNECTION_ID Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.16-5">RETIRE_CONNECTION_ID frames contain the following fields:<a href="#section-19.16-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.16-6">
+          <dt id="section-19.16-6.1">Sequence Number:</dt>
+<dd id="section-19.16-6.2">
+  The sequence number of the connection ID being retired; see <a href="#retire-cid" class="xref">Section 5.1.2</a>.<a href="#section-19.16-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.16-7">Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number greater
+than any previously sent to the peer MUST be treated as a connection error of
+type PROTOCOL_VIOLATION.<a href="#section-19.16-7" class="pilcrow">¶</a></p>
+<p id="section-19.16-8">The sequence number specified in a RETIRE_CONNECTION_ID frame MUST NOT refer
+to the Destination Connection ID field of the packet in which the frame is
+contained.  The peer MAY treat this as a connection error of type
+FRAME_ENCODING_ERROR.<a href="#section-19.16-8" class="pilcrow">¶</a></p>
+<p id="section-19.16-9">An endpoint cannot send this frame if it was provided with a zero-length
+connection ID by its peer.  An endpoint that provides a zero-length connection
+ID MUST treat receipt of a RETIRE_CONNECTION_ID frame as a connection error of
+type PROTOCOL_VIOLATION.<a href="#section-19.16-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-path-challenge">
+<section id="section-19.17">
+        <h3 id="name-path_challenge-frame">
+<a href="#section-19.17" class="section-number selfRef">19.17. </a><a href="#name-path_challenge-frame" class="section-name selfRef">PATH_CHALLENGE Frame</a>
+        </h3>
+<p id="section-19.17-1">Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check reachability to the
+peer and for path validation during connection migration.<a href="#section-19.17-1" class="pilcrow">¶</a></p>
+<p id="section-19.17-2">The PATH_CHALLENGE frame is shown in <a href="#fig-path-challenge" class="xref">Figure 38</a>.<a href="#section-19.17-2" class="pilcrow">¶</a></p>
+<span id="name-path_challenge-frame-format"></span><div id="fig-path-challenge">
+<figure id="figure-38">
+          <div class="artwork art-text alignLeft" id="section-19.17-3.1">
+<pre>
+PATH_CHALLENGE Frame {
+  Type (i) = 0x1a,
+  Data (64),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-38" class="selfRef">Figure 38</a>:
+<a href="#name-path_challenge-frame-format" class="selfRef">PATH_CHALLENGE Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.17-4">PATH_CHALLENGE frames contain the following fields:<a href="#section-19.17-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.17-5">
+          <dt id="section-19.17-5.1">Data:</dt>
+<dd id="section-19.17-5.2">
+  This 8-byte field contains arbitrary data.<a href="#section-19.17-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.17-6">A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is sufficient
+to ensure that it is easier to receive the packet than it is to guess the value
+correctly.<a href="#section-19.17-6" class="pilcrow">¶</a></p>
+<p id="section-19.17-7">The recipient of this frame MUST generate a PATH_RESPONSE frame
+(<a href="#frame-path-response" class="xref">Section 19.18</a>) containing the same Data.<a href="#section-19.17-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-path-response">
+<section id="section-19.18">
+        <h3 id="name-path_response-frame">
+<a href="#section-19.18" class="section-number selfRef">19.18. </a><a href="#name-path_response-frame" class="section-name selfRef">PATH_RESPONSE Frame</a>
+        </h3>
+<p id="section-19.18-1">The PATH_RESPONSE frame (type=0x1b) is sent in response to a PATH_CHALLENGE
+frame.  Its format, shown in <a href="#fig-path-response" class="xref">Figure 39</a> is identical to the
+PATH_CHALLENGE frame (<a href="#frame-path-challenge" class="xref">Section 19.17</a>).<a href="#section-19.18-1" class="pilcrow">¶</a></p>
+<span id="name-path_response-frame-format"></span><div id="fig-path-response">
+<figure id="figure-39">
+          <div class="artwork art-text alignLeft" id="section-19.18-2.1">
+<pre>
+PATH_RESPONSE Frame {
+  Type (i) = 0x1b,
+  Data (64),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-39" class="selfRef">Figure 39</a>:
+<a href="#name-path_response-frame-format" class="selfRef">PATH_RESPONSE Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.18-3">If the content of a PATH_RESPONSE frame does not match the content of a
+PATH_CHALLENGE frame previously sent by the endpoint, the endpoint MAY generate
+a connection error of type PROTOCOL_VIOLATION.<a href="#section-19.18-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-connection-close">
+<section id="section-19.19">
+        <h3 id="name-connection_close-frames">
+<a href="#section-19.19" class="section-number selfRef">19.19. </a><a href="#name-connection_close-frames" class="section-name selfRef">CONNECTION_CLOSE Frames</a>
+        </h3>
+<p id="section-19.19-1">An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to notify its
+peer that the connection is being closed.  The CONNECTION_CLOSE with a frame
+type of 0x1c is used to signal errors at only the QUIC layer, or the absence of
+errors (with the NO_ERROR code).  The CONNECTION_CLOSE frame with a type of 0x1d
+is used to signal an error with the application that uses QUIC.<a href="#section-19.19-1" class="pilcrow">¶</a></p>
+<p id="section-19.19-2">If there are open streams that haven't been explicitly closed, they are
+implicitly closed when the connection is closed.<a href="#section-19.19-2" class="pilcrow">¶</a></p>
+<p id="section-19.19-3">The CONNECTION_CLOSE frames are shown in <a href="#fig-connection-close" class="xref">Figure 40</a>.<a href="#section-19.19-3" class="pilcrow">¶</a></p>
+<span id="name-connection_close-frame-form"></span><div id="fig-connection-close">
+<figure id="figure-40">
+          <div class="artwork art-text alignLeft" id="section-19.19-4.1">
+<pre>
+CONNECTION_CLOSE Frame {
+  Type (i) = 0x1c..0x1d,
+  Error Code (i),
+  [Frame Type (i)],
+  Reason Phrase Length (i),
+  Reason Phrase (..),
+}
+</pre>
+</div>
+<figcaption><a href="#figure-40" class="selfRef">Figure 40</a>:
+<a href="#name-connection_close-frame-form" class="selfRef">CONNECTION_CLOSE Frame Format</a>
+          </figcaption></figure>
+</div>
+<p id="section-19.19-5">CONNECTION_CLOSE frames contain the following fields:<a href="#section-19.19-5" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-19.19-6">
+          <dt id="section-19.19-6.1">Error Code:</dt>
+<dd id="section-19.19-6.2">
+  A variable length integer error code which indicates the reason for
+closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes
+from the space defined in <a href="#error-codes" class="xref">Section 20</a>.  A CONNECTION_CLOSE frame of
+type 0x1d uses codes from the application protocol error code space;
+see <a href="#app-error-codes" class="xref">Section 20.1</a><a href="#section-19.19-6.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.19-6.3">Frame Type:</dt>
+<dd id="section-19.19-6.4">
+  A variable-length integer encoding the type of frame that triggered the error.
+A value of 0 (equivalent to the mention of the PADDING frame) is used when the
+frame type is unknown.  The application-specific variant of CONNECTION_CLOSE
+(type 0x1d) does not include this field.<a href="#section-19.19-6.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.19-6.5">Reason Phrase Length:</dt>
+<dd id="section-19.19-6.6">
+  A variable-length integer specifying the length of the reason phrase in bytes.
+Because a CONNECTION_CLOSE frame cannot be split between packets, any limits
+on packet size will also limit the space available for a reason phrase.<a href="#section-19.19-6.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-19.19-6.7">Reason Phrase:</dt>
+<dd id="section-19.19-6.8">
+  A human-readable explanation for why the connection was closed.  This can be
+zero length if the sender chooses to not give details beyond the Error Code.
+This SHOULD be a UTF-8 encoded string <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span>.<a href="#section-19.19-6.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-19.19-7">The application-specific variant of CONNECTION_CLOSE (type 0x1d) can only be
+sent using 0-RTT or 1-RTT packets (<span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>, Section 4).  When an
+application wishes to abandon a connection during the handshake, an endpoint
+can send a CONNECTION_CLOSE frame (type 0x1c) with an error code of
+APPLICATION_ERROR in an Initial or a Handshake packet.<a href="#section-19.19-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="frame-handshake-done">
+<section id="section-19.20">
+        <h3 id="name-handshake_done-frame">
+<a href="#section-19.20" class="section-number selfRef">19.20. </a><a href="#name-handshake_done-frame" class="section-name selfRef">HANDSHAKE_DONE frame</a>
+        </h3>
+<p id="section-19.20-1">The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal confirmation of
+the handshake to the client.  The HANDSHAKE_DONE frame contains no additional
+fields.<a href="#section-19.20-1" class="pilcrow">¶</a></p>
+<p id="section-19.20-2">This frame can only be sent by the server. Servers MUST NOT send a
+HANDSHAKE_DONE frame before completing the handshake.  A server MUST treat
+receipt of a HANDSHAKE_DONE frame as a connection error of type
+PROTOCOL_VIOLATION.<a href="#section-19.20-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="extension-frames">
+<section id="section-19.21">
+        <h3 id="name-extension-frames">
+<a href="#section-19.21" class="section-number selfRef">19.21. </a><a href="#name-extension-frames" class="section-name selfRef">Extension Frames</a>
+        </h3>
+<p id="section-19.21-1">QUIC frames do not use a self-describing encoding.  An endpoint therefore needs
+to understand the syntax of all frames before it can successfully process a
+packet.  This allows for efficient encoding of frames, but it means that an
+endpoint cannot send a frame of a type that is unknown to its peer.<a href="#section-19.21-1" class="pilcrow">¶</a></p>
+<p id="section-19.21-2">An extension to QUIC that wishes to use a new type of frame MUST first ensure
+that a peer is able to understand the frame.  An endpoint can use a transport
+parameter to signal its willingness to receive one or more extension frame types
+with the one transport parameter.<a href="#section-19.21-2" class="pilcrow">¶</a></p>
+<p id="section-19.21-3">Extensions that modify or replace core protocol functionality (including frame
+types) will be difficult to combine with other extensions which modify or
+replace the same functionality unless the behavior of the combination is
+explicitly defined.  Such extensions SHOULD define their interaction with
+previously-defined extensions modifying the same protocol components.<a href="#section-19.21-3" class="pilcrow">¶</a></p>
+<p id="section-19.21-4">Extension frames MUST be congestion controlled and MUST cause an ACK frame to
+be sent.  The exception is extension frames that replace or supplement the ACK
+frame.  Extension frames are not included in flow control unless specified
+in the extension.<a href="#section-19.21-4" class="pilcrow">¶</a></p>
+<p id="section-19.21-5">An IANA registry is used to manage the assignment of frame types; see
+<a href="#iana-frames" class="xref">Section 22.3</a>.<a href="#section-19.21-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="error-codes">
+<section id="section-20">
+      <h2 id="name-transport-error-codes">
+<a href="#section-20" class="section-number selfRef">20. </a><a href="#name-transport-error-codes" class="section-name selfRef">Transport Error Codes</a>
+      </h2>
+<p id="section-20-1">QUIC error codes are 62-bit unsigned integers.<a href="#section-20-1" class="pilcrow">¶</a></p>
+<p id="section-20-2">This section lists the defined QUIC transport error codes that may be used in a
+CONNECTION_CLOSE frame.  These errors apply to the entire connection.<a href="#section-20-2" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-20-3">
+        <dt id="section-20-3.1">NO_ERROR (0x0):</dt>
+<dd id="section-20-3.2">
+  An endpoint uses this with CONNECTION_CLOSE to signal that the connection is
+being closed abruptly in the absence of any error.<a href="#section-20-3.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.3">INTERNAL_ERROR (0x1):</dt>
+<dd id="section-20-3.4">
+  The endpoint encountered an internal error and cannot continue with the
+connection.<a href="#section-20-3.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.5">CONNECTION_REFUSED (0x2):</dt>
+<dd id="section-20-3.6">
+  The server refused to accept a new connection.<a href="#section-20-3.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.7">FLOW_CONTROL_ERROR (0x3):</dt>
+<dd id="section-20-3.8">
+  An endpoint received more data than it permitted in its advertised data
+limits; see <a href="#flow-control" class="xref">Section 4</a>.<a href="#section-20-3.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.9">STREAM_LIMIT_ERROR (0x4):</dt>
+<dd id="section-20-3.10">
+  An endpoint received a frame for a stream identifier that exceeded its
+advertised stream limit for the corresponding stream type.<a href="#section-20-3.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.11">STREAM_STATE_ERROR (0x5):</dt>
+<dd id="section-20-3.12">
+  An endpoint received a frame for a stream that was not in a state that
+permitted that frame; see <a href="#stream-states" class="xref">Section 3</a>.<a href="#section-20-3.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.13">FINAL_SIZE_ERROR (0x6):</dt>
+<dd id="section-20-3.14">
+  An endpoint received a STREAM frame containing data that exceeded the
+previously established final size.  Or an endpoint received a STREAM frame or
+a RESET_STREAM frame containing a final size that was lower than the size of
+stream data that was already received.  Or an endpoint received a STREAM frame
+or a RESET_STREAM frame containing a different final size to the one already
+established.<a href="#section-20-3.14" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.15">FRAME_ENCODING_ERROR (0x7):</dt>
+<dd id="section-20-3.16">
+  An endpoint received a frame that was badly formatted.  For instance, a frame
+of an unknown type, or an ACK frame that has more acknowledgment ranges than
+the remainder of the packet could carry.<a href="#section-20-3.16" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.17">TRANSPORT_PARAMETER_ERROR (0x8):</dt>
+<dd id="section-20-3.18">
+  An endpoint received transport parameters that were badly formatted, included
+an invalid value, was absent even though it is mandatory, was present though
+it is forbidden, or is otherwise in error.<a href="#section-20-3.18" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.19">CONNECTION_ID_LIMIT_ERROR (0x9):</dt>
+<dd id="section-20-3.20">
+  The number of connection IDs provided by the peer exceeds the advertised
+active_connection_id_limit.<a href="#section-20-3.20" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.21">PROTOCOL_VIOLATION (0xA):</dt>
+<dd id="section-20-3.22">
+  An endpoint detected an error with protocol compliance that was not covered by
+more specific error codes.<a href="#section-20-3.22" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.23">INVALID_TOKEN (0xB):</dt>
+<dd id="section-20-3.24">
+  A server received a Retry Token in a client Initial that is invalid.<a href="#section-20-3.24" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.25">APPLICATION_ERROR (0xC):</dt>
+<dd id="section-20-3.26">
+  The application or application protocol caused the connection to be closed.<a href="#section-20-3.26" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.27">CRYPTO_BUFFER_EXCEEDED (0xD):</dt>
+<dd id="section-20-3.28">
+  An endpoint has received more data in CRYPTO frames than it can buffer.<a href="#section-20-3.28" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-20-3.29">CRYPTO_ERROR (0x1XX):</dt>
+<dd id="section-20-3.30">
+  The cryptographic handshake failed.  A range of 256 values is reserved for
+carrying error codes specific to the cryptographic handshake that is used.
+Codes for errors occurring when TLS is used for the crypto handshake are
+described in Section 4.8 of <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span>.<a href="#section-20-3.30" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-20-4">See <a href="#iana-error-codes" class="xref">Section 22.4</a> for details of registering new error codes.<a href="#section-20-4" class="pilcrow">¶</a></p>
+<p id="section-20-5">In defining these error codes, several principles are applied.  Error conditions
+that might require specific action on the part of a recipient are given unique
+codes.  Errors that represent common conditions are given specific codes.
+Absent either of these conditions, error codes are used to identify a general
+function of the stack, like flow control or transport parameter handling.
+Finally, generic errors are provided for conditions where implementations are
+unable or unwilling to use more specific codes.<a href="#section-20-5" class="pilcrow">¶</a></p>
+<div id="app-error-codes">
+<section id="section-20.1">
+        <h3 id="name-application-protocol-error-">
+<a href="#section-20.1" class="section-number selfRef">20.1. </a><a href="#name-application-protocol-error-" class="section-name selfRef">Application Protocol Error Codes</a>
+        </h3>
+<p id="section-20.1-1">Application protocol error codes are 62-bit unsigned integers, but the
+management of application error codes is left to application protocols.
+Application protocol error codes are used for the RESET_STREAM frame
+(<a href="#frame-reset-stream" class="xref">Section 19.4</a>), the STOP_SENDING frame (<a href="#frame-stop-sending" class="xref">Section 19.5</a>), and
+the CONNECTION_CLOSE frame with a type of 0x1d (<a href="#frame-connection-close" class="xref">Section 19.19</a>).<a href="#section-20.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="security-considerations">
+<section id="section-21">
+      <h2 id="name-security-considerations">
+<a href="#section-21" class="section-number selfRef">21. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
+      </h2>
+<div id="handshake-dos">
+<section id="section-21.1">
+        <h3 id="name-handshake-denial-of-service">
+<a href="#section-21.1" class="section-number selfRef">21.1. </a><a href="#name-handshake-denial-of-service" class="section-name selfRef">Handshake Denial of Service</a>
+        </h3>
+<p id="section-21.1-1">As an encrypted and authenticated transport QUIC provides a range of protections
+against denial of service.  Once the cryptographic handshake is complete, QUIC
+endpoints discard most packets that are not authenticated, greatly limiting the
+ability of an attacker to interfere with existing connections.<a href="#section-21.1-1" class="pilcrow">¶</a></p>
+<p id="section-21.1-2">Once a connection is established QUIC endpoints might accept some
+unauthenticated ICMP packets (see <a href="#icmp-pmtud" class="xref">Section 14.2</a>), but the use of these packets
+is extremely limited.  The only other type of packet that an endpoint might
+accept is a stateless reset (<a href="#stateless-reset" class="xref">Section 10.4</a>) which relies on the token
+being kept secret until it is used.<a href="#section-21.1-2" class="pilcrow">¶</a></p>
+<p id="section-21.1-3">During the creation of a connection, QUIC only provides protection against
+attack from off the network path.  All QUIC packets contain proof that the
+recipient saw a preceding packet from its peer.<a href="#section-21.1-3" class="pilcrow">¶</a></p>
+<p id="section-21.1-4">Addresses cannot change during the handshake, so endpoints can discard packets
+that are received on a different network path.<a href="#section-21.1-4" class="pilcrow">¶</a></p>
+<p id="section-21.1-5">The Source and Destination Connection ID fields are the primary means of
+protection against off-path attack during the handshake.  These are required to
+match those set by a peer.  Except for an Initial and stateless reset packets,
+an endpoint only accepts packets that include a Destination Connection ID field
+that matches a value the endpoint previously chose.  This is the only protection
+offered for Version Negotiation packets.<a href="#section-21.1-5" class="pilcrow">¶</a></p>
+<p id="section-21.1-6">The Destination Connection ID field in an Initial packet is selected by a client
+to be unpredictable, which serves an additional purpose.  The packets that carry
+the cryptographic handshake are protected with a key that is derived from this
+connection ID and salt specific to the QUIC version.  This allows endpoints to
+use the same process for authenticating packets that they receive as they use
+after the cryptographic handshake completes.  Packets that cannot be
+authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw the Initial packet and
+understood it.<a href="#section-21.1-6" class="pilcrow">¶</a></p>
+<p id="section-21.1-7">These protections are not intended to be effective against an attacker that is
+able to receive QUIC packets prior to the connection being established.  Such an
+attacker can potentially send packets that will be accepted by QUIC endpoints.
+This version of QUIC attempts to detect this sort of attack, but it expects that
+endpoints will fail to establish a connection rather than recovering.  For the
+most part, the cryptographic handshake protocol <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span> is responsible for
+detecting tampering during the handshake.<a href="#section-21.1-7" class="pilcrow">¶</a></p>
+<p id="section-21.1-8">Endpoints are permitted to use other methods to detect and attempt to recover
+from interference with the handshake.  Invalid packets may be identified and
+discarded using other methods, but no specific method is mandated in this
+document.<a href="#section-21.1-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="amplification-attack">
+<section id="section-21.2">
+        <h3 id="name-amplification-attack">
+<a href="#section-21.2" class="section-number selfRef">21.2. </a><a href="#name-amplification-attack" class="section-name selfRef">Amplification Attack</a>
+        </h3>
+<p id="section-21.2-1">An attacker might be able to receive an address validation token
+(<a href="#address-validation" class="xref">Section 8</a>) from a server and then release the IP address it used
+to acquire that token.  At a later time, the attacker may initiate a 0-RTT
+connection with a server by spoofing this same address, which might now address
+a different (victim) endpoint.  The attacker can thus potentially cause the
+server to send an initial congestion window's worth of data towards the victim.<a href="#section-21.2-1" class="pilcrow">¶</a></p>
+<p id="section-21.2-2">Servers SHOULD provide mitigations for this attack by limiting the usage and
+lifetime of address validation tokens; see <a href="#validate-future" class="xref">Section 8.1.3</a>.<a href="#section-21.2-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="optimistic-ack-attack">
+<section id="section-21.3">
+        <h3 id="name-optimistic-ack-attack">
+<a href="#section-21.3" class="section-number selfRef">21.3. </a><a href="#name-optimistic-ack-attack" class="section-name selfRef">Optimistic ACK Attack</a>
+        </h3>
+<p id="section-21.3-1">An endpoint that acknowledges packets it has not received might cause a
+congestion controller to permit sending at rates beyond what the network
+supports.  An endpoint MAY skip packet numbers when sending packets to detect
+this behavior.  An endpoint can then immediately close the connection with a
+connection error of type PROTOCOL_VIOLATION; see <a href="#immediate-close" class="xref">Section 10.3</a>.<a href="#section-21.3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="slowloris-attacks">
+<section id="section-21.4">
+        <h3 id="name-slowloris-attacks">
+<a href="#section-21.4" class="section-number selfRef">21.4. </a><a href="#name-slowloris-attacks" class="section-name selfRef">Slowloris Attacks</a>
+        </h3>
+<p id="section-21.4-1">The attacks commonly known as Slowloris <span>[<a href="#SLOWLORIS" class="xref">SLOWLORIS</a>]</span> try to keep many
+connections to the target endpoint open and hold them open as long as possible.
+These attacks can be executed against a QUIC endpoint by generating the minimum
+amount of activity necessary to avoid being closed for inactivity.  This might
+involve sending small amounts of data, gradually opening flow control windows in
+order to control the sender rate, or manufacturing ACK frames that simulate a
+high loss rate.<a href="#section-21.4-1" class="pilcrow">¶</a></p>
+<p id="section-21.4-2">QUIC deployments SHOULD provide mitigations for the Slowloris attacks, such as
+increasing the maximum number of clients the server will allow, limiting the
+number of connections a single IP address is allowed to make, imposing
+restrictions on the minimum transfer speed a connection is allowed to have, and
+restricting the length of time an endpoint is allowed to stay connected.<a href="#section-21.4-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-fragmentation-and-reassembly-attacks">
+<section id="section-21.5">
+        <h3 id="name-stream-fragmentation-and-re">
+<a href="#section-21.5" class="section-number selfRef">21.5. </a><a href="#name-stream-fragmentation-and-re" class="section-name selfRef">Stream Fragmentation and Reassembly Attacks</a>
+        </h3>
+<p id="section-21.5-1">An adversarial sender might intentionally send fragments of stream data in
+order to cause disproportionate receive buffer memory commitment and/or
+creation of a large and inefficient data structure.<a href="#section-21.5-1" class="pilcrow">¶</a></p>
+<p id="section-21.5-2">An adversarial receiver might intentionally not acknowledge packets
+containing stream data in order to force the sender to store the
+unacknowledged stream data for retransmission.<a href="#section-21.5-2" class="pilcrow">¶</a></p>
+<p id="section-21.5-3">The attack on receivers is mitigated if flow control windows correspond to
+available memory.  However, some receivers will over-commit memory and
+advertise flow control offsets in the aggregate that exceed actual available
+memory.  The over-commitment strategy can lead to better performance when
+endpoints are well behaved, but renders endpoints vulnerable to the stream
+fragmentation attack.<a href="#section-21.5-3" class="pilcrow">¶</a></p>
+<p id="section-21.5-4">QUIC deployments SHOULD provide mitigations against stream fragmentation
+attacks.  Mitigations could consist of avoiding over-committing memory,
+limiting the size of tracking data structures, delaying reassembly
+of STREAM frames, implementing heuristics based on the age and
+duration of reassembly holes, or some combination.<a href="#section-21.5-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="stream-commitment-attack">
+<section id="section-21.6">
+        <h3 id="name-stream-commitment-attack">
+<a href="#section-21.6" class="section-number selfRef">21.6. </a><a href="#name-stream-commitment-attack" class="section-name selfRef">Stream Commitment Attack</a>
+        </h3>
+<p id="section-21.6-1">An adversarial endpoint can open lots of streams, exhausting state on an
+endpoint.  The adversarial endpoint could repeat the process on a large number
+of connections, in a manner similar to SYN flooding attacks in TCP.<a href="#section-21.6-1" class="pilcrow">¶</a></p>
+<p id="section-21.6-2">Normally, clients will open streams sequentially, as explained in <a href="#stream-id" class="xref">Section 2.1</a>.
+However, when several streams are initiated at short intervals, loss or
+reordering may cause STREAM frames that open streams to be received out of
+sequence.  On receiving a higher-numbered stream ID, a receiver is required to
+open all intervening streams of the same type; see <a href="#stream-recv-states" class="xref">Section 3.2</a>.
+Thus, on a new connection, opening stream 4000000 opens 1 million and 1
+client-initiated bidirectional streams.<a href="#section-21.6-2" class="pilcrow">¶</a></p>
+<p id="section-21.6-3">The number of active streams is limited by the initial_max_streams_bidi and
+initial_max_streams_uni transport parameters, as explained in
+<a href="#controlling-concurrency" class="xref">Section 4.5</a>.  If chosen judiciously, these limits mitigate the
+effect of the stream commitment attack.  However, setting the limit too low
+could affect performance when applications expect to open large number of
+streams.<a href="#section-21.6-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="useless">
+<section id="section-21.7">
+        <h3 id="name-peer-denial-of-service">
+<a href="#section-21.7" class="section-number selfRef">21.7. </a><a href="#name-peer-denial-of-service" class="section-name selfRef">Peer Denial of Service</a>
+        </h3>
+<p id="section-21.7-1">QUIC and TLS both contain messages that have legitimate uses in some contexts,
+but that can be abused to cause a peer to expend processing resources without
+having any observable impact on the state of the connection.<a href="#section-21.7-1" class="pilcrow">¶</a></p>
+<p id="section-21.7-2">Messages can also be used to change and revert state in small or inconsequential
+ways, such as by sending small increments to flow control limits.<a href="#section-21.7-2" class="pilcrow">¶</a></p>
+<p id="section-21.7-3">If processing costs are disproportionately large in comparison to bandwidth
+consumption or effect on state, then this could allow a malicious peer to
+exhaust processing capacity.<a href="#section-21.7-3" class="pilcrow">¶</a></p>
+<p id="section-21.7-4">While there are legitimate uses for all messages, implementations SHOULD track
+cost of processing relative to progress and treat excessive quantities of any
+non-productive packets as indicative of an attack.  Endpoints MAY respond to
+this condition with a connection error, or by dropping packets.<a href="#section-21.7-4" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="security-ecn">
+<section id="section-21.8">
+        <h3 id="name-explicit-congestion-notifica">
+<a href="#section-21.8" class="section-number selfRef">21.8. </a><a href="#name-explicit-congestion-notifica" class="section-name selfRef">Explicit Congestion Notification Attacks</a>
+        </h3>
+<p id="section-21.8-1">An on-path attacker could manipulate the value of ECN codepoints in the IP
+header to influence the sender's rate. <span>[<a href="#RFC3168" class="xref">RFC3168</a>]</span> discusses manipulations and
+their effects in more detail.<a href="#section-21.8-1" class="pilcrow">¶</a></p>
+<p id="section-21.8-2">An on-the-side attacker can duplicate and send packets with modified ECN
+codepoints to affect the sender's rate.  If duplicate packets are discarded by a
+receiver, an off-path attacker will need to race the duplicate packet against
+the original to be successful in this attack.  Therefore, QUIC endpoints ignore
+the ECN codepoint field on an IP packet unless at least one QUIC packet in that
+IP packet is successfully processed; see <a href="#ecn" class="xref">Section 13.4</a>.<a href="#section-21.8-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="reset-oracle">
+<section id="section-21.9">
+        <h3 id="name-stateless-reset-oracle">
+<a href="#section-21.9" class="section-number selfRef">21.9. </a><a href="#name-stateless-reset-oracle" class="section-name selfRef">Stateless Reset Oracle</a>
+        </h3>
+<p id="section-21.9-1">Stateless resets create a possible denial of service attack analogous to a TCP
+reset injection. This attack is possible if an attacker is able to cause a
+stateless reset token to be generated for a connection with a selected
+connection ID. An attacker that can cause this token to be generated can reset
+an active connection with the same connection ID.<a href="#section-21.9-1" class="pilcrow">¶</a></p>
+<p id="section-21.9-2">If a packet can be routed to different instances that share a static key, for
+example by changing an IP address or port, then an attacker can cause the server
+to send a stateless reset.  To defend against this style of denial service,
+endpoints that share a static key for stateless reset (see <a href="#reset-token" class="xref">Section 10.4.2</a>) MUST
+be arranged so that packets with a given connection ID always arrive at an
+instance that has connection state, unless that connection is no longer active.<a href="#section-21.9-2" class="pilcrow">¶</a></p>
+<p id="section-21.9-3">In the case of a cluster that uses dynamic load balancing, it's possible that a
+change in load balancer configuration could happen while an active instance
+retains connection state; even if an instance retains connection state, the
+change in routing and resulting stateless reset will result in the connection
+being terminated.  If there is no chance in the packet being routed to the
+correct instance, it is better to send a stateless reset than wait for
+connections to time out.  However, this is acceptable only if the routing cannot
+be influenced by an attacker.<a href="#section-21.9-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="version-downgrade">
+<section id="section-21.10">
+        <h3 id="name-version-downgrade">
+<a href="#section-21.10" class="section-number selfRef">21.10. </a><a href="#name-version-downgrade" class="section-name selfRef">Version Downgrade</a>
+        </h3>
+<p id="section-21.10-1">This document defines QUIC Version Negotiation packets in
+<a href="#version-negotiation" class="xref">Section 6</a>, which can be used to negotiate the QUIC version used
+between two endpoints. However, this document does not specify how this
+negotiation will be performed between this version and subsequent future
+versions.  In particular, Version Negotiation packets do not contain any
+mechanism to prevent version downgrade attacks.  Future versions of QUIC that
+use Version Negotiation packets MUST define a mechanism that is robust against
+version downgrade attacks.<a href="#section-21.10-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="targeted-attacks-by-routing">
+<section id="section-21.11">
+        <h3 id="name-targeted-attacks-by-routing">
+<a href="#section-21.11" class="section-number selfRef">21.11. </a><a href="#name-targeted-attacks-by-routing" class="section-name selfRef">Targeted Attacks by Routing</a>
+        </h3>
+<p id="section-21.11-1">Deployments should limit the ability of an attacker to target a new connection
+to a particular server instance.  This means that client-controlled fields, such
+as the initial Destination Connection ID used on Initial and 0-RTT packets
+SHOULD NOT be used by themselves to make routing decisions.  Ideally, routing
+decisions are made independently of client-selected values; a Source Connection
+ID can be selected to route later packets to the same server.<a href="#section-21.11-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="security-properties">
+<section id="section-21.12">
+        <h3 id="name-overview-of-security-proper">
+<a href="#section-21.12" class="section-number selfRef">21.12. </a><a href="#name-overview-of-security-proper" class="section-name selfRef">Overview of Security Properties</a>
+        </h3>
+<p id="section-21.12-1">A complete security analysis of QUIC is outside the scope of this document.
+This section provides an informal description of the desired security properties
+as an aid to implementors and to help guide protocol analysis.<a href="#section-21.12-1" class="pilcrow">¶</a></p>
+<p id="section-21.12-2">QUIC assumes the threat model described in <span>[<a href="#SEC-CONS" class="xref">SEC-CONS</a>]</span> and provides
+protections against many of the attacks that arise from that model.<a href="#section-21.12-2" class="pilcrow">¶</a></p>
+<p id="section-21.12-3">For this purpose, attacks are divided into passive and active attacks.  Passive
+attackers have the capability to read packets from the network, while active
+attackers also have the capability to write packets into the network.  However,
+a passive attack may involve an attacker with the ability to cause a routing
+change or other modification in the path taken by packets that comprise a
+connection.<a href="#section-21.12-3" class="pilcrow">¶</a></p>
+<p id="section-21.12-4">Attackers are additionally categorized as either on-path attackers or off-path
+attackers; see Section 3.5 of <span>[<a href="#SEC-CONS" class="xref">SEC-CONS</a>]</span>.  An on-path attacker can read,
+modify, or remove any packet it observes such that it no longer reaches its
+destination, while an off-path attacker observes the packets, but cannot prevent
+the original packet from reaching its intended destination.  An off-path
+attacker can also transmit arbitrary packets.<a href="#section-21.12-4" class="pilcrow">¶</a></p>
+<p id="section-21.12-5">Properties of the handshake, protected packets, and connection migration are
+considered separately.<a href="#section-21.12-5" class="pilcrow">¶</a></p>
+<div id="handshake-properties">
+<section id="section-21.12.1">
+          <h4 id="name-handshake">
+<a href="#section-21.12.1" class="section-number selfRef">21.12.1. </a><a href="#name-handshake" class="section-name selfRef">Handshake</a>
+          </h4>
+<p id="section-21.12.1-1">The QUIC handshake incorporates the TLS 1.3 handshake and inherits the
+cryptographic properties described in Appendix E.1 of <span>[<a href="#TLS13" class="xref">TLS13</a>]</span>. Many
+of the security properties of QUIC depend on the TLS handshake providing these
+properties. Any attack on the TLS handshake could affect QUIC.<a href="#section-21.12.1-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.1-2">Any attack on the TLS handshake that compromises the secrecy or uniqueness
+of session keys affects other security guarantees provided by QUIC that depends
+on these keys. For instance, migration (<a href="#migration" class="xref">Section 9</a>) depends on the efficacy
+of confidentiality protections, both for the negotiation of keys using the TLS
+handshake and for QUIC packet protection, to avoid linkability across network
+paths.<a href="#section-21.12.1-2" class="pilcrow">¶</a></p>
+<p id="section-21.12.1-3">An attack on the integrity of the TLS handshake might allow an attacker to
+affect the selection of application protocol or QUIC version.<a href="#section-21.12.1-3" class="pilcrow">¶</a></p>
+<p id="section-21.12.1-4">In addition to the properties provided by TLS, the QUIC handshake provides some
+defense against DoS attacks on the handshake.<a href="#section-21.12.1-4" class="pilcrow">¶</a></p>
+<div id="anti-amplification">
+<section id="section-21.12.1.1">
+            <h5 id="name-anti-amplification">
+<a href="#section-21.12.1.1" class="section-number selfRef">21.12.1.1. </a><a href="#name-anti-amplification" class="section-name selfRef">Anti-Amplification</a>
+            </h5>
+<p id="section-21.12.1.1-1">Address validation (<a href="#address-validation" class="xref">Section 8</a>) is used to verify that an entity
+that claims a given address is able to receive packets at that address. Address
+validation limits amplification attack targets to addresses for which an
+attacker is either on-path or off-path.<a href="#section-21.12.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.1.1-2">Prior to validation, endpoints are limited in what they are able to send.
+During the handshake, a server cannot send more than three times the data it
+receives; clients that initiate new connections or migrate to a new network
+path are limited.<a href="#section-21.12.1.1-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="server-side-dos">
+<section id="section-21.12.1.2">
+            <h5 id="name-server-side-dos">
+<a href="#section-21.12.1.2" class="section-number selfRef">21.12.1.2. </a><a href="#name-server-side-dos" class="section-name selfRef">Server-Side DoS</a>
+            </h5>
+<p id="section-21.12.1.2-1">Computing the server's first flight for a full handshake is potentially
+expensive, requiring both a signature and a key exchange computation. In order
+to prevent computational DoS attacks, the Retry packet provides a cheap token
+exchange mechanism which allows servers to validate a client's IP address prior
+to doing any expensive computations at the cost of a single round trip. After a
+successful handshake, servers can issue new tokens to a client which will allow
+new connection establishment without incurring this cost.<a href="#section-21.12.1.2-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="on-path-handshake-termination">
+<section id="section-21.12.1.3">
+            <h5 id="name-on-path-handshake-terminati">
+<a href="#section-21.12.1.3" class="section-number selfRef">21.12.1.3. </a><a href="#name-on-path-handshake-terminati" class="section-name selfRef">On-Path Handshake Termination</a>
+            </h5>
+<p id="section-21.12.1.3-1">An on-path or off-path attacker can force a handshake to fail by replacing or
+racing Initial packets. Once valid Initial packets have been exchanged,
+subsequent Handshake packets are protected with the handshake keys and an
+on-path attacker cannot force handshake failure other than by dropping packets
+to cause endpoints to abandon the attempt.<a href="#section-21.12.1.3-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.1.3-2">An on-path attacker can also replace the addresses of packets on either side and
+therefore cause the client or server to have an incorrect view of the remote
+addresses. Such an attack is indistinguishable from the functions performed by a
+NAT.<a href="#section-21.12.1.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="parameter-negotiation">
+<section id="section-21.12.1.4">
+            <h5 id="name-parameter-negotiation">
+<a href="#section-21.12.1.4" class="section-number selfRef">21.12.1.4. </a><a href="#name-parameter-negotiation" class="section-name selfRef">Parameter Negotiation</a>
+            </h5>
+<p id="section-21.12.1.4-1">The entire handshake is cryptographically protected, with the Initial packets
+being encrypted with per-version keys and the Handshake and later packets being
+encrypted with keys derived from the TLS key exchange.  Further, parameter
+negotiation is folded into the TLS transcript and thus provides the same
+integrity guarantees as ordinary TLS negotiation.  An attacker can observe
+the client's transport parameters (as long as it knows the version-specific
+keys) but cannot observe the server's transport parameters and cannot influence
+parameter negotiation.<a href="#section-21.12.1.4-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.1.4-2">Connection IDs are unencrypted but integrity protected in all packets.<a href="#section-21.12.1.4-2" class="pilcrow">¶</a></p>
+<p id="section-21.12.1.4-3">This version of QUIC does not incorporate a version negotiation mechanism;
+implementations of incompatible versions will simply fail to establish a
+connection.<a href="#section-21.12.1.4-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="protected-packet-properties">
+<section id="section-21.12.2">
+          <h4 id="name-protected-packets-2">
+<a href="#section-21.12.2" class="section-number selfRef">21.12.2. </a><a href="#name-protected-packets-2" class="section-name selfRef">Protected Packets</a>
+          </h4>
+<p id="section-21.12.2-1">Packet protection (<a href="#packet-protected" class="xref">Section 12.1</a>) provides authentication and encryption
+of all packets except Version Negotiation packets, though Initial and Retry
+packets have limited encryption and authentication based on version-specific
+keys; see <span>[<a href="#QUIC-TLS" class="xref">QUIC-TLS</a>]</span> for more details. This section considers passive and
+active attacks against protected packets.<a href="#section-21.12.2-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.2-2">Both on-path and off-path attackers can mount a passive attack in which they
+save observed packets for an offline attack against packet protection at a
+future time; this is true for any observer of any packet on any network.<a href="#section-21.12.2-2" class="pilcrow">¶</a></p>
+<p id="section-21.12.2-3">A blind attacker, one who injects packets without being able to observe valid
+packets for a connection, is unlikely to be successful, since packet protection
+ensures that valid packets are only generated by endpoints which possess the
+key material established during the handshake; see <a href="#handshake" class="xref">Section 7</a> and
+<a href="#handshake-properties" class="xref">Section 21.12.1</a>. Similarly, any active attacker that observes packets
+and attempts to insert new data or modify existing data in those packets should
+not be able to generate packets deemed valid by the receiving endpoint.<a href="#section-21.12.2-3" class="pilcrow">¶</a></p>
+<p id="section-21.12.2-4">A spoofing attack, in which an active attacker rewrites unprotected parts of a
+packet that it forwards or injects, such as the source or destination
+address, is only effective if the attacker can forward packets to the original
+endpoint.  Packet protection ensures that the packet payloads can only be
+processed by the endpoints that completed the handshake, and invalid
+packets are ignored by those endpoints.<a href="#section-21.12.2-4" class="pilcrow">¶</a></p>
+<p id="section-21.12.2-5">An attacker can also modify the boundaries between packets and UDP datagrams,
+causing multiple packets to be coalesced into a single datagram, or splitting
+coalesced packets into multiple datagrams. Aside from datagrams containing
+Initial packets, which require padding, modification of how packets are
+arranged in datagrams has no functional effect on a connection, although it
+might change some performance characteristics.<a href="#section-21.12.2-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="migration-properties">
+<section id="section-21.12.3">
+          <h4 id="name-connection-migration-2">
+<a href="#section-21.12.3" class="section-number selfRef">21.12.3. </a><a href="#name-connection-migration-2" class="section-name selfRef">Connection Migration</a>
+          </h4>
+<p id="section-21.12.3-1">Connection Migration (<a href="#migration" class="xref">Section 9</a>) provides endpoints with the ability to
+transition between IP addresses and ports on multiple paths, using one path at a
+time for transmission and receipt of non-probing frames.  Path validation
+(<a href="#migrate-validate" class="xref">Section 8.2</a>) establishes that a peer is both willing and able
+to receive packets sent on a particular path.  This helps reduce the effects of
+address spoofing by limiting the number of packets sent to a spoofed address.<a href="#section-21.12.3-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.3-2">This section describes the intended security properties of connection migration
+when under various types of DoS attacks.<a href="#section-21.12.3-2" class="pilcrow">¶</a></p>
+<div id="on-path-active-attacks">
+<section id="section-21.12.3.1">
+            <h5 id="name-on-path-active-attacks">
+<a href="#section-21.12.3.1" class="section-number selfRef">21.12.3.1. </a><a href="#name-on-path-active-attacks" class="section-name selfRef">On-Path Active Attacks</a>
+            </h5>
+<p id="section-21.12.3.1-1">An attacker that can cause a packet it observes to no longer reach its intended
+destination is considered an on-path attacker. When an attacker is present
+between a client and server, endpoints are required to send packets through the
+attacker to establish connectivity on a given path.<a href="#section-21.12.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.1-2">An on-path attacker can:<a href="#section-21.12.3.1-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-21.12.3.1-3.1">Inspect packets<a href="#section-21.12.3.1-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.1-3.2">Modify IP and UDP packet headers<a href="#section-21.12.3.1-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.1-3.3">Inject new packets<a href="#section-21.12.3.1-3.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.1-3.4">Delay packets<a href="#section-21.12.3.1-3.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.1-3.5">Reorder packets<a href="#section-21.12.3.1-3.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.1-3.6">Drop packets<a href="#section-21.12.3.1-3.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.1-3.7">Split and merge datagrams along packet boundaries<a href="#section-21.12.3.1-3.7" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-21.12.3.1-4">An on-path attacker cannot:<a href="#section-21.12.3.1-4" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-21.12.3.1-5.1">Modify an authenticated portion of a packet and cause the recipient to accept
+that packet<a href="#section-21.12.3.1-5.1" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-21.12.3.1-6">An on-path attacker has the opportunity to modify the packets that it observes,
+however any modifications to an authenticated portion of a packet will cause it
+to be dropped by the receiving endpoint as invalid, as packet payloads are both
+authenticated and encrypted.<a href="#section-21.12.3.1-6" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.1-7">In the presence of an on-path attacker, QUIC aims to provide the following
+properties:<a href="#section-21.12.3.1-7" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-21.12.3.1-8">
+              <li id="section-21.12.3.1-8.1">An on-path attacker can prevent use of a path for a connection, causing
+it to fail if it cannot use a different path that does not contain the
+attacker. This can be achieved by dropping all packets, modifying them so
+that they fail to decrypt, or other methods.<a href="#section-21.12.3.1-8.1" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.1-8.2">An on-path attacker can prevent migration to a new path for which the
+attacker is also on-path by causing path validation to fail on the new path.<a href="#section-21.12.3.1-8.2" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.1-8.3">An on-path attacker cannot prevent a client from migrating to a path for
+which the attacker is not on-path.<a href="#section-21.12.3.1-8.3" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.1-8.4">An on-path attacker can reduce the throughput of a connection by delaying
+packets or dropping them.<a href="#section-21.12.3.1-8.4" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.1-8.5">An on-path attacker cannot cause an endpoint to accept a packet for which it
+has modified an authenticated portion of that packet.<a href="#section-21.12.3.1-8.5" class="pilcrow">¶</a>
+</li>
+</ol>
+</section>
+</div>
+<div id="off-path-active-attacks">
+<section id="section-21.12.3.2">
+            <h5 id="name-off-path-active-attacks">
+<a href="#section-21.12.3.2" class="section-number selfRef">21.12.3.2. </a><a href="#name-off-path-active-attacks" class="section-name selfRef">Off-Path Active Attacks</a>
+            </h5>
+<p id="section-21.12.3.2-1">An off-path attacker is not directly on the path between a client and server,
+but could be able to obtain copies of some or all packets sent between the
+client and the server. It is also able to send copies of those packets to
+either endpoint.<a href="#section-21.12.3.2-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.2-2">An off-path attacker can:<a href="#section-21.12.3.2-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-21.12.3.2-3.1">Inspect packets<a href="#section-21.12.3.2-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.2-3.2">Inject new packets<a href="#section-21.12.3.2-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.2-3.3">Reorder injected packets<a href="#section-21.12.3.2-3.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-21.12.3.2-4">An off-path attacker cannot:<a href="#section-21.12.3.2-4" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-21.12.3.2-5.1">Modify any part of a packet<a href="#section-21.12.3.2-5.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.2-5.2">Delay packets<a href="#section-21.12.3.2-5.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.2-5.3">Drop packets<a href="#section-21.12.3.2-5.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.2-5.4">Reorder original packets<a href="#section-21.12.3.2-5.4" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-21.12.3.2-6">An off-path attacker can modify packets that it has observed and inject them
+back into the network, potentially with spoofed source and destination
+addresses.<a href="#section-21.12.3.2-6" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.2-7">For the purposes of this discussion, it is assumed that an off-path attacker
+has the ability to observe, modify, and re-inject a packet into the network
+that will reach the destination endpoint prior to the arrival of the original
+packet observed by the attacker. In other words, an attacker has the ability to
+consistently "win" a race with the legitimate packets between the endpoints,
+potentially causing the original packet to be ignored by the recipient.<a href="#section-21.12.3.2-7" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.2-8">It is also assumed that an attacker has the resources necessary to affect NAT
+state, potentially both causing an endpoint to lose its NAT binding, and an
+attacker to obtain the same port for use with its traffic.<a href="#section-21.12.3.2-8" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.2-9">In the presence of an off-path attacker, QUIC aims to provide the following
+properties:<a href="#section-21.12.3.2-9" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-21.12.3.2-10">
+              <li id="section-21.12.3.2-10.1">An off-path attacker can race packets and attempt to become a "limited"
+on-path attacker.<a href="#section-21.12.3.2-10.1" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.2-10.2">An off-path attacker can cause path validation to succeed for forwarded
+packets with the source address listed as the off-path attacker as long as
+it can provide improved connectivity between the client and the server.<a href="#section-21.12.3.2-10.2" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.2-10.3">An off-path attacker cannot cause a connection to close once the handshake
+has completed.<a href="#section-21.12.3.2-10.3" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.2-10.4">An off-path attacker cannot cause migration to a new path to fail if it
+cannot observe the new path.<a href="#section-21.12.3.2-10.4" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.2-10.5">An off-path attacker can become a limited on-path attacker during migration
+to a new path for which it is also an off-path attacker.<a href="#section-21.12.3.2-10.5" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.2-10.6">An off-path attacker can become a limited on-path attacker by affecting
+shared NAT state such that it sends packets to the server from the same IP
+address and port that the client originally used.<a href="#section-21.12.3.2-10.6" class="pilcrow">¶</a>
+</li>
+</ol>
+</section>
+</div>
+<div id="limited-on-path-active-attacks">
+<section id="section-21.12.3.3">
+            <h5 id="name-limited-on-path-active-atta">
+<a href="#section-21.12.3.3" class="section-number selfRef">21.12.3.3. </a><a href="#name-limited-on-path-active-atta" class="section-name selfRef">Limited On-Path Active Attacks</a>
+            </h5>
+<p id="section-21.12.3.3-1">A limited on-path attacker is an off-path attacker that has offered improved
+routing of packets by duplicating and forwarding original packets between the
+server and the client, causing those packets to arrive before the original
+copies such that the original packets are dropped by the destination endpoint.<a href="#section-21.12.3.3-1" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.3-2">A limited on-path attacker differs from an on-path attacker in that it is not on
+the original path between endpoints, and therefore the original packets sent by
+an endpoint are still reaching their destination.  This means that a future
+failure to route copied packets to the destination faster than their original
+path will not prevent the original packets from reaching the destination.<a href="#section-21.12.3.3-2" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.3-3">A limited on-path attacker can:<a href="#section-21.12.3.3-3" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-21.12.3.3-4.1">Inspect packets<a href="#section-21.12.3.3-4.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.3-4.2">Inject new packets<a href="#section-21.12.3.3-4.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.3-4.3">Modify unencrypted packet headers<a href="#section-21.12.3.3-4.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.3-4.4">Reorder packets<a href="#section-21.12.3.3-4.4" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-21.12.3.3-5">A limited on-path attacker cannot:<a href="#section-21.12.3.3-5" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-21.12.3.3-6.1">Delay packets so that they arrive later than packets sent on the original path<a href="#section-21.12.3.3-6.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.3-6.2">Drop packets<a href="#section-21.12.3.3-6.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-21.12.3.3-6.3">Modify the authenticated and encrypted portion of a packet and cause the
+ recipient to accept that packet<a href="#section-21.12.3.3-6.3" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-21.12.3.3-7">A limited on-path attacker can only delay packets up to the point that the
+original packets arrive before the duplicate packets, meaning that it cannot
+offer routing with worse latency than the original path.  If a limited on-path
+attacker drops packets, the original copy will still arrive at the destination
+endpoint.<a href="#section-21.12.3.3-7" class="pilcrow">¶</a></p>
+<p id="section-21.12.3.3-8">In the presence of a limited on-path attacker, QUIC aims to provide the
+following properties:<a href="#section-21.12.3.3-8" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-21.12.3.3-9">
+              <li id="section-21.12.3.3-9.1">A limited on-path attacker cannot cause a connection to close once the
+handshake has completed.<a href="#section-21.12.3.3-9.1" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.3-9.2">A limited on-path attacker cannot cause an idle connection to close if the
+client is first to resume activity.<a href="#section-21.12.3.3-9.2" class="pilcrow">¶</a>
+</li>
+<li id="section-21.12.3.3-9.3">A limited on-path attacker can cause an idle connection to be deemed lost if
+the server is the first to resume activity.<a href="#section-21.12.3.3-9.3" class="pilcrow">¶</a>
+</li>
+</ol>
+<p id="section-21.12.3.3-10">Note that these guarantees are the same guarantees provided for any NAT, for the
+same reasons.<a href="#section-21.12.3.3-10" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="iana">
+<section id="section-22">
+      <h2 id="name-iana-considerations">
+<a href="#section-22" class="section-number selfRef">22. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
+      </h2>
+<p id="section-22-1">This document establishes several registries for the management of codepoints in
+QUIC.  These registries operate on a common set of policies as defined in
+<a href="#iana-policy" class="xref">Section 22.1</a>.<a href="#section-22-1" class="pilcrow">¶</a></p>
+<div id="iana-policy">
+<section id="section-22.1">
+        <h3 id="name-registration-policies-for-q">
+<a href="#section-22.1" class="section-number selfRef">22.1. </a><a href="#name-registration-policies-for-q" class="section-name selfRef">Registration Policies for QUIC Registries</a>
+        </h3>
+<p id="section-22.1-1">All QUIC registries allow for both provisional and permanent registration of
+codepoints.  This section documents policies that are common to these
+registries.<a href="#section-22.1-1" class="pilcrow">¶</a></p>
+<div id="iana-provisional">
+<section id="section-22.1.1">
+          <h4 id="name-provisional-registrations">
+<a href="#section-22.1.1" class="section-number selfRef">22.1.1. </a><a href="#name-provisional-registrations" class="section-name selfRef">Provisional Registrations</a>
+          </h4>
+<p id="section-22.1.1-1">Provisional registration of codepoints are intended to allow for private use and
+experimentation with extensions to QUIC.  Provisional registrations only require
+the inclusion of the codepoint value and contact information.  However,
+provisional registrations could be reclaimed and reassigned for another purpose.<a href="#section-22.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-22.1.1-2">Provisional registrations require Expert Review, as defined in Section 4.5 of
+<span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.  Designated expert(s) are advised that only registrations for an
+excessive proportion of remaining codepoint space or the very first unassigned
+value (see <a href="#iana-random" class="xref">Section 22.1.2</a>) can be rejected.<a href="#section-22.1.1-2" class="pilcrow">¶</a></p>
+<p id="section-22.1.1-3">Provisional registrations will include a date field that indicates when the
+registration was last updated.  A request to update the date on any provisional
+registration can be made without review from the designated expert(s).<a href="#section-22.1.1-3" class="pilcrow">¶</a></p>
+<p id="section-22.1.1-4">All QUIC registries include the following fields to support provisional
+registration:<a href="#section-22.1.1-4" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-22.1.1-5">
+            <dt id="section-22.1.1-5.1">Value:</dt>
+<dd id="section-22.1.1-5.2">
+  The assigned codepoint.<a href="#section-22.1.1-5.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-22.1.1-5.3">Status:</dt>
+<dd id="section-22.1.1-5.4">
+  "Permanent" or "Provisional".<a href="#section-22.1.1-5.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-22.1.1-5.5">Specification:</dt>
+<dd id="section-22.1.1-5.6">
+  A reference to a publicly available specification for the value.<a href="#section-22.1.1-5.6" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-22.1.1-5.7">Date:</dt>
+<dd id="section-22.1.1-5.8">
+  The date of last update to the registration.<a href="#section-22.1.1-5.8" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-22.1.1-5.9">Contact:</dt>
+<dd id="section-22.1.1-5.10">
+  Contact details for the registrant.<a href="#section-22.1.1-5.10" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-22.1.1-5.11">Notes:</dt>
+<dd id="section-22.1.1-5.12">
+  Supplementary notes about the registration.<a href="#section-22.1.1-5.12" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-22.1.1-6">Provisional registrations MAY omit the Specification and Notes fields, plus any
+additional fields that might be required for a permanent registration.  The Date
+field is not required as part of requesting a registration as it is set to the
+date the registration is created or updated.<a href="#section-22.1.1-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-random">
+<section id="section-22.1.2">
+          <h4 id="name-selecting-codepoints">
+<a href="#section-22.1.2" class="section-number selfRef">22.1.2. </a><a href="#name-selecting-codepoints" class="section-name selfRef">Selecting Codepoints</a>
+          </h4>
+<p id="section-22.1.2-1">New uses of codepoints from QUIC registries SHOULD use a randomly selected
+codepoint that excludes both existing allocations and the first unallocated
+codepoint in the selected space.  Requests for multiple codepoints MAY use a
+contiguous range.  This minimizes the risk that differing semantics are
+attributed to the same codepoint by different implementations.  Use of the first
+codepoint in a range is intended for use by specifications that are developed
+through the standards process <span>[<a href="#STD" class="xref">STD</a>]</span> and its allocation MUST be
+negotiated with IANA before use.<a href="#section-22.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-22.1.2-2">For codepoints that are encoded in variable-length integers
+(<a href="#integer-encoding" class="xref">Section 16</a>), such as frame types, codepoints that encode to four or
+eight bytes (that is, values 2^14 and above) SHOULD be used unless the usage is
+especially sensitive to having a longer encoding.<a href="#section-22.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-22.1.2-3">Applications to register codepoints in QUIC registries MAY include a codepoint
+as part of the registration.  IANA MUST allocate the selected codepoint unless
+that codepoint is already assigned or the codepoint is the first unallocated
+codepoint in the registry.<a href="#section-22.1.2-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="reclaiming-provisional-codepoints">
+<section id="section-22.1.3">
+          <h4 id="name-reclaiming-provisional-code">
+<a href="#section-22.1.3" class="section-number selfRef">22.1.3. </a><a href="#name-reclaiming-provisional-code" class="section-name selfRef">Reclaiming Provisional Codepoints</a>
+          </h4>
+<p id="section-22.1.3-1">A request might be made to remove an unused provisional registration from the
+registry to reclaim space in a registry, or portion of the registry (such as the
+64-16383 range for codepoints that use variable-length encodings).  This SHOULD
+be done only for the codepoints with the earliest recorded date and entries that
+have been updated less than a year prior SHOULD NOT be reclaimed.<a href="#section-22.1.3-1" class="pilcrow">¶</a></p>
+<p id="section-22.1.3-2">A request to remove a codepoint MUST be reviewed by the designated expert(s).
+The expert(s) MUST attempt to determine whether the codepoint is still in use.
+Experts are advised to contact the listed contacts for the registration, plus as
+wide a set of protocol implementers as possible in order to determine whether
+any use of the codepoint is known.  The expert(s) are advised to allow at least
+four weeks for responses.<a href="#section-22.1.3-2" class="pilcrow">¶</a></p>
+<p id="section-22.1.3-3">If any use of the codepoints is identified by this search or a request to update
+the registration is made, the codepoint MUST NOT be reclaimed.  Instead, the
+date on the registration is updated.  A note might be added for the registration
+recording relevant information that was learned.<a href="#section-22.1.3-3" class="pilcrow">¶</a></p>
+<p id="section-22.1.3-4">If no use of the codepoint was identified and no request was made to update the
+registration, the codepoint MAY be removed from the registry.<a href="#section-22.1.3-4" class="pilcrow">¶</a></p>
+<p id="section-22.1.3-5">This process also applies to requests to change a provisional registration into
+a permanent registration, except that the goal is not to determine whether there
+is no use of the codepoint, but to determine that the registration is an
+accurate representation of any deployed usage.<a href="#section-22.1.3-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-permanent">
+<section id="section-22.1.4">
+          <h4 id="name-permanent-registrations">
+<a href="#section-22.1.4" class="section-number selfRef">22.1.4. </a><a href="#name-permanent-registrations" class="section-name selfRef">Permanent Registrations</a>
+          </h4>
+<p id="section-22.1.4-1">Permanent registrations in QUIC registries use the Specification Required policy
+<span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>, unless otherwise specified.  The designated expert(s) verify that
+a specification exists and is readily accessible.  Expert(s) are encouraged to
+be biased towards approving registrations unless they are abusive, frivolous, or
+actively harmful (not merely aesthetically displeasing, or architecturally
+dubious).  The creation of a registry MAY specify additional constraints on
+permanent registrations.<a href="#section-22.1.4-1" class="pilcrow">¶</a></p>
+<p id="section-22.1.4-2">The creation of a registries MAY identify a range of codepoints where
+registrations are governed by a different registration policy.  For instance,
+the registries for 62-bit codepoints in this document have stricter policies for
+codepoints in the range from 0 to 63.<a href="#section-22.1.4-2" class="pilcrow">¶</a></p>
+<p id="section-22.1.4-3">Any stricter requirements for permanent registrations do not prevent provisional
+registrations for affected codepoints.  For instance, a provisional registration
+for a frame type <a href="#iana-frames" class="xref">Section 22.3</a> of 61 could be requested.<a href="#section-22.1.4-3" class="pilcrow">¶</a></p>
+<p id="section-22.1.4-4">All registrations made by Standards Track publications MUST be permanent.<a href="#section-22.1.4-4" class="pilcrow">¶</a></p>
+<p id="section-22.1.4-5">All registrations in this document are assigned a permanent status and list as
+contact both the IESG (ietf@ietf.org) and the QUIC working group
+(<a href="mailto:quic@ietf.org">quic@ietf.org</a>).<a href="#section-22.1.4-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="iana-transport-parameters">
+<section id="section-22.2">
+        <h3 id="name-quic-transport-parameter-re">
+<a href="#section-22.2" class="section-number selfRef">22.2. </a><a href="#name-quic-transport-parameter-re" class="section-name selfRef">QUIC Transport Parameter Registry</a>
+        </h3>
+<p id="section-22.2-1">IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" under a
+"QUIC" heading.<a href="#section-22.2-1" class="pilcrow">¶</a></p>
+<p id="section-22.2-2">The "QUIC Transport Parameters" registry governs a 62-bit space.  This registry
+follows the registration policy from <a href="#iana-policy" class="xref">Section 22.1</a>.  Permanent registrations
+in this registry are assigned using the Specification Required policy
+<span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-22.2-2" class="pilcrow">¶</a></p>
+<p id="section-22.2-3">In addition to the fields in <a href="#iana-provisional" class="xref">Section 22.1.1</a>, permanent registrations in
+this registry MUST include the following fields:<a href="#section-22.2-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-22.2-4">
+          <dt id="section-22.2-4.1">Parameter Name:</dt>
+<dd id="section-22.2-4.2">
+  A short mnemonic for the parameter.<a href="#section-22.2-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-22.2-5">The initial contents of this registry are shown in <a href="#iana-tp-table" class="xref">Table 6</a>.<a href="#section-22.2-5" class="pilcrow">¶</a></p>
+<span id="name-initial-quic-transport-para"></span><div id="iana-tp-table">
+<table class="center" id="table-6">
+          <caption>
+<a href="#table-6" class="selfRef">Table 6</a>:
+<a href="#name-initial-quic-transport-para" class="selfRef">Initial QUIC Transport Parameters Entries</a>
+          </caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Value</th>
+              <th class="text-left" rowspan="1" colspan="1">Parameter Name</th>
+              <th class="text-left" rowspan="1" colspan="1">Specification</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x00</td>
+              <td class="text-left" rowspan="1" colspan="1">original_destination_connection_id</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x01</td>
+              <td class="text-left" rowspan="1" colspan="1">max_idle_timeout</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x02</td>
+              <td class="text-left" rowspan="1" colspan="1">stateless_reset_token</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x03</td>
+              <td class="text-left" rowspan="1" colspan="1">max_udp_payload_size</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x04</td>
+              <td class="text-left" rowspan="1" colspan="1">initial_max_data</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x05</td>
+              <td class="text-left" rowspan="1" colspan="1">initial_max_stream_data_bidi_local</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x06</td>
+              <td class="text-left" rowspan="1" colspan="1">initial_max_stream_data_bidi_remote</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x07</td>
+              <td class="text-left" rowspan="1" colspan="1">initial_max_stream_data_uni</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x08</td>
+              <td class="text-left" rowspan="1" colspan="1">initial_max_streams_bidi</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x09</td>
+              <td class="text-left" rowspan="1" colspan="1">initial_max_streams_uni</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x0a</td>
+              <td class="text-left" rowspan="1" colspan="1">ack_delay_exponent</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x0b</td>
+              <td class="text-left" rowspan="1" colspan="1">max_ack_delay</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x0c</td>
+              <td class="text-left" rowspan="1" colspan="1">disable_active_migration</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x0d</td>
+              <td class="text-left" rowspan="1" colspan="1">preferred_address</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x0e</td>
+              <td class="text-left" rowspan="1" colspan="1">active_connection_id_limit</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x0f</td>
+              <td class="text-left" rowspan="1" colspan="1">initial_source_connection_id</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x10</td>
+              <td class="text-left" rowspan="1" colspan="1">retry_source_connection_id</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>
+</td>
+            </tr>
+          </tbody>
+        </table>
+</div>
+<p id="section-22.2-7">Additionally, each value of the format <code>31 * N + 27</code> for integer values of N
+(that is, 27, 58, 89, ...) are reserved and MUST NOT be assigned by IANA.<a href="#section-22.2-7" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-frames">
+<section id="section-22.3">
+        <h3 id="name-quic-frame-type-registry">
+<a href="#section-22.3" class="section-number selfRef">22.3. </a><a href="#name-quic-frame-type-registry" class="section-name selfRef">QUIC Frame Type Registry</a>
+        </h3>
+<p id="section-22.3-1">IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
+"QUIC" heading.<a href="#section-22.3-1" class="pilcrow">¶</a></p>
+<p id="section-22.3-2">The "QUIC Frame Types" registry governs a 62-bit space.  This registry follows
+the registration policy from <a href="#iana-policy" class="xref">Section 22.1</a>.  Permanent registrations in this
+registry are assigned using the Specification Required policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>,
+except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are
+assigned using Standards Action or IESG Approval as defined in Section 4.9 and
+4.10 of <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-22.3-2" class="pilcrow">¶</a></p>
+<p id="section-22.3-3">In addition to the fields in <a href="#iana-provisional" class="xref">Section 22.1.1</a>, permanent registrations in
+this registry MUST include the following fields:<a href="#section-22.3-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-22.3-4">
+          <dt id="section-22.3-4.1">Frame Name:</dt>
+<dd id="section-22.3-4.2">
+  A short mnemonic for the frame type.<a href="#section-22.3-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-22.3-5">In addition to the advice in <a href="#iana-policy" class="xref">Section 22.1</a>, specifications for new permanent
+registrations SHOULD describe the means by which an endpoint might determine
+that it can send the identified type of frame.  An accompanying transport
+parameter registration is expected for most registrations; see
+<a href="#iana-transport-parameters" class="xref">Section 22.2</a>.  Specifications for permanent registrations also
+needs to describe the format and assigned semantics of any fields in the frame.<a href="#section-22.3-5" class="pilcrow">¶</a></p>
+<p id="section-22.3-6">The initial contents of this registry are tabulated in <a href="#frame-types" class="xref">Table 3</a>.<a href="#section-22.3-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="iana-error-codes">
+<section id="section-22.4">
+        <h3 id="name-quic-transport-error-codes-">
+<a href="#section-22.4" class="section-number selfRef">22.4. </a><a href="#name-quic-transport-error-codes-" class="section-name selfRef">QUIC Transport Error Codes Registry</a>
+        </h3>
+<p id="section-22.4-1">IANA [SHALL add/has added] a registry for "QUIC Transport Error Codes" under a
+"QUIC" heading.<a href="#section-22.4-1" class="pilcrow">¶</a></p>
+<p id="section-22.4-2">The "QUIC Transport Error Codes" registry governs a 62-bit space.  This space is
+split into three spaces that are governed by different policies.  Permanent
+registrations in this registry are assigned using the Specification Required
+policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>, except for values between 0x00 and 0x3f (in hexadecimal;
+inclusive), which are assigned using Standards Action or IESG Approval as
+defined in Section 4.9 and 4.10 of <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-22.4-2" class="pilcrow">¶</a></p>
+<p id="section-22.4-3">In addition to the fields in <a href="#iana-provisional" class="xref">Section 22.1.1</a>, permanent registrations in
+this registry MUST include the following fields:<a href="#section-22.4-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-22.4-4">
+          <dt id="section-22.4-4.1">Code:</dt>
+<dd id="section-22.4-4.2">
+  A short mnemonic for the parameter.<a href="#section-22.4-4.2" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+<dt id="section-22.4-4.3">Description:</dt>
+<dd id="section-22.4-4.4">
+  A brief description of the error code semantics, which MAY be a summary if a
+specification reference is provided.<a href="#section-22.4-4.4" class="pilcrow">¶</a>
+</dd>
+<dd class="break"></dd>
+</dl>
+<p id="section-22.4-5">The initial contents of this registry are shown in <a href="#iana-error-table" class="xref">Table 7</a>.<a href="#section-22.4-5" class="pilcrow">¶</a></p>
+<span id="name-initial-quic-transport-erro"></span><div id="iana-error-table">
+<table class="center" id="table-7">
+          <caption>
+<a href="#table-7" class="selfRef">Table 7</a>:
+<a href="#name-initial-quic-transport-erro" class="selfRef">Initial QUIC Transport Error Codes Entries</a>
+          </caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Value</th>
+              <th class="text-left" rowspan="1" colspan="1">Error</th>
+              <th class="text-left" rowspan="1" colspan="1">Description</th>
+              <th class="text-left" rowspan="1" colspan="1">Specification</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x0</td>
+              <td class="text-left" rowspan="1" colspan="1">NO_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">No error</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x1</td>
+              <td class="text-left" rowspan="1" colspan="1">INTERNAL_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Implementation error</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x2</td>
+              <td class="text-left" rowspan="1" colspan="1">CONNECTION_REFUSED_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Server refuses a connection</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x3</td>
+              <td class="text-left" rowspan="1" colspan="1">FLOW_CONTROL_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Flow control error</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x4</td>
+              <td class="text-left" rowspan="1" colspan="1">STREAM_LIMIT_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Too many streams opened</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x5</td>
+              <td class="text-left" rowspan="1" colspan="1">STREAM_STATE_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Frame received in invalid stream state</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x6</td>
+              <td class="text-left" rowspan="1" colspan="1">FINAL_SIZE_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Change to final size</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x7</td>
+              <td class="text-left" rowspan="1" colspan="1">FRAME_ENCODING_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Frame encoding error</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x8</td>
+              <td class="text-left" rowspan="1" colspan="1">TRANSPORT_PARAMETER_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Error in transport parameters</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0x9</td>
+              <td class="text-left" rowspan="1" colspan="1">CONNECTION_ID_LIMIT_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Too many connection IDs received</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0xA</td>
+              <td class="text-left" rowspan="1" colspan="1">PROTOCOL_VIOLATION</td>
+              <td class="text-left" rowspan="1" colspan="1">Generic protocol violation</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0xB</td>
+              <td class="text-left" rowspan="1" colspan="1">INVALID_TOKEN</td>
+              <td class="text-left" rowspan="1" colspan="1">Invalid Token Received</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0xC</td>
+              <td class="text-left" rowspan="1" colspan="1">APPLICATION_ERROR</td>
+              <td class="text-left" rowspan="1" colspan="1">Application error</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0xD</td>
+              <td class="text-left" rowspan="1" colspan="1">CRYPTO_BUFFER_EXCEEDED</td>
+              <td class="text-left" rowspan="1" colspan="1">CRYPTO data buffer overflowed</td>
+              <td class="text-left" rowspan="1" colspan="1">
+                <a href="#error-codes" class="xref">Section 20</a>
+</td>
+            </tr>
+          </tbody>
+        </table>
+</div>
+</section>
+</div>
+</section>
+</div>
+<section id="section-23">
+      <h2 id="name-references">
+<a href="#section-23" class="section-number selfRef">23. </a><a href="#name-references" class="section-name selfRef">References</a>
+      </h2>
+<section id="section-23.1">
+        <h3 id="name-normative-references">
+<a href="#section-23.1" class="section-number selfRef">23.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
+        </h3>
+<dl class="references">
+<dt id="DPLPMTUD">[DPLPMTUD]</dt>
+<dd>
+<span class="refAuthor">Fairhurst, G.</span><span class="refAuthor">, Jones, T.</span><span class="refAuthor">, Tuexen, M.</span><span class="refAuthor">, Ruengeler, I.</span><span class="refAuthor">, and T. Voelker</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery for Datagram Transports"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tsvwg-datagram-plpmtud-21</span>, <time datetime="2020-05-12">12 May 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-datagram-plpmtud-21.txt">http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-datagram-plpmtud-21.txt</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="IPv4">[IPv4]</dt>
+<dd>
+<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 791</span>, <span class="seriesInfo">DOI 10.17487/RFC0791</span>, <time datetime="1981-09">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc791">https://www.rfc-editor.org/info/rfc791</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-RECOVERY">[QUIC-RECOVERY]</dt>
+<dd>
+<span class="refAuthor">Iyengar, J., Ed.</span><span class="refAuthor"> and I. Swett, Ed.</span>, <span class="refTitle">"QUIC Loss Detection and Congestion Control"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-recovery-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-recovery-latest">https://tools.ietf.org/html/draft-ietf-quic-recovery-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-TLS">[QUIC-TLS]</dt>
+<dd>
+<span class="refAuthor">Thomson, M., Ed.</span><span class="refAuthor"> and S. Turner, Ed.</span>, <span class="refTitle">"Using Transport Layer Security (TLS) to Secure QUIC"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-tls-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-tls-latest">https://tools.ietf.org/html/draft-ietf-quic-tls-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC1191">[RFC1191]</dt>
+<dd>
+<span class="refAuthor">Mogul, J.C.</span><span class="refAuthor"> and S.E. Deering</span>, <span class="refTitle">"Path MTU discovery"</span>, <span class="seriesInfo">RFC 1191</span>, <span class="seriesInfo">DOI 10.17487/RFC1191</span>, <time datetime="1990-11">November 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1191">https://www.rfc-editor.org/info/rfc1191</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2119">[RFC2119]</dt>
+<dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC3168">[RFC3168]</dt>
+<dd>
+<span class="refAuthor">Ramakrishnan, K.</span><span class="refAuthor">, Floyd, S.</span><span class="refAuthor">, and D. Black</span>, <span class="refTitle">"The Addition of Explicit Congestion Notification (ECN) to IP"</span>, <span class="seriesInfo">RFC 3168</span>, <span class="seriesInfo">DOI 10.17487/RFC3168</span>, <time datetime="2001-09">September 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3168">https://www.rfc-editor.org/info/rfc3168</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC3629">[RFC3629]</dt>
+<dd>
+<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 63</span>, <span class="seriesInfo">RFC 3629</span>, <span class="seriesInfo">DOI 10.17487/RFC3629</span>, <time datetime="2003-11">November 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC4086">[RFC4086]</dt>
+<dd>
+<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor">, Schiller, J.</span><span class="refAuthor">, and S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5116">[RFC5116]</dt>
+<dd>
+<span class="refAuthor">McGrew, D.</span>, <span class="refTitle">"An Interface and Algorithms for Authenticated Encryption"</span>, <span class="seriesInfo">RFC 5116</span>, <span class="seriesInfo">DOI 10.17487/RFC5116</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5116">https://www.rfc-editor.org/info/rfc5116</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC6437">[RFC6437]</dt>
+<dd>
+<span class="refAuthor">Amante, S.</span><span class="refAuthor">, Carpenter, B.</span><span class="refAuthor">, Jiang, S.</span><span class="refAuthor">, and J. Rajahalme</span>, <span class="refTitle">"IPv6 Flow Label Specification"</span>, <span class="seriesInfo">RFC 6437</span>, <span class="seriesInfo">DOI 10.17487/RFC6437</span>, <time datetime="2011-11">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6437">https://www.rfc-editor.org/info/rfc6437</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8085">[RFC8085]</dt>
+<dd>
+<span class="refAuthor">Eggert, L.</span><span class="refAuthor">, Fairhurst, G.</span><span class="refAuthor">, and G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8126">[RFC8126]</dt>
+<dd>
+<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8174">[RFC8174]</dt>
+<dd>
+<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8201">[RFC8201]</dt>
+<dd>
+<span class="refAuthor">McCann, J.</span><span class="refAuthor">, Deering, S.</span><span class="refAuthor">, Mogul, J.</span><span class="refAuthor">, and R. Hinden, Ed.</span>, <span class="refTitle">"Path MTU Discovery for IP version 6"</span>, <span class="seriesInfo">STD 87</span>, <span class="seriesInfo">RFC 8201</span>, <span class="seriesInfo">DOI 10.17487/RFC8201</span>, <time datetime="2017-07">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8201">https://www.rfc-editor.org/info/rfc8201</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8311">[RFC8311]</dt>
+<dd>
+<span class="refAuthor">Black, D.</span>, <span class="refTitle">"Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation"</span>, <span class="seriesInfo">RFC 8311</span>, <span class="seriesInfo">DOI 10.17487/RFC8311</span>, <time datetime="2018-01">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8311">https://www.rfc-editor.org/info/rfc8311</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="TLS13">[TLS13]</dt>
+<dd>
+<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+<section id="section-23.2">
+        <h3 id="name-informative-references">
+<a href="#section-23.2" class="section-number selfRef">23.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
+        </h3>
+<dl class="references">
+<dt id="ALTSVC">[ALTSVC]</dt>
+<dd>
+<span class="refAuthor">Nottingham, M.</span><span class="refAuthor">, McManus, P.</span><span class="refAuthor">, and J. Reschke</span>, <span class="refTitle">"HTTP Alternative Services"</span>, <span class="seriesInfo">RFC 7838</span>, <span class="seriesInfo">DOI 10.17487/RFC7838</span>, <time datetime="2016-04">April 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7838">https://www.rfc-editor.org/info/rfc7838</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="EARLY-DESIGN">[EARLY-DESIGN]</dt>
+<dd>
+<span class="refAuthor">Roskind, J.</span>, <span class="refTitle">"QUIC: Multiplexed Transport Over UDP"</span>, <time datetime="2013-12-02">2 December 2013</time>, <span>&lt;<a href="https://goo.gl/dMVtFi">https://goo.gl/dMVtFi</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="HTTP2">[HTTP2]</dt>
+<dd>
+<span class="refAuthor">Belshe, M.</span><span class="refAuthor">, Peon, R.</span><span class="refAuthor">, and M. Thomson, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol Version 2 (HTTP/2)"</span>, <span class="seriesInfo">RFC 7540</span>, <span class="seriesInfo">DOI 10.17487/RFC7540</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7540">https://www.rfc-editor.org/info/rfc7540</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-INVARIANTS">[QUIC-INVARIANTS]</dt>
+<dd>
+<span class="refAuthor">Thomson, M.</span>, <span class="refTitle">"Version-Independent Properties of QUIC"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-invariants-latest</span>, <time datetime="2020-06-03">3 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-invariants-latest">https://tools.ietf.org/html/draft-ietf-quic-invariants-latest</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="QUIC-MANAGEABILITY">[QUIC-MANAGEABILITY]</dt>
+<dd>
+<span class="refAuthor">Kuehlewind, M.</span><span class="refAuthor"> and B. Trammell</span>, <span class="refTitle">"Manageability of the QUIC Transport Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-manageability-06</span>, <time datetime="2020-01-06">6 January 2020</time>, <span>&lt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-quic-manageability-06.txt">http://www.ietf.org/internet-drafts/draft-ietf-quic-manageability-06.txt</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC1812">[RFC1812]</dt>
+<dd>
+<span class="refAuthor">Baker, F., Ed.</span>, <span class="refTitle">"Requirements for IP Version 4 Routers"</span>, <span class="seriesInfo">RFC 1812</span>, <span class="seriesInfo">DOI 10.17487/RFC1812</span>, <time datetime="1995-06">June 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1812">https://www.rfc-editor.org/info/rfc1812</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2018">[RFC2018]</dt>
+<dd>
+<span class="refAuthor">Mathis, M.</span><span class="refAuthor">, Mahdavi, J.</span><span class="refAuthor">, Floyd, S.</span><span class="refAuthor">, and A. Romanow</span>, <span class="refTitle">"TCP Selective Acknowledgment Options"</span>, <span class="seriesInfo">RFC 2018</span>, <span class="seriesInfo">DOI 10.17487/RFC2018</span>, <time datetime="1996-10">October 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2018">https://www.rfc-editor.org/info/rfc2018</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC2104">[RFC2104]</dt>
+<dd>
+<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor">, Bellare, M.</span><span class="refAuthor">, and R. Canetti</span>, <span class="refTitle">"HMAC: Keyed-Hashing for Message Authentication"</span>, <span class="seriesInfo">RFC 2104</span>, <span class="seriesInfo">DOI 10.17487/RFC2104</span>, <time datetime="1997-02">February 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2104">https://www.rfc-editor.org/info/rfc2104</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC3449">[RFC3449]</dt>
+<dd>
+<span class="refAuthor">Balakrishnan, H.</span><span class="refAuthor">, Padmanabhan, V.</span><span class="refAuthor">, Fairhurst, G.</span><span class="refAuthor">, and M. Sooriyabandara</span>, <span class="refTitle">"TCP Performance Implications of Network Path Asymmetry"</span>, <span class="seriesInfo">BCP 69</span>, <span class="seriesInfo">RFC 3449</span>, <span class="seriesInfo">DOI 10.17487/RFC3449</span>, <time datetime="2002-12">December 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3449">https://www.rfc-editor.org/info/rfc3449</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC4443">[RFC4443]</dt>
+<dd>
+<span class="refAuthor">Conta, A.</span><span class="refAuthor">, Deering, S.</span><span class="refAuthor">, and M. Gupta, Ed.</span>, <span class="refTitle">"Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 89</span>, <span class="seriesInfo">RFC 4443</span>, <span class="seriesInfo">DOI 10.17487/RFC4443</span>, <time datetime="2006-03">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4443">https://www.rfc-editor.org/info/rfc4443</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC4787">[RFC4787]</dt>
+<dd>
+<span class="refAuthor">Audet, F., Ed.</span><span class="refAuthor"> and C. Jennings</span>, <span class="refTitle">"Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"</span>, <span class="seriesInfo">BCP 127</span>, <span class="seriesInfo">RFC 4787</span>, <span class="seriesInfo">DOI 10.17487/RFC4787</span>, <time datetime="2007-01">January 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4787">https://www.rfc-editor.org/info/rfc4787</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5681">[RFC5681]</dt>
+<dd>
+<span class="refAuthor">Allman, M.</span><span class="refAuthor">, Paxson, V.</span><span class="refAuthor">, and E. Blanton</span>, <span class="refTitle">"TCP Congestion Control"</span>, <span class="seriesInfo">RFC 5681</span>, <span class="seriesInfo">DOI 10.17487/RFC5681</span>, <time datetime="2009-09">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5681">https://www.rfc-editor.org/info/rfc5681</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC5869">[RFC5869]</dt>
+<dd>
+<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P. Eronen</span>, <span class="refTitle">"HMAC-based Extract-and-Expand Key Derivation Function (HKDF)"</span>, <span class="seriesInfo">RFC 5869</span>, <span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC7301">[RFC7301]</dt>
+<dd>
+<span class="refAuthor">Friedl, S.</span><span class="refAuthor">, Popov, A.</span><span class="refAuthor">, Langley, A.</span><span class="refAuthor">, and E. Stephan</span>, <span class="refTitle">"Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension"</span>, <span class="seriesInfo">RFC 7301</span>, <span class="seriesInfo">DOI 10.17487/RFC7301</span>, <time datetime="2014-07">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7301">https://www.rfc-editor.org/info/rfc7301</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="RFC8200">[RFC8200]</dt>
+<dd>
+<span class="refAuthor">Deering, S.</span><span class="refAuthor"> and R. Hinden</span>, <span class="refTitle">"Internet Protocol, Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 86</span>, <span class="seriesInfo">RFC 8200</span>, <span class="seriesInfo">DOI 10.17487/RFC8200</span>, <time datetime="2017-07">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8200">https://www.rfc-editor.org/info/rfc8200</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="SEC-CONS">[SEC-CONS]</dt>
+<dd>
+<span class="refAuthor">Rescorla, E.</span><span class="refAuthor"> and B. Korver</span>, <span class="refTitle">"Guidelines for Writing RFC Text on Security Considerations"</span>, <span class="seriesInfo">BCP 72</span>, <span class="seriesInfo">RFC 3552</span>, <span class="seriesInfo">DOI 10.17487/RFC3552</span>, <time datetime="2003-07">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3552">https://www.rfc-editor.org/info/rfc3552</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="SLOWLORIS">[SLOWLORIS]</dt>
+<dd>
+<span class="refAuthor">RSnake Hansen, R.</span>, <span class="refTitle">"Welcome to Slowloris..."</span>, <time datetime="2009-06">June 2009</time>, <span>&lt;<a href="https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/">https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+<dt id="STD">[STD]</dt>
+<dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"The Internet Standards Process -- Revision 3"</span>, <span class="seriesInfo">BCP 9</span>, <span class="seriesInfo">RFC 2026</span>, <span class="seriesInfo">DOI 10.17487/RFC2026</span>, <time datetime="1996-10">October 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2026">https://www.rfc-editor.org/info/rfc2026</a>&gt;</span>. </dd>
+<dd class="break"></dd>
+</dl>
+</section>
+</section>
+<div id="sample-packet-number-decoding">
+<section id="section-appendix.a">
+      <h2 id="name-sample-packet-number-decodi">
+<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-sample-packet-number-decodi" class="section-name selfRef">Sample Packet Number Decoding Algorithm</a>
+      </h2>
+<p id="section-appendix.a-1">The pseudo-code in <a href="#alg-decode-pn" class="xref">Figure 41</a> shows how an implementation can decode
+packet numbers after header protection has been removed.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
+<span id="name-sample-packet-number-decodin"></span><div id="alg-decode-pn">
+<figure id="figure-41">
+        <div class="artwork art-text alignLeft" id="section-appendix.a-2.1">
+<pre>
+DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
+   expected_pn  = largest_pn + 1
+   pn_win       = 1 &lt;&lt; pn_nbits
+   pn_hwin      = pn_win / 2
+   pn_mask      = pn_win - 1
+   // The incoming packet number should be greater than
+   // expected_pn - pn_hwin and less than or equal to
+   // expected_pn + pn_hwin
+   //
+   // This means we can't just strip the trailing bits from
+   // expected_pn and add the truncated_pn because that might
+   // yield a value outside the window.
+   //
+   // The following code calculates a candidate value and
+   // makes sure it's within the packet number window.
+   // Note the extra checks to prevent overflow and underflow.
+   candidate_pn = (expected_pn &amp; ~pn_mask) | truncated_pn
+   if candidate_pn &lt;= expected_pn - pn_hwin and
+      candidate_pn &lt; (1 &lt;&lt; 62) - pn_win:
+      return candidate_pn + pn_win
+   if candidate_pn &gt; expected_pn + pn_hwin and
+      candidate_pn &gt;= pn_win:
+      return candidate_pn - pn_win
+   return candidate_pn
+</pre>
+</div>
+<figcaption><a href="#figure-41" class="selfRef">Figure 41</a>:
+<a href="#name-sample-packet-number-decodin" class="selfRef">Sample Packet Number Decoding Algorithm</a>
+        </figcaption></figure>
+</div>
+</section>
+</div>
+<div id="ecn-alg">
+<section id="section-appendix.b">
+      <h2 id="name-sample-ecn-validation-algor">
+<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-sample-ecn-validation-algor" class="section-name selfRef">Sample ECN Validation Algorithm</a>
+      </h2>
+<p id="section-appendix.b-1">Each time an endpoint commences sending on a new network path, it determines
+whether the path supports ECN; see <a href="#ecn" class="xref">Section 13.4</a>.  If the path supports ECN, the goal
+is to use ECN.  Endpoints might also periodically reassess a path that was
+determined to not support ECN.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
+<p id="section-appendix.b-2">This section describes one method for testing new paths.  This algorithm is
+intended to show how a path might be tested for ECN support.  Endpoints can
+implement different methods.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
+<p id="section-appendix.b-3">The path is assigned an ECN state that is one of "testing", "unknown", "failed",
+or "capable".  On paths with a "testing" or "capable" state the endpoint sends
+packets with an ECT marking, by default ECT(0); otherwise, the endpoint sends
+unmarked packets.<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
+<p id="section-appendix.b-4">To start testing a path, the ECN state is set to "testing" and existing ECN
+counts are remembered as a baseline.<a href="#section-appendix.b-4" class="pilcrow">¶</a></p>
+<p id="section-appendix.b-5">The testing period runs for a number of packets or round-trip times, as
+determined by the endpoint.  The goal is not to limit the duration of the
+testing period, but to ensure that enough marked packets are sent for received
+ECN counts to provide a clear indication of how the path treats marked packets.
+<a href="#ecn-ack" class="xref">Section 13.4.2.2</a> suggests limiting this to 10 packets or 3 round-trip times.<a href="#section-appendix.b-5" class="pilcrow">¶</a></p>
+<p id="section-appendix.b-6">After the testing period ends, the ECN state for the path becomes "unknown".
+From the "unknown" state, successful validation of the ECN counts an ACK frame
+(see <a href="#ecn-ack" class="xref">Section 13.4.2.2</a>) causes the ECN state for the path to become "capable", unless
+no marked packet has been acknowledged.<a href="#section-appendix.b-6" class="pilcrow">¶</a></p>
+<p id="section-appendix.b-7">If validation of ECN counts fails at any time, the ECN state for the affected
+path becomes "failed".  An endpoint can also mark the ECN state for a path as
+"failed" if marked packets are all declared lost or if they are all CE marked.<a href="#section-appendix.b-7" class="pilcrow">¶</a></p>
+<p id="section-appendix.b-8">Following this algorithm ensures that ECN is rarely disabled for paths that
+properly support ECN.  Any path that incorrectly modifies markings will cause
+ECN to be disabled.  For those rare cases where marked packets are discarded by
+the path, the short duration of the testing period limits the number of losses
+incurred.<a href="#section-appendix.b-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="change-log">
+<section id="section-appendix.c">
+      <h2 id="name-change-log">
+<a href="#section-appendix.c" class="section-number selfRef">Appendix C. </a><a href="#name-change-log" class="section-name selfRef">Change Log</a>
+      </h2>
+<ul class="ulEmpty normal">
+<li class="ulEmpty normal" id="section-appendix.c-1.1">
+          <strong>RFC Editor's Note:</strong> Please remove this section prior to publication of a
+final version of this document.<a href="#section-appendix.c-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+<p id="section-appendix.c-2">Issue and pull request numbers are listed with a leading octothorp.<a href="#section-appendix.c-2" class="pilcrow">¶</a></p>
+<div id="since-draft-ietf-quic-transport-27">
+<section id="section-c.1">
+        <h2 id="name-since-draft-ietf-quic-trans">
+<a href="#section-c.1" class="section-number selfRef">C.1. </a><a href="#name-since-draft-ietf-quic-trans" class="section-name selfRef">Since draft-ietf-quic-transport-27</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.1-1.1">Allowed CONNECTION_CLOSE in any packet number space, with a requirement to
+use a new transport-level error for application-specific errors in Initial
+and Handshake packets (#3430, #3435, #3440)<a href="#section-c.1-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.2">Clearer requirements for address validation (#2125, #3327)<a href="#section-c.1-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.3">Security analysis of handshake and migration (#2143, #2387, #2925)<a href="#section-c.1-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.4">The entire payload of a datagram is used when counting bytes for
+mitigating amplification attacks (#3333, #3470)<a href="#section-c.1-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.5">Connection IDs can be used at any time, including in the handshake (#3348,
+#3560, #3438, #3565)<a href="#section-c.1-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.6">Only one ACK should be sent for each instance of reordering (#3357, #3361)<a href="#section-c.1-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.7">Remove text allowing a server to proceed with a bad Retry token (#3396,
+#3398)<a href="#section-c.1-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.8">Ignore active_connection_id_limit with a zero-length connection ID (#3427,
+#3426)<a href="#section-c.1-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.9">Require active_connection_id_limit be remembered for 0-RTT (#3423, #3425)<a href="#section-c.1-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.10">Require ack_delay not be remembered for 0-RTT (#3433, #3545)<a href="#section-c.1-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.11">Redefined max_packet_size to max_udp_datagram_size (#3471, #3473)<a href="#section-c.1-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.12">Guidance on limiting outstanding attempts to retire connection IDs (#3489,
+#3509, #3557, #3547)<a href="#section-c.1-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.13">Restored text on dropping bogus Version Negotiation packets (#3532, #3533)<a href="#section-c.1-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.14">Clarified that largest acknowledged needs to be saved, but not necessarily
+signaled in all cases (#3541, #3581)<a href="#section-c.1-1.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.15">Addressed linkability risk with the use of preferred_address (#3559, #3563)<a href="#section-c.1-1.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.16">Added authentication of handshake connection IDs (#3439, #3499)<a href="#section-c.1-1.16" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.1-1.17">Opening a stream in the wrong direction is an error (#3527)<a href="#section-c.1-1.17" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-26">
+<section id="section-c.2">
+        <h2 id="name-since-draft-ietf-quic-transp">
+<a href="#section-c.2" class="section-number selfRef">C.2. </a><a href="#name-since-draft-ietf-quic-transp" class="section-name selfRef">Since draft-ietf-quic-transport-26</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.2-1.1">Change format of transport parameters to use varints (#3294, #3169)<a href="#section-c.2-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-25">
+<section id="section-c.3">
+        <h2 id="name-since-draft-ietf-quic-transpo">
+<a href="#section-c.3" class="section-number selfRef">C.3. </a><a href="#name-since-draft-ietf-quic-transpo" class="section-name selfRef">Since draft-ietf-quic-transport-25</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.3-1.1">Define the use of CONNECTION_CLOSE prior to establishing connection state
+(#3269, #3297, #3292)<a href="#section-c.3-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.3-1.2">Allow use of address validation tokens after client address changes (#3307,
+#3308)<a href="#section-c.3-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.3-1.3">Define the timer for address validation (#2910, #3339)<a href="#section-c.3-1.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-24">
+<section id="section-c.4">
+        <h2 id="name-since-draft-ietf-quic-transpor">
+<a href="#section-c.4" class="section-number selfRef">C.4. </a><a href="#name-since-draft-ietf-quic-transpor" class="section-name selfRef">Since draft-ietf-quic-transport-24</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.4-1.1">Added HANDSHAKE_DONE to signal handshake confirmation (#2863, #3142, #3145)<a href="#section-c.4-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.2">Add integrity check to Retry packets (#3014, #3274, #3120)<a href="#section-c.4-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.3">Specify handling of reordered NEW_CONNECTION_ID frames (#3194, #3202)<a href="#section-c.4-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.4">Require checking of sequence numbers in RETIRE_CONNECTION_ID (#3037, #3036)<a href="#section-c.4-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.5">active_connection_id_limit is enforced (#3193, #3197, #3200, #3201)<a href="#section-c.4-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.6">Correct overflow in packet number decode algorithm (#3187, #3188)<a href="#section-c.4-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.7">Allow use of CRYPTO_BUFFER_EXCEEDED for CRYPTO frame errors (#3258, #3186)<a href="#section-c.4-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.8">Define applicability and scope of NEW_TOKEN (#3150, #3152, #3155, #3156)<a href="#section-c.4-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.9">Tokens from Retry and NEW_TOKEN must be differentiated (#3127, #3128)<a href="#section-c.4-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.10">Allow CONNECTION_CLOSE in response to invalid token (#3168, #3107)<a href="#section-c.4-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.11">Treat an invalid CONNECTION_CLOSE as an invalid frame (#2475, #3230, #3231)<a href="#section-c.4-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.12">Throttle when sending CONNECTION_CLOSE after discarding state (#3095, #3157)<a href="#section-c.4-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.13">Application-variant of CONNECTION_CLOSE can only be sent in 0-RTT or 1-RTT
+packets (#3158, #3164)<a href="#section-c.4-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.14">Advise sending while blocked to avoid idle timeout (#2744, #3266)<a href="#section-c.4-1.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.15">Define error codes for invalid frames (#3027, #3042)<a href="#section-c.4-1.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.16">Idle timeout is symmetric (#2602, #3099)<a href="#section-c.4-1.16" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.17">Prohibit IP fragmentation (#3243, #3280)<a href="#section-c.4-1.17" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.18">Define the use of provisional registration for all registries (#3109, #3020,
+#3102, #3170)<a href="#section-c.4-1.18" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.4-1.19">Packets on one path must not adjust values for a different path (#2909,
+#3139)<a href="#section-c.4-1.19" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-23">
+<section id="section-c.5">
+        <h2 id="name-since-draft-ietf-quic-transport">
+<a href="#section-c.5" class="section-number selfRef">C.5. </a><a href="#name-since-draft-ietf-quic-transport" class="section-name selfRef">Since draft-ietf-quic-transport-23</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.5-1.1">Allow ClientHello to span multiple packets (#2928, #3045)<a href="#section-c.5-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.2">Client Initial size constraints apply to UDP datagram payload (#3053, #3051)<a href="#section-c.5-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.3">
+            <p id="section-c.5-1.3.1">Stateless reset changes (#2152, #2993)<a href="#section-c.5-1.3.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-c.5-1.3.2.1">tokens need to be compared in constant time<a href="#section-c.5-1.3.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.3.2.2">detection uses UDP datagrams, not packets<a href="#section-c.5-1.3.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.3.2.3">tokens cannot be reused (#2785, #2968)<a href="#section-c.5-1.3.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-c.5-1.4">Clearer rules for sharing of UDP ports and use of connection IDs when doing so
+(#2844, #2851)<a href="#section-c.5-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.5">A new connection ID is necessary when responding to migration (#2778, #2969)<a href="#section-c.5-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.6">Stronger requirements for connection ID retirement (#3046, #3096)<a href="#section-c.5-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.7">NEW_TOKEN cannot be empty (#2978, #2977)<a href="#section-c.5-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.8">PING can be sent at any encryption level (#3034, #3035)<a href="#section-c.5-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.9">CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)<a href="#section-c.5-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.10">Frame encoding error conditions updated (#3027, #3042)<a href="#section-c.5-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.11">Non-ack-eliciting packets cannot be sent in response to non-ack-eliciting
+packets (#3100, #3104)<a href="#section-c.5-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.5-1.12">Servers have to change connection IDs in Retry (#2837, #3147)<a href="#section-c.5-1.12" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-22">
+<section id="section-c.6">
+        <h2 id="name-since-draft-ietf-quic-transport-">
+<a href="#section-c.6" class="section-number selfRef">C.6. </a><a href="#name-since-draft-ietf-quic-transport-" class="section-name selfRef">Since draft-ietf-quic-transport-22</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.6-1.1">Rules for preventing correlation by connection ID tightened (#2084, #2929)<a href="#section-c.6-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.2">Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, #2541, #2688)<a href="#section-c.6-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.3">Discourage regressions of largest acknowledged in ACK (#2205, #2752)<a href="#section-c.6-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.4">Improved robustness of validation process for ECN counts (#2534, #2752)<a href="#section-c.6-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.5">Require endpoints to ignore spurious migration attempts (#2342, #2893)<a href="#section-c.6-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.6">Transport parameter for disabling migration clarified to allow NAT rebinding
+(#2389, #2893)<a href="#section-c.6-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.7">Document principles for defining new error codes (#2388, #2880)<a href="#section-c.6-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.8">Reserve transport parameters for greasing (#2550, #2873)<a href="#section-c.6-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.9">A maximum ACK delay of 0 is used for handshake packet number spaces (#2646,
+#2638)<a href="#section-c.6-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.10">Improved rules for use of congestion control state on new paths (#2685, #2918)<a href="#section-c.6-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.11">Removed recommendation to coordinate spin for multiple connections that share
+a path (#2763, #2882)<a href="#section-c.6-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.12">Allow smaller stateless resets and recommend a smaller minimum on packets
+that might trigger a stateless reset (#2770, #2869, #2927, #3007).<a href="#section-c.6-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.13">Provide guidance around the interface to QUIC as used by application protocols
+(#2805, #2857)<a href="#section-c.6-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.14">Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825, #2826)<a href="#section-c.6-1.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.15">Tighter rules about processing of rejected 0-RTT packets (#2829, #2840, #2841)<a href="#section-c.6-1.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.16">Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)<a href="#section-c.6-1.16" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.17">Cryptographic handshake needs to provide server transport parameter encryption
+(#2920, #2921)<a href="#section-c.6-1.17" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.6-1.18">Moved ACK generation guidance from recovery draft to transport draft (#1860,
+#2916).<a href="#section-c.6-1.18" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-21">
+<section id="section-c.7">
+        <h2 id="name-since-draft-ietf-quic-transport-2">
+<a href="#section-c.7" class="section-number selfRef">C.7. </a><a href="#name-since-draft-ietf-quic-transport-2" class="section-name selfRef">Since draft-ietf-quic-transport-21</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.7-1.1">Connection ID lengths are now one octet, but limited in version 1 to 20 octets
+of length (#2736, #2749)<a href="#section-c.7-1.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-20">
+<section id="section-c.8">
+        <h2 id="name-since-draft-ietf-quic-transport-20">
+<a href="#section-c.8" class="section-number selfRef">C.8. </a><a href="#name-since-draft-ietf-quic-transport-20" class="section-name selfRef">Since draft-ietf-quic-transport-20</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.8-1.1">Error codes are encoded as variable-length integers (#2672, #2680)<a href="#section-c.8-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.2">NEW_CONNECTION_ID includes a request to retire old connection IDs (#2645,
+#2769)<a href="#section-c.8-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.3">Tighter rules for generating and explicitly eliciting ACK frames (#2546,
+#2794)<a href="#section-c.8-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.4">Recommend having only one packet per encryption level in a datagram (#2308,
+#2747)<a href="#section-c.8-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.5">More normative language about use of stateless reset (#2471, #2574)<a href="#section-c.8-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.6">Allow reuse of stateless reset tokens (#2732, #2733)<a href="#section-c.8-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.7">Allow, but not require, enforcing non-duplicate transport parameters (#2689,
+#2691)<a href="#section-c.8-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.8">Added an active_connection_id_limit transport parameter (#1994, #1998)<a href="#section-c.8-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.9">max_ack_delay transport parameter defaults to 0 (#2638, #2646)<a href="#section-c.8-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.10">When sending 0-RTT, only remembered transport parameters apply (#2458, #2360,
+#2466, #2461)<a href="#section-c.8-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.11">Define handshake completion and confirmation; define clearer rules when it
+encryption keys should be discarded (#2214, #2267, #2673)<a href="#section-c.8-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.12">Prohibit path migration prior to handshake confirmation (#2309, #2370)<a href="#section-c.8-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.13">PATH_RESPONSE no longer needs to be received on the validated path (#2582,
+#2580, #2579, #2637)<a href="#section-c.8-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.14">PATH_RESPONSE frames are not stored and retransmitted (#2724, #2729)<a href="#section-c.8-1.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.8-1.15">Document hack for enabling routing of ICMP when doing PMTU probing (#1243,
+#2402)<a href="#section-c.8-1.15" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-19">
+<section id="section-c.9">
+        <h2 id="name-since-draft-ietf-quic-transport-1">
+<a href="#section-c.9" class="section-number selfRef">C.9. </a><a href="#name-since-draft-ietf-quic-transport-1" class="section-name selfRef">Since draft-ietf-quic-transport-19</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.9-1.1">Refine discussion of 0-RTT transport parameters (#2467, #2464)<a href="#section-c.9-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.2">Fewer transport parameters need to be remembered for 0-RTT (#2624, #2467)<a href="#section-c.9-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.3">Spin bit text incorporated (#2564)<a href="#section-c.9-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.4">Close the connection when maximum stream ID in MAX_STREAMS exceeds 2^62 - 1
+(#2499, #2487)<a href="#section-c.9-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.5">New connection ID required for intentional migration (#2414, #2413)<a href="#section-c.9-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.6">Connection ID issuance can be rate-limited (#2436, #2428)<a href="#section-c.9-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.7">The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)<a href="#section-c.9-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.8">Initial packets from clients need to be padded to 1200 unless a Handshake
+packet is sent as well (#2522, #2523)<a href="#section-c.9-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.9">CRYPTO frames can be discarded if too much data is buffered (#1834, #2524)<a href="#section-c.9-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.9-1.10">Stateless reset uses a short header packet (#2599, #2600)<a href="#section-c.9-1.10" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-18">
+<section id="section-c.10">
+        <h2 id="name-since-draft-ietf-quic-transport-18">
+<a href="#section-c.10" class="section-number selfRef">C.10. </a><a href="#name-since-draft-ietf-quic-transport-18" class="section-name selfRef">Since draft-ietf-quic-transport-18</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.10-1.1">Removed version negotiation; version negotiation, including authentication of
+the result, will be addressed in the next version of QUIC (#1773, #2313)<a href="#section-c.10-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.2">Added discussion of the use of IPv6 flow labels (#2348, #2399)<a href="#section-c.10-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.3">A connection ID can't be retired in a packet that uses that connection ID
+(#2101, #2420)<a href="#section-c.10-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.4">Idle timeout transport parameter is in milliseconds (from seconds) (#2453,
+#2454)<a href="#section-c.10-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.5">Endpoints are required to use new connection IDs when they use new network
+paths (#2413, #2414)<a href="#section-c.10-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.10-1.6">Increased the set of permissible frames in 0-RTT (#2344, #2355)<a href="#section-c.10-1.6" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-17">
+<section id="section-c.11">
+        <h2 id="name-since-draft-ietf-quic-transport-17">
+<a href="#section-c.11" class="section-number selfRef">C.11. </a><a href="#name-since-draft-ietf-quic-transport-17" class="section-name selfRef">Since draft-ietf-quic-transport-17</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.11-1.1">Stream-related errors now use STREAM_STATE_ERROR (#2305)<a href="#section-c.11-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.2">Endpoints discard initial keys as soon as handshake keys are available (#1951,
+#2045)<a href="#section-c.11-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.3">Expanded conditions for ignoring ICMP packet too big messages (#2108, #2161)<a href="#section-c.11-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.4">Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, #2241)<a href="#section-c.11-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.5">Endpoints are permitted to discard malformed initial packets (#2141)<a href="#section-c.11-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.6">Clarified ECN implementation and usage requirements (#2156, #2201)<a href="#section-c.11-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.7">Disable ECN count verification for packets that arrive out of order (#2198,
+#2215)<a href="#section-c.11-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.8">Use Probe Timeout (PTO) instead of RTO (#2206, #2238)<a href="#section-c.11-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.9">Loosen constraints on retransmission of ACK ranges (#2199, #2245)<a href="#section-c.11-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.10">Limit Retry and Version Negotiation to once per datagram (#2259, #2303)<a href="#section-c.11-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.11">Set a maximum value for max_ack_delay transport parameter (#2282, #2301)<a href="#section-c.11-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.12">Allow server preferred address for both IPv4 and IPv6 (#2122, #2296)<a href="#section-c.11-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.13">Corrected requirements for migration to a preferred address (#2146, #2349)<a href="#section-c.11-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.11-1.14">ACK of non-existent packet is illegal (#2298, #2302)<a href="#section-c.11-1.14" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-16">
+<section id="section-c.12">
+        <h2 id="name-since-draft-ietf-quic-transport-16">
+<a href="#section-c.12" class="section-number selfRef">C.12. </a><a href="#name-since-draft-ietf-quic-transport-16" class="section-name selfRef">Since draft-ietf-quic-transport-16</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.12-1.1">Stream limits are defined as counts, not maximums (#1850, #1906)<a href="#section-c.12-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.2">Require amplification attack defense after closing (#1905, #1911)<a href="#section-c.12-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.3">Remove reservation of application error code 0 for STOPPING (#1804, #1922)<a href="#section-c.12-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.4">Renumbered frames (#1945)<a href="#section-c.12-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.5">Renumbered transport parameters (#1946)<a href="#section-c.12-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.6">Numeric transport parameters are expressed as varints (#1608, #1947, #1955)<a href="#section-c.12-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.7">Reorder the NEW_CONNECTION_ID frame (#1952, #1963)<a href="#section-c.12-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8">
+            <p id="section-c.12-1.8.1">Rework the first byte (#2006)<a href="#section-c.12-1.8.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-c.12-1.8.2.1">Fix the 0x40 bit<a href="#section-c.12-1.8.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8.2.2">Change type values for long header<a href="#section-c.12-1.8.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8.2.3">Add spin bit to short header (#631, #1988)<a href="#section-c.12-1.8.2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8.2.4">Encrypt the remainder of the first byte (#1322)<a href="#section-c.12-1.8.2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8.2.5">Move packet number length to first byte<a href="#section-c.12-1.8.2.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8.2.6">Move ODCIL to first byte of retry packets<a href="#section-c.12-1.8.2.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.8.2.7">Simplify packet number protection (#1575)<a href="#section-c.12-1.8.2.7" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-c.12-1.9">Allow STOP_SENDING to open a remote bidirectional stream (#1797, #2013)<a href="#section-c.12-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.10">Added mitigation for off-path migration attacks (#1278, #1749, #2033)<a href="#section-c.12-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.11">Don't let the PMTU to drop below 1280 (#2063, #2069)<a href="#section-c.12-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.12">Require peers to replace retired connection IDs (#2085)<a href="#section-c.12-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.13">Servers are required to ignore Version Negotiation packets (#2088)<a href="#section-c.12-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.14">Tokens are repeated in all Initial packets (#2089)<a href="#section-c.12-1.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.15">Clarified how PING frames are sent after loss (#2094)<a href="#section-c.12-1.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.16">Initial keys are discarded once Handshake are available (#1951, #2045)<a href="#section-c.12-1.16" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.12-1.17">ICMP PTB validation clarifications (#2161, #2109, #2108)<a href="#section-c.12-1.17" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-15">
+<section id="section-c.13">
+        <h2 id="name-since-draft-ietf-quic-transport-15">
+<a href="#section-c.13" class="section-number selfRef">C.13. </a><a href="#name-since-draft-ietf-quic-transport-15" class="section-name selfRef">Since draft-ietf-quic-transport-15</a>
+        </h2>
+<p id="section-c.13-1">Substantial editorial reorganization; no technical changes.<a href="#section-c.13-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-14">
+<section id="section-c.14">
+        <h2 id="name-since-draft-ietf-quic-transport-14">
+<a href="#section-c.14" class="section-number selfRef">C.14. </a><a href="#name-since-draft-ietf-quic-transport-14" class="section-name selfRef">Since draft-ietf-quic-transport-14</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.14-1.1">Merge ACK and ACK_ECN (#1778, #1801)<a href="#section-c.14-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.2">Explicitly communicate max_ack_delay (#981, #1781)<a href="#section-c.14-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.3">Validate original connection ID after Retry packets (#1710, #1486, #1793)<a href="#section-c.14-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.4">Idle timeout is optional and has no specified maximum (#1765)<a href="#section-c.14-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.5">Update connection ID handling; add RETIRE_CONNECTION_ID type (#1464, #1468,
+#1483, #1484, #1486, #1495, #1729, #1742, #1799, #1821)<a href="#section-c.14-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.6">Include a Token in all Initial packets (#1649, #1794)<a href="#section-c.14-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.14-1.7">Prevent handshake deadlock (#1764, #1824)<a href="#section-c.14-1.7" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-13">
+<section id="section-c.15">
+        <h2 id="name-since-draft-ietf-quic-transport-13">
+<a href="#section-c.15" class="section-number selfRef">C.15. </a><a href="#name-since-draft-ietf-quic-transport-13" class="section-name selfRef">Since draft-ietf-quic-transport-13</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.15-1.1">Streams open when higher-numbered streams of the same type open (#1342, #1549)<a href="#section-c.15-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.2">Split initial stream flow control limit into 3 transport parameters (#1016,
+#1542)<a href="#section-c.15-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.3">All flow control transport parameters are optional (#1610)<a href="#section-c.15-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.4">Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)<a href="#section-c.15-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.5">Permit stateless reset in response to any packet (#1348, #1553)<a href="#section-c.15-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.6">Recommended defense against stateless reset spoofing (#1386, #1554)<a href="#section-c.15-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.7">Prevent infinite stateless reset exchanges (#1443, #1627)<a href="#section-c.15-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.8">Forbid processing of the same packet number twice (#1405, #1624)<a href="#section-c.15-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.9">Added a packet number decoding example (#1493)<a href="#section-c.15-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.10">More precisely define idle timeout (#1429, #1614, #1652)<a href="#section-c.15-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.11">Corrected format of Retry packet and prevented looping (#1492, #1451, #1448,
+#1498)<a href="#section-c.15-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.12">Permit 0-RTT after receiving Version Negotiation or Retry (#1507, #1514,
+#1621)<a href="#section-c.15-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.13">Permit Retry in response to 0-RTT (#1547, #1552)<a href="#section-c.15-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.14">Looser verification of ECN counters to account for ACK loss (#1555, #1481,
+#1565)<a href="#section-c.15-1.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.15-1.15">Remove frame type field from APPLICATION_CLOSE (#1508, #1528)<a href="#section-c.15-1.15" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-12">
+<section id="section-c.16">
+        <h2 id="name-since-draft-ietf-quic-transport-12">
+<a href="#section-c.16" class="section-number selfRef">C.16. </a><a href="#name-since-draft-ietf-quic-transport-12" class="section-name selfRef">Since draft-ietf-quic-transport-12</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.16-1.1">
+            <p id="section-c.16-1.1.1">Changes to integration of the TLS handshake (#829, #1018, #1094, #1165, #1190,
+#1233, #1242, #1252, #1450, #1458)<a href="#section-c.16-1.1.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-c.16-1.1.2.1">The cryptographic handshake uses CRYPTO frames, not stream 0<a href="#section-c.16-1.1.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.1.2.2">QUIC packet protection is used in place of TLS record protection<a href="#section-c.16-1.1.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.1.2.3">Separate QUIC packet number spaces are used for the handshake<a href="#section-c.16-1.1.2.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.1.2.4">Changed Retry to be independent of the cryptographic handshake<a href="#section-c.16-1.1.2.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.1.2.5">Added NEW_TOKEN frame and Token fields to Initial packet<a href="#section-c.16-1.1.2.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.1.2.6">Limit the use of HelloRetryRequest to address TLS needs (like key shares)<a href="#section-c.16-1.1.2.6" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-c.16-1.2">Enable server to transition connections to a preferred address (#560, #1251,
+#1373)<a href="#section-c.16-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.3">Added ECN feedback mechanisms and handling; new ACK_ECN frame (#804, #805,
+#1372)<a href="#section-c.16-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.4">Changed rules and recommendations for use of new connection IDs (#1258, #1264,
+#1276, #1280, #1419, #1452, #1453, #1465)<a href="#section-c.16-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.5">Added a transport parameter to disable intentional connection migration
+(#1271, #1447)<a href="#section-c.16-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.6">Packets from different connection ID can't be coalesced (#1287, #1423)<a href="#section-c.16-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.7">Fixed sampling method for packet number encryption; the length field in long
+headers includes the packet number field in addition to the packet payload
+(#1387, #1389)<a href="#section-c.16-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.8">Stateless Reset is now symmetric and subject to size constraints (#466, #1346)<a href="#section-c.16-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.16-1.9">Added frame type extension mechanism (#58, #1473)<a href="#section-c.16-1.9" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-11">
+<section id="section-c.17">
+        <h2 id="name-since-draft-ietf-quic-transport-11">
+<a href="#section-c.17" class="section-number selfRef">C.17. </a><a href="#name-since-draft-ietf-quic-transport-11" class="section-name selfRef">Since draft-ietf-quic-transport-11</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.17-1.1">Enable server to transition connections to a preferred address (#560, #1251)<a href="#section-c.17-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.17-1.2">Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, #990, #734,
+#1317, #1267, #1079)<a href="#section-c.17-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.17-1.3">Packet numbers use a variable-length encoding (#989, #1334)<a href="#section-c.17-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.17-1.4">STREAM frames can now be empty (#1350)<a href="#section-c.17-1.4" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-10">
+<section id="section-c.18">
+        <h2 id="name-since-draft-ietf-quic-transport-10">
+<a href="#section-c.18" class="section-number selfRef">C.18. </a><a href="#name-since-draft-ietf-quic-transport-10" class="section-name selfRef">Since draft-ietf-quic-transport-10</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.18-1.1">Swap payload length and packed number fields in long header (#1294)<a href="#section-c.18-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.2">Clarified that CONNECTION_CLOSE is allowed in Handshake packet (#1274)<a href="#section-c.18-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.3">Spin bit reserved (#1283)<a href="#section-c.18-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.4">Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)<a href="#section-c.18-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.5">A more complete connection migration (#1249)<a href="#section-c.18-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.6">Refine opportunistic ACK defense text (#305, #1030, #1185)<a href="#section-c.18-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.7">A Stateless Reset Token isn't mandatory (#818, #1191)<a href="#section-c.18-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.8">Removed implicit stream opening (#896, #1193)<a href="#section-c.18-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.9">An empty STREAM frame can be used to open a stream without sending data (#901,
+#1194)<a href="#section-c.18-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.10">Define stream counts in transport parameters rather than a maximum stream ID
+(#1023, #1065)<a href="#section-c.18-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.11">STOP_SENDING is now prohibited before streams are used (#1050)<a href="#section-c.18-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.12">Recommend including ACK in Retry packets and allow PADDING (#1067, #882)<a href="#section-c.18-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.13">Endpoints now become closing after an idle timeout (#1178, #1179)<a href="#section-c.18-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.18-1.14">Remove implication that Version Negotiation is sent when a packet of the wrong
+version is received (#1197)<a href="#section-c.18-1.14" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-09">
+<section id="section-c.19">
+        <h2 id="name-since-draft-ietf-quic-transport-0">
+<a href="#section-c.19" class="section-number selfRef">C.19. </a><a href="#name-since-draft-ietf-quic-transport-0" class="section-name selfRef">Since draft-ietf-quic-transport-09</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.19-1.1">Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with Data and
+PONG frame. Changed ACK frame type from 0x0e to 0x0d. (#1091, #725, #1086)<a href="#section-c.19-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.19-1.2">A server can now only send 3 packets without validating the client address
+(#38, #1090)<a href="#section-c.19-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.19-1.3">Delivery order of stream data is no longer strongly specified (#252, #1070)<a href="#section-c.19-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.19-1.4">Rework of packet handling and version negotiation (#1038)<a href="#section-c.19-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.19-1.5">Stream 0 is now exempt from flow control until the handshake completes (#1074,
+#725, #825, #1082)<a href="#section-c.19-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.19-1.6">Improved retransmission rules for all frame types: information is
+retransmitted, not packets or frames (#463, #765, #1095, #1053)<a href="#section-c.19-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.19-1.7">Added an error code for server busy signals (#1137)<a href="#section-c.19-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.19-1.8">Endpoints now set the connection ID that their peer uses.  Connection IDs are
+variable length.  Removed the omit_connection_id transport parameter and the
+corresponding short header flag. (#1089, #1052, #1146, #821, #745, #821,
+#1166, #1151)<a href="#section-c.19-1.8" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-08">
+<section id="section-c.20">
+        <h2 id="name-since-draft-ietf-quic-transport-08">
+<a href="#section-c.20" class="section-number selfRef">C.20. </a><a href="#name-since-draft-ietf-quic-transport-08" class="section-name selfRef">Since draft-ietf-quic-transport-08</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.20-1.1">Clarified requirements for BLOCKED usage (#65,  #924)<a href="#section-c.20-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.2">BLOCKED frame now includes reason for blocking (#452, #924, #927, #928)<a href="#section-c.20-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.3">GAP limitation in ACK Frame (#613)<a href="#section-c.20-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.4">Improved PMTUD description (#614, #1036)<a href="#section-c.20-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.5">Clarified stream state machine (#634, #662, #743, #894)<a href="#section-c.20-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.6">Reserved versions don't need to be generated deterministically (#831, #931)<a href="#section-c.20-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.7">You don't always need the draining period (#871)<a href="#section-c.20-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.8">Stateless reset clarified as version-specific (#930, #986)<a href="#section-c.20-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.9">initial_max_stream_id_x transport parameters are optional (#970, #971)<a href="#section-c.20-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.10">Ack Delay assumes a default value during the handshake (#1007, #1009)<a href="#section-c.20-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.20-1.11">Removed transport parameters from NewSessionTicket (#1015)<a href="#section-c.20-1.11" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-07">
+<section id="section-c.21">
+        <h2 id="name-since-draft-ietf-quic-transport-07">
+<a href="#section-c.21" class="section-number selfRef">C.21. </a><a href="#name-since-draft-ietf-quic-transport-07" class="section-name selfRef">Since draft-ietf-quic-transport-07</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.21-1.1">The long header now has version before packet number (#926, #939)<a href="#section-c.21-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.2">Rename and consolidate packet types (#846, #822, #847)<a href="#section-c.21-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.3">Packet types are assigned new codepoints and the Connection ID Flag is
+inverted (#426, #956)<a href="#section-c.21-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.4">Removed type for Version Negotiation and use Version 0 (#963, #968)<a href="#section-c.21-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.5">
+            <p id="section-c.21-1.5.1">Streams are split into unidirectional and bidirectional (#643, #656, #720,
+#872, #175, #885)<a href="#section-c.21-1.5.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-c.21-1.5.2.1">Stream limits now have separate uni- and bi-directional transport parameters
+(#909, #958)<a href="#section-c.21-1.5.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.5.2.2">Stream limit transport parameters are now optional and default to 0 (#970,
+#971)<a href="#section-c.21-1.5.2.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-c.21-1.6">The stream state machine has been split into read and write (#634, #894)<a href="#section-c.21-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.7">Employ variable-length integer encodings throughout (#595)<a href="#section-c.21-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.8">
+            <p id="section-c.21-1.8.1">Improvements to connection close<a href="#section-c.21-1.8.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-c.21-1.8.2.1">Added distinct closing and draining states (#899, #871)<a href="#section-c.21-1.8.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.8.2.2">Draining period can terminate early (#869, #870)<a href="#section-c.21-1.8.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.8.2.3">Clarifications about stateless reset (#889, #890)<a href="#section-c.21-1.8.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-c.21-1.9">Address validation for connection migration (#161, #732, #878)<a href="#section-c.21-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.10">Clearly defined retransmission rules for BLOCKED (#452, #65, #924)<a href="#section-c.21-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.11">negotiated_version is sent in server transport parameters (#710, #959)<a href="#section-c.21-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.21-1.12">Increased the range over which packet numbers are randomized (#864, #850,
+#964)<a href="#section-c.21-1.12" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-06">
+<section id="section-c.22">
+        <h2 id="name-since-draft-ietf-quic-transport-06">
+<a href="#section-c.22" class="section-number selfRef">C.22. </a><a href="#name-since-draft-ietf-quic-transport-06" class="section-name selfRef">Since draft-ietf-quic-transport-06</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.22-1.1">Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)<a href="#section-c.22-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.22-1.2">Split error code space between application and transport (#485)<a href="#section-c.22-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.22-1.3">Stateless reset token moved to end (#820)<a href="#section-c.22-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.22-1.4">1-RTT-protected long header types removed (#848)<a href="#section-c.22-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.22-1.5">No acknowledgments during draining period (#852)<a href="#section-c.22-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.22-1.6">Remove "application close" as a separate close type (#854)<a href="#section-c.22-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.22-1.7">Remove timestamps from the ACK frame (#841)<a href="#section-c.22-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.22-1.8">Require transport parameters to only appear once (#792)<a href="#section-c.22-1.8" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-05">
+<section id="section-c.23">
+        <h2 id="name-since-draft-ietf-quic-transport-05">
+<a href="#section-c.23" class="section-number selfRef">C.23. </a><a href="#name-since-draft-ietf-quic-transport-05" class="section-name selfRef">Since draft-ietf-quic-transport-05</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.23-1.1">Stateless token is server-only (#726)<a href="#section-c.23-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.23-1.2">Refactor section on connection termination (#733, #748, #328, #177)<a href="#section-c.23-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.23-1.3">Limit size of Version Negotiation packet (#585)<a href="#section-c.23-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.23-1.4">Clarify when and what to ack (#736)<a href="#section-c.23-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.23-1.5">Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED<a href="#section-c.23-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.23-1.6">Clarify Keep-alive requirements (#729)<a href="#section-c.23-1.6" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-04">
+<section id="section-c.24">
+        <h2 id="name-since-draft-ietf-quic-transport-04">
+<a href="#section-c.24" class="section-number selfRef">C.24. </a><a href="#name-since-draft-ietf-quic-transport-04" class="section-name selfRef">Since draft-ietf-quic-transport-04</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.24-1.1">Introduce STOP_SENDING frame, RESET_STREAM only resets in one direction (#165)<a href="#section-c.24-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.2">Removed GOAWAY; application protocols are responsible for graceful shutdown
+(#696)<a href="#section-c.24-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.3">Reduced the number of error codes (#96, #177, #184, #211)<a href="#section-c.24-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.4">Version validation fields can't move or change (#121)<a href="#section-c.24-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.5">Removed versions from the transport parameters in a NewSessionTicket message
+(#547)<a href="#section-c.24-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.6">Clarify the meaning of "bytes in flight" (#550)<a href="#section-c.24-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.7">Public reset is now stateless reset and not visible to the path (#215)<a href="#section-c.24-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.8">Reordered bits and fields in STREAM frame (#620)<a href="#section-c.24-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.9">Clarifications to the stream state machine (#572, #571)<a href="#section-c.24-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.10">Increased the maximum length of the Largest Acknowledged field in ACK frames
+to 64 bits (#629)<a href="#section-c.24-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.11">truncate_connection_id is renamed to omit_connection_id (#659)<a href="#section-c.24-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.12">CONNECTION_CLOSE terminates the connection like TCP RST (#330, #328)<a href="#section-c.24-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.24-1.13">Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)<a href="#section-c.24-1.13" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-03">
+<section id="section-c.25">
+        <h2 id="name-since-draft-ietf-quic-transport-03">
+<a href="#section-c.25" class="section-number selfRef">C.25. </a><a href="#name-since-draft-ietf-quic-transport-03" class="section-name selfRef">Since draft-ietf-quic-transport-03</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.25-1.1">Change STREAM and RESET_STREAM layout<a href="#section-c.25-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.25-1.2">Add MAX_STREAM_ID settings<a href="#section-c.25-1.2" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-02">
+<section id="section-c.26">
+        <h2 id="name-since-draft-ietf-quic-transport-02">
+<a href="#section-c.26" class="section-number selfRef">C.26. </a><a href="#name-since-draft-ietf-quic-transport-02" class="section-name selfRef">Since draft-ietf-quic-transport-02</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.26-1.1">The size of the initial packet payload has a fixed minimum (#267, #472)<a href="#section-c.26-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.2">Define when Version Negotiation packets are ignored (#284, #294, #241, #143,
+#474)<a href="#section-c.26-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.3">The 64-bit FNV-1a algorithm is used for integrity protection of unprotected
+packets (#167, #480, #481, #517)<a href="#section-c.26-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.4">Rework initial packet types to change how the connection ID is chosen (#482,
+#442, #493)<a href="#section-c.26-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.5">No timestamps are forbidden in unprotected packets (#542, #429)<a href="#section-c.26-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.6">Cryptographic handshake is now on stream 0 (#456)<a href="#section-c.26-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.7">Remove congestion control exemption for cryptographic handshake (#248, #476)<a href="#section-c.26-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.8">Version 1 of QUIC uses TLS; a new version is needed to use a different
+handshake protocol (#516)<a href="#section-c.26-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.9">STREAM frames have a reduced number of offset lengths (#543, #430)<a href="#section-c.26-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.10">
+            <p id="section-c.26-1.10.1">Split some frames into separate connection- and stream- level frames
+(#443)<a href="#section-c.26-1.10.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-c.26-1.10.2.1">WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450)<a href="#section-c.26-1.10.2.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.10.2.2">BLOCKED split to match WINDOW_UPDATE split (#454)<a href="#section-c.26-1.10.2.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.10.2.3">Define STREAM_ID_NEEDED frame (#455)<a href="#section-c.26-1.10.2.3" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-c.26-1.11">A NEW_CONNECTION_ID frame supports connection migration without linkability
+(#232, #491, #496)<a href="#section-c.26-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.26-1.12">
+            <p id="section-c.26-1.12.1">Transport parameters for 0-RTT are retained from a previous connection (#405,
+#513, #512)<a href="#section-c.26-1.12.1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-c.26-1.12.2.1">A client in 0-RTT no longer required to reset excess streams (#425, #479)<a href="#section-c.26-1.12.2.1" class="pilcrow">¶</a>
+</li>
+</ul>
+</li>
+<li class="normal" id="section-c.26-1.13">Expanded security considerations (#440, #444, #445, #448)<a href="#section-c.26-1.13" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-01">
+<section id="section-c.27">
+        <h2 id="name-since-draft-ietf-quic-transport-01">
+<a href="#section-c.27" class="section-number selfRef">C.27. </a><a href="#name-since-draft-ietf-quic-transport-01" class="section-name selfRef">Since draft-ietf-quic-transport-01</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.27-1.1">Defined short and long packet headers (#40, #148, #361)<a href="#section-c.27-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.2">Defined a versioning scheme and stable fields (#51, #361)<a href="#section-c.27-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.3">Define reserved version values for "greasing" negotiation (#112, #278)<a href="#section-c.27-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.4">The initial packet number is randomized (#35, #283)<a href="#section-c.27-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.5">Narrow the packet number encoding range requirement (#67, #286, #299, #323,
+#356)<a href="#section-c.27-1.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.6">Defined client address validation (#52, #118, #120, #275)<a href="#section-c.27-1.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.7">Define transport parameters as a TLS extension (#49, #122)<a href="#section-c.27-1.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.8">SCUP and COPT parameters are no longer valid (#116, #117)<a href="#section-c.27-1.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.9">Transport parameters for 0-RTT are either remembered from before, or assume
+default values (#126)<a href="#section-c.27-1.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.10">The server chooses connection IDs in its final flight (#119, #349, #361)<a href="#section-c.27-1.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.11">The server echoes the Connection ID and packet number fields when sending a
+Version Negotiation packet (#133, #295, #244)<a href="#section-c.27-1.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.12">Defined a minimum packet size for the initial handshake packet from the client
+(#69, #136, #139, #164)<a href="#section-c.27-1.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.13">Path MTU Discovery (#64, #106)<a href="#section-c.27-1.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.14">The initial handshake packet from the client needs to fit in a single packet
+(#338)<a href="#section-c.27-1.14" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.15">Forbid acknowledgment of packets containing only ACK and PADDING (#291)<a href="#section-c.27-1.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.16">Require that frames are processed when packets are acknowledged (#381, #341)<a href="#section-c.27-1.16" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.17">Removed the STOP_WAITING frame (#66)<a href="#section-c.27-1.17" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.18">Don't require retransmission of old timestamps for lost ACK frames (#308)<a href="#section-c.27-1.18" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.19">Clarified that frames are not retransmitted, but the information in them can
+be (#157, #298)<a href="#section-c.27-1.19" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.20">Error handling definitions (#335)<a href="#section-c.27-1.20" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.21">Split error codes into four sections (#74)<a href="#section-c.27-1.21" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.22">Forbid the use of Public Reset where CONNECTION_CLOSE is possible (#289)<a href="#section-c.27-1.22" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.23">Define packet protection rules (#336)<a href="#section-c.27-1.23" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.24">Require that stream be entirely delivered or reset, including acknowledgment
+of all STREAM frames or the RESET_STREAM, before it closes (#381)<a href="#section-c.27-1.24" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.25">Remove stream reservation from state machine (#174, #280)<a href="#section-c.27-1.25" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.26">Only stream 1 does not contribute to connection-level flow control (#204)<a href="#section-c.27-1.26" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.27">Stream 1 counts towards the maximum concurrent stream limit (#201, #282)<a href="#section-c.27-1.27" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.28">Remove connection-level flow control exclusion for some streams (except 1)
+(#246)<a href="#section-c.27-1.28" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.29">RESET_STREAM affects connection-level flow control (#162, #163)<a href="#section-c.27-1.29" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.30">Flow control accounting uses the maximum data offset on each stream, rather
+than bytes received (#378)<a href="#section-c.27-1.30" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.31">Moved length-determining fields to the start of STREAM and ACK (#168, #277)<a href="#section-c.27-1.31" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.32">Added the ability to pad between frames (#158, #276)<a href="#section-c.27-1.32" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.33">Remove error code and reason phrase from GOAWAY (#352, #355)<a href="#section-c.27-1.33" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.34">GOAWAY includes a final stream number for both directions (#347)<a href="#section-c.27-1.34" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.35">Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a consistent
+offset (#249)<a href="#section-c.27-1.35" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.27-1.36">Defined priority as the responsibility of the application protocol (#104,
+#303)<a href="#section-c.27-1.36" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-ietf-quic-transport-00">
+<section id="section-c.28">
+        <h2 id="name-since-draft-ietf-quic-transport-00">
+<a href="#section-c.28" class="section-number selfRef">C.28. </a><a href="#name-since-draft-ietf-quic-transport-00" class="section-name selfRef">Since draft-ietf-quic-transport-00</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.28-1.1">Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag<a href="#section-c.28-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.28-1.2">Defined versioning<a href="#section-c.28-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.28-1.3">Reworked description of packet and frame layout<a href="#section-c.28-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.28-1.4">Error code space is divided into regions for each component<a href="#section-c.28-1.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.28-1.5">Use big endian for all numeric values<a href="#section-c.28-1.5" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="since-draft-hamilton-quic-transport-protocol-01">
+<section id="section-c.29">
+        <h2 id="name-since-draft-hamilton-quic-t">
+<a href="#section-c.29" class="section-number selfRef">C.29. </a><a href="#name-since-draft-hamilton-quic-t" class="section-name selfRef">Since draft-hamilton-quic-transport-protocol-01</a>
+        </h2>
+<ul class="normal">
+<li class="normal" id="section-c.29-1.1">Adopted as base for draft-ietf-quic-tls<a href="#section-c.29-1.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.29-1.2">Updated authors/editors list<a href="#section-c.29-1.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.29-1.3">Added IANA Considerations section<a href="#section-c.29-1.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-c.29-1.4">Moved Contributors and Acknowledgments to appendices<a href="#section-c.29-1.4" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+</section>
+</div>
+<div id="contributors">
+<section id="section-appendix.d">
+      <h2 id="name-contributors">
+<a href="#name-contributors" class="section-name selfRef">Contributors</a>
+      </h2>
+<p id="section-appendix.d-1">The original design and rationale behind this protocol draw significantly from
+work by Jim Roskind <span>[<a href="#EARLY-DESIGN" class="xref">EARLY-DESIGN</a>]</span>.<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
+<p id="section-appendix.d-2">The IETF QUIC Working Group received an enormous amount of support from many
+people. The following people provided substantive contributions to this
+document:<a href="#section-appendix.d-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-appendix.d-3.1">Alessandro Ghedini<a href="#section-appendix.d-3.1" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.2">Alyssa Wilk<a href="#section-appendix.d-3.2" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.3">Antoine Delignat-Lavaud<a href="#section-appendix.d-3.3" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.4">Brian Trammell<a href="#section-appendix.d-3.4" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.5">Christian Huitema<a href="#section-appendix.d-3.5" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.6">Colin Perkins<a href="#section-appendix.d-3.6" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.7">David Schinazi<a href="#section-appendix.d-3.7" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.8">Dmitri Tikhonov<a href="#section-appendix.d-3.8" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.9">Eric Kinnear<a href="#section-appendix.d-3.9" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.10">Eric Rescorla<a href="#section-appendix.d-3.10" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.11">Gorry Fairhurst<a href="#section-appendix.d-3.11" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.12">Ian Swett<a href="#section-appendix.d-3.12" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.13">Igor Lubashev<a href="#section-appendix.d-3.13" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.14">
+          <p id="section-appendix.d-3.14.1">        <span class="contact-name"><span class="non-ascii">奥 一穂</span> (<span class="ascii">Kazuho Oku</span>)</span><a href="#section-appendix.d-3.14.1" class="pilcrow">¶</a></p>
+</li>
+<li class="normal" id="section-appendix.d-3.15">Lucas Pardue<a href="#section-appendix.d-3.15" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.16">Magnus Westerlund<a href="#section-appendix.d-3.16" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.17">Marten Seemann<a href="#section-appendix.d-3.17" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.18">Martin Duke<a href="#section-appendix.d-3.18" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.19">Mike Bishop<a href="#section-appendix.d-3.19" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.20">
+          <p id="section-appendix.d-3.20.1">        <span class="contact-name">Mikkel Fahnøe Jørgensen</span><a href="#section-appendix.d-3.20.1" class="pilcrow">¶</a></p>
+</li>
+<li class="normal" id="section-appendix.d-3.21">
+          <p id="section-appendix.d-3.21.1">        <span class="contact-name">Mirja Kühlewind</span><a href="#section-appendix.d-3.21.1" class="pilcrow">¶</a></p>
+</li>
+<li class="normal" id="section-appendix.d-3.22">Nick Banks<a href="#section-appendix.d-3.22" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.23">Nick Harper<a href="#section-appendix.d-3.23" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.24">Patrick McManus<a href="#section-appendix.d-3.24" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.25">Roberto Peon<a href="#section-appendix.d-3.25" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.26">Ryan Hamilton<a href="#section-appendix.d-3.26" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.27">Subodh Iyengar<a href="#section-appendix.d-3.27" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.28">Tatsuhiro Tsujikawa<a href="#section-appendix.d-3.28" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.29">Ted Hardie<a href="#section-appendix.d-3.29" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.30">Tom Jones<a href="#section-appendix.d-3.30" class="pilcrow">¶</a>
+</li>
+<li class="normal" id="section-appendix.d-3.31">Victor Vasiliev<a href="#section-appendix.d-3.31" class="pilcrow">¶</a>
+</li>
+</ul>
+</section>
+</div>
+<div id="authors-addresses">
+<section id="section-appendix.e">
+      <h2 id="name-authors-addresses">
+<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+      </h2>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Jana Iyengar (<span class="role">editor</span>)</span></div>
+<div dir="auto" class="left"><span class="org">Fastly</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:jri.ietf@gmail.com" class="email">jri.ietf@gmail.com</a>
+</div>
+</address>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Martin Thomson (<span class="role">editor</span>)</span></div>
+<div dir="auto" class="left"><span class="org">Mozilla</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:mt@lowentropy.net" class="email">mt@lowentropy.net</a>
+</div>
+</address>
+</section>
+</div>
+<script>const toc = document.getElementById("toc");
+toc.querySelector("h2").addEventListener("click", e => {
+  toc.classList.toggle("active");
+});
+toc.querySelector("nav").addEventListener("click", e => {
+  toc.classList.remove("active");
+});
+</script>
+</body>
+</html>
diff --git a/jri/mustnot/draft-ietf-quic-transport.txt b/jri/mustnot/draft-ietf-quic-transport.txt
new file mode 100644
index 0000000000..860d71beb7
--- /dev/null
+++ b/jri/mustnot/draft-ietf-quic-transport.txt
@@ -0,0 +1,10248 @@
+
+
+
+
+QUIC                                                     J. Iyengar, Ed.
+Internet-Draft                                                    Fastly
+Intended status: Standards Track                         M. Thomson, Ed.
+Expires: 5 December 2020                                         Mozilla
+                                                             3 June 2020
+
+
+           QUIC: A UDP-Based Multiplexed and Secure Transport
+                    draft-ietf-quic-transport-latest
+
+Abstract
+
+   This document defines the core of the QUIC transport protocol.
+   Accompanying documents describe QUIC's loss detection and congestion
+   control and the use of TLS for key negotiation.
+
+Note to Readers
+
+   Discussion of this draft takes place on the QUIC working group
+   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
+   archived at https://mailarchive.ietf.org/arch/search/?email_list=quic
+
+   Working Group information can be found at https://github.com/quicwg;
+   source code and issues list for this draft can be found at
+   https://github.com/quicwg/base-drafts/labels/-transport.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at https://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on 5 December 2020.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 1]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (https://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.  Code Components
+   extracted from this document must include Simplified BSD License text
+   as described in Section 4.e of the Trust Legal Provisions and are
+   provided without warranty as described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
+     1.1.  Document Structure  . . . . . . . . . . . . . . . . . . .   7
+     1.2.  Terms and Definitions . . . . . . . . . . . . . . . . . .   8
+     1.3.  Notational Conventions  . . . . . . . . . . . . . . . . .   9
+   2.  Streams . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     2.1.  Stream Types and Identifiers  . . . . . . . . . . . . . .  11
+     2.2.  Sending and Receiving Data  . . . . . . . . . . . . . . .  12
+     2.3.  Stream Prioritization . . . . . . . . . . . . . . . . . .  12
+     2.4.  Required Operations on Streams  . . . . . . . . . . . . .  13
+   3.  Stream States . . . . . . . . . . . . . . . . . . . . . . . .  13
+     3.1.  Sending Stream States . . . . . . . . . . . . . . . . . .  14
+     3.2.  Receiving Stream States . . . . . . . . . . . . . . . . .  17
+     3.3.  Permitted Frame Types . . . . . . . . . . . . . . . . . .  19
+     3.4.  Bidirectional Stream States . . . . . . . . . . . . . . .  20
+     3.5.  Solicited State Transitions . . . . . . . . . . . . . . .  21
+   4.  Flow Control  . . . . . . . . . . . . . . . . . . . . . . . .  23
+     4.1.  Data Flow Control . . . . . . . . . . . . . . . . . . . .  23
+     4.2.  Flow Credit Increments  . . . . . . . . . . . . . . . . .  24
+     4.3.  Handling Stream Cancellation  . . . . . . . . . . . . . .  25
+     4.4.  Stream Final Size . . . . . . . . . . . . . . . . . . . .  26
+     4.5.  Controlling Concurrency . . . . . . . . . . . . . . . . .  26
+   5.  Connections . . . . . . . . . . . . . . . . . . . . . . . . .  27
+     5.1.  Connection ID . . . . . . . . . . . . . . . . . . . . . .  27
+       5.1.1.  Issuing Connection IDs  . . . . . . . . . . . . . . .  29
+       5.1.2.  Consuming and Retiring Connection IDs . . . . . . . .  30
+     5.2.  Matching Packets to Connections . . . . . . . . . . . . .  31
+       5.2.1.  Client Packet Handling  . . . . . . . . . . . . . . .  32
+       5.2.2.  Server Packet Handling  . . . . . . . . . . . . . . .  32
+       5.2.3.  Considerations for Simple Load Balancers  . . . . . .  33
+     5.3.  Life of a QUIC Connection . . . . . . . . . . . . . . . .  33
+     5.4.  Required Operations on Connections  . . . . . . . . . . .  34
+   6.  Version Negotiation . . . . . . . . . . . . . . . . . . . . .  35
+     6.1.  Sending Version Negotiation Packets . . . . . . . . . . .  35
+     6.2.  Handling Version Negotiation Packets  . . . . . . . . . .  36
+       6.2.1.  Version Negotiation Between Draft Versions  . . . . .  36
+     6.3.  Using Reserved Versions . . . . . . . . . . . . . . . . .  37
+   7.  Cryptographic and Transport Handshake . . . . . . . . . . . .  37
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 2]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+     7.1.  Example Handshake Flows . . . . . . . . . . . . . . . . .  38
+     7.2.  Negotiating Connection IDs  . . . . . . . . . . . . . . .  39
+     7.3.  Authenticating Connection IDs . . . . . . . . . . . . . .  41
+     7.4.  Transport Parameters  . . . . . . . . . . . . . . . . . .  43
+       7.4.1.  Values of Transport Parameters for 0-RTT  . . . . . .  43
+       7.4.2.  New Transport Parameters  . . . . . . . . . . . . . .  45
+     7.5.  Cryptographic Message Buffering . . . . . . . . . . . . .  45
+   8.  Address Validation  . . . . . . . . . . . . . . . . . . . . .  46
+     8.1.  Address Validation During Connection Establishment  . . .  46
+       8.1.1.  Token Construction  . . . . . . . . . . . . . . . . .  47
+       8.1.2.  Address Validation using Retry Packets  . . . . . . .  47
+       8.1.3.  Address Validation for Future Connections . . . . . .  48
+       8.1.4.  Address Validation Token Integrity  . . . . . . . . .  51
+     8.2.  Path Validation . . . . . . . . . . . . . . . . . . . . .  51
+     8.3.  Initiating Path Validation  . . . . . . . . . . . . . . .  52
+     8.4.  Path Validation Responses . . . . . . . . . . . . . . . .  52
+     8.5.  Successful Path Validation  . . . . . . . . . . . . . . .  53
+     8.6.  Failed Path Validation  . . . . . . . . . . . . . . . . .  53
+   9.  Connection Migration  . . . . . . . . . . . . . . . . . . . .  54
+     9.1.  Probing a New Path  . . . . . . . . . . . . . . . . . . .  55
+     9.2.  Initiating Connection Migration . . . . . . . . . . . . .  55
+     9.3.  Responding to Connection Migration  . . . . . . . . . . .  56
+       9.3.1.  Peer Address Spoofing . . . . . . . . . . . . . . . .  56
+       9.3.2.  On-Path Address Spoofing  . . . . . . . . . . . . . .  57
+       9.3.3.  Off-Path Packet Forwarding  . . . . . . . . . . . . .  58
+     9.4.  Loss Detection and Congestion Control . . . . . . . . . .  59
+     9.5.  Privacy Implications of Connection Migration  . . . . . .  60
+     9.6.  Server's Preferred Address  . . . . . . . . . . . . . . .  61
+       9.6.1.  Communicating a Preferred Address . . . . . . . . . .  61
+       9.6.2.  Responding to Connection Migration  . . . . . . . . .  62
+       9.6.3.  Interaction of Client Migration and Preferred
+               Address . . . . . . . . . . . . . . . . . . . . . . .  62
+     9.7.  Use of IPv6 Flow-Label and Migration  . . . . . . . . . .  63
+   10. Connection Termination  . . . . . . . . . . . . . . . . . . .  63
+     10.1.  Closing and Draining Connection States . . . . . . . . .  64
+     10.2.  Idle Timeout . . . . . . . . . . . . . . . . . . . . . .  65
+     10.3.  Immediate Close  . . . . . . . . . . . . . . . . . . . .  66
+       10.3.1.  Immediate Close During the Handshake . . . . . . . .  67
+     10.4.  Stateless Reset  . . . . . . . . . . . . . . . . . . . .  69
+       10.4.1.  Detecting a Stateless Reset  . . . . . . . . . . . .  71
+       10.4.2.  Calculating a Stateless Reset Token  . . . . . . . .  72
+       10.4.3.  Looping  . . . . . . . . . . . . . . . . . . . . . .  73
+   11. Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  74
+     11.1.  Connection Errors  . . . . . . . . . . . . . . . . . . .  74
+     11.2.  Stream Errors  . . . . . . . . . . . . . . . . . . . . .  75
+   12. Packets and Frames  . . . . . . . . . . . . . . . . . . . . .  75
+     12.1.  Protected Packets  . . . . . . . . . . . . . . . . . . .  76
+     12.2.  Coalescing Packets . . . . . . . . . . . . . . . . . . .  76
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 3]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+     12.3.  Packet Numbers . . . . . . . . . . . . . . . . . . . . .  77
+     12.4.  Frames and Frame Types . . . . . . . . . . . . . . . . .  79
+   13. Packetization and Reliability . . . . . . . . . . . . . . . .  81
+     13.1.  Packet Processing  . . . . . . . . . . . . . . . . . . .  82
+     13.2.  Generating Acknowledgements  . . . . . . . . . . . . . .  82
+       13.2.1.  Sending ACK Frames . . . . . . . . . . . . . . . . .  83
+       13.2.2.  Acknowledgement Frequency  . . . . . . . . . . . . .  84
+       13.2.3.  Managing ACK Ranges  . . . . . . . . . . . . . . . .  84
+       13.2.4.  Receiver Tracking of ACK Frames  . . . . . . . . . .  85
+       13.2.5.  Limiting ACK Ranges  . . . . . . . . . . . . . . . .  85
+       13.2.6.  Measuring and Reporting Host Delay . . . . . . . . .  86
+       13.2.7.  ACK Frames and Packet Protection . . . . . . . . . .  86
+       13.2.8.  PADDING Frames Consume Congestion Window . . . . . .  87
+     13.3.  Retransmission of Information  . . . . . . . . . . . . .  87
+     13.4.  Explicit Congestion Notification . . . . . . . . . . . .  90
+       13.4.1.  ECN Counts . . . . . . . . . . . . . . . . . . . . .  90
+       13.4.2.  ECN Validation . . . . . . . . . . . . . . . . . . .  91
+   14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . .  93
+     14.1.  Path Maximum Transmission Unit (PMTU)  . . . . . . . . .  93
+     14.2.  ICMP Packet Too Big Messages . . . . . . . . . . . . . .  94
+     14.3.  Datagram Packetization Layer PMTU Discovery  . . . . . .  95
+       14.3.1.  PMTU Probes Containing Source Connection ID  . . . .  96
+   15. Versions  . . . . . . . . . . . . . . . . . . . . . . . . . .  96
+   16. Variable-Length Integer Encoding  . . . . . . . . . . . . . .  97
+   17. Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .  98
+     17.1.  Packet Number Encoding and Decoding  . . . . . . . . . .  98
+     17.2.  Long Header Packets  . . . . . . . . . . . . . . . . . .  99
+       17.2.1.  Version Negotiation Packet . . . . . . . . . . . . . 102
+       17.2.2.  Initial Packet . . . . . . . . . . . . . . . . . . . 104
+       17.2.3.  0-RTT  . . . . . . . . . . . . . . . . . . . . . . . 106
+       17.2.4.  Handshake Packet . . . . . . . . . . . . . . . . . . 107
+       17.2.5.  Retry Packet . . . . . . . . . . . . . . . . . . . . 108
+     17.3.  Short Header Packets . . . . . . . . . . . . . . . . . . 110
+       17.3.1.  Latency Spin Bit . . . . . . . . . . . . . . . . . . 112
+   18. Transport Parameter Encoding  . . . . . . . . . . . . . . . . 113
+     18.1.  Reserved Transport Parameters  . . . . . . . . . . . . . 114
+     18.2.  Transport Parameter Definitions  . . . . . . . . . . . . 114
+   19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 118
+     19.1.  PADDING Frame  . . . . . . . . . . . . . . . . . . . . . 118
+     19.2.  PING Frame . . . . . . . . . . . . . . . . . . . . . . . 119
+     19.3.  ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 119
+       19.3.1.  ACK Ranges . . . . . . . . . . . . . . . . . . . . . 121
+       19.3.2.  ECN Counts . . . . . . . . . . . . . . . . . . . . . 122
+     19.4.  RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 123
+     19.5.  STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 124
+     19.6.  CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 124
+     19.7.  NEW_TOKEN Frame  . . . . . . . . . . . . . . . . . . . . 125
+     19.8.  STREAM Frames  . . . . . . . . . . . . . . . . . . . . . 126
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 4]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+     19.9.  MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 128
+     19.10. MAX_STREAM_DATA Frame  . . . . . . . . . . . . . . . . . 128
+     19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 129
+     19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 130
+     19.13. STREAM_DATA_BLOCKED Frame  . . . . . . . . . . . . . . . 131
+     19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 131
+     19.15. NEW_CONNECTION_ID Frame  . . . . . . . . . . . . . . . . 132
+     19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 133
+     19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 134
+     19.18. PATH_RESPONSE Frame  . . . . . . . . . . . . . . . . . . 135
+     19.19. CONNECTION_CLOSE Frames  . . . . . . . . . . . . . . . . 135
+     19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 136
+     19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 137
+   20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 137
+     20.1.  Application Protocol Error Codes . . . . . . . . . . . . 139
+   21. Security Considerations . . . . . . . . . . . . . . . . . . . 139
+     21.1.  Handshake Denial of Service  . . . . . . . . . . . . . . 139
+     21.2.  Amplification Attack . . . . . . . . . . . . . . . . . . 140
+     21.3.  Optimistic ACK Attack  . . . . . . . . . . . . . . . . . 141
+     21.4.  Slowloris Attacks  . . . . . . . . . . . . . . . . . . . 141
+     21.5.  Stream Fragmentation and Reassembly Attacks  . . . . . . 141
+     21.6.  Stream Commitment Attack . . . . . . . . . . . . . . . . 142
+     21.7.  Peer Denial of Service . . . . . . . . . . . . . . . . . 142
+     21.8.  Explicit Congestion Notification Attacks . . . . . . . . 143
+     21.9.  Stateless Reset Oracle . . . . . . . . . . . . . . . . . 143
+     21.10. Version Downgrade  . . . . . . . . . . . . . . . . . . . 144
+     21.11. Targeted Attacks by Routing  . . . . . . . . . . . . . . 144
+     21.12. Overview of Security Properties  . . . . . . . . . . . . 144
+       21.12.1.  Handshake . . . . . . . . . . . . . . . . . . . . . 145
+       21.12.2.  Protected Packets . . . . . . . . . . . . . . . . . 146
+       21.12.3.  Connection Migration  . . . . . . . . . . . . . . . 147
+   22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151
+     22.1.  Registration Policies for QUIC Registries  . . . . . . . 151
+       22.1.1.  Provisional Registrations  . . . . . . . . . . . . . 151
+       22.1.2.  Selecting Codepoints . . . . . . . . . . . . . . . . 152
+       22.1.3.  Reclaiming Provisional Codepoints  . . . . . . . . . 153
+       22.1.4.  Permanent Registrations  . . . . . . . . . . . . . . 154
+     22.2.  QUIC Transport Parameter Registry  . . . . . . . . . . . 154
+     22.3.  QUIC Frame Type Registry . . . . . . . . . . . . . . . . 155
+     22.4.  QUIC Transport Error Codes Registry  . . . . . . . . . . 156
+   23. References  . . . . . . . . . . . . . . . . . . . . . . . . . 158
+     23.1.  Normative References . . . . . . . . . . . . . . . . . . 158
+     23.2.  Informative References . . . . . . . . . . . . . . . . . 159
+   Appendix A.  Sample Packet Number Decoding Algorithm  . . . . . . 161
+   Appendix B.  Sample ECN Validation Algorithm  . . . . . . . . . . 162
+   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . . 163
+     C.1.  Since draft-ietf-quic-transport-27  . . . . . . . . . . . 163
+     C.2.  Since draft-ietf-quic-transport-26  . . . . . . . . . . . 164
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 5]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+     C.3.  Since draft-ietf-quic-transport-25  . . . . . . . . . . . 164
+     C.4.  Since draft-ietf-quic-transport-24  . . . . . . . . . . . 165
+     C.5.  Since draft-ietf-quic-transport-23  . . . . . . . . . . . 166
+     C.6.  Since draft-ietf-quic-transport-22  . . . . . . . . . . . 166
+     C.7.  Since draft-ietf-quic-transport-21  . . . . . . . . . . . 167
+     C.8.  Since draft-ietf-quic-transport-20  . . . . . . . . . . . 168
+     C.9.  Since draft-ietf-quic-transport-19  . . . . . . . . . . . 169
+     C.10. Since draft-ietf-quic-transport-18  . . . . . . . . . . . 169
+     C.11. Since draft-ietf-quic-transport-17  . . . . . . . . . . . 169
+     C.12. Since draft-ietf-quic-transport-16  . . . . . . . . . . . 170
+     C.13. Since draft-ietf-quic-transport-15  . . . . . . . . . . . 171
+     C.14. Since draft-ietf-quic-transport-14  . . . . . . . . . . . 172
+     C.15. Since draft-ietf-quic-transport-13  . . . . . . . . . . . 172
+     C.16. Since draft-ietf-quic-transport-12  . . . . . . . . . . . 173
+     C.17. Since draft-ietf-quic-transport-11  . . . . . . . . . . . 174
+     C.18. Since draft-ietf-quic-transport-10  . . . . . . . . . . . 174
+     C.19. Since draft-ietf-quic-transport-09  . . . . . . . . . . . 175
+     C.20. Since draft-ietf-quic-transport-08  . . . . . . . . . . . 175
+     C.21. Since draft-ietf-quic-transport-07  . . . . . . . . . . . 176
+     C.22. Since draft-ietf-quic-transport-06  . . . . . . . . . . . 177
+     C.23. Since draft-ietf-quic-transport-05  . . . . . . . . . . . 177
+     C.24. Since draft-ietf-quic-transport-04  . . . . . . . . . . . 177
+     C.25. Since draft-ietf-quic-transport-03  . . . . . . . . . . . 178
+     C.26. Since draft-ietf-quic-transport-02  . . . . . . . . . . . 178
+     C.27. Since draft-ietf-quic-transport-01  . . . . . . . . . . . 179
+     C.28. Since draft-ietf-quic-transport-00  . . . . . . . . . . . 181
+     C.29. Since draft-hamilton-quic-transport-protocol-01 . . . . . 181
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 182
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 183
+
+1.  Introduction
+
+   QUIC is a multiplexed and secure general-purpose transport protocol
+   that provides:
+
+   *  Stream multiplexing
+
+   *  Stream and connection-level flow control
+
+   *  Low-latency connection establishment
+
+   *  Connection migration and resilience to NAT rebinding
+
+   *  Authenticated and encrypted header and payload
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 6]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   QUIC uses UDP as a substrate to avoid requiring changes to legacy
+   client operating systems and middleboxes.  QUIC authenticates all of
+   its headers and encrypts most of the data it exchanges, including its
+   signaling, to avoid incurring a dependency on middleboxes.
+
+1.1.  Document Structure
+
+   This document describes the core QUIC protocol and is structured as
+   follows:
+
+   *  Streams are the basic service abstraction that QUIC provides.
+
+      -  Section 2 describes core concepts related to streams,
+
+      -  Section 3 provides a reference model for stream states, and
+
+      -  Section 4 outlines the operation of flow control.
+
+   *  Connections are the context in which QUIC endpoints communicate.
+
+      -  Section 5 describes core concepts related to connections,
+
+      -  Section 6 describes version negotiation,
+
+      -  Section 7 details the process for establishing connections,
+
+      -  Section 8 specifies critical denial of service mitigation
+         mechanisms,
+
+      -  Section 9 describes how endpoints migrate a connection to a new
+         network path,
+
+      -  Section 10 lists the options for terminating an open
+         connection, and
+
+      -  Section 11 provides general guidance for error handling.
+
+   *  Packets and frames are the basic unit used by QUIC to communicate.
+
+      -  Section 12 describes concepts related to packets and frames,
+
+      -  Section 13 defines models for the transmission, retransmission,
+         and acknowledgement of data, and
+
+      -  Section 14 specifies rules for managing the size of packets.
+
+   *  Finally, encoding details of QUIC protocol elements are described
+      in:
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 7]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      -  Section 15 (Versions),
+
+      -  Section 16 (Integer Encoding),
+
+      -  Section 17 (Packet Headers),
+
+      -  Section 18 (Transport Parameters),
+
+      -  Section 19 (Frames), and
+
+      -  Section 20 (Errors).
+
+   Accompanying documents describe QUIC's loss detection and congestion
+   control [QUIC-RECOVERY], and the use of TLS for key negotiation
+   [QUIC-TLS].
+
+   This document defines QUIC version 1, which conforms to the protocol
+   invariants in [QUIC-INVARIANTS].
+
+   To refer to QUIC version 1, cite this document.  References to the
+   limited set of version-independent properties of QUIC can cite
+   [QUIC-INVARIANTS].
+
+1.2.  Terms and Definitions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Commonly used terms in the document are described below.
+
+   QUIC:  The transport protocol described by this document.  QUIC is a
+      name, not an acronym.
+
+   QUIC packet:  A complete processable unit of QUIC that can be
+      encapsulated in a UDP datagram.  Multiple QUIC packets can be
+      encapsulated in a single UDP datagram.
+
+   Ack-eliciting Packet:  A QUIC packet that contains frames other than
+      ACK, PADDING, and CONNECTION_CLOSE.  These cause a recipient to
+      send an acknowledgment; see Section 13.2.1.
+
+   Out-of-order packet:  A packet that does not increase the largest
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 8]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      received packet number for its packet number space (Section 12.3)
+      by exactly one.  A packet can arrive out of order if it is
+      delayed, if earlier packets are lost or delayed, or if the sender
+      intentionally skips a packet number.
+
+   Endpoint:  An entity that can participate in a QUIC connection by
+      generating, receiving, and processing QUIC packets.  There are
+      only two types of endpoint in QUIC: client and server.
+
+   Client:  The endpoint initiating a QUIC connection.
+
+   Server:  The endpoint accepting incoming QUIC connections.
+
+   Address:  When used without qualification, the tuple of IP version,
+      IP address, UDP protocol, and UDP port number that represents one
+      end of a network path.
+
+   Connection ID:  An opaque identifier that is used to identify a QUIC
+      connection at an endpoint.  Each endpoint sets a value for its
+      peer to include in packets sent towards the endpoint.
+
+   Stream:  A unidirectional or bidirectional channel of ordered bytes
+      within a QUIC connection.  A QUIC connection can carry multiple
+      simultaneous streams.
+
+   Application:  An entity that uses QUIC to send and receive data.
+
+1.3.  Notational Conventions
+
+   Packet and frame diagrams in this document use a bespoke format.  The
+   purpose of this format is to summarize, not define, protocol
+   elements.  Prose defines the complete semantics and details of
+   structures.
+
+   Complex fields are named and then followed by a list of fields
+   surrounded by a pair of matching braces.  Each field in this list is
+   separated by commas.
+
+   Individual fields include length information, plus indications about
+   fixed value, optionality, or repetitions.  Individual fields use the
+   following notational conventions, with all lengths in bits:
+
+   x (A):  Indicates that x is A bits long
+
+   x (i):  Indicates that x uses the variable-length encoding in
+      Section 16
+
+   x (A..B):  Indicates that x can be any length from A to B; A can be
+
+
+
+Iyengar & Thomson        Expires 5 December 2020                [Page 9]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      omitted to indicate a minimum of zero bits and B can be omitted to
+      indicate no set upper limit; values in this format always end on
+      an octet boundary
+
+   x (?) = C:  Indicates that x has a fixed value of C
+
+   x (?) = C..D:  Indicates that x has a value in the range from C to D,
+      inclusive
+
+   [x (E)]:  Indicates that x is optional (and has length of E)
+
+   x (E) ...:  Indicates that x is repeated zero or more times (and that
+      each instance is length E)
+
+   By convention, individual fields reference a complex field by using
+   the name of the complex field.
+
+   For example:
+
+   Example Structure {
+     One-bit Field (1),
+     7-bit Field with Fixed Value (7) = 61,
+     Field with Variable-Length Integer (i),
+     Arbitrary-Length Field (..),
+     Variable-Length Field (8..24),
+     Field With Minimum Length (16..),
+     Field With Maximum Length (..128),
+     [Optional Field (64)],
+     Repeated Field (8) ...,
+   }
+
+                          Figure 1: Example Format
+
+2.  Streams
+
+   Streams in QUIC provide a lightweight, ordered byte-stream
+   abstraction to an application.  Streams can be unidirectional or
+   bidirectional.  An alternative view of QUIC unidirectional streams is
+   a "message" abstraction of practically unlimited length.
+
+   Streams can be created by sending data.  Other processes associated
+   with stream management - ending, cancelling, and managing flow
+   control - are all designed to impose minimal overheads.  For
+   instance, a single STREAM frame (Section 19.8) can open, carry data
+   for, and close a stream.  Streams can also be long-lived and can last
+   the entire duration of a connection.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 10]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Streams can be created by either endpoint, can concurrently send data
+   interleaved with other streams, and can be cancelled.  QUIC does not
+   provide any means of ensuring ordering between bytes on different
+   streams.
+
+   QUIC allows for an arbitrary number of streams to operate
+   concurrently and for an arbitrary amount of data to be sent on any
+   stream, subject to flow control constraints and stream limits; see
+   Section 4.
+
+2.1.  Stream Types and Identifiers
+
+   Streams can be unidirectional or bidirectional.  Unidirectional
+   streams carry data in one direction: from the initiator of the stream
+   to its peer.  Bidirectional streams allow for data to be sent in both
+   directions.
+
+   Streams are identified within a connection by a numeric value,
+   referred to as the stream ID.  A stream ID is a 62-bit integer (0 to
+   2^62-1) that is unique for all streams on a connection.  Stream IDs
+   are encoded as variable-length integers; see Section 16.  A QUIC
+   endpoint MUST NOT reuse a stream ID within a connection.
+
+   The least significant bit (0x1) of the stream ID identifies the
+   initiator of the stream.  Client-initiated streams have even-numbered
+   stream IDs (with the bit set to 0), and server-initiated streams have
+   odd-numbered stream IDs (with the bit set to 1).
+
+   The second least significant bit (0x2) of the stream ID distinguishes
+   between bidirectional streams (with the bit set to 0) and
+   unidirectional streams (with the bit set to 1).
+
+   The least significant two bits from a stream ID therefore identify a
+   stream as one of four types, as summarized in Table 1.
+
+                +------+----------------------------------+
+                | Bits | Stream Type                      |
+                +======+==================================+
+                | 0x0  | Client-Initiated, Bidirectional  |
+                +------+----------------------------------+
+                | 0x1  | Server-Initiated, Bidirectional  |
+                +------+----------------------------------+
+                | 0x2  | Client-Initiated, Unidirectional |
+                +------+----------------------------------+
+                | 0x3  | Server-Initiated, Unidirectional |
+                +------+----------------------------------+
+
+                          Table 1: Stream ID Types
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 11]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Within each type, streams are created with numerically increasing
+   stream IDs.  A stream ID that is used out of order results in all
+   streams of that type with lower-numbered stream IDs also being
+   opened.
+
+   The first bidirectional stream opened by the client has a stream ID
+   of 0.
+
+2.2.  Sending and Receiving Data
+
+   STREAM frames (Section 19.8) encapsulate data sent by an application.
+   An endpoint uses the Stream ID and Offset fields in STREAM frames to
+   place data in order.
+
+   Endpoints MUST be able to deliver stream data to an application as an
+   ordered byte-stream.  Delivering an ordered byte-stream requires that
+   an endpoint buffer any data that is received out of order, up to the
+   advertised flow control limit.
+
+   QUIC makes no specific allowances for delivery of stream data out of
+   order.  However, implementations MAY choose to offer the ability to
+   deliver data out of order to a receiving application.
+
+   An endpoint could receive data for a stream at the same stream offset
+   multiple times.  Data that has already been received can be
+   discarded.  The data at a given offset MUST NOT change if it is sent
+   multiple times; an endpoint MAY treat receipt of different data at
+   the same offset within a stream as a connection error of type
+   PROTOCOL_VIOLATION.
+
+   Streams are an ordered byte-stream abstraction with no other
+   structure visible to QUIC.  STREAM frame boundaries are not expected
+   to be preserved when data is transmitted, retransmitted after packet
+   loss, or delivered to the application at a receiver.
+
+   An endpoint MUST NOT send data on any stream without ensuring that it
+   is within the flow control limits set by its peer.  Flow control is
+   described in detail in Section 4.
+
+2.3.  Stream Prioritization
+
+   Stream multiplexing can have a significant effect on application
+   performance if resources allocated to streams are correctly
+   prioritized.
+
+   QUIC does not provide a mechanism for exchanging prioritization
+   information.  Instead, it relies on receiving priority information
+   from the application that uses QUIC.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 12]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   A QUIC implementation SHOULD provide ways in which an application can
+   indicate the relative priority of streams.  When deciding which
+   streams to dedicate resources to, the implementation SHOULD use the
+   information provided by the application.
+
+2.4.  Required Operations on Streams
+
+   There are certain operations which an application MUST be able to
+   perform when interacting with QUIC streams.  This document does not
+   specify an API, but any implementation of this version of QUIC MUST
+   expose the ability to perform the operations described in this
+   section on a QUIC stream.
+
+   On the sending part of a stream, application protocols need to be
+   able to:
+
+   *  write data, understanding when stream flow control credit
+      (Section 4.1) has successfully been reserved to send the written
+      data;
+
+   *  end the stream (clean termination), resulting in a STREAM frame
+      (Section 19.8) with the FIN bit set; and
+
+   *  reset the stream (abrupt termination), resulting in a RESET_STREAM
+      frame (Section 19.4), if the stream was not already in a terminal
+      state.
+
+   On the receiving part of a stream, application protocols need to be
+   able to:
+
+   *  read data; and
+
+   *  abort reading of the stream and request closure, possibly
+      resulting in a STOP_SENDING frame (Section 19.5).
+
+   Applications also need to be informed of state changes on streams,
+   including when the peer has opened or reset a stream, when a peer
+   aborts reading on a stream, when new data is available, and when data
+   can or cannot be written to the stream due to flow control.
+
+3.  Stream States
+
+   This section describes streams in terms of their send or receive
+   components.  Two state machines are described: one for the streams on
+   which an endpoint transmits data (Section 3.1), and another for
+   streams on which an endpoint receives data (Section 3.2).
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 13]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Unidirectional streams use the applicable state machine directly.
+   Bidirectional streams use both state machines.  For the most part,
+   the use of these state machines is the same whether the stream is
+   unidirectional or bidirectional.  The conditions for opening a stream
+   are slightly more complex for a bidirectional stream because the
+   opening of either send or receive sides causes the stream to open in
+   both directions.
+
+   An endpoint MUST open streams of the same type in increasing order of
+   stream ID.
+
+   Note:  These states are largely informative.  This document uses
+      stream states to describe rules for when and how different types
+      of frames can be sent and the reactions that are expected when
+      different types of frames are received.  Though these state
+      machines are intended to be useful in implementing QUIC, these
+      states aren't intended to constrain implementations.  An
+      implementation can define a different state machine as long as its
+      behavior is consistent with an implementation that implements
+      these states.
+
+3.1.  Sending Stream States
+
+   Figure 2 shows the states for the part of a stream that sends data to
+   a peer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 14]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+          o
+          | Create Stream (Sending)
+          | Peer Creates Bidirectional Stream
+          v
+      +-------+
+      | Ready | Send RESET_STREAM
+      |       |-----------------------.
+      +-------+                       |
+          |                           |
+          | Send STREAM /             |
+          |      STREAM_DATA_BLOCKED  |
+          |                           |
+          | Peer Creates              |
+          |      Bidirectional Stream |
+          v                           |
+      +-------+                       |
+      | Send  | Send RESET_STREAM     |
+      |       |---------------------->|
+      +-------+                       |
+          |                           |
+          | Send STREAM + FIN         |
+          v                           v
+      +-------+                   +-------+
+      | Data  | Send RESET_STREAM | Reset |
+      | Sent  |------------------>| Sent  |
+      +-------+                   +-------+
+          |                           |
+          | Recv All ACKs             | Recv ACK
+          v                           v
+      +-------+                   +-------+
+      | Data  |                   | Reset |
+      | Recvd |                   | Recvd |
+      +-------+                   +-------+
+
+               Figure 2: States for Sending Parts of Streams
+
+   The sending part of stream that the endpoint initiates (types 0 and 2
+   for clients, 1 and 3 for servers) is opened by the application.  The
+   "Ready" state represents a newly created stream that is able to
+   accept data from the application.  Stream data might be buffered in
+   this state in preparation for sending.
+
+   Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a
+   sending part of a stream to enter the "Send" state.  An
+   implementation might choose to defer allocating a stream ID to a
+   stream until it sends the first STREAM frame and enters this state,
+   which can allow for better stream prioritization.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 15]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The sending part of a bidirectional stream initiated by a peer (type
+   0 for a server, type 1 for a client) starts in the "Ready" state when
+   the receiving part is created.
+
+   In the "Send" state, an endpoint transmits - and retransmits as
+   necessary - stream data in STREAM frames.  The endpoint respects the
+   flow control limits set by its peer, and continues to accept and
+   process MAX_STREAM_DATA frames.  An endpoint in the "Send" state
+   generates STREAM_DATA_BLOCKED frames if it is blocked from sending by
+   stream or connection flow control limits Section 4.1.
+
+   After the application indicates that all stream data has been sent
+   and a STREAM frame containing the FIN bit is sent, the sending part
+   of the stream enters the "Data Sent" state.  From this state, the
+   endpoint only retransmits stream data as necessary.  The endpoint
+   does not need to check flow control limits or send
+   STREAM_DATA_BLOCKED frames for a stream in this state.
+   MAX_STREAM_DATA frames might be received until the peer receives the
+   final stream offset.  The endpoint can safely ignore any
+   MAX_STREAM_DATA frames it receives from its peer for a stream in this
+   state.
+
+   Once all stream data has been successfully acknowledged, the sending
+   part of the stream enters the "Data Recvd" state, which is a terminal
+   state.
+
+   From any of the "Ready", "Send", or "Data Sent" states, an
+   application can signal that it wishes to abandon transmission of
+   stream data.  Alternatively, an endpoint might receive a STOP_SENDING
+   frame from its peer.  In either case, the endpoint sends a
+   RESET_STREAM frame, which causes the stream to enter the "Reset Sent"
+   state.
+
+   An endpoint MAY send a RESET_STREAM as the first frame that mentions
+   a stream; this causes the sending part of that stream to open and
+   then immediately transition to the "Reset Sent" state.
+
+   Once a packet containing a RESET_STREAM has been acknowledged, the
+   sending part of the stream enters the "Reset Recvd" state, which is a
+   terminal state.
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 16]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+3.2.  Receiving Stream States
+
+   Figure 3 shows the states for the part of a stream that receives data
+   from a peer.  The states for a receiving part of a stream mirror only
+   some of the states of the sending part of the stream at the peer.
+   The receiving part of a stream does not track states on the sending
+   part that cannot be observed, such as the "Ready" state.  Instead,
+   the receiving part of a stream tracks the delivery of data to the
+   application, some of which cannot be observed by the sender.
+
+          o
+          | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
+          | Create Bidirectional Stream (Sending)
+          | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)
+          | Create Higher-Numbered Stream
+          v
+      +-------+
+      | Recv  | Recv RESET_STREAM
+      |       |-----------------------.
+      +-------+                       |
+          |                           |
+          | Recv STREAM + FIN         |
+          v                           |
+      +-------+                       |
+      | Size  | Recv RESET_STREAM     |
+      | Known |---------------------->|
+      +-------+                       |
+          |                           |
+          | Recv All Data             |
+          v                           v
+      +-------+ Recv RESET_STREAM +-------+
+      | Data  |--- (optional) --->| Reset |
+      | Recvd |  Recv All Data    | Recvd |
+      +-------+<-- (optional) ----+-------+
+          |                           |
+          | App Read All Data         | App Read RST
+          v                           v
+      +-------+                   +-------+
+      | Data  |                   | Reset |
+      | Read  |                   | Read  |
+      +-------+                   +-------+
+
+              Figure 3: States for Receiving Parts of Streams
+
+   The receiving part of a stream initiated by a peer (types 1 and 3 for
+   a client, or 0 and 2 for a server) is created when the first STREAM,
+   STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream.
+   For bidirectional streams initiated by a peer, receipt of a
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 17]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
+   stream also creates the receiving part.  The initial state for the
+   receiving part of stream is "Recv".
+
+   The receiving part of a stream enters the "Recv" state when the
+   sending part of a bidirectional stream initiated by the endpoint
+   (type 0 for a client, type 1 for a server) enters the "Ready" state.
+
+   An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or
+   STOP_SENDING frame is received from the peer for that stream.
+   Receiving a MAX_STREAM_DATA frame for an unopened stream indicates
+   that the remote peer has opened the stream and is providing flow
+   control credit.  Receiving a STOP_SENDING frame for an unopened
+   stream indicates that the remote peer no longer wishes to receive
+   data on this stream.  Either frame might arrive before a STREAM or
+   STREAM_DATA_BLOCKED frame if packets are lost or reordered.
+
+   Before a stream is created, all streams of the same type with lower-
+   numbered stream IDs MUST be created.  This ensures that the creation
+   order for streams is consistent on both endpoints.
+
+   In the "Recv" state, the endpoint receives STREAM and
+   STREAM_DATA_BLOCKED frames.  Incoming data is buffered and can be
+   reassembled into the correct order for delivery to the application.
+   As data is consumed by the application and buffer space becomes
+   available, the endpoint sends MAX_STREAM_DATA frames to allow the
+   peer to send more data.
+
+   When a STREAM frame with a FIN bit is received, the final size of the
+   stream is known; see Section 4.4.  The receiving part of the stream
+   then enters the "Size Known" state.  In this state, the endpoint no
+   longer needs to send MAX_STREAM_DATA frames, it only receives any
+   retransmissions of stream data.
+
+   Once all data for the stream has been received, the receiving part
+   enters the "Data Recvd" state.  This might happen as a result of
+   receiving the same STREAM frame that causes the transition to "Size
+   Known".  After all data has been received, any STREAM or
+   STREAM_DATA_BLOCKED frames for the stream can be discarded.
+
+   The "Data Recvd" state persists until stream data has been delivered
+   to the application.  Once stream data has been delivered, the stream
+   enters the "Data Read" state, which is a terminal state.
+
+   Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states
+   causes the stream to enter the "Reset Recvd" state.  This might cause
+   the delivery of stream data to the application to be interrupted.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 18]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   It is possible that all stream data is received when a RESET_STREAM
+   is received (that is, from the "Data Recvd" state).  Similarly, it is
+   possible for remaining stream data to arrive after receiving a
+   RESET_STREAM frame (the "Reset Recvd" state).  An implementation is
+   free to manage this situation as it chooses.
+
+   Sending RESET_STREAM means that an endpoint cannot guarantee delivery
+   of stream data; however there is no requirement that stream data not
+   be delivered if a RESET_STREAM is received.  An implementation MAY
+   interrupt delivery of stream data, discard any data that was not
+   consumed, and signal the receipt of the RESET_STREAM.  A RESET_STREAM
+   signal might be suppressed or withheld if stream data is completely
+   received and is buffered to be read by the application.  If the
+   RESET_STREAM is suppressed, the receiving part of the stream remains
+   in "Data Recvd".
+
+   Once the application receives the signal indicating that the stream
+   was reset, the receiving part of the stream transitions to the "Reset
+   Read" state, which is a terminal state.
+
+3.3.  Permitted Frame Types
+
+   The sender of a stream sends just three frame types that affect the
+   state of a stream at either sender or receiver: STREAM
+   (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM
+   (Section 19.4).
+
+   A sender MUST NOT send any of these frames from a terminal state
+   ("Data Recvd" or "Reset Recvd").  A sender MUST NOT send STREAM or
+   STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the
+   terminal states and in the "Reset Sent" state.  A receiver could
+   receive any of these three frames in any state, due to the
+   possibility of delayed delivery of packets carrying them.
+
+   The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and
+   STOP_SENDING frames (Section 19.5).
+
+   The receiver only sends MAX_STREAM_DATA in the "Recv" state.  A
+   receiver can send STOP_SENDING in any state where it has not received
+   a RESET_STREAM frame; that is states other than "Reset Recvd" or
+   "Reset Read".  However there is little value in sending a
+   STOP_SENDING frame in the "Data Recvd" state, since all stream data
+   has been received.  A sender could receive either of these two frames
+   in any state as a result of delayed delivery of packets.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 19]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+3.4.  Bidirectional Stream States
+
+   A bidirectional stream is composed of sending and receiving parts.
+   Implementations may represent states of the bidirectional stream as
+   composites of sending and receiving stream states.  The simplest
+   model presents the stream as "open" when either sending or receiving
+   parts are in a non-terminal state and "closed" when both sending and
+   receiving streams are in terminal states.
+
+   Table 2 shows a more complex mapping of bidirectional stream states
+   that loosely correspond to the stream states in HTTP/2 [HTTP2].  This
+   shows that multiple states on sending or receiving parts of streams
+   are mapped to the same composite state.  Note that this is just one
+   possibility for such a mapping; this mapping requires that data is
+   acknowledged before the transition to a "closed" or "half-closed"
+   state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 20]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+     +----------------------+----------------------+-----------------+
+     | Sending Part         | Receiving Part       | Composite State |
+     +======================+======================+=================+
+     | No Stream/Ready      | No Stream/Recv *1    | idle            |
+     +----------------------+----------------------+-----------------+
+     | Ready/Send/Data Sent | Recv/Size Known      | open            |
+     +----------------------+----------------------+-----------------+
+     | Ready/Send/Data Sent | Data Recvd/Data Read | half-closed     |
+     |                      |                      | (remote)        |
+     +----------------------+----------------------+-----------------+
+     | Ready/Send/Data Sent | Reset Recvd/Reset    | half-closed     |
+     |                      | Read                 | (remote)        |
+     +----------------------+----------------------+-----------------+
+     | Data Recvd           | Recv/Size Known      | half-closed     |
+     |                      |                      | (local)         |
+     +----------------------+----------------------+-----------------+
+     | Reset Sent/Reset     | Recv/Size Known      | half-closed     |
+     | Recvd                |                      | (local)         |
+     +----------------------+----------------------+-----------------+
+     | Reset Sent/Reset     | Data Recvd/Data Read | closed          |
+     | Recvd                |                      |                 |
+     +----------------------+----------------------+-----------------+
+     | Reset Sent/Reset     | Reset Recvd/Reset    | closed          |
+     | Recvd                | Read                 |                 |
+     +----------------------+----------------------+-----------------+
+     | Data Recvd           | Data Recvd/Data Read | closed          |
+     +----------------------+----------------------+-----------------+
+     | Data Recvd           | Reset Recvd/Reset    | closed          |
+     |                      | Read                 |                 |
+     +----------------------+----------------------+-----------------+
+
+            Table 2: Possible Mapping of Stream States to HTTP/2
+
+   Note (*1):  A stream is considered "idle" if it has not yet been
+      created, or if the receiving part of the stream is in the "Recv"
+      state without yet having received any frames.
+
+3.5.  Solicited State Transitions
+
+   If an application is no longer interested in the data it is receiving
+   on a stream, it can abort reading the stream and specify an
+   application error code.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 21]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   If the stream is in the "Recv" or "Size Known" states, the transport
+   SHOULD signal this by sending a STOP_SENDING frame to prompt closure
+   of the stream in the opposite direction.  This typically indicates
+   that the receiving application is no longer reading data it receives
+   from the stream, but it is not a guarantee that incoming data will be
+   ignored.
+
+   STREAM frames received after sending STOP_SENDING are still counted
+   toward connection and stream flow control, even though these frames
+   can be discarded upon receipt.
+
+   A STOP_SENDING frame requests that the receiving endpoint send a
+   RESET_STREAM frame.  An endpoint that receives a STOP_SENDING frame
+   MUST send a RESET_STREAM frame if the stream is in the Ready or Send
+   state.  If the stream is in the Data Sent state and any outstanding
+   data is declared lost, an endpoint SHOULD send a RESET_STREAM frame
+   in lieu of a retransmission.
+
+   An endpoint SHOULD copy the error code from the STOP_SENDING frame to
+   the RESET_STREAM frame it sends, but MAY use any application error
+   code.  The endpoint that sends a STOP_SENDING frame MAY ignore the
+   error code carried in any RESET_STREAM frame it receives.
+
+   If the STOP_SENDING frame is received on a stream that is already in
+   the "Data Sent" state, an endpoint that wishes to cease
+   retransmission of previously-sent STREAM frames on that stream MUST
+   first send a RESET_STREAM frame.
+
+   STOP_SENDING SHOULD only be sent for a stream that has not been reset
+   by the peer.  STOP_SENDING is most useful for streams in the "Recv"
+   or "Size Known" states.
+
+   An endpoint is expected to send another STOP_SENDING frame if a
+   packet containing a previous STOP_SENDING is lost.  However, once
+   either all stream data or a RESET_STREAM frame has been received for
+   the stream - that is, the stream is in any state other than "Recv" or
+   "Size Known" - sending a STOP_SENDING frame is unnecessary.
+
+   An endpoint that wishes to terminate both directions of a
+   bidirectional stream can terminate one direction by sending a
+   RESET_STREAM, and it can encourage prompt termination in the opposite
+   direction by sending a STOP_SENDING frame.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 22]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+4.  Flow Control
+
+   It is necessary to limit the amount of data that a receiver could
+   buffer, to prevent a fast sender from overwhelming a slow receiver,
+   or to prevent a malicious sender from consuming a large amount of
+   memory at a receiver.  To enable a receiver to limit memory
+   commitment to a connection and to apply back pressure on the sender,
+   streams are flow controlled both individually and as an aggregate.  A
+   QUIC receiver controls the maximum amount of data the sender can send
+   on a stream at any time, as described in Section 4.1 and Section 4.2
+
+   Similarly, to limit concurrency within a connection, a QUIC endpoint
+   controls the maximum cumulative number of streams that its peer can
+   initiate, as described in Section 4.5.
+
+   Data sent in CRYPTO frames is not flow controlled in the same way as
+   stream data.  QUIC relies on the cryptographic protocol
+   implementation to avoid excessive buffering of data; see [QUIC-TLS].
+   The implementation SHOULD provide an interface to QUIC to tell it
+   about its buffering limits so that there is not excessive buffering
+   at multiple layers.
+
+4.1.  Data Flow Control
+
+   QUIC employs a credit-based flow-control scheme similar to that in
+   HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is
+   prepared to receive on a given stream and for the entire connection.
+   This leads to two levels of data flow control in QUIC:
+
+   *  Stream flow control, which prevents a single stream from consuming
+      the entire receive buffer for a connection by limiting the amount
+      of data that can be sent on any stream.
+
+   *  Connection flow control, which prevents senders from exceeding a
+      receiver's buffer capacity for the connection, by limiting the
+      total bytes of stream data sent in STREAM frames on all streams.
+
+   A receiver sets initial credits for all streams by sending transport
+   parameters during the handshake (Section 7.4).  A receiver sends
+   MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to
+   the sender to advertise additional credit.
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 23]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   A receiver advertises credit for a stream by sending a
+   MAX_STREAM_DATA frame with the Stream ID field set appropriately.  A
+   MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a
+   stream.  A receiver could use the current offset of data consumed to
+   determine the flow control offset to be advertised.  A receiver MAY
+   send MAX_STREAM_DATA frames in multiple packets in order to make sure
+   that the sender receives an update before running out of flow control
+   credit, even if one of the packets is lost.
+
+   A receiver advertises credit for a connection by sending a MAX_DATA
+   frame, which indicates the maximum of the sum of the absolute byte
+   offsets of all streams.  A receiver maintains a cumulative sum of
+   bytes received on all streams, which is used to check for flow
+   control violations.  A receiver might use a sum of bytes consumed on
+   all streams to determine the maximum data limit to be advertised.
+
+   A receiver can advertise a larger offset by sending MAX_STREAM_DATA
+   or MAX_DATA frames.  Once a receiver advertises an offset, it MAY
+   advertise a smaller offset, but this has no effect.
+
+   A receiver MUST close the connection with a FLOW_CONTROL_ERROR error
+   (Section 11) if the sender violates the advertised connection or
+   stream data limits.
+
+   A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do
+   not increase flow control limits.
+
+   If a sender runs out of flow control credit, it will be unable to
+   send new data and is considered blocked.  A sender SHOULD send a
+   STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to
+   write but is blocked by flow control limits.  If a sender is blocked
+   for a period longer than the idle timeout (Section 10.2), the
+   connection might be closed even when data is available for
+   transmission.  To keep the connection from closing, a sender that is
+   flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED
+   or DATA_BLOCKED frame when it has no ack-eliciting packets in flight.
+
+4.2.  Flow Credit Increments
+
+   Implementations decide when and how much credit to advertise in
+   MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few
+   considerations.
+
+   To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or
+   MAX_DATA frame multiple times within a round trip or send it early
+   enough to allow for recovery from loss of the frame.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 24]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Control frames contribute to connection overhead.  Therefore,
+   frequently sending MAX_STREAM_DATA and MAX_DATA frames with small
+   changes is undesirable.  On the other hand, if updates are less
+   frequent, larger increments to limits are necessary to avoid blocking
+   a sender, requiring larger resource commitments at the receiver.
+   There is a trade-off between resource commitment and overhead when
+   determining how large a limit is advertised.
+
+   A receiver can use an autotuning mechanism to tune the frequency and
+   amount of advertised additional credit based on a round-trip time
+   estimate and the rate at which the receiving application consumes
+   data, similar to common TCP implementations.  As an optimization, an
+   endpoint could send frames related to flow control only when there
+   are other frames to send or when a peer is blocked, ensuring that
+   flow control does not cause extra packets to be sent.
+
+   A blocked sender is not required to send STREAM_DATA_BLOCKED or
+   DATA_BLOCKED frames.  Therefore, a receiver MUST NOT wait for a
+   STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a
+   MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the
+   sender being blocked for the rest of the connection.  Even if the
+   sender sends these frames, waiting for them will result in the sender
+   being blocked for at least an entire round trip.
+
+   When a sender receives credit after being blocked, it might be able
+   to send a large amount of data in response, resulting in short-term
+   congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of
+   how a sender can avoid this congestion.
+
+4.3.  Handling Stream Cancellation
+
+   Endpoints need to eventually agree on the amount of flow control
+   credit that has been consumed, to avoid either exceeding flow control
+   limits or deadlocking.
+
+   On receipt of a RESET_STREAM frame, an endpoint will tear down state
+   for the matching stream and ignore further data arriving on that
+   stream.  Without the offset included in RESET_STREAM, the two
+   endpoints could disagree on the number of bytes that count towards
+   connection flow control.
+
+   To remedy this issue, a RESET_STREAM frame (Section 19.4) includes
+   the final size of data sent on the stream.  On receiving a
+   RESET_STREAM frame, a receiver definitively knows how many bytes were
+   sent on that stream before the RESET_STREAM frame, and the receiver
+   MUST use the final size of the stream to account for all bytes sent
+   on the stream in its connection level flow controller.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 25]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   RESET_STREAM terminates one direction of a stream abruptly.  For a
+   bidirectional stream, RESET_STREAM has no effect on data flow in the
+   opposite direction.  Both endpoints MUST maintain flow control state
+   for the stream in the unterminated direction until that direction
+   enters a terminal state, or until one of the endpoints sends
+   CONNECTION_CLOSE.
+
+4.4.  Stream Final Size
+
+   The final size is the amount of flow control credit that is consumed
+   by a stream.  Assuming that every contiguous byte on the stream was
+   sent once, the final size is the number of bytes sent.  More
+   generally, this is one higher than the offset of the byte with the
+   largest offset sent on the stream, or zero if no bytes were sent.
+
+   For a stream that is reset, the final size is carried explicitly in a
+   RESET_STREAM frame.  Otherwise, the final size is the offset plus the
+   length of a STREAM frame marked with a FIN flag, or 0 in the case of
+   incoming unidirectional streams.
+
+   An endpoint will know the final size for a stream when the receiving
+   part of the stream enters the "Size Known" or "Reset Recvd" state
+   (Section 3).
+
+   An endpoint MUST NOT send data on a stream at or beyond the final
+   size.
+
+   Once a final size for a stream is known, it cannot change.  If a
+   RESET_STREAM or STREAM frame is received indicating a change in the
+   final size for the stream, an endpoint SHOULD respond with a
+   FINAL_SIZE_ERROR error; see Section 11.  A receiver SHOULD treat
+   receipt of data at or beyond the final size as a FINAL_SIZE_ERROR
+   error, even after a stream is closed.  Generating these errors is not
+   mandatory, but only because requiring that an endpoint generate these
+   errors also means that the endpoint needs to maintain the final size
+   state for closed streams, which could mean a significant state
+   commitment.
+
+4.5.  Controlling Concurrency
+
+   An endpoint limits the cumulative number of incoming streams a peer
+   can open.  Only streams with a stream ID less than (max_stream * 4 +
+   initial_stream_id_for_type) can be opened; see Table 5.  Initial
+   limits are set in the transport parameters (see Section 18.2) and
+   subsequently limits are advertised using MAX_STREAMS frames
+   (Section 19.11).  Separate limits apply to unidirectional and
+   bidirectional streams.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 26]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   If a max_streams transport parameter or MAX_STREAMS frame is received
+   with a value greater than 2^60, this would allow a maximum stream ID
+   that cannot be expressed as a variable-length integer; see
+   Section 16.  If either is received, the connection MUST be closed
+   immediately with a connection error of type STREAM_LIMIT_ERROR; see
+   Section 10.3.
+
+   Endpoints MUST NOT exceed the limit set by their peer.  An endpoint
+   that receives a frame with a stream ID exceeding the limit it has
+   sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR
+   (Section 11).
+
+   Once a receiver advertises a stream limit using the MAX_STREAMS
+   frame, advertising a smaller limit has no effect.  A receiver MUST
+   ignore any MAX_STREAMS frame that does not increase the stream limit.
+
+   As with stream and connection flow control, this document leaves when
+   and how many streams to advertise to a peer via MAX_STREAMS to
+   implementations.  Implementations might choose to increase limits as
+   streams close to keep the number of streams available to peers
+   roughly consistent.
+
+   An endpoint that is unable to open a new stream due to the peer's
+   limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14).  This
+   signal is considered useful for debugging.  An endpoint MUST NOT wait
+   to receive this signal before advertising additional credit, since
+   doing so will mean that the peer will be blocked for at least an
+   entire round trip, and potentially for longer if the peer chooses to
+   not send STREAMS_BLOCKED frames.
+
+5.  Connections
+
+   QUIC's connection establishment combines version negotiation with the
+   cryptographic and transport handshakes to reduce connection
+   establishment latency, as described in Section 7.  Once established,
+   a connection may migrate to a different IP or port at either endpoint
+   as described in Section 9.  Finally, a connection may be terminated
+   by either endpoint, as described in Section 10.
+
+5.1.  Connection ID
+
+   Each connection possesses a set of connection identifiers, or
+   connection IDs, each of which can identify the connection.
+   Connection IDs are independently selected by endpoints; each endpoint
+   selects the connection IDs that its peer uses.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 27]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The primary function of a connection ID is to ensure that changes in
+   addressing at lower protocol layers (UDP, IP) don't cause packets for
+   a QUIC connection to be delivered to the wrong endpoint.  Each
+   endpoint selects connection IDs using an implementation-specific (and
+   perhaps deployment-specific) method which will allow packets with
+   that connection ID to be routed back to the endpoint and identified
+   by the endpoint upon receipt.
+
+   Connection IDs MUST NOT contain any information that can be used by
+   an external observer (that is, one that does not cooperate with the
+   issuer) to correlate them with other connection IDs for the same
+   connection.  As a trivial example, this means the same connection ID
+   MUST NOT be issued more than once on the same connection.
+
+   Packets with long headers include Source Connection ID and
+   Destination Connection ID fields.  These fields are used to set the
+   connection IDs for new connections; see Section 7.2 for details.
+
+   Packets with short headers (Section 17.3) only include the
+   Destination Connection ID and omit the explicit length.  The length
+   of the Destination Connection ID field is expected to be known to
+   endpoints.  Endpoints using a load balancer that routes based on
+   connection ID could agree with the load balancer on a fixed length
+   for connection IDs, or agree on an encoding scheme.  A fixed portion
+   could encode an explicit length, which allows the entire connection
+   ID to vary in length and still be used by the load balancer.
+
+   A Version Negotiation (Section 17.2.1) packet echoes the connection
+   IDs selected by the client, both to ensure correct routing toward the
+   client and to allow the client to validate that the packet is in
+   response to an Initial packet.
+
+   A zero-length connection ID can be used when a connection ID is not
+   needed to route to the correct endpoint.  However, multiplexing
+   connections on the same local IP address and port while using zero-
+   length connection IDs will cause failures in the presence of peer
+   connection migration, NAT rebinding, and client port reuse; and
+   therefore MUST NOT be done unless an endpoint is certain that those
+   protocol features are not in use.
+
+   When an endpoint uses a non-zero-length connection ID, it needs to
+   ensure that the peer has a supply of connection IDs from which to
+   choose for packets sent to the endpoint.  These connection IDs are
+   supplied by the endpoint using the NEW_CONNECTION_ID frame
+   (Section 19.15).
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 28]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+5.1.1.  Issuing Connection IDs
+
+   Each Connection ID has an associated sequence number to assist in
+   deduplicating messages.  The initial connection ID issued by an
+   endpoint is sent in the Source Connection ID field of the long packet
+   header (Section 17.2) during the handshake.  The sequence number of
+   the initial connection ID is 0.  If the preferred_address transport
+   parameter is sent, the sequence number of the supplied connection ID
+   is 1.
+
+   Additional connection IDs are communicated to the peer using
+   NEW_CONNECTION_ID frames (Section 19.15).  The sequence number on
+   each newly-issued connection ID MUST increase by 1.  The connection
+   ID randomly selected by the client in the Initial packet and any
+   connection ID provided by a Retry packet are not assigned sequence
+   numbers unless a server opts to retain them as its initial connection
+   ID.
+
+   When an endpoint issues a connection ID, it MUST accept packets that
+   carry this connection ID for the duration of the connection or until
+   its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
+   frame (Section 19.16).  Connection IDs that are issued and not
+   retired are considered active; any active connection ID is valid for
+   use with the current connection at any time, in any packet type.
+   This includes the connection ID issued by the server via the
+   preferred_address transport parameter.
+
+   An endpoint SHOULD ensure that its peer has a sufficient number of
+   available and unused connection IDs.  Endpoints advertise the number
+   of active connection IDs they are willing to maintain using the
+   active_connection_id_limit transport parameter.  An endpoint MUST NOT
+   provide more connection IDs than the peer's limit.  An endpoint MAY
+   send connection IDs that temporarily exceed a peer's limit if the
+   NEW_CONNECTION_ID frame also requires the retirement of any excess,
+   by including a sufficiently large value in the Retire Prior To field.
+
+   A NEW_CONNECTION_ID frame might cause an endpoint to add some active
+   connection IDs and retire others based on the value of the Retire
+   Prior To field.  After processing a NEW_CONNECTION_ID frame and
+   adding and retiring active connection IDs, if the number of active
+   connection IDs exceeds the value advertised in its
+   active_connection_id_limit transport parameter, an endpoint MUST
+   close the connection with an error of type CONNECTION_ID_LIMIT_ERROR.
+
+   An endpoint SHOULD supply a new connection ID when the peer retires a
+   connection ID.  If an endpoint provided fewer connection IDs than the
+   peer's active_connection_id_limit, it MAY supply a new connection ID
+   when it receives a packet with a previously unused connection ID.  An
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 29]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   endpoint MAY limit the frequency or the total number of connection
+   IDs issued for each connection to avoid the risk of running out of
+   connection IDs; see Section 10.4.2.  An endpoint MAY also limit the
+   issuance of connection IDs to reduce the amount of per-path state it
+   maintains, such as path validation status, as its peer might interact
+   with it over as many paths as there are issued connection IDs.
+
+   An endpoint that initiates migration and requires non-zero-length
+   connection IDs SHOULD ensure that the pool of connection IDs
+   available to its peer allows the peer to use a new connection ID on
+   migration, as the peer will close the connection if the pool is
+   exhausted.
+
+5.1.2.  Consuming and Retiring Connection IDs
+
+   An endpoint can change the connection ID it uses for a peer to
+   another available one at any time during the connection.  An endpoint
+   consumes connection IDs in response to a migrating peer; see
+   Section 9.5 for more.
+
+   An endpoint maintains a set of connection IDs received from its peer,
+   any of which it can use when sending packets.  When the endpoint
+   wishes to remove a connection ID from use, it sends a
+   RETIRE_CONNECTION_ID frame to its peer.  Sending a
+   RETIRE_CONNECTION_ID frame indicates that the connection ID will not
+   be used again and requests that the peer replace it with a new
+   connection ID using a NEW_CONNECTION_ID frame.
+
+   As discussed in Section 9.5, endpoints limit the use of a connection
+   ID to packets sent from a single local address to a single
+   destination address.  Endpoints SHOULD retire connection IDs when
+   they are no longer actively using either the local or destination
+   address for which the connection ID was used.
+
+   An endpoint might need to stop accepting previously issued connection
+   IDs in certain circumstances.  Such an endpoint can cause its peer to
+   retire connection IDs by sending a NEW_CONNECTION_ID frame with an
+   increased Retire Prior To field.  The endpoint SHOULD continue to
+   accept the previously issued connection IDs until they are retired by
+   the peer.  If the endpoint can no longer process the indicated
+   connection IDs, it MAY close the connection.
+
+   Upon receipt of an increased Retire Prior To field, the peer MUST
+   stop using the corresponding connection IDs and retire them with
+   RETIRE_CONNECTION_ID frames before adding the newly provided
+   connection ID to the set of active connection IDs.  This ordering
+   allows an endpoint to replace all active connection IDs without the
+   possibility of a peer having no available connection IDs and without
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 30]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   exceeding the limit the peer sets in the active_connection_id_limit
+   transport parameter; see Section 18.2.  Failure to cease using the
+   connection IDs when requested can result in connection failures, as
+   the issuing endpoint might be unable to continue using the connection
+   IDs with the active connection.
+
+   An endpoint SHOULD limit the number of connection IDs it has retired
+   locally and have not yet been acknowledged.  An endpoint SHOULD allow
+   for sending and tracking a number of RETIRE_CONNECTION_ID frames of
+   at least twice the active_connection_id limit.  An endpoint MUST NOT
+   forget a connection ID without retiring it, though it MAY choose to
+   treat having connection IDs in need of retirement that exceed this
+   limit as a connection error of type CONNECTION_ID_LIMIT_ERROR.
+
+   Endpoints SHOULD NOT issue updates of the Retire Prior To field
+   before receiving RETIRE_CONNECTION_ID frames that retire all
+   connection IDs indicated by the previous Retire Prior To value.
+
+5.2.  Matching Packets to Connections
+
+   Incoming packets are classified on receipt.  Packets can either be
+   associated with an existing connection, or - for servers -
+   potentially create a new connection.
+
+   Endpoints try to associate a packet with an existing connection.  If
+   the packet has a non-zero-length Destination Connection ID
+   corresponding to an existing connection, QUIC processes that packet
+   accordingly.  Note that more than one connection ID can be associated
+   with a connection; see Section 5.1.
+
+   If the Destination Connection ID is zero length and the addressing
+   information in the packet matches the addressing information the
+   endpoint uses to identify a connection with a zero-length connection
+   ID, QUIC processes the packet as part of that connection.  An
+   endpoint can use just destination IP and port or both source and
+   destination addresses for identification, though this makes
+   connections fragile as described in Section 5.1.
+
+   Endpoints can send a Stateless Reset (Section 10.4) for any packets
+   that cannot be attributed to an existing connection.  A stateless
+   reset allows a peer to more quickly identify when a connection
+   becomes unusable.
+
+   Packets that are matched to an existing connection are discarded if
+   the packets are inconsistent with the state of that connection.  For
+   example, packets are discarded if they indicate a different protocol
+   version than that of the connection, or if the removal of packet
+   protection is unsuccessful once the expected keys are available.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 31]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Invalid packets without packet protection, such as Initial, Retry, or
+   Version Negotiation, MAY be discarded.  An endpoint MUST generate a
+   connection error if it commits changes to state before discovering an
+   error.
+
+5.2.1.  Client Packet Handling
+
+   Valid packets sent to clients always include a Destination Connection
+   ID that matches a value the client selects.  Clients that choose to
+   receive zero-length connection IDs can use the local address and port
+   to identify a connection.  Packets that don't match an existing
+   connection are discarded.
+
+   Due to packet reordering or loss, a client might receive packets for
+   a connection that are encrypted with a key it has not yet computed.
+   The client MAY drop these packets, or MAY buffer them in anticipation
+   of later packets that allow it to compute the key.
+
+   If a client receives a packet that has an unsupported version, it
+   MUST discard that packet.
+
+5.2.2.  Server Packet Handling
+
+   If a server receives a packet that has an unsupported version, but
+   the packet is sufficiently large to initiate a new connection for any
+   version supported by the server, it SHOULD send a Version Negotiation
+   packet as described in Section 6.1.  Servers MAY rate control these
+   packets to avoid storms of Version Negotiation packets.  Otherwise,
+   servers MUST drop packets that specify unsupported versions.
+
+   The first packet for an unsupported version can use different
+   semantics and encodings for any version-specific field.  In
+   particular, different packet protection keys might be used for
+   different versions.  Servers that do not support a particular version
+   are unlikely to be able to decrypt the payload of the packet.
+   Servers SHOULD NOT attempt to decode or decrypt a packet from an
+   unknown version, but instead send a Version Negotiation packet,
+   provided that the packet is sufficiently long.
+
+   Packets with a supported version, or no version field, are matched to
+   a connection using the connection ID or - for packets with zero-
+   length connection IDs - the local address and port.  If the packet
+   doesn't match an existing connection, the server continues below.
+
+   If the packet is an Initial packet fully conforming with the
+   specification, the server proceeds with the handshake (Section 7).
+   This commits the server to the version that the client selected.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 32]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   If a server refuses to accept a new connection, it SHOULD send an
+   Initial packet containing a CONNECTION_CLOSE frame with error code
+   CONNECTION_REFUSED.
+
+   If the packet is a 0-RTT packet, the server MAY buffer a limited
+   number of these packets in anticipation of a late-arriving Initial
+   packet.  Clients are not able to send Handshake packets prior to
+   receiving a server response, so servers SHOULD ignore any such
+   packets.
+
+   Servers MUST drop incoming packets under all other circumstances.
+
+5.2.3.  Considerations for Simple Load Balancers
+
+   A server deployment could load balance among servers using only
+   source and destination IP addresses and ports.  Changes to the
+   client's IP address or port could result in packets being forwarded
+   to the wrong server.  Such a server deployment could use one of the
+   following methods for connection continuity when a client's address
+   changes.
+
+   *  Servers could use an out-of-band mechanism to forward packets to
+      the correct server based on Connection ID.
+
+   *  If servers can use a dedicated server IP address or port, other
+      than the one that the client initially connects to, they could use
+      the preferred_address transport parameter to request that clients
+      move connections to that dedicated address.  Note that clients
+      could choose not to use the preferred address.
+
+   A server in a deployment that does not implement a solution to
+   maintain connection continuity during connection migration SHOULD
+   disallow migration using the disable_active_migration transport
+   parameter.
+
+   Server deployments that use this simple form of load balancing MUST
+   avoid the creation of a stateless reset oracle; see Section 21.9.
+
+5.3.  Life of a QUIC Connection
+
+   A QUIC connection is a stateful interaction between a client and
+   server, the primary purpose of which is to support the exchange of
+   data by an application protocol.  Streams (Section 2) are the primary
+   means by which an application protocol exchanges information.
+
+   Each connection starts with a handshake phase, during which client
+   and server establish a shared secret using the cryptographic
+   handshake protocol [QUIC-TLS] and negotiate the application protocol.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 33]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The handshake (Section 7) confirms that both endpoints are willing to
+   communicate (Section 8.1) and establishes parameters for the
+   connection (Section 7.4).
+
+   An application protocol can also operate in a limited fashion during
+   the handshake phase.  0-RTT allows application messages to be sent by
+   a client before receiving any messages from the server.  However,
+   0-RTT lacks certain key security guarantees.  In particular, there is
+   no protection against replay attacks in 0-RTT; see [QUIC-TLS].
+   Separately, a server can also send application data to a client
+   before it receives the final cryptographic handshake messages that
+   allow it to confirm the identity and liveness of the client.  These
+   capabilities allow an application protocol to offer the option to
+   trade some security guarantees for reduced latency.
+
+   The use of connection IDs (Section 5.1) allows connections to migrate
+   to a new network path, both as a direct choice of an endpoint and
+   when forced by a change in a middlebox.  Section 9 describes
+   mitigations for the security and privacy issues associated with
+   migration.
+
+   For connections that are no longer needed or desired, there are
+   several ways for a client and server to terminate a connection
+   (Section 10).
+
+5.4.  Required Operations on Connections
+
+   There are certain operations which an application MUST be able to
+   perform when interacting with the QUIC transport.  This document does
+   not specify an API, but any implementation of this version of QUIC
+   MUST expose the ability to perform the operations described in this
+   section on a QUIC connection.
+
+   When implementing the client role, applications need to be able to:
+
+   *  open a connection, which begins the exchange described in
+      Section 7;
+
+   *  enable 0-RTT when available; and
+
+   *  be informed when 0-RTT has been accepted or rejected by a server.
+
+   When implementing the server role, applications need to be able to:
+
+   *  listen for incoming connections, which prepares for the exchange
+      described in Section 7;
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 34]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  if Early Data is supported, embed application-controlled data in
+      the TLS resumption ticket sent to the client; and
+
+   *  if Early Data is supported, retrieve application-controlled data
+      from the client's resumption ticket and enable rejecting Early
+      Data based on that information.
+
+   In either role, applications need to be able to:
+
+   *  configure minimum values for the initial number of permitted
+      streams of each type, as communicated in the transport parameters
+      (Section 7.4);
+
+   *  control resource allocation of various types, including flow
+      control and the number of permitted streams of each type;
+
+   *  identify whether the handshake has completed successfully or is
+      still ongoing;
+
+   *  keep a connection from silently closing, either by generating PING
+      frames (Section 19.2) or by requesting that the transport send
+      additional frames before the idle timeout expires (Section 10.2);
+      and
+
+   *  immediately close (Section 10.3) the connection.
+
+6.  Version Negotiation
+
+   Version negotiation ensures that client and server agree to a QUIC
+   version that is mutually supported.  A server sends a Version
+   Negotiation packet in response to each packet that might initiate a
+   new connection; see Section 5.2 for details.
+
+   The size of the first packet sent by a client will determine whether
+   a server sends a Version Negotiation packet.  Clients that support
+   multiple QUIC versions SHOULD pad the first packet they send to the
+   largest of the minimum packet sizes across all versions they support.
+   This ensures that the server responds if there is a mutually
+   supported version.
+
+6.1.  Sending Version Negotiation Packets
+
+   If the version selected by the client is not acceptable to the
+   server, the server responds with a Version Negotiation packet; see
+   Section 17.2.1.  This includes a list of versions that the server
+   will accept.  An endpoint MUST NOT send a Version Negotiation packet
+   in response to receiving a Version Negotiation packet.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 35]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   This system allows a server to process packets with unsupported
+   versions without retaining state.  Though either the Initial packet
+   or the Version Negotiation packet that is sent in response could be
+   lost, the client will send new packets until it successfully receives
+   a response or it abandons the connection attempt.  As a result, the
+   client discards all state for the connection and does not send any
+   more packets on the connection.
+
+   A server MAY limit the number of Version Negotiation packets it
+   sends.  For instance, a server that is able to recognize packets as
+   0-RTT might choose not to send Version Negotiation packets in
+   response to 0-RTT packets with the expectation that it will
+   eventually receive an Initial packet.
+
+6.2.  Handling Version Negotiation Packets
+
+   Version Negotiation packets are designed to allow future versions of
+   QUIC to negotiate the version in use between endpoints.  Future
+   versions of QUIC might change how implementations that support
+   multiple versions of QUIC react to Version Negotiation packets when
+   attempting to establish a connection using this version.
+
+   A client that supports only this version of QUIC MUST abandon the
+   current connection attempt if it receives a Version Negotiation
+   packet, with the following two exceptions.  A client MUST discard any
+   Version Negotiation packet if it has received and successfully
+   processed any other packet, including an earlier Version Negotiation
+   packet.  A client MUST discard a Version Negotiation packet that
+   lists the QUIC version selected by the client.
+
+   How to perform version negotiation is left as future work defined by
+   future versions of QUIC.  In particular, that future work will ensure
+   robustness against version downgrade attacks; see Section 21.10.
+
+6.2.1.  Version Negotiation Between Draft Versions
+
+   [[RFC editor: please remove this section before publication.]]
+
+   When a draft implementation receives a Version Negotiation packet, it
+   MAY use it to attempt a new connection with one of the versions
+   listed in the packet, instead of abandoning the current connection
+   attempt; see Section 6.2.
+
+   The client MUST check that the Destination and Source Connection ID
+   fields match the Source and Destination Connection ID fields in a
+   packet that the client sent.  If this check fails, the packet MUST be
+   discarded.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 36]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Once the Version Negotiation packet is determined to be valid, the
+   client then selects an acceptable protocol version from the list
+   provided by the server.  The client then attempts to create a new
+   connection using that version.  The new connection MUST use a new
+   random Destination Connection ID different from the one it had
+   previously sent.
+
+   Note that this mechanism does not protect against downgrade attacks
+   and MUST NOT be used outside of draft implementations.
+
+6.3.  Using Reserved Versions
+
+   For a server to use a new version in the future, clients need to
+   correctly handle unsupported versions.  Some version numbers
+   (0x?a?a?a?a as defined in Section 15) are reserved for inclusion in
+   fields that contain version numbers.
+
+   Endpoints MAY add reserved versions to any field where unknown or
+   unsupported versions are ignored to test that a peer correctly
+   ignores the value.  For instance, an endpoint could include a
+   reserved version in a Version Negotiation packet; see Section 17.2.1.
+   Endpoints MAY send packets with a reserved version to test that a
+   peer correctly discards the packet.
+
+7.  Cryptographic and Transport Handshake
+
+   QUIC relies on a combined cryptographic and transport handshake to
+   minimize connection establishment latency.  QUIC uses the CRYPTO
+   frame Section 19.6 to transmit the cryptographic handshake.  Version
+   0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different
+   QUIC version number could indicate that a different cryptographic
+   handshake protocol is in use.
+
+   QUIC provides reliable, ordered delivery of the cryptographic
+   handshake data.  QUIC packet protection is used to encrypt as much of
+   the handshake protocol as possible.  The cryptographic handshake MUST
+   provide the following properties:
+
+   *  authenticated key exchange, where
+
+      -  a server is always authenticated,
+
+      -  a client is optionally authenticated,
+
+      -  every connection produces distinct and unrelated keys,
+
+      -  keying material is usable for packet protection for both 0-RTT
+         and 1-RTT packets, and
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 37]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      -  1-RTT keys have forward secrecy
+
+   *  authenticated values for transport parameters of both endpoints,
+      and confidentiality protection for server transport parameters
+      (see Section 7.4)
+
+   *  authenticated negotiation of an application protocol (TLS uses
+      ALPN [RFC7301] for this purpose)
+
+   An endpoint can verify support for Explicit Congestion Notification
+   (ECN) in the first packets it sends, as described in Section 13.4.2.
+
+   The CRYPTO frame can be sent in different packet number spaces
+   (Section 12.3).  The sequence numbers used by CRYPTO frames to ensure
+   ordered delivery of cryptographic handshake data start from zero in
+   each packet number space.
+
+   Endpoints MUST explicitly negotiate an application protocol.  This
+   avoids situations where there is a disagreement about the protocol
+   that is in use.
+
+7.1.  Example Handshake Flows
+
+   Details of how TLS is integrated with QUIC are provided in
+   [QUIC-TLS], but some examples are provided here.  An extension of
+   this exchange to support client address validation is shown in
+   Section 8.1.2.
+
+   Once any address validation exchanges are complete, the cryptographic
+   handshake is used to agree on cryptographic keys.  The cryptographic
+   handshake is carried in Initial (Section 17.2.2) and Handshake
+   (Section 17.2.4) packets.
+
+   Figure 4 provides an overview of the 1-RTT handshake.  Each line
+   shows a QUIC packet with the packet type and packet number shown
+   first, followed by the frames that are typically contained in those
+   packets.  So, for instance the first packet is of type Initial, with
+   packet number 0, and contains a CRYPTO frame carrying the
+   ClientHello.
+
+   Note that multiple QUIC packets - even of different packet types -
+   can be coalesced into a single UDP datagram; see Section 12.2).  As a
+   result, this handshake may consist of as few as 4 UDP datagrams, or
+   any number more.  For instance, the server's first flight contains
+   Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT
+   packets with a short header.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 38]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Client                                                  Server
+
+   Initial[0]: CRYPTO[CH] ->
+
+                                    Initial[0]: CRYPTO[SH] ACK[0]
+                          Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
+                                    <- 1-RTT[0]: STREAM[1, "..."]
+
+   Initial[1]: ACK[0]
+   Handshake[0]: CRYPTO[FIN], ACK[0]
+   1-RTT[0]: STREAM[0, "..."], ACK[0] ->
+
+                                             Handshake[1]: ACK[0]
+                            <- 1-RTT[1]: STREAM[3, "..."], ACK[0]
+
+                     Figure 4: Example 1-RTT Handshake
+
+   Figure 5 shows an example of a connection with a 0-RTT handshake and
+   a single packet of 0-RTT data.  Note that as described in
+   Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets,
+   and the client sends 1-RTT packets in the same packet number space.
+
+   Client                                                  Server
+
+   Initial[0]: CRYPTO[CH]
+   0-RTT[0]: STREAM[0, "..."] ->
+
+                                    Initial[0]: CRYPTO[SH] ACK[0]
+                                     Handshake[0] CRYPTO[EE, FIN]
+                             <- 1-RTT[0]: STREAM[1, "..."] ACK[0]
+
+   Initial[1]: ACK[0]
+   Handshake[0]: CRYPTO[FIN], ACK[0]
+   1-RTT[1]: STREAM[0, "..."] ACK[0] ->
+
+                                             Handshake[1]: ACK[0]
+                            <- 1-RTT[1]: STREAM[3, "..."], ACK[1]
+
+                     Figure 5: Example 0-RTT Handshake
+
+7.2.  Negotiating Connection IDs
+
+   A connection ID is used to ensure consistent routing of packets, as
+   described in Section 5.1.  The long header contains two connection
+   IDs: the Destination Connection ID is chosen by the recipient of the
+   packet and is used to provide consistent routing; the Source
+   Connection ID is used to set the Destination Connection ID used by
+   the peer.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 39]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   During the handshake, packets with the long header (Section 17.2) are
+   used to establish the connection IDs in each direction.  Each
+   endpoint uses the Source Connection ID field to specify the
+   connection ID that is used in the Destination Connection ID field of
+   packets being sent to them.  Upon receiving a packet, each endpoint
+   sets the Destination Connection ID it sends to match the value of the
+   Source Connection ID that it receives.
+
+   When an Initial packet is sent by a client that has not previously
+   received an Initial or Retry packet from the server, the client
+   populates the Destination Connection ID field with an unpredictable
+   value.  This Destination Connection ID MUST be at least 8 bytes in
+   length.  Until a packet is received from the server, the client MUST
+   use the same Destination Connection ID value on all packets in this
+   connection.  This Destination Connection ID is used to determine
+   packet protection keys for Initial packets.
+
+   The client populates the Source Connection ID field with a value of
+   its choosing and sets the SCID Length field to indicate the length.
+
+   The first flight of 0-RTT packets use the same Destination Connection
+   ID and Source Connection ID values as the client's first Initial
+   packet.
+
+   Upon first receiving an Initial or Retry packet from the server, the
+   client uses the Source Connection ID supplied by the server as the
+   Destination Connection ID for subsequent packets, including any 0-RTT
+   packets.  This means that a client might have to change the
+   connection ID it sets in the Destination Connection ID field twice
+   during connection establishment: once in response to a Retry, and
+   once in response to an Initial packet from the server.  Once a client
+   has received a valid Initial packet from the server, it MUST discard
+   any subsequent packet it receives with a different Source Connection
+   ID.
+
+   A client MUST change the Destination Connection ID it uses for
+   sending packets in response to only the first received Initial or
+   Retry packet.  A server MUST set the Destination Connection ID it
+   uses for sending packets based on the first received Initial packet.
+   Any further changes to the Destination Connection ID are only
+   permitted if the values are taken from any received NEW_CONNECTION_ID
+   frames; if subsequent Initial packets include a different Source
+   Connection ID, they MUST be discarded.  This avoids unpredictable
+   outcomes that might otherwise result from stateless processing of
+   multiple Initial packets with different Source Connection IDs.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 40]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The Destination Connection ID that an endpoint sends can change over
+   the lifetime of a connection, especially in response to connection
+   migration (Section 9); see Section 5.1.1 for details.
+
+7.3.  Authenticating Connection IDs
+
+   The choice each endpoint makes about connection IDs during the
+   handshake is authenticated by including all values in transport
+   parameters; see Section 7.4.  This ensures that all connection IDs
+   used for the handshake are also authenticated by the cryptographic
+   handshake.
+
+   Each endpoint includes the value of the Source Connection ID field
+   from the first Initial packet it sent in the
+   initial_source_connection_id transport parameter; see Section 18.2.
+   A server includes the Destination Connection ID field from the first
+   Initial packet it received from the client in the
+   original_destination_connection_id transport parameter; if the server
+   sent a Retry packet this refers to the first Initial packet received
+   before sending the Retry packet.  If it sends a Retry packet, a
+   server also includes the Source Connection ID field from the Retry
+   packet in the retry_source_connection_id transport parameter.
+
+   The values provided by a peer for these transport parameters MUST
+   match the values that an endpoint used in the Destination and Source
+   Connection ID fields of Initial packets that it sent.  Including
+   connection ID values in transport parameters and verifying them
+   ensures that that an attacker cannot influence the choice of
+   connection ID for a successful connection by injecting packets
+   carrying attacker-chosen connection IDs during the handshake.  An
+   endpoint MUST treat any of the following as a connection error of
+   type PROTOCOL_VIOLATION:
+
+   *  absence of the initial_source_connection_id transport parameter
+      from either endpoint,
+
+   *  absence of the original_destination_connection_id transport
+      parameter from the server,
+
+   *  absence of the retry_source_connection_id transport parameter from
+      the server after receiving a Retry packet,
+
+   *  presence of the retry_source_connection_id transport parameter
+      when no Retry packet was received, or
+
+   *  a mismatch between values received from a peer in these transport
+      parameters and the value sent in the corresponding Destination or
+      Source Connection ID fields of Initial packets.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 41]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   If a zero-length connection ID is selected, the corresponding
+   transport parameter is included with a zero-length value.
+
+   Figure 6 shows the connection IDs that are used in a complete
+   handshake.  The exchange of Initial packets is shown, plus the later
+   exchange of 1-RTT packets that includes the connection ID established
+   during the handshake.
+
+   Client                                                  Server
+
+   Initial: DCID=S1, SCID=C1 ->
+                                     <- Initial: DCID=C1, SCID=S3
+                                ...
+   1-RTT: DCID=S3 ->
+                                                <- 1-RTT: DCID=C1
+
+               Figure 6: Use of Connection IDs in a Handshake
+
+   Figure 7 shows a similar handshake that includes a Retry packet.
+
+   Client                                                  Server
+
+   Initial: DCID=S1, SCID=C1 ->
+                                       <- Retry: DCID=C1, SCID=S2
+   Initial: DCID=S2, SCID=C1 ->
+                                     <- Initial: DCID=C1, SCID=S3
+                                ...
+   1-RTT: DCID=S3 ->
+                                                <- 1-RTT: DCID=C1
+
+         Figure 7: Use of Connection IDs in a Handshake with Retry
+
+   For the handshakes in Figure 6 and Figure 7 the client sets the value
+   of the initial_source_connection_id transport parameter to "C1".  In
+   Figure 7, the server sets original_destination_connection_id to "S1",
+   retry_source_connection_id to "S2", and initial_source_connection_id
+   to "S3".  In Figure 6, the server sets
+   original_destination_connection_id to "S1",
+   initial_source_connection_id to "S3", and does not include
+   retry_source_connection_id.  Each endpoint validates the transport
+   parameters set by their peer, including the client confirming that
+   retry_source_connection_id is absent if no Retry packet was
+   processed.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 42]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+7.4.  Transport Parameters
+
+   During connection establishment, both endpoints make authenticated
+   declarations of their transport parameters.  Endpoints are required
+   to comply with the restrictions implied by these parameters; the
+   description of each parameter includes rules for its handling.
+
+   Transport parameters are declarations that are made unilaterally by
+   each endpoint.  Each endpoint can choose values for transport
+   parameters independent of the values chosen by its peer.
+
+   The encoding of the transport parameters is detailed in Section 18.
+
+   QUIC includes the encoded transport parameters in the cryptographic
+   handshake.  Once the handshake completes, the transport parameters
+   declared by the peer are available.  Each endpoint validates the
+   value provided by its peer.
+
+   Definitions for each of the defined transport parameters are included
+   in Section 18.2.
+
+   An endpoint MUST treat receipt of a transport parameter with an
+   invalid value as a connection error of type
+   TRANSPORT_PARAMETER_ERROR.
+
+   An endpoint MUST NOT send a parameter more than once in a given
+   transport parameters extension.  An endpoint SHOULD treat receipt of
+   duplicate transport parameters as a connection error of type
+   TRANSPORT_PARAMETER_ERROR.
+
+   Endpoints use transport parameters to authenticate the negotiation of
+   connection IDs during the handshake; see Section 7.3.
+
+7.4.1.  Values of Transport Parameters for 0-RTT
+
+   Both endpoints store the value of the server transport parameters
+   from a connection and apply them to any 0-RTT packets that are sent
+   in subsequent connections to that peer, except for transport
+   parameters that are explicitly excluded.  Remembered transport
+   parameters apply to the new connection until the handshake completes
+   and the client starts sending 1-RTT packets.  Once the handshake
+   completes, the client uses the transport parameters established in
+   the handshake.
+
+   The definition of new transport parameters (Section 7.4.2) MUST
+   specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT.  A
+   client need not store a transport parameter it cannot process.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 43]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   A client MUST NOT use remembered values for the following parameters:
+   ack_delay_exponent, max_ack_delay, initial_source_connection_id,
+   original_destination_connection_id, preferred_address,
+   retry_source_connection_id, and stateless_reset_token.  The client
+   MUST use the server's new values in the handshake instead, and absent
+   new values from the server, the default value.
+
+   A client that attempts to send 0-RTT data MUST remember all other
+   transport parameters used by the server.  The server can remember
+   these transport parameters, or store an integrity-protected copy of
+   the values in the ticket and recover the information when accepting
+   0-RTT data.  A server uses the transport parameters in determining
+   whether to accept 0-RTT data.
+
+   If 0-RTT data is accepted by the server, the server MUST NOT reduce
+   any limits or alter any values that might be violated by the client
+   with its 0-RTT data.  In particular, a server that accepts 0-RTT data
+   MUST NOT set values for the following parameters (Section 18.2) that
+   are smaller than the remembered value of the parameters.
+
+   *  active_connection_id_limit
+
+   *  initial_max_data
+
+   *  initial_max_stream_data_bidi_local
+
+   *  initial_max_stream_data_bidi_remote
+
+   *  initial_max_stream_data_uni
+
+   *  initial_max_streams_bidi
+
+   *  initial_max_streams_uni
+
+   Omitting or setting a zero value for certain transport parameters can
+   result in 0-RTT data being enabled, but not usable.  The applicable
+   subset of transport parameters that permit sending of application
+   data SHOULD be set to non-zero values for 0-RTT.  This includes
+   initial_max_data and either initial_max_streams_bidi and
+   initial_max_stream_data_bidi_remote, or initial_max_streams_uni and
+   initial_max_stream_data_uni.
+
+   A server MUST either reject 0-RTT data or abort a handshake if the
+   implied values for transport parameters cannot be supported.
+
+   When sending frames in 0-RTT packets, a client MUST only use
+   remembered transport parameters; importantly, it MUST NOT use updated
+   values that it learns from the server's updated transport parameters
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 44]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   or from frames received in 1-RTT packets.  Updated values of
+   transport parameters from the handshake apply only to 1-RTT packets.
+   For instance, flow control limits from remembered transport
+   parameters apply to all 0-RTT packets even if those values are
+   increased by the handshake or by frames sent in 1-RTT packets.  A
+   server MAY treat use of updated transport parameters in 0-RTT as a
+   connection error of type PROTOCOL_VIOLATION.
+
+7.4.2.  New Transport Parameters
+
+   New transport parameters can be used to negotiate new protocol
+   behavior.  An endpoint MUST ignore transport parameters that it does
+   not support.  Absence of a transport parameter therefore disables any
+   optional protocol feature that is negotiated using the parameter.  As
+   described in Section 18.1, some identifiers are reserved in order to
+   exercise this requirement.
+
+   New transport parameters can be registered according to the rules in
+   Section 22.2.
+
+7.5.  Cryptographic Message Buffering
+
+   Implementations need to maintain a buffer of CRYPTO data received out
+   of order.  Because there is no flow control of CRYPTO frames, an
+   endpoint could potentially force its peer to buffer an unbounded
+   amount of data.
+
+   Implementations MUST support buffering at least 4096 bytes of data
+   received in CRYPTO frames out of order.  Endpoints MAY choose to
+   allow more data to be buffered during the handshake.  A larger limit
+   during the handshake could allow for larger keys or credentials to be
+   exchanged.  An endpoint's buffer size does not need to remain
+   constant during the life of the connection.
+
+   Being unable to buffer CRYPTO frames during the handshake can lead to
+   a connection failure.  If an endpoint's buffer is exceeded during the
+   handshake, it can expand its buffer temporarily to complete the
+   handshake.  If an endpoint does not expand its buffer, it MUST close
+   the connection with a CRYPTO_BUFFER_EXCEEDED error code.
+
+   Once the handshake completes, if an endpoint is unable to buffer all
+   data in a CRYPTO frame, it MAY discard that CRYPTO frame and all
+   CRYPTO frames received in the future, or it MAY close the connection
+   with a CRYPTO_BUFFER_EXCEEDED error code.  Packets containing
+   discarded CRYPTO frames MUST be acknowledged because the packet has
+   been received and processed by the transport even though the CRYPTO
+   frame was discarded.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 45]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+8.  Address Validation
+
+   Address validation is used by QUIC to avoid being used for a traffic
+   amplification attack.  In such an attack, a packet is sent to a
+   server with spoofed source address information that identifies a
+   victim.  If a server generates more or larger packets in response to
+   that packet, the attacker can use the server to send more data toward
+   the victim than it would be able to send on its own.
+
+   The primary defense against amplification attack is verifying that an
+   endpoint is able to receive packets at the transport address that it
+   claims.  Address validation is performed both during connection
+   establishment (see Section 8.1) and during connection migration (see
+   Section 8.2).
+
+8.1.  Address Validation During Connection Establishment
+
+   Connection establishment implicitly provides address validation for
+   both endpoints.  In particular, receipt of a packet protected with
+   Handshake keys confirms that the client received the Initial packet
+   from the server.  Once the server has successfully processed a
+   Handshake packet from the client, it can consider the client address
+   to have been validated.
+
+   Prior to validating the client address, servers MUST NOT send more
+   than three times as many bytes as the number of bytes they have
+   received.  This limits the magnitude of any amplification attack that
+   can be mounted using spoofed source addresses.  For the purposes of
+   avoiding amplification prior to address validation, servers MUST
+   count all of the payload bytes received in datagrams that are
+   uniquely attributed to a single connection.  This includes datagrams
+   that contain packets that are successfully processed and datagrams
+   that contain packets that are all discarded.
+
+   Clients MUST ensure that UDP datagrams containing Initial packets
+   have UDP payloads of at least 1200 bytes, adding padding to packets
+   in the datagram as necessary.  Sending padded datagrams ensures that
+   the server is not overly constrained by the amplification
+   restriction.
+
+   Loss of an Initial or Handshake packet from the server can cause a
+   deadlock if the client does not send additional Initial or Handshake
+   packets.  A deadlock could occur when the server reaches its anti-
+   amplification limit and the client has received acknowledgements for
+   all the data it has sent.  In this case, when the client has no
+   reason to send additional packets, the server will be unable to send
+   more data because it has not validated the client's address.  To
+   prevent this deadlock, clients MUST send a packet on a probe timeout
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 46]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   (PTO, see Section 5.3 of [QUIC-RECOVERY]).  Specifically, the client
+   MUST send an Initial packet in a UDP datagram of at least 1200 bytes
+   if it does not have Handshake keys, and otherwise send a Handshake
+   packet.
+
+   A server might wish to validate the client address before starting
+   the cryptographic handshake.  QUIC uses a token in the Initial packet
+   to provide address validation prior to completing the handshake.
+   This token is delivered to the client during connection establishment
+   with a Retry packet (see Section 8.1.2) or in a previous connection
+   using the NEW_TOKEN frame (see Section 8.1.3).
+
+   In addition to sending limits imposed prior to address validation,
+   servers are also constrained in what they can send by the limits set
+   by the congestion controller.  Clients are only constrained by the
+   congestion controller.
+
+8.1.1.  Token Construction
+
+   A token sent in a NEW_TOKEN frames or a Retry packet MUST be
+   constructed in a way that allows the server to identify how it was
+   provided to a client.  These tokens are carried in the same field,
+   but require different handling from servers.
+
+8.1.2.  Address Validation using Retry Packets
+
+   Upon receiving the client's Initial packet, the server can request
+   address validation by sending a Retry packet (Section 17.2.5)
+   containing a token.  This token MUST be repeated by the client in all
+   Initial packets it sends for that connection after it receives the
+   Retry packet.  In response to processing an Initial containing a
+   token, a server can either abort the connection or permit it to
+   proceed.
+
+   As long as it is not possible for an attacker to generate a valid
+   token for its own address (see Section 8.1.4) and the client is able
+   to return that token, it proves to the server that it received the
+   token.
+
+   A server can also use a Retry packet to defer the state and
+   processing costs of connection establishment.  Requiring the server
+   to provide a different connection ID, along with the
+   original_destination_connection_id transport parameter defined in
+   Section 18.2, forces the server to demonstrate that it, or an entity
+   it cooperates with, received the original Initial packet from the
+   client.  Providing a different connection ID also grants a server
+   some control over how subsequent packets are routed.  This can be
+   used to direct connections to a different server instance.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 47]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   If a server receives a client Initial that can be unprotected but
+   contains an invalid Retry token, it knows the client will not accept
+   another Retry token.  The server can discard such a packet and allow
+   the client to time out to detect handshake failure, but that could
+   impose a significant latency penalty on the client.  Instead, the
+   server SHOULD immediately close (Section 10.3) the connection with an
+   INVALID_TOKEN error.  Note that a server has not established any
+   state for the connection at this point and so does not enter the
+   closing period.
+
+   A flow showing the use of a Retry packet is shown in Figure 8.
+
+   Client                                                  Server
+
+   Initial[0]: CRYPTO[CH] ->
+
+                                                   <- Retry+Token
+
+   Initial+Token[1]: CRYPTO[CH] ->
+
+                                    Initial[0]: CRYPTO[SH] ACK[1]
+                          Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
+                                    <- 1-RTT[0]: STREAM[1, "..."]
+
+                   Figure 8: Example Handshake with Retry
+
+8.1.3.  Address Validation for Future Connections
+
+   A server MAY provide clients with an address validation token during
+   one connection that can be used on a subsequent connection.  Address
+   validation is especially important with 0-RTT because a server
+   potentially sends a significant amount of data to a client in
+   response to 0-RTT data.
+
+   The server uses the NEW_TOKEN frame Section 19.7 to provide the
+   client with an address validation token that can be used to validate
+   future connections.  The client includes this token in Initial
+   packets to provide address validation in a future connection.  The
+   client MUST include the token in all Initial packets it sends, unless
+   a Retry replaces the token with a newer one.  The client MUST NOT use
+   the token provided in a Retry for future connections.  Servers MAY
+   discard any Initial packet that does not carry the expected token.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 48]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Unlike the token that is created for a Retry packet, which is used
+   immediately, the token sent in the NEW_TOKEN frame might be used
+   after some period of time has passed.  Thus, a token SHOULD have an
+   expiration time, which could be either an explicit expiration time or
+   an issued timestamp that can be used to dynamically calculate the
+   expiration time.  A server can store the expiration time or include
+   it in an encrypted form in the token.
+
+   A token issued with NEW_TOKEN MUST NOT include information that would
+   allow values to be linked by an observer to the connection on which
+   it was issued, unless the values are encrypted.  For example, it
+   cannot include the previous connection ID or addressing information.
+   A server MUST ensure that every NEW_TOKEN frame it sends is unique
+   across all clients, with the exception of those sent to repair losses
+   of previously sent NEW_TOKEN frames.  Information that allows the
+   server to distinguish between tokens from Retry and NEW_TOKEN MAY be
+   accessible to entities other than the server.
+
+   It is unlikely that the client port number is the same on two
+   different connections; validating the port is therefore unlikely to
+   be successful.
+
+   A token received in a NEW_TOKEN frame is applicable to any server
+   that the connection is considered authoritative for (e.g., server
+   names included in the certificate).  When connecting to a server for
+   which the client retains an applicable and unused token, it SHOULD
+   include that token in the Token field of its Initial packet.
+   Including a token might allow the server to validate the client
+   address without an additional round trip.  A client MUST NOT include
+   a token that is not applicable to the server that it is connecting
+   to, unless the client has the knowledge that the server that issued
+   the token and the server the client is connecting to are jointly
+   managing the tokens.  A client MAY use a token from any previous
+   connection to that server.
+
+   A token allows a server to correlate activity between the connection
+   where the token was issued and any connection where it is used.
+   Clients that want to break continuity of identity with a server MAY
+   discard tokens provided using the NEW_TOKEN frame.  In comparison, a
+   token obtained in a Retry packet MUST be used immediately during the
+   connection attempt and cannot be used in subsequent connection
+   attempts.
+
+   A client SHOULD NOT reuse a NEW_TOKEN token for different connection
+   attempts.  Reusing a token allows connections to be linked by
+   entities on the network path; see Section 9.5.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 49]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Clients might receive multiple tokens on a single connection.  Aside
+   from preventing linkability, any token can be used in any connection
+   attempt.  Servers can send additional tokens to either enable address
+   validation for multiple connection attempts or to replace older
+   tokens that might become invalid.  For a client, this ambiguity means
+   that sending the most recent unused token is most likely to be
+   effective.  Though saving and using older tokens has no negative
+   consequences, clients can regard older tokens as being less likely be
+   useful to the server for address validation.
+
+   When a server receives an Initial packet with an address validation
+   token, it MUST attempt to validate the token, unless it has already
+   completed address validation.  If the token is invalid then the
+   server SHOULD proceed as if the client did not have a validated
+   address, including potentially sending a Retry.  If the validation
+   succeeds, the server SHOULD then allow the handshake to proceed.
+
+   Note:  The rationale for treating the client as unvalidated rather
+      than discarding the packet is that the client might have received
+      the token in a previous connection using the NEW_TOKEN frame, and
+      if the server has lost state, it might be unable to validate the
+      token at all, leading to connection failure if the packet is
+      discarded.  A server SHOULD encode tokens provided with NEW_TOKEN
+      frames and Retry packets differently, and validate the latter more
+      strictly.
+
+   In a stateless design, a server can use encrypted and authenticated
+   tokens to pass information to clients that the server can later
+   recover and use to validate a client address.  Tokens are not
+   integrated into the cryptographic handshake and so they are not
+   authenticated.  For instance, a client might be able to reuse a
+   token.  To avoid attacks that exploit this property, a server can
+   limit its use of tokens to only the information needed to validate
+   client addresses.
+
+   Clients MAY use tokens obtained on one connection for any connection
+   attempt using the same version.  When selecting a token to use,
+   clients do not need to consider other properties of the connection
+   that is being attempted, including the choice of possible application
+   protocols, session tickets, or other connection properties.
+
+   Attackers could replay tokens to use servers as amplifiers in DDoS
+   attacks.  To protect against such attacks, servers SHOULD ensure that
+   tokens sent in Retry packets are only accepted for a short time.
+   Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to
+   be valid for longer, but SHOULD NOT be accepted multiple times in a
+   short period.  Servers are encouraged to allow tokens to be used only
+   once, if possible.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 50]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+8.1.4.  Address Validation Token Integrity
+
+   An address validation token MUST be difficult to guess.  Including a
+   large enough random value in the token would be sufficient, but this
+   depends on the server remembering the value it sends to clients.
+
+   A token-based scheme allows the server to offload any state
+   associated with validation to the client.  For this design to work,
+   the token MUST be covered by integrity protection against
+   modification or falsification by clients.  Without integrity
+   protection, malicious clients could generate or guess values for
+   tokens that would be accepted by the server.  Only the server
+   requires access to the integrity protection key for tokens.
+
+   There is no need for a single well-defined format for the token
+   because the server that generates the token also consumes it.  Tokens
+   sent in Retry packets SHOULD include information that allows the
+   server to verify that the source IP address and port in client
+   packets remain constant.
+
+   Tokens sent in NEW_TOKEN frames MUST include information that allows
+   the server to verify that the client IP address has not changed from
+   when the token was issued.  Servers can use tokens from NEW_TOKEN in
+   deciding not to send a Retry packet, even if the client address has
+   changed.  If the client IP address has changed, the server MUST
+   adhere to the anti-amplification limits found in Section 8.1.  Note
+   that in the presence of NAT, this requirement might be insufficient
+   to protect other hosts that share the NAT from amplification attack.
+
+   Servers MUST ensure that replay of tokens is prevented or limited.
+   For instance, servers might limit the time over which a token is
+   accepted.  Tokens provided in NEW_TOKEN frames might need to allow
+   longer validity periods.  Tokens MAY include additional information
+   about clients to further narrow applicability or reuse.
+
+8.2.  Path Validation
+
+   Path validation is used during connection migration (see Section 9
+   and Section 9.6) by the migrating endpoint to verify reachability of
+   a peer from a new local address.  In path validation, endpoints test
+   reachability between a specific local address and a specific peer
+   address, where an address is the two-tuple of IP address and port.
+
+   Path validation tests that packets (PATH_CHALLENGE) can be both sent
+   to and received (PATH_RESPONSE) from a peer on the path.
+   Importantly, it validates that the packets received from the
+   migrating endpoint do not carry a spoofed source address.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 51]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Path validation can be used at any time by either endpoint.  For
+   instance, an endpoint might check that a peer is still in possession
+   of its address after a period of quiescence.
+
+   Path validation is not designed as a NAT traversal mechanism.  Though
+   the mechanism described here might be effective for the creation of
+   NAT bindings that support NAT traversal, the expectation is that one
+   or other peer is able to receive packets without first having sent a
+   packet on that path.  Effective NAT traversal needs additional
+   synchronization mechanisms that are not provided here.
+
+   An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that
+   are used for path validation with other frames.  In particular, an
+   endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU
+   discovery, or an endpoint may bundle a PATH_RESPONSE with its own
+   PATH_CHALLENGE.
+
+   When probing a new path, an endpoint might want to ensure that its
+   peer has an unused connection ID available for responses.  The
+   endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the
+   same packet.  This ensures that an unused connection ID will be
+   available to the peer when sending a response.
+
+8.3.  Initiating Path Validation
+
+   To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
+   containing a random payload on the path to be validated.
+
+   An endpoint MAY send multiple PATH_CHALLENGE frames to guard against
+   packet loss.  However, an endpoint SHOULD NOT send multiple
+   PATH_CHALLENGE frames in a single packet.  An endpoint SHOULD NOT
+   send a PATH_CHALLENGE more frequently than it would an Initial
+   packet, ensuring that connection migration is no more load on a new
+   path than establishing a new connection.
+
+   The endpoint MUST use unpredictable data in every PATH_CHALLENGE
+   frame so that it can associate the peer's response with the
+   corresponding PATH_CHALLENGE.
+
+8.4.  Path Validation Responses
+
+   On receiving a PATH_CHALLENGE frame, an endpoint MUST respond
+   immediately by echoing the data contained in the PATH_CHALLENGE frame
+   in a PATH_RESPONSE frame.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 52]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   An endpoint MUST NOT send more than one PATH_RESPONSE frame in
+   response to one PATH_CHALLENGE frame; see Section 13.3.  The peer is
+   expected to send more PATH_CHALLENGE frames as necessary to evoke
+   additional PATH_RESPONSE frames.
+
+8.5.  Successful Path Validation
+
+   A new address is considered valid when a PATH_RESPONSE frame is
+   received that contains the data that was sent in a previous
+   PATH_CHALLENGE.  Receipt of an acknowledgment for a packet containing
+   a PATH_CHALLENGE frame is not adequate validation, since the
+   acknowledgment can be spoofed by a malicious peer.
+
+   Note that receipt on a different local address does not result in
+   path validation failure, as it might be a result of a forwarded
+   packet (see Section 9.3.3) or misrouting.  It is possible that a
+   valid PATH_RESPONSE might be received in the future.
+
+8.6.  Failed Path Validation
+
+   Path validation only fails when the endpoint attempting to validate
+   the path abandons its attempt to validate the path.
+
+   Endpoints SHOULD abandon path validation based on a timer.  When
+   setting this timer, implementations are cautioned that the new path
+   could have a longer round-trip time than the original.  A value of
+   three times the larger of the current Probe Timeout (PTO) or the
+   initial timeout (that is, 2*kInitialRtt) as defined in
+   [QUIC-RECOVERY] is RECOMMENDED.  That is:
+
+      validation_timeout = max(3*PTO, 6*kInitialRtt)
+
+   Note that the endpoint might receive packets containing other frames
+   on the new path, but a PATH_RESPONSE frame with appropriate data is
+   required for path validation to succeed.
+
+   When an endpoint abandons path validation, it determines that the
+   path is unusable.  This does not necessarily imply a failure of the
+   connection - endpoints can continue sending packets over other paths
+   as appropriate.  If no paths are available, an endpoint can wait for
+   a new path to become available or close the connection.
+
+   A path validation might be abandoned for other reasons besides
+   failure.  Primarily, this happens if a connection migration to a new
+   path is initiated while a path validation on the old path is in
+   progress.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 53]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+9.  Connection Migration
+
+   The use of a connection ID allows connections to survive changes to
+   endpoint addresses (IP address and port), such as those caused by an
+   endpoint migrating to a new network.  This section describes the
+   process by which an endpoint migrates to a new address.
+
+   The design of QUIC relies on endpoints retaining a stable address for
+   the duration of the handshake.  An endpoint MUST NOT initiate
+   connection migration before the handshake is confirmed, as defined in
+   section 4.1.2 of [QUIC-TLS].
+
+   An endpoint also MUST NOT send packets from a different local
+   address, actively initiating migration, if the peer sent the
+   disable_active_migration transport parameter during the handshake.
+   An endpoint which has sent this transport parameter, but detects that
+   a peer has nonetheless migrated to a different network MUST either
+   drop the incoming packets on that path without generating a stateless
+   reset or proceed with path validation and allow the peer to migrate.
+   Generating a stateless reset or closing the connection would allow
+   third parties in the network to cause connections to close by
+   spoofing or otherwise manipulating observed traffic.
+
+   Not all changes of peer address are intentional, or active,
+   migrations.  The peer could experience NAT rebinding: a change of
+   address due to a middlebox, usually a NAT, allocating a new outgoing
+   port or even a new outgoing IP address for a flow.  An endpoint MUST
+   perform path validation (Section 8.2) if it detects any change to a
+   peer's address, unless it has previously validated that address.
+
+   When an endpoint has no validated path on which to send packets, it
+   MAY discard connection state.  An endpoint capable of connection
+   migration MAY wait for a new path to become available before
+   discarding connection state.
+
+   This document limits migration of connections to new client
+   addresses, except as described in Section 9.6.  Clients are
+   responsible for initiating all migrations.  Servers do not send non-
+   probing packets (see Section 9.1) toward a client address until they
+   see a non-probing packet from that address.  If a client receives
+   packets from an unknown server address, the client MUST discard these
+   packets.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 54]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+9.1.  Probing a New Path
+
+   An endpoint MAY probe for peer reachability from a new local address
+   using path validation Section 8.2 prior to migrating the connection
+   to the new local address.  Failure of path validation simply means
+   that the new path is not usable for this connection.  Failure to
+   validate a path does not cause the connection to end unless there are
+   no valid alternative paths available.
+
+   An endpoint uses a new connection ID for probes sent from a new local
+   address; see Section 9.5 for further discussion.  An endpoint that
+   uses a new local address needs to ensure that at least one new
+   connection ID is available at the peer.  That can be achieved by
+   including a NEW_CONNECTION_ID frame in the probe.
+
+   Receiving a PATH_CHALLENGE frame from a peer indicates that the peer
+   is probing for reachability on a path.  An endpoint sends a
+   PATH_RESPONSE in response as per Section 8.2.
+
+   PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames
+   are "probing frames", and all other frames are "non-probing frames".
+   A packet containing only probing frames is a "probing packet", and a
+   packet containing any other frame is a "non-probing packet".
+
+9.2.  Initiating Connection Migration
+
+   An endpoint can migrate a connection to a new local address by
+   sending packets containing non-probing frames from that address.
+
+   Each endpoint validates its peer's address during connection
+   establishment.  Therefore, a migrating endpoint can send to its peer
+   knowing that the peer is willing to receive at the peer's current
+   address.  Thus an endpoint can migrate to a new local address without
+   first validating the peer's address.
+
+   When migrating, the new path might not support the endpoint's current
+   sending rate.  Therefore, the endpoint resets its congestion
+   controller, as described in Section 9.4.
+
+   The new path might not have the same ECN capability.  Therefore, the
+   endpoint verifies ECN capability as described in Section 13.4.
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 55]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Receiving acknowledgments for data sent on the new path serves as
+   proof of the peer's reachability from the new address.  Note that
+   since acknowledgments may be received on any path, return
+   reachability on the new path is not established.  To establish return
+   reachability on the new path, an endpoint MAY concurrently initiate
+   path validation Section 8.2 on the new path or it MAY choose to wait
+   for the peer to send the next non-probing frame to its new address.
+
+9.3.  Responding to Connection Migration
+
+   Receiving a packet from a new peer address containing a non-probing
+   frame indicates that the peer has migrated to that address.
+
+   In response to such a packet, an endpoint MUST start sending
+   subsequent packets to the new peer address and MUST initiate path
+   validation (Section 8.2) to verify the peer's ownership of the
+   unvalidated address.
+
+   An endpoint MAY send data to an unvalidated peer address, but it MUST
+   protect against potential attacks as described in Section 9.3.1 and
+   Section 9.3.2.  An endpoint MAY skip validation of a peer address if
+   that address has been seen recently.  In particular, if an endpoint
+   returns to a previously-validated path after detecting some form of
+   spurious migration, skipping address validation and restoring loss
+   detection and congestion state can reduce the performance impact of
+   the attack.
+
+   An endpoint only changes the address that it sends packets to in
+   response to the highest-numbered non-probing packet.  This ensures
+   that an endpoint does not send packets to an old peer address in the
+   case that it receives reordered packets.
+
+   After changing the address to which it sends non-probing packets, an
+   endpoint could abandon any path validation for other addresses.
+
+   Receiving a packet from a new peer address might be the result of a
+   NAT rebinding at the peer.
+
+   After verifying a new client address, the server SHOULD send new
+   address validation tokens (Section 8) to the client.
+
+9.3.1.  Peer Address Spoofing
+
+   It is possible that a peer is spoofing its source address to cause an
+   endpoint to send excessive amounts of data to an unwilling host.  If
+   the endpoint sends significantly more data than the spoofing peer,
+   connection migration might be used to amplify the volume of data that
+   an attacker can generate toward a victim.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 56]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   As described in Section 9.3, an endpoint is required to validate a
+   peer's new address to confirm the peer's possession of the new
+   address.  Until a peer's address is deemed valid, an endpoint MUST
+   limit the rate at which it sends data to this address.  The endpoint
+   MUST NOT send more than a minimum congestion window's worth of data
+   per estimated round-trip time (kMinimumWindow, as defined in
+   [QUIC-RECOVERY]).  In the absence of this limit, an endpoint risks
+   being used for a denial of service attack against an unsuspecting
+   victim.  Note that since the endpoint will not have any round-trip
+   time measurements to this address, the estimate SHOULD be the default
+   initial value; see [QUIC-RECOVERY].
+
+   If an endpoint skips validation of a peer address as described in
+   Section 9.3, it does not need to limit its sending rate.
+
+9.3.2.  On-Path Address Spoofing
+
+   An on-path attacker could cause a spurious connection migration by
+   copying and forwarding a packet with a spoofed address such that it
+   arrives before the original packet.  The packet with the spoofed
+   address will be seen to come from a migrating connection, and the
+   original packet will be seen as a duplicate and dropped.  After a
+   spurious migration, validation of the source address will fail
+   because the entity at the source address does not have the necessary
+   cryptographic keys to read or respond to the PATH_CHALLENGE frame
+   that is sent to it even if it wanted to.
+
+   To protect the connection from failing due to such a spurious
+   migration, an endpoint MUST revert to using the last validated peer
+   address when validation of a new peer address fails.
+
+   If an endpoint has no state about the last validated peer address, it
+   MUST close the connection silently by discarding all connection
+   state.  This results in new packets on the connection being handled
+   generically.  For instance, an endpoint MAY send a stateless reset in
+   response to any further incoming packets.
+
+   Note that receipt of packets with higher packet numbers from the
+   legitimate peer address will trigger another connection migration.
+   This will cause the validation of the address of the spurious
+   migration to be abandoned.
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 57]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+9.3.3.  Off-Path Packet Forwarding
+
+   An off-path attacker that can observe packets might forward copies of
+   genuine packets to endpoints.  If the copied packet arrives before
+   the genuine packet, this will appear as a NAT rebinding.  Any genuine
+   packet will be discarded as a duplicate.  If the attacker is able to
+   continue forwarding packets, it might be able to cause migration to a
+   path via the attacker.  This places the attacker on path, giving it
+   the ability to observe or drop all subsequent packets.
+
+   Unlike the attack described in Section 9.3.2, the attacker can ensure
+   that the new path is successfully validated.
+
+   This style of attack relies on the attacker using a path that is
+   approximately as fast as the direct path between endpoints.  The
+   attack is more reliable if relatively few packets are sent or if
+   packet loss coincides with the attempted attack.
+
+   A non-probing packet received on the original path that increases the
+   maximum received packet number will cause the endpoint to move back
+   to that path.  Eliciting packets on this path increases the
+   likelihood that the attack is unsuccessful.  Therefore, mitigation of
+   this attack relies on triggering the exchange of packets.
+
+   In response to an apparent migration, endpoints MUST validate the
+   previously active path using a PATH_CHALLENGE frame.  This induces
+   the sending of new packets on that path.  If the path is no longer
+   viable, the validation attempt will time out and fail; if the path is
+   viable, but no longer desired, the validation will succeed, but only
+   results in probing packets being sent on the path.
+
+   An endpoint that receives a PATH_CHALLENGE on an active path SHOULD
+   send a non-probing packet in response.  If the non-probing packet
+   arrives before any copy made by an attacker, this results in the
+   connection being migrated back to the original path.  Any subsequent
+   migration to another path restarts this entire process.
+
+   This defense is imperfect, but this is not considered a serious
+   problem.  If the path via the attack is reliably faster than the
+   original path despite multiple attempts to use that original path, it
+   is not possible to distinguish between attack and an improvement in
+   routing.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 58]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   An endpoint could also use heuristics to improve detection of this
+   style of attack.  For instance, NAT rebinding is improbable if
+   packets were recently received on the old path, similarly rebinding
+   is rare on IPv6 paths.  Endpoints can also look for duplicated
+   packets.  Conversely, a change in connection ID is more likely to
+   indicate an intentional migration rather than an attack.
+
+9.4.  Loss Detection and Congestion Control
+
+   The capacity available on the new path might not be the same as the
+   old path.  Packets sent on the old path MUST NOT contribute to
+   congestion control or RTT estimation for the new path.
+
+   On confirming a peer's ownership of its new address, an endpoint MUST
+   immediately reset the congestion controller and round-trip time
+   estimator for the new path to initial values (see Sections A.3 and
+   B.3 in [QUIC-RECOVERY]) unless it has knowledge that a previous send
+   rate or round-trip time estimate is valid for the new path.  For
+   instance, an endpoint might infer that a change in only the client's
+   port number is indicative of a NAT rebinding, meaning that the new
+   path is likely to have similar bandwidth and round-trip time.
+   However, this determination will be imperfect.  If the determination
+   is incorrect, the congestion controller and the RTT estimator are
+   expected to adapt to the new path.  Generally, implementations are
+   advised to be cautious when using previous values on a new path.
+
+   There may be apparent reordering at the receiver when an endpoint
+   sends data and probes from/to multiple addresses during the migration
+   period, since the two resulting paths may have different round-trip
+   times.  A receiver of packets on multiple paths will still send ACK
+   frames covering all received packets.
+
+   While multiple paths might be used during connection migration, a
+   single congestion control context and a single loss recovery context
+   (as described in [QUIC-RECOVERY]) may be adequate.  For instance, an
+   endpoint might delay switching to a new congestion control context
+   until it is confirmed that an old path is no longer needed (such as
+   the case in Section 9.3.3).
+
+   A sender can make exceptions for probe packets so that their loss
+   detection is independent and does not unduly cause the congestion
+   controller to reduce its sending rate.  An endpoint might set a
+   separate timer when a PATH_CHALLENGE is sent, which is cancelled if
+   the corresponding PATH_RESPONSE is received.  If the timer fires
+   before the PATH_RESPONSE is received, the endpoint might send a new
+   PATH_CHALLENGE, and restart the timer for a longer period of time.
+   This timer SHOULD be set as described in Section 5.3 of
+   [QUIC-RECOVERY] and MUST NOT be more aggressive.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 59]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+9.5.  Privacy Implications of Connection Migration
+
+   Using a stable connection ID on multiple network paths allows a
+   passive observer to correlate activity between those paths.  An
+   endpoint that moves between networks might not wish to have their
+   activity correlated by any entity other than their peer, so different
+   connection IDs are used when sending from different local addresses,
+   as discussed in Section 5.1.  For this to be effective endpoints need
+   to ensure that connection IDs they provide cannot be linked by any
+   other entity.
+
+   At any time, endpoints MAY change the Destination Connection ID they
+   send to a value that has not been used on another path.
+
+   An endpoint MUST NOT reuse a connection ID when sending from more
+   than one local address, for example when initiating connection
+   migration as described in Section 9.2 or when probing a new network
+   path as described in Section 9.1.
+
+   Similarly, an endpoint MUST NOT reuse a connection ID when sending to
+   more than one destination address.  Due to network changes outside
+   the control of its peer, an endpoint might receive packets from a new
+   source address with the same destination connection ID, in which case
+   it MAY continue to use the current connection ID with the new remote
+   address while still sending from the same local address.
+
+   These requirements regarding connection ID reuse apply only to the
+   sending of packets, as unintentional changes in path without a change
+   in connection ID are possible.  For example, after a period of
+   network inactivity, NAT rebinding might cause packets to be sent on a
+   new path when the client resumes sending.  An endpoint responds to
+   such an event as described in Section 9.3.
+
+   Using different connection IDs for packets sent in both directions on
+   each new network path eliminates the use of the connection ID for
+   linking packets from the same connection across different network
+   paths.  Header protection ensures that packet numbers cannot be used
+   to correlate activity.  This does not prevent other properties of
+   packets, such as timing and size, from being used to correlate
+   activity.
+
+   An endpoint SHOULD NOT initiate migration with a peer that has
+   requested a zero-length connection ID, because traffic over the new
+   path might be trivially linkable to traffic over the old one.  If the
+   server is able to route packets with a zero-length connection ID to
+   the right connection, it means that the server is using other
+   information to demultiplex packets.  For example, a server might
+   provide a unique address to every client, for instance using HTTP
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 60]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   alternative services [ALTSVC].  Information that might allow correct
+   routing of packets across multiple network paths will also allow
+   activity on those paths to be linked by entities other than the peer.
+
+   A client might wish to reduce linkability by employing a new
+   connection ID and source UDP port when sending traffic after a period
+   of inactivity.  Changing the UDP port from which it sends packets at
+   the same time might cause the packet to appear as a connection
+   migration.  This ensures that the mechanisms that support migration
+   are exercised even for clients that don't experience NAT rebindings
+   or genuine migrations.  Changing port number can cause a peer to
+   reset its congestion state (see Section 9.4), so the port SHOULD only
+   be changed infrequently.
+
+   An endpoint that exhausts available connection IDs cannot probe new
+   paths or initiate migration, nor can it respond to probes or attempts
+   by its peer to migrate.  To ensure that migration is possible and
+   packets sent on different paths cannot be correlated, endpoints
+   SHOULD provide new connection IDs before peers migrate; see
+   Section 5.1.1.  If a peer might have exhausted available connection
+   IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in
+   all packets sent on a new network path.
+
+9.6.  Server's Preferred Address
+
+   QUIC allows servers to accept connections on one IP address and
+   attempt to transfer these connections to a more preferred address
+   shortly after the handshake.  This is particularly useful when
+   clients initially connect to an address shared by multiple servers
+   but would prefer to use a unicast address to ensure connection
+   stability.  This section describes the protocol for migrating a
+   connection to a preferred server address.
+
+   Migrating a connection to a new server address mid-connection is left
+   for future work.  If a client receives packets from a new server
+   address not indicated by the preferred_address transport parameter,
+   the client SHOULD discard these packets.
+
+9.6.1.  Communicating a Preferred Address
+
+   A server conveys a preferred address by including the
+   preferred_address transport parameter in the TLS handshake.
+
+   Servers MAY communicate a preferred address of each address family
+   (IPv4 and IPv6) to allow clients to pick the one most suited to their
+   network attachment.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 61]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Once the handshake is confirmed, the client SHOULD select one of the
+   two server's preferred addresses and initiate path validation (see
+   Section 8.2) of that address using any previously unused active
+   connection ID, taken from either the preferred_address transport
+   parameter or a NEW_CONNECTION_ID frame.
+
+   If path validation succeeds, the client SHOULD immediately begin
+   sending all future packets to the new server address using the new
+   connection ID and discontinue use of the old server address.  If path
+   validation fails, the client MUST continue sending all future packets
+   to the server's original IP address.
+
+9.6.2.  Responding to Connection Migration
+
+   A server might receive a packet addressed to its preferred IP address
+   at any time after it accepts a connection.  If this packet contains a
+   PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per
+   Section 8.2.  The server MUST send other non-probing frames from its
+   original address until it receives a non-probing packet from the
+   client at its preferred address and until the server has validated
+   the new path.
+
+   The server MUST probe on the path toward the client from its
+   preferred address.  This helps to guard against spurious migration
+   initiated by an attacker.
+
+   Once the server has completed its path validation and has received a
+   non-probing packet with a new largest packet number on its preferred
+   address, the server begins sending non-probing packets to the client
+   exclusively from its preferred IP address.  It SHOULD drop packets
+   for this connection received on the old IP address, but MAY continue
+   to process delayed packets.
+
+   The addresses that a server provides in the preferred_address
+   transport parameter are only valid for the connection in which they
+   are provided.  A client MUST NOT use these for other connections,
+   including connections that are resumed from the current connection.
+
+9.6.3.  Interaction of Client Migration and Preferred Address
+
+   A client might need to perform a connection migration before it has
+   migrated to the server's preferred address.  In this case, the client
+   SHOULD perform path validation to both the original and preferred
+   server address from the client's new address concurrently.
+
+   If path validation of the server's preferred address succeeds, the
+   client MUST abandon validation of the original address and migrate to
+   using the server's preferred address.  If path validation of the
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 62]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   server's preferred address fails but validation of the server's
+   original address succeeds, the client MAY migrate to its new address
+   and continue sending to the server's original address.
+
+   If the connection to the server's preferred address is not from the
+   same client address, the server MUST protect against potential
+   attacks as described in Section 9.3.1 and Section 9.3.2.  In addition
+   to intentional simultaneous migration, this might also occur because
+   the client's access network used a different NAT binding for the
+   server's preferred address.
+
+   Servers SHOULD initiate path validation to the client's new address
+   upon receiving a probe packet from a different address.  Servers MUST
+   NOT send more than a minimum congestion window's worth of non-probing
+   packets to the new address before path validation is complete.
+
+   A client that migrates to a new address SHOULD use a preferred
+   address from the same address family for the server.
+
+   The connection ID provided in the preferred_address transport
+   parameter is not specific to the addresses that are provided.  This
+   connection ID is provided to ensure that the client has a connection
+   ID available for migration, but the client MAY use this connection ID
+   on any path.
+
+9.7.  Use of IPv6 Flow-Label and Migration
+
+   Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
+   in compliance with [RFC6437], unless the local API does not allow
+   setting IPv6 flow labels.
+
+   The IPv6 flow label SHOULD be a pseudo-random function of the source
+   and destination addresses, source and destination UDP ports, and the
+   destination CID.  The flow label generation MUST be designed to
+   minimize the chances of linkability with a previously used flow
+   label, as this would enable correlating activity on multiple paths;
+   see Section 9.5.
+
+   A possible implementation is to compute the flow label as a
+   cryptographic hash function of the source and destination addresses,
+   source and destination UDP ports, destination CID, and a local
+   secret.
+
+10.  Connection Termination
+
+   An established QUIC connection can be terminated in one of three
+   ways:
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 63]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  idle timeout (Section 10.2)
+
+   *  immediate close (Section 10.3)
+
+   *  stateless reset (Section 10.4)
+
+   An endpoint MAY discard connection state if it does not have a
+   validated path on which it can send packets; see Section 8.2.
+
+10.1.  Closing and Draining Connection States
+
+   The closing and draining connection states exist to ensure that
+   connections close cleanly and that delayed or reordered packets are
+   properly discarded.  These states SHOULD persist for at least three
+   times the current Probe Timeout (PTO) interval as defined in
+   [QUIC-RECOVERY].
+
+   An endpoint enters a closing period after initiating an immediate
+   close; Section 10.3.  While closing, an endpoint MUST NOT send
+   packets unless they contain a CONNECTION_CLOSE frame; see
+   Section 10.3 for details.  An endpoint retains only enough
+   information to generate a packet containing a CONNECTION_CLOSE frame
+   and to identify packets as belonging to the connection.  The
+   endpoint's selected connection ID and the QUIC version are sufficient
+   information to identify packets for a closing connection; an endpoint
+   can discard all other connection state.  An endpoint MAY retain
+   packet protection keys for incoming packets to allow it to read and
+   process a CONNECTION_CLOSE frame.
+
+   The draining state is entered once an endpoint receives a signal that
+   its peer is closing or draining.  While otherwise identical to the
+   closing state, an endpoint in the draining state MUST NOT send any
+   packets.  Retaining packet protection keys is unnecessary once a
+   connection is in the draining state.
+
+   An endpoint MAY transition from the closing period to the draining
+   period if it receives a CONNECTION_CLOSE frame or stateless reset,
+   both of which indicate that the peer is also closing or draining.
+   The draining period SHOULD end when the closing period would have
+   ended.  In other words, the endpoint can use the same end time, but
+   cease retransmission of the closing packet.
+
+   Disposing of connection state prior to the end of the closing or
+   draining period could cause delayed or reordered packets to generate
+   an unnecessary stateless reset.  Endpoints that have some alternative
+   means to ensure that late-arriving packets on the connection do not
+   induce a response, such as those that are able to close the UDP
+   socket, MAY use an abbreviated draining period which can allow for
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 64]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   faster resource recovery.  Servers that retain an open socket for
+   accepting new connections SHOULD NOT exit the closing or draining
+   period early.
+
+   Once the closing or draining period has ended, an endpoint SHOULD
+   discard all connection state.  This results in new packets on the
+   connection being handled generically.  For instance, an endpoint MAY
+   send a stateless reset in response to any further incoming packets.
+
+   The draining and closing periods do not apply when a stateless reset
+   (Section 10.4) is sent.
+
+   An endpoint is not expected to handle key updates when it is closing
+   or draining.  A key update might prevent the endpoint from moving
+   from the closing state to draining, but it otherwise has no impact.
+
+   While in the closing period, an endpoint could receive packets from a
+   new source address, indicating a connection migration; Section 9.  An
+   endpoint in the closing state MUST strictly limit the number of
+   packets it sends to this new address until the address is validated;
+   see Section 8.2.  A server in the closing state MAY instead choose to
+   discard packets received from a new source address.
+
+10.2.  Idle Timeout
+
+   If a max_idle_timeout is specified by either peer in its transport
+   parameters (Section 18.2), the connection is silently closed and its
+   state is discarded when it remains idle for longer than the minimum
+   of both peers max_idle_timeout values and three times the current
+   Probe Timeout (PTO).
+
+   Each endpoint advertises a max_idle_timeout, but the effective value
+   at an endpoint is computed as the minimum of the two advertised
+   values.  By announcing a max_idle_timeout, an endpoint commits to
+   initiating an immediate close (Section 10.3) if it abandons the
+   connection prior to the effective value.
+
+   An endpoint restarts its idle timer when a packet from its peer is
+   received and processed successfully.  An endpoint also restarts its
+   idle timer when sending an ack-eliciting packet if no other ack-
+   eliciting packets have been sent since last receiving and processing
+   a packet.  Restarting this timer when sending a packet ensures that
+   connections are not closed after new activity is initiated.
+
+   An endpoint might need to send ack-eliciting packets to avoid an idle
+   timeout if it is expecting response data, but does not have or is
+   unable to send application data.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 65]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   An endpoint that sends packets close to the effective timeout risks
+   having them be discarded at the peer, since the peer might enter its
+   draining state before these packets arrive.  An endpoint can send a
+   PING or another ack-eliciting frame to test the connection for
+   liveness if the peer could time out soon, such as within a PTO; see
+   Section 6.6 of [QUIC-RECOVERY].  This is especially useful if any
+   available application data cannot be safely retried.  Note that the
+   application determines what data is safe to retry.
+
+10.3.  Immediate Close
+
+   An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to
+   terminate the connection immediately.  A CONNECTION_CLOSE frame
+   causes all streams to immediately become closed; open streams can be
+   assumed to be implicitly reset.
+
+   After sending a CONNECTION_CLOSE frame, an endpoint immediately
+   enters the closing state.
+
+   During the closing period, an endpoint that sends a CONNECTION_CLOSE
+   frame SHOULD respond to any incoming packet that can be decrypted
+   with another packet containing a CONNECTION_CLOSE frame.  Such an
+   endpoint SHOULD limit the number of packets it generates containing a
+   CONNECTION_CLOSE frame.  For instance, an endpoint could wait for a
+   progressively increasing number of received packets or amount of time
+   before responding to a received packet.
+
+   An endpoint is allowed to drop the packet protection keys when
+   entering the closing period (Section 10.1) and send a packet
+   containing a CONNECTION_CLOSE in response to any UDP datagram that is
+   received.  However, an endpoint without the packet protection keys
+   cannot identify and discard invalid packets.  To avoid creating an
+   unwitting amplification attack, such endpoints MUST reduce the
+   frequency with which it sends packets containing a CONNECTION_CLOSE
+   frame.  To minimize the state that an endpoint maintains for a
+   closing connection, endpoints MAY send the exact same packet.
+
+   Note:  Allowing retransmission of a closing packet contradicts other
+      advice in this document that recommends the creation of new packet
+      numbers for every packet.  Sending new packet numbers is primarily
+      of advantage to loss recovery and congestion control, which are
+      not expected to be relevant for a closed connection.
+      Retransmitting the final packet requires less state.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 66]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   New packets from unverified addresses could be used to create an
+   amplification attack; see Section 8.  To avoid this, endpoints MUST
+   either limit transmission of CONNECTION_CLOSE frames to validated
+   addresses or drop packets without response if the response would be
+   more than three times larger than the received packet.
+
+   After receiving a CONNECTION_CLOSE frame, endpoints enter the
+   draining state.  An endpoint that receives a CONNECTION_CLOSE frame
+   MAY send a single packet containing a CONNECTION_CLOSE frame before
+   entering the draining state, using a CONNECTION_CLOSE frame and a
+   NO_ERROR code if appropriate.  An endpoint MUST NOT send further
+   packets, which could result in a constant exchange of
+   CONNECTION_CLOSE frames until the closing period on either peer
+   ended.
+
+   An immediate close can be used after an application protocol has
+   arranged to close a connection.  This might be after the application
+   protocols negotiates a graceful shutdown.  The application protocol
+   exchanges whatever messages that are needed to cause both endpoints
+   to agree to close the connection, after which the application
+   requests that the connection be closed.  The application protocol can
+   use a CONNECTION_CLOSE frame with an appropriate error code to signal
+   closure.
+
+10.3.1.  Immediate Close During the Handshake
+
+   When sending CONNECTION_CLOSE, the goal is to ensure that the peer
+   will process the frame.  Generally, this means sending the frame in a
+   packet with the highest level of packet protection to avoid the
+   packet being discarded.  After the handshake is confirmed (see
+   Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any
+   CONNECTION_CLOSE frames in a 1-RTT packet.  However, prior to
+   confirming the handshake, it is possible that more advanced packet
+   protection keys are not available to the peer, so another
+   CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower
+   packet protection level.  More specifically:
+
+   *  A client will always know whether the server has Handshake keys
+      (see Section 17.2.2.1), but it is possible that a server does not
+      know whether the client has Handshake keys.  Under these
+      circumstances, a server SHOULD send a CONNECTION_CLOSE frame in
+      both Handshake and Initial packets to ensure that at least one of
+      them is processable by the client.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 67]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
+      assured of the server has accepted 0-RTT and so sending a
+      CONNECTION_CLOSE frame in an Initial packet makes it more likely
+      that the server can receive the close signal, even if the
+      application error code might not be received.
+
+   *  Prior to confirming the handshake, a peer might be unable to
+      process 1-RTT packets, so an endpoint SHOULD send CONNECTION_CLOSE
+      in both Handshake and 1-RTT packets.  A server SHOULD also send
+      CONNECTION_CLOSE in an Initial packet.
+
+   Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake
+   packet could expose application state or be used to alter application
+   state.  A CONNECTION_CLOSE of type 0x1d MUST be replaced by a
+   CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or
+   Handshake packets.  Otherwise, information about the application
+   state might be revealed.  Endpoints MUST clear the value of the
+   Reason Phrase field and SHOULD use the APPLICATION_ERROR code when
+   converting to a CONNECTION_CLOSE of type 0x1c.
+
+   CONNECTION_CLOSE frames sent in multiple packet types can be
+   coalesced into a single UDP datagram; see Section 12.2.
+
+   An endpoint might send a CONNECTION_CLOSE frame in an Initial packet
+   or in response to unauthenticated information received in Initial or
+   Handshake packets.  Such an immediate close might expose legitimate
+   connections to a denial of service.  QUIC does not include defensive
+   measures for on-path attacks during the handshake; see Section 21.1.
+   However, at the cost of reducing feedback about errors for legitimate
+   peers, some forms of denial of service can be made more difficult for
+   an attacker if endpoints discard illegal packets rather than
+   terminating a connection with CONNECTION_CLOSE.  For this reason,
+   endpoints MAY discard packets rather than immediately close if errors
+   are detected in packets that lack authentication.
+
+   An endpoint that has not established state, such as a server that
+   detects an error in an Initial packet, does not enter the closing
+   state.  An endpoint that has no state for the connection does not
+   enter a closing or draining period on sending a CONNECTION_CLOSE
+   frame.
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 68]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+10.4.  Stateless Reset
+
+   A stateless reset is provided as an option of last resort for an
+   endpoint that does not have access to the state of a connection.  A
+   crash or outage might result in peers continuing to send data to an
+   endpoint that is unable to properly continue the connection.  An
+   endpoint MAY send a stateless reset in response to receiving a packet
+   that it cannot associate with an active connection.
+
+   A stateless reset is not appropriate for signaling error conditions.
+   An endpoint that wishes to communicate a fatal connection error MUST
+   use a CONNECTION_CLOSE frame if it has sufficient state to do so.
+
+   To support this process, a token is sent by endpoints.  The token is
+   carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
+   frame.  Servers can also specify a stateless_reset_token transport
+   parameter during the handshake that applies to the connection ID that
+   it selected during the handshake; clients cannot use this transport
+   parameter because their transport parameters don't have
+   confidentiality protection.  These tokens are protected by
+   encryption, so only client and server know their value.  Tokens are
+   invalidated when their associated connection ID is retired via a
+   RETIRE_CONNECTION_ID frame (Section 19.16).
+
+   An endpoint that receives packets that it cannot process sends a
+   packet in the following layout:
+
+   Stateless Reset {
+     Fixed Bits (2) = 1,
+     Unpredictable Bits (38..),
+     Stateless Reset Token (128),
+   }
+
+                      Figure 9: Stateless Reset Packet
+
+   This design ensures that a stateless reset packet is - to the extent
+   possible - indistinguishable from a regular packet with a short
+   header.
+
+   A stateless reset uses an entire UDP datagram, starting with the
+   first two bits of the packet header.  The remainder of the first byte
+   and an arbitrary number of bytes following it that are set to
+   unpredictable values.  The last 16 bytes of the datagram contain a
+   Stateless Reset Token.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 69]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   To entities other than its intended recipient, a stateless reset will
+   appear to be a packet with a short header.  For the stateless reset
+   to appear as a valid QUIC packet, the Unpredictable Bits field needs
+   to include at least 38 bits of data (or 5 bytes, less the two fixed
+   bits).
+
+   A minimum size of 21 bytes does not guarantee that a stateless reset
+   is difficult to distinguish from other packets if the recipient
+   requires the use of a connection ID.  To prevent a resulting
+   stateless reset from being trivially distinguishable from a valid
+   packet, all packets sent by an endpoint SHOULD be padded to at least
+   22 bytes longer than the minimum connection ID that the endpoint
+   might use.  An endpoint that sends a stateless reset in response to a
+   packet that is 43 bytes or less in length SHOULD send a stateless
+   reset that is one byte shorter than the packet it responds to.
+
+   These values assume that the Stateless Reset Token is the same length
+   as the minimum expansion of the packet protection AEAD.  Additional
+   unpredictable bytes are necessary if the endpoint could have
+   negotiated a packet protection scheme with a larger minimum
+   expansion.
+
+   An endpoint MUST NOT send a stateless reset that is three times or
+   more larger than the packet it receives to avoid being used for
+   amplification.  Section 10.4.3 describes additional limits on
+   stateless reset size.
+
+   Endpoints MUST discard packets that are too small to be valid QUIC
+   packets.  With the set of AEAD functions defined in [QUIC-TLS],
+   packets that are smaller than 21 bytes are never valid.
+
+   Endpoints MUST send stateless reset packets formatted as a packet
+   with a short header.  However, endpoints MUST treat any packet ending
+   in a valid stateless reset token as a stateless reset, as other QUIC
+   versions might allow the use of a long header.
+
+   An endpoint MAY send a stateless reset in response to a packet with a
+   long header.  Sending a stateless reset is not effective prior to the
+   stateless reset token being available to a peer.  In this QUIC
+   version, packets with a long header are only used during connection
+   establishment.  Because the stateless reset token is not available
+   until connection establishment is complete or near completion,
+   ignoring an unknown packet with a long header might be as effective
+   as sending a stateless reset.
+
+   An endpoint cannot determine the Source Connection ID from a packet
+   with a short header, therefore it cannot set the Destination
+   Connection ID in the stateless reset packet.  The Destination
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 70]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Connection ID will therefore differ from the value used in previous
+   packets.  A random Destination Connection ID makes the connection ID
+   appear to be the result of moving to a new connection ID that was
+   provided using a NEW_CONNECTION_ID frame (Section 19.15).
+
+   Using a randomized connection ID results in two problems:
+
+   *  The packet might not reach the peer.  If the Destination
+      Connection ID is critical for routing toward the peer, then this
+      packet could be incorrectly routed.  This might also trigger
+      another Stateless Reset in response; see Section 10.4.3.  A
+      Stateless Reset that is not correctly routed is an ineffective
+      error detection and recovery mechanism.  In this case, endpoints
+      will need to rely on other methods - such as timers - to detect
+      that the connection has failed.
+
+   *  The randomly generated connection ID can be used by entities other
+      than the peer to identify this as a potential stateless reset.  An
+      endpoint that occasionally uses different connection IDs might
+      introduce some uncertainty about this.
+
+   This stateless reset design is specific to QUIC version 1.  An
+   endpoint that supports multiple versions of QUIC needs to generate a
+   stateless reset that will be accepted by peers that support any
+   version that the endpoint might support (or might have supported
+   prior to losing state).  Designers of new versions of QUIC need to be
+   aware of this and either reuse this design, or use a portion of the
+   packet other than the last 16 bytes for carrying data.
+
+10.4.1.  Detecting a Stateless Reset
+
+   An endpoint detects a potential stateless reset using the trailing 16
+   bytes of the UDP datagram.  An endpoint remembers all Stateless Reset
+   Tokens associated with the connection IDs and remote addresses for
+   datagrams it has recently sent.  This includes Stateless Reset Tokens
+   from NEW_CONNECTION_ID frames and the server's transport parameters
+   but excludes Stateless Reset Tokens associated with connection IDs
+   that are either unused or retired.  The endpoint identifies a
+   received datagram as a stateless reset by comparing the last 16 bytes
+   of the datagram with all Stateless Reset Tokens associated with the
+   remote address on which the datagram was received.
+
+   This comparison can be performed for every inbound datagram.
+   Endpoints MAY skip this check if any packet from a datagram is
+   successfully processed.  However, the comparison MUST be performed
+   when the first packet in an incoming datagram either cannot be
+   associated with a connection, or cannot be decrypted.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 71]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   An endpoint MUST NOT check for any Stateless Reset Tokens associated
+   with connection IDs it has not used or for connection IDs that have
+   been retired.
+
+   When comparing a datagram to Stateless Reset Token values, endpoints
+   MUST perform the comparison without leaking information about the
+   value of the token.  For example, performing this comparison in
+   constant time protects the value of individual Stateless Reset Tokens
+   from information leakage through timing side channels.  Another
+   approach would be to store and compare the transformed values of
+   Stateless Reset Tokens instead of the raw token values, where the
+   transformation is defined as a cryptographically-secure pseudo-random
+   function using a secret key (e.g., block cipher, HMAC [RFC2104]).  An
+   endpoint is not expected to protect information about whether a
+   packet was successfully decrypted, or the number of valid Stateless
+   Reset Tokens.
+
+   If the last 16 bytes of the datagram are identical in value to a
+   Stateless Reset Token, the endpoint MUST enter the draining period
+   and not send any further packets on this connection.
+
+10.4.2.  Calculating a Stateless Reset Token
+
+   The stateless reset token MUST be difficult to guess.  In order to
+   create a Stateless Reset Token, an endpoint could randomly generate
+   [RFC4086] a secret for every connection that it creates.  However,
+   this presents a coordination problem when there are multiple
+   instances in a cluster or a storage problem for an endpoint that
+   might lose state.  Stateless reset specifically exists to handle the
+   case where state is lost, so this approach is suboptimal.
+
+   A single static key can be used across all connections to the same
+   endpoint by generating the proof using a second iteration of a
+   preimage-resistant function that takes a static key and the
+   connection ID chosen by the endpoint (see Section 5.1) as input.  An
+   endpoint could use HMAC [RFC2104] (for example, HMAC(static_key,
+   connection_id)) or HKDF [RFC5869] (for example, using the static key
+   as input keying material, with the connection ID as salt).  The
+   output of this function is truncated to 16 bytes to produce the
+   Stateless Reset Token for that connection.
+
+   An endpoint that loses state can use the same method to generate a
+   valid Stateless Reset Token.  The connection ID comes from the packet
+   that the endpoint receives.
+
+   This design relies on the peer always sending a connection ID in its
+   packets so that the endpoint can use the connection ID from a packet
+   to reset the connection.  An endpoint that uses this design MUST
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 72]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   either use the same connection ID length for all connections or
+   encode the length of the connection ID such that it can be recovered
+   without state.  In addition, it cannot provide a zero-length
+   connection ID.
+
+   Revealing the Stateless Reset Token allows any entity to terminate
+   the connection, so a value can only be used once.  This method for
+   choosing the Stateless Reset Token means that the combination of
+   connection ID and static key MUST NOT be used for another connection.
+   A denial of service attack is possible if the same connection ID is
+   used by instances that share a static key, or if an attacker can
+   cause a packet to be routed to an instance that has no state but the
+   same static key; see Section 21.9.  A connection ID from a connection
+   that is reset by revealing the Stateless Reset Token MUST NOT be
+   reused for new connections at nodes that share a static key.
+
+   The same Stateless Reset Token MUST NOT be used for multiple
+   connection IDs.  Endpoints are not required to compare new values
+   against all previous values, but a duplicate value MAY be treated as
+   a connection error of type PROTOCOL_VIOLATION.
+
+   Note that Stateless Reset packets do not have any cryptographic
+   protection.
+
+10.4.3.  Looping
+
+   The design of a Stateless Reset is such that without knowing the
+   stateless reset token it is indistinguishable from a valid packet.
+   For instance, if a server sends a Stateless Reset to another server
+   it might receive another Stateless Reset in response, which could
+   lead to an infinite exchange.
+
+   An endpoint MUST ensure that every Stateless Reset that it sends is
+   smaller than the packet which triggered it, unless it maintains state
+   sufficient to prevent looping.  In the event of a loop, this results
+   in packets eventually being too small to trigger a response.
+
+   An endpoint can remember the number of Stateless Reset packets that
+   it has sent and stop generating new Stateless Reset packets once a
+   limit is reached.  Using separate limits for different remote
+   addresses will ensure that Stateless Reset packets can be used to
+   close connections when other peers or connections have exhausted
+   limits.
+
+   Reducing the size of a Stateless Reset below 41 bytes means that the
+   packet could reveal to an observer that it is a Stateless Reset,
+   depending upon the length of the peer's connection IDs.  Conversely,
+   refusing to send a Stateless Reset in response to a small packet
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 73]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   might result in Stateless Reset not being useful in detecting cases
+   of broken connections where only very small packets are sent; such
+   failures might only be detected by other means, such as timers.
+
+11.  Error Handling
+
+   An endpoint that detects an error SHOULD signal the existence of that
+   error to its peer.  Both transport-level and application-level errors
+   can affect an entire connection; see Section 11.1.  Only application-
+   level errors can be isolated to a single stream; see Section 11.2.
+
+   The most appropriate error code (Section 20) SHOULD be included in
+   the frame that signals the error.  Where this specification
+   identifies error conditions, it also identifies the error code that
+   is used; though these are worded as requirements, different
+   implementation strategies might lead to different errors being
+   reported.  In particular, an endpoint MAY use any applicable error
+   code when it detects an error condition; a generic error code (such
+   as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place
+   of specific error codes.
+
+   A stateless reset (Section 10.4) is not suitable for any error that
+   can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame.  A
+   stateless reset MUST NOT be used by an endpoint that has the state
+   necessary to send a frame on the connection.
+
+11.1.  Connection Errors
+
+   Errors that result in the connection being unusable, such as an
+   obvious violation of protocol semantics or corruption of state that
+   affects an entire connection, MUST be signaled using a
+   CONNECTION_CLOSE frame (Section 19.19).  An endpoint MAY close the
+   connection in this manner even if the error only affects a single
+   stream.
+
+   Application protocols can signal application-specific protocol errors
+   using the application-specific variant of the CONNECTION_CLOSE frame.
+   Errors that are specific to the transport, including all those
+   described in this document, are carried in the QUIC-specific variant
+   of the CONNECTION_CLOSE frame.
+
+   A CONNECTION_CLOSE frame could be sent in a packet that is lost.  An
+   endpoint SHOULD be prepared to retransmit a packet containing a
+   CONNECTION_CLOSE frame if it receives more packets on a terminated
+   connection.  Limiting the number of retransmissions and the time over
+   which this final packet is sent limits the effort expended on
+   terminated connections.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 74]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   An endpoint that chooses not to retransmit packets containing a
+   CONNECTION_CLOSE frame risks a peer missing the first such packet.
+   The only mechanism available to an endpoint that continues to receive
+   data for a terminated connection is to use the stateless reset
+   process (Section 10.4).
+
+11.2.  Stream Errors
+
+   If an application-level error affects a single stream, but otherwise
+   leaves the connection in a recoverable state, the endpoint can send a
+   RESET_STREAM frame (Section 19.4) with an appropriate error code to
+   terminate just the affected stream.
+
+   Resetting a stream without the involvement of the application
+   protocol could cause the application protocol to enter an
+   unrecoverable state.  RESET_STREAM MUST only be instigated by the
+   application protocol that uses QUIC.
+
+   The semantics of the application error code carried in RESET_STREAM
+   are defined by the application protocol.  Only the application
+   protocol is able to cause a stream to be terminated.  A local
+   instance of the application protocol uses a direct API call and a
+   remote instance uses the STOP_SENDING frame, which triggers an
+   automatic RESET_STREAM.
+
+   Application protocols SHOULD define rules for handling streams that
+   are prematurely cancelled by either endpoint.
+
+12.  Packets and Frames
+
+   QUIC endpoints communicate by exchanging packets.  Packets have
+   confidentiality and integrity protection; see Section 12.1.  Packets
+   are carried in UDP datagrams; see Section 12.2.
+
+   This version of QUIC uses the long packet header during connection
+   establishment; see Section 17.2.  Packets with the long header are
+   Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake
+   (Section 17.2.4), and Retry (Section 17.2.5).  Version negotiation
+   uses a version-independent packet with a long header; see
+   Section 17.2.1.
+
+   Packets with the short header are designed for minimal overhead and
+   are used after a connection is established and 1-RTT keys are
+   available; see Section 17.3.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 75]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+12.1.  Protected Packets
+
+   All QUIC packets except Version Negotiation packets use authenticated
+   encryption with additional data (AEAD) [RFC5116] to provide
+   confidentiality and integrity protection.  Retry packets use AEAD to
+   provide integrity protection.  Details of packet protection are found
+   in [QUIC-TLS]; this section includes an overview of the process.
+
+   Initial packets are protected using keys that are statically derived.
+   This packet protection is not effective confidentiality protection.
+   Initial protection only exists to ensure that the sender of the
+   packet is on the network path.  Any entity that receives the Initial
+   packet from a client can recover the keys necessary to remove packet
+   protection or to generate packets that will be successfully
+   authenticated.
+
+   All other packets are protected with keys derived from the
+   cryptographic handshake.  The type of the packet from the long header
+   or key phase from the short header are used to identify which
+   encryption keys are used.  Packets protected with 0-RTT and 1-RTT
+   keys are expected to have confidentiality and data origin
+   authentication; the cryptographic handshake ensures that only the
+   communicating endpoints receive the corresponding keys.
+
+   The packet number field contains a packet number, which has
+   additional confidentiality protection that is applied after packet
+   protection is applied; see [QUIC-TLS] for details.  The underlying
+   packet number increases with each packet sent in a given packet
+   number space; see Section 12.3 for details.
+
+12.2.  Coalescing Packets
+
+   Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake
+   (Section 17.2.4) packets contain a Length field, which determines the
+   end of the packet.  The length includes both the Packet Number and
+   Payload fields, both of which are confidentiality protected and
+   initially of unknown length.  The length of the Payload field is
+   learned once header protection is removed.
+
+   Using the Length field, a sender can coalesce multiple QUIC packets
+   into one UDP datagram.  This can reduce the number of UDP datagrams
+   needed to complete the cryptographic handshake and start sending
+   data.  This can also be used to construct PMTU probes; see
+   Section 14.3.1.  Receivers MUST be able to process coalesced packets.
+
+   Coalescing packets in order of increasing encryption levels (Initial,
+   0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it
+   more likely the receiver will be able to process all the packets in a
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 76]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   single pass.  A packet with a short header does not include a length,
+   so it can only be the last packet included in a UDP datagram.  An
+   endpoint SHOULD NOT coalesce multiple packets at the same encryption
+   level.
+
+   Senders MUST NOT coalesce QUIC packets for different connections into
+   a single UDP datagram.  Receivers SHOULD ignore any subsequent
+   packets with a different Destination Connection ID than the first
+   packet in the datagram.
+
+   Every QUIC packet that is coalesced into a single UDP datagram is
+   separate and complete.  The receiver of coalesced QUIC packets MUST
+   individually process each QUIC packet and separately acknowledge
+   them, as if they were received as the payload of different UDP
+   datagrams.  For example, if decryption fails (because the keys are
+   not available or any other reason), the receiver MAY either discard
+   or buffer the packet for later processing and MUST attempt to process
+   the remaining packets.
+
+   Retry packets (Section 17.2.5), Version Negotiation packets
+   (Section 17.2.1), and packets with a short header (Section 17.3) do
+   not contain a Length field and so cannot be followed by other packets
+   in the same UDP datagram.  Note also that there is no situation where
+   a Retry or Version Negotiation packet is coalesced with another
+   packet.
+
+12.3.  Packet Numbers
+
+   The packet number is an integer in the range 0 to 2^62-1.  This
+   number is used in determining the cryptographic nonce for packet
+   protection.  Each endpoint maintains a separate packet number for
+   sending and receiving.
+
+   Packet numbers are limited to this range because they need to be
+   representable in whole in the Largest Acknowledged field of an ACK
+   frame (Section 19.3).  When present in a long or short header
+   however, packet numbers are reduced and encoded in 1 to 4 bytes; see
+   Section 17.1.
+
+   Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5)
+   packets do not include a packet number.
+
+   Packet numbers are divided into 3 spaces in QUIC:
+
+   *  Initial space: All Initial packets (Section 17.2.2) are in this
+      space.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 77]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Handshake space: All Handshake packets (Section 17.2.4) are in
+      this space.
+
+   *  Application data space: All 0-RTT and 1-RTT encrypted packets
+      (Section 12.1) are in this space.
+
+   As described in [QUIC-TLS], each packet type uses different
+   protection keys.
+
+   Conceptually, a packet number space is the context in which a packet
+   can be processed and acknowledged.  Initial packets can only be sent
+   with Initial packet protection keys and acknowledged in packets which
+   are also Initial packets.  Similarly, Handshake packets are sent at
+   the Handshake encryption level and can only be acknowledged in
+   Handshake packets.
+
+   This enforces cryptographic separation between the data sent in the
+   different packet sequence number spaces.  Packet numbers in each
+   space start at packet number 0.  Subsequent packets sent in the same
+   packet number space MUST increase the packet number by at least one.
+
+   0-RTT and 1-RTT data exist in the same packet number space to make
+   loss recovery algorithms easier to implement between the two packet
+   types.
+
+   A QUIC endpoint MUST NOT reuse a packet number within the same packet
+   number space in one connection.  If the packet number for sending
+   reaches 2^62 - 1, the sender MUST close the connection without
+   sending a CONNECTION_CLOSE frame or any further packets; an endpoint
+   MAY send a Stateless Reset (Section 10.4) in response to further
+   packets that it receives.
+
+   A receiver MUST discard a newly unprotected packet unless it is
+   certain that it has not processed another packet with the same packet
+   number from the same packet number space.  Duplicate suppression MUST
+   happen after removing packet protection for the reasons described in
+   Section 9.3 of [QUIC-TLS].
+
+   Endpoints that track all individual packets for the purposes of
+   detecting duplicates are at risk of accumulating excessive state.
+   The data required for detecting duplicates can be limited by
+   maintaining a minimum packet number below which all packets are
+   immediately dropped.  Any minimum needs to account for large
+   variations in round trip time, which includes the possibility that a
+   peer might probe network paths with a much larger round trip times;
+   see Section 9.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 78]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Packet number encoding at a sender and decoding at a receiver are
+   described in Section 17.1.
+
+12.4.  Frames and Frame Types
+
+   The payload of QUIC packets, after removing packet protection,
+   consists of a sequence of complete frames, as shown in Figure 10.
+   Version Negotiation, Stateless Reset, and Retry packets do not
+   contain frames.
+
+   Packet Payload {
+     Frame (..) ...,
+   }
+
+                          Figure 10: QUIC Payload
+
+   The payload of a packet that contains frames MUST contain at least
+   one frame, and MAY contain multiple frames and multiple frame types.
+   Frames always fit within a single QUIC packet and cannot span
+   multiple packets.
+
+   Each frame begins with a Frame Type, indicating its type, followed by
+   additional type-dependent fields:
+
+   Frame {
+     Frame Type (i),
+     Type-Dependent Fields (..),
+   }
+
+                      Figure 11: Generic Frame Layout
+
+   The frame types defined in this specification are listed in Table 3.
+   The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and
+   CONNECTION_CLOSE frames is used to carry other frame-specific flags.
+   For all other frames, the Frame Type field simply identifies the
+   frame.  These frames are explained in more detail in Section 19.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 79]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+     +-------------+----------------------+---------------+---------+
+     | Type Value  | Frame Type Name      | Definition    | Packets |
+     +=============+======================+===============+=========+
+     | 0x00        | PADDING              | Section 19.1  | IH01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x01        | PING                 | Section 19.2  | IH01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x02 - 0x03 | ACK                  | Section 19.3  | IH_1    |
+     +-------------+----------------------+---------------+---------+
+     | 0x04        | RESET_STREAM         | Section 19.4  | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x05        | STOP_SENDING         | Section 19.5  | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x06        | CRYPTO               | Section 19.6  | IH_1    |
+     +-------------+----------------------+---------------+---------+
+     | 0x07        | NEW_TOKEN            | Section 19.7  | ___1    |
+     +-------------+----------------------+---------------+---------+
+     | 0x08 - 0x0f | STREAM               | Section 19.8  | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x10        | MAX_DATA             | Section 19.9  | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x11        | MAX_STREAM_DATA      | Section 19.10 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x12 - 0x13 | MAX_STREAMS          | Section 19.11 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x14        | DATA_BLOCKED         | Section 19.12 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x15        | STREAM_DATA_BLOCKED  | Section 19.13 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x16 - 0x17 | STREAMS_BLOCKED      | Section 19.14 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x18        | NEW_CONNECTION_ID    | Section 19.15 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x19        | RETIRE_CONNECTION_ID | Section 19.16 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x1a        | PATH_CHALLENGE       | Section 19.17 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x1b        | PATH_RESPONSE        | Section 19.18 | __01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x1c - 0x1d | CONNECTION_CLOSE     | Section 19.19 | ih01    |
+     +-------------+----------------------+---------------+---------+
+     | 0x1e        | HANDSHAKE_DONE       | Section 19.20 | ___1    |
+     +-------------+----------------------+---------------+---------+
+
+                           Table 3: Frame Types
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 80]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The "Packets" column in Table 3 does not form part of the IANA
+   registry; see Section 22.3.  This column lists the types of packets
+   that each frame type could appear in, indicated by the following
+   characters:
+
+   I:  Initial (Section 17.2.2)
+
+   H:  Handshake (Section 17.2.4)
+
+   0:  0-RTT (Section 17.2.3)
+
+   1:  1-RTT (Section 17.3)
+
+   ih:  A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial
+      or Handshake packets.
+
+   Section 4 of [QUIC-TLS] provides more detail about these
+   restrictions.  Note that all frames can appear in 1-RTT packets.
+
+   An endpoint MUST treat the receipt of a frame of unknown type as a
+   connection error of type FRAME_ENCODING_ERROR.
+
+   All QUIC frames are idempotent in this version of QUIC.  That is, a
+   valid frame does not cause undesirable side effects or errors when
+   received more than once.
+
+   The Frame Type field uses a variable length integer encoding (see
+   Section 16) with one exception.  To ensure simple and efficient
+   implementations of frame parsing, a frame type MUST use the shortest
+   possible encoding.  For frame types defined in this document, this
+   means a single-byte encoding, even though it is possible to encode
+   these values as a two-, four- or eight-byte variable length integer.
+   For instance, though 0x4001 is a legitimate two-byte encoding for a
+   variable-length integer with a value of 1, PING frames are always
+   encoded as a single byte with the value 0x01.  This rule applies to
+   all current and future QUIC frame types.  An endpoint MAY treat the
+   receipt of a frame type that uses a longer encoding than necessary as
+   a connection error of type PROTOCOL_VIOLATION.
+
+13.  Packetization and Reliability
+
+   A sender bundles one or more frames in a QUIC packet; see
+   Section 12.4.
+
+   A sender can minimize per-packet bandwidth and computational costs by
+   bundling as many frames as possible within a QUIC packet.  A sender
+   MAY wait for a short period of time to bundle multiple frames before
+   sending a packet that is not maximally packed, to avoid sending out
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 81]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   large numbers of small packets.  An implementation MAY use knowledge
+   about application sending behavior or heuristics to determine whether
+   and for how long to wait.  This waiting period is an implementation
+   decision, and an implementation should be careful to delay
+   conservatively, since any delay is likely to increase application-
+   visible latency.
+
+   Stream multiplexing is achieved by interleaving STREAM frames from
+   multiple streams into one or more QUIC packets.  A single QUIC packet
+   can include multiple STREAM frames from one or more streams.
+
+   One of the benefits of QUIC is avoidance of head-of-line blocking
+   across multiple streams.  When a packet loss occurs, only streams
+   with data in that packet are blocked waiting for a retransmission to
+   be received, while other streams can continue making progress.  Note
+   that when data from multiple streams is bundled into a single QUIC
+   packet, loss of that packet blocks all those streams from making
+   progress.  Implementations are advised to bundle as few streams as
+   necessary in outgoing packets without losing transmission efficiency
+   to underfilled packets.
+
+13.1.  Packet Processing
+
+   A packet MUST NOT be acknowledged until packet protection has been
+   successfully removed and all frames contained in the packet have been
+   processed.  For STREAM frames, this means the data has been enqueued
+   in preparation to be received by the application protocol, but it
+   does not require that data is delivered and consumed.
+
+   Once the packet has been fully processed, a receiver acknowledges
+   receipt by sending one or more ACK frames containing the packet
+   number of the received packet.
+
+   An endpoint SHOULD treat receipt of an acknowledgment for a packet it
+   did not send as a connection error of type PROTOCOL_VIOLATION, if it
+   is able to detect the condition.
+
+13.2.  Generating Acknowledgements
+
+   Endpoints acknowledge all packets they receive and process.  However,
+   only ack-eliciting packets cause an ACK frame to be sent within the
+   maximum ack delay.  Packets that are not ack-eliciting are only
+   acknowledged when an ACK frame is sent for other reasons.
+
+   When sending a packet for any reason, an endpoint SHOULD attempt to
+   bundle an ACK frame if one has not been sent recently.  Doing so
+   helps with timely loss detection at the peer.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 82]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   In general, frequent feedback from a receiver improves loss and
+   congestion response, but this has to be balanced against excessive
+   load generated by a receiver that sends an ACK frame in response to
+   every ack-eliciting packet.  The guidance offered below seeks to
+   strike this balance.
+
+13.2.1.  Sending ACK Frames
+
+   Every packet SHOULD be acknowledged at least once, and ack-eliciting
+   packets MUST be acknowledged at least once within the maximum ack
+   delay.  An endpoint communicates its maximum delay using the
+   max_ack_delay transport parameter; see Section 18.2.  max_ack_delay
+   declares an explicit contract: an endpoint promises to never
+   intentionally delay acknowledgments of an ack-eliciting packet by
+   more than the indicated value.  If it does, any excess accrues to the
+   RTT estimate and could result in spurious or delayed retransmissions
+   from the peer.  For Initial and Handshake packets, a max_ack_delay of
+   0 is used.  The sender uses the receiver's max_ack_delay value in
+   determining timeouts for timer-based retransmission, as detailed in
+   Section 5.2.1 of [QUIC-RECOVERY].
+
+   Since packets containing only ACK frames are not congestion
+   controlled, an endpoint MUST NOT send more than one such packet in
+   response to receiving an ack-eliciting packet.
+
+   An endpoint MUST NOT send a non-ack-eliciting packet in response to a
+   non-ack-eliciting packet, even if there are packet gaps which precede
+   the received packet.  This avoids an infinite feedback loop of
+   acknowledgements, which could prevent the connection from ever
+   becoming idle.  Non-ack-eliciting packets are eventually acknowledged
+   when the endpoint sends an ACK frame in response to other events.
+
+   In order to assist loss detection at the sender, an endpoint SHOULD
+   send an ACK frame immediately on receiving an ack-eliciting packet
+   that is out of order.  The endpoint SHOULD NOT continue sending ACK
+   frames immediately unless more ack-eliciting packets are received out
+   of order.  If every subsequent ack-eliciting packet arrives out of
+   order, then an ACK frame SHOULD be sent immediately for every
+   received ack-eliciting packet.
+
+   Similarly, packets marked with the ECN Congestion Experienced (CE)
+   codepoint in the IP header SHOULD be acknowledged immediately, to
+   reduce the peer's response time to congestion events.
+
+   The algorithms in [QUIC-RECOVERY] are expected to be resilient to
+   receivers that do not follow guidance offered above.  However, an
+   implementer should only deviate from these requirements after careful
+   consideration of the performance implications of doing so.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 83]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   An endpoint that is only sending ACK frames will not receive
+   acknowledgments from its peer unless those acknowledgements are
+   included in packets with ack-eliciting frames.  An endpoint SHOULD
+   bundle ACK frames with other frames when there are new ack-eliciting
+   packets to acknowledge.  When only non-ack-eliciting packets need to
+   be acknowledged, an endpoint MAY wait until an ack-eliciting packet
+   has been received to bundle an ACK frame with outgoing frames.
+
+13.2.2.  Acknowledgement Frequency
+
+   A receiver determines how frequently to send acknowledgements in
+   response to ack-eliciting packets.  This determination involves a
+   tradeoff.
+
+   Endpoints rely on timely acknowledgment to detect loss; see Section 5
+   of [QUIC-RECOVERY].  Window-based congestion controllers, such as the
+   one in Section 6 of [QUIC-RECOVERY], rely on acknowledgments to
+   manage their congestion window.  In both cases, delaying
+   acknowledgments can adversely affect performance.
+
+   On the other hand, reducing the frequency of packets that carry only
+   acknowledgements reduces packet transmission and processing cost at
+   both endpoints.  It can also improve connection throughput on
+   severely asymmetric links; see Section 3 of [RFC3449].
+
+   A receiver SHOULD send an ACK frame after receiving at least two ack-
+   eliciting packets.  This recommendation is general in nature and
+   consistent with recommendations for TCP endpoint behavior [RFC5681].
+   Knowledge of network conditions, knowledge of the peer's congestion
+   controller, or further research and experimentation might suggest
+   alternative acknowledgment strategies with better performance
+   characteristics.
+
+   A receiver MAY process multiple available packets before determining
+   whether to send an ACK frame in response.
+
+13.2.3.  Managing ACK Ranges
+
+   When an ACK frame is sent, one or more ranges of acknowledged packets
+   are included.  Including older packets reduces the chance of spurious
+   retransmits caused by losing previously sent ACK frames, at the cost
+   of larger ACK frames.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 84]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   ACK frames SHOULD always acknowledge the most recently received
+   packets, and the more out-of-order the packets are, the more
+   important it is to send an updated ACK frame quickly, to prevent the
+   peer from declaring a packet as lost and spuriously retransmitting
+   the frames it contains.  An ACK frame is expected to fit within a
+   single QUIC packet.  If it does not, then older ranges (those with
+   the smallest packet numbers) are omitted.
+
+   Section 13.2.4 and Section 13.2.5 describe an exemplary approach for
+   determining what packets to acknowledge in each ACK frame.  Though
+   the goal of these algorithms is to generate an acknowledgment for
+   every packet that is processed, it is still possible for
+   acknowledgments to be lost.  A sender cannot expect to receive an
+   acknowledgment for every packet that the receiver processes.
+
+13.2.4.  Receiver Tracking of ACK Frames
+
+   When a packet containing an ACK frame is sent, the largest
+   acknowledged in that frame may be saved.  When a packet containing an
+   ACK frame is acknowledged, the receiver can stop acknowledging
+   packets less than or equal to the largest acknowledged in the sent
+   ACK frame.
+
+   In cases without ACK frame loss, this algorithm allows for a minimum
+   of 1 RTT of reordering.  In cases with ACK frame loss and reordering,
+   this approach does not guarantee that every acknowledgement is seen
+   by the sender before it is no longer included in the ACK frame.
+   Packets could be received out of order and all subsequent ACK frames
+   containing them could be lost.  In this case, the loss recovery
+   algorithm could cause spurious retransmits, but the sender will
+   continue making forward progress.
+
+13.2.5.  Limiting ACK Ranges
+
+   A receiver limits the number of ACK Ranges (Section 19.3.1) it
+   remembers and sends in ACK frames, both to limit the size of ACK
+   frames and to avoid resource exhaustion.  After receiving
+   acknowledgments for an ACK frame, the receiver SHOULD stop tracking
+   those acknowledged ACK Ranges.
+
+   It is possible that retaining many ACK Ranges could cause an ACK
+   frame to become too large.  A receiver can discard unacknowledged ACK
+   Ranges to limit ACK frame size, at the cost of increased
+   retransmissions from the sender.  This is necessary if an ACK frame
+   would be too large to fit in a packet, however receivers MAY also
+   limit ACK frame size further to preserve space for other frames.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 85]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   A receiver MUST retain an ACK Range unless it can ensure that it will
+   not subsequently accept packets with numbers in that range.
+   Maintaining a minimum packet number that increases as ranges are
+   discarded is one way to achieve this with minimal state.
+
+   Receivers can discard all ACK Ranges, but they MUST retain the
+   largest packet number that has been successfully processed as that is
+   used to recover packet numbers from subsequent packets; see
+   Section 17.1.
+
+   A receiver SHOULD include an ACK Range containing the largest
+   received packet number in every ACK frame.  The Largest Acknowledged
+   field is used in ECN validation at a sender and including a lower
+   value than what was included in a previous ACK frame could cause ECN
+   to be unnecessarily disabled; see Section 13.4.2.
+
+   A receiver that sends only non-ack-eliciting packets, such as ACK
+   frames, might not receive an acknowledgement for a long period of
+   time.  This could cause the receiver to maintain state for a large
+   number of ACK frames for a long period of time, and ACK frames it
+   sends could be unnecessarily large.  In such a case, a receiver could
+   bundle a PING or other small ack-eliciting frame occasionally, such
+   as once per round trip, to elicit an ACK from the peer.
+
+   A receiver MUST NOT bundle an ack-eliciting frame with all packets
+   that would otherwise be non-ack-eliciting, to avoid an infinite
+   feedback loop of acknowledgements.
+
+13.2.6.  Measuring and Reporting Host Delay
+
+   An endpoint measures the delays intentionally introduced between the
+   time the packet with the largest packet number is received and the
+   time an acknowledgment is sent.  The endpoint encodes this delay in
+   the Ack Delay field of an ACK frame; see Section 19.3.  This allows
+   the receiver of the ACK to adjust for any intentional delays, which
+   is important for getting a better estimate of the path RTT when
+   acknowledgments are delayed.  A packet might be held in the OS kernel
+   or elsewhere on the host before being processed.  An endpoint MUST
+   NOT include delays that it does not control when populating the Ack
+   Delay field in an ACK frame.
+
+13.2.7.  ACK Frames and Packet Protection
+
+   ACK frames MUST only be carried in a packet that has the same packet
+   number space as the packet being ACKed; see Section 12.1.  For
+   instance, packets that are protected with 1-RTT keys MUST be
+   acknowledged in packets that are also protected with 1-RTT keys.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 86]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Packets that a client sends with 0-RTT packet protection MUST be
+   acknowledged by the server in packets protected by 1-RTT keys.  This
+   can mean that the client is unable to use these acknowledgments if
+   the server cryptographic handshake messages are delayed or lost.
+   Note that the same limitation applies to other data sent by the
+   server protected by the 1-RTT keys.
+
+13.2.8.  PADDING Frames Consume Congestion Window
+
+   Packets containing PADDING frames are considered to be in flight for
+   congestion control purposes [QUIC-RECOVERY].  Packets containing only
+   PADDING frames therefore consume congestion window but do not
+   generate acknowledgments that will open the congestion window.  To
+   avoid a deadlock, a sender SHOULD ensure that other frames are sent
+   periodically in addition to PADDING frames to elicit acknowledgments
+   from the receiver.
+
+13.3.  Retransmission of Information
+
+   QUIC packets that are determined to be lost are not retransmitted
+   whole.  The same applies to the frames that are contained within lost
+   packets.  Instead, the information that might be carried in frames is
+   sent again in new frames as needed.
+
+   New frames and packets are used to carry information that is
+   determined to have been lost.  In general, information is sent again
+   when a packet containing that information is determined to be lost
+   and sending ceases when a packet containing that information is
+   acknowledged.
+
+   *  Data sent in CRYPTO frames is retransmitted according to the rules
+      in [QUIC-RECOVERY], until all data has been acknowledged.  Data in
+      CRYPTO frames for Initial and Handshake packets is discarded when
+      keys for the corresponding packet number space are discarded.
+
+   *  Application data sent in STREAM frames is retransmitted in new
+      STREAM frames unless the endpoint has sent a RESET_STREAM for that
+      stream.  Once an endpoint sends a RESET_STREAM frame, no further
+      STREAM frames are needed.
+
+   *  ACK frames carry the most recent set of acknowledgements and the
+      Ack Delay from the largest acknowledged packet, as described in
+      Section 13.2.1.  Delaying the transmission of packets containing
+      ACK frames or sending old ACK frames can cause the peer to
+      generate an inflated RTT sample or unnecessarily disable ECN.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 87]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Cancellation of stream transmission, as carried in a RESET_STREAM
+      frame, is sent until acknowledged or until all stream data is
+      acknowledged by the peer (that is, either the "Reset Recvd" or
+      "Data Recvd" state is reached on the sending part of the stream).
+      The content of a RESET_STREAM frame MUST NOT change when it is
+      sent again.
+
+   *  Similarly, a request to cancel stream transmission, as encoded in
+      a STOP_SENDING frame, is sent until the receiving part of the
+      stream enters either a "Data Recvd" or "Reset Recvd" state; see
+      Section 3.5.
+
+   *  Connection close signals, including packets that contain
+      CONNECTION_CLOSE frames, are not sent again when packet loss is
+      detected, but as described in Section 10.
+
+   *  The current connection maximum data is sent in MAX_DATA frames.
+      An updated value is sent in a MAX_DATA frame if the packet
+      containing the most recently sent MAX_DATA frame is declared lost,
+      or when the endpoint decides to update the limit.  Care is
+      necessary to avoid sending this frame too often as the limit can
+      increase frequently and cause an unnecessarily large number of
+      MAX_DATA frames to be sent.
+
+   *  The current maximum stream data offset is sent in MAX_STREAM_DATA
+      frames.  Like MAX_DATA, an updated value is sent when the packet
+      containing the most recent MAX_STREAM_DATA frame for a stream is
+      lost or when the limit is updated, with care taken to prevent the
+      frame from being sent too often.  An endpoint SHOULD stop sending
+      MAX_STREAM_DATA frames when the receiving part of the stream
+      enters a "Size Known" state.
+
+   *  The limit on streams of a given type is sent in MAX_STREAMS
+      frames.  Like MAX_DATA, an updated value is sent when a packet
+      containing the most recent MAX_STREAMS for a stream type frame is
+      declared lost or when the limit is updated, with care taken to
+      prevent the frame from being sent too often.
+
+   *  Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED,
+      and STREAMS_BLOCKED frames.  DATA_BLOCKED frames have connection
+      scope, STREAM_DATA_BLOCKED frames have stream scope, and
+      STREAMS_BLOCKED frames are scoped to a specific stream type.  New
+      frames are sent if packets containing the most recent frame for a
+      scope is lost, but only while the endpoint is blocked on the
+      corresponding limit.  These frames always include the limit that
+      is causing blocking at the time that they are transmitted.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 88]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  A liveness or path validation check using PATH_CHALLENGE frames is
+      sent periodically until a matching PATH_RESPONSE frame is received
+      or until there is no remaining need for liveness or path
+      validation checking.  PATH_CHALLENGE frames include a different
+      payload each time they are sent.
+
+   *  Responses to path validation using PATH_RESPONSE frames are sent
+      just once.  The peer is expected to send more PATH_CHALLENGE
+      frames as necessary to evoke additional PATH_RESPONSE frames.
+
+   *  New connection IDs are sent in NEW_CONNECTION_ID frames and
+      retransmitted if the packet containing them is lost.
+      Retransmissions of this frame carry the same sequence number
+      value.  Likewise, retired connection IDs are sent in
+      RETIRE_CONNECTION_ID frames and retransmitted if the packet
+      containing them is lost.
+
+   *  NEW_TOKEN frames are retransmitted if the packet containing them
+      is lost.  No special support is made for detecting reordered and
+      duplicated NEW_TOKEN frames other than a direct comparison of the
+      frame contents.
+
+   *  PING and PADDING frames contain no information, so lost PING or
+      PADDING frames do not require repair.
+
+   *  The HANDSHAKE_DONE frame MUST be retransmitted until it is
+      acknowledged.
+
+   Endpoints SHOULD prioritize retransmission of data over sending new
+   data, unless priorities specified by the application indicate
+   otherwise; see Section 2.3.
+
+   Even though a sender is encouraged to assemble frames containing up-
+   to-date information every time it sends a packet, it is not forbidden
+   to retransmit copies of frames from lost packets.  A sender that
+   retransmits copies of frames needs to handle decreases in available
+   payload size due to change in packet number length, connection ID
+   length, and path MTU.  A receiver MUST accept packets containing an
+   outdated frame, such as a MAX_DATA frame carrying a smaller maximum
+   data than one found in an older packet.
+
+   Upon detecting losses, a sender MUST take appropriate congestion
+   control action.  The details of loss detection and congestion control
+   are described in [QUIC-RECOVERY].
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 89]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+13.4.  Explicit Congestion Notification
+
+   QUIC endpoints can use Explicit Congestion Notification (ECN)
+   [RFC3168] to detect and respond to network congestion.  ECN allows a
+   network node to indicate congestion in the network by setting a
+   codepoint in the IP header of a packet instead of dropping it.
+   Endpoints react to congestion by reducing their sending rate in
+   response, as described in [QUIC-RECOVERY].
+
+   To use ECN, QUIC endpoints first determine whether a path supports
+   ECN marking and the peer is able to access the ECN codepoint in the
+   IP header.  A network path does not support ECN if ECN marked packets
+   get dropped or ECN markings are rewritten on the path.  An endpoint
+   validates the use of ECN on the path, both during connection
+   establishment and when migrating to a new path (Section 9).
+
+13.4.1.  ECN Counts
+
+   On receiving a QUIC packet with an ECT or CE codepoint, an ECN-
+   enabled endpoint that can access the ECN codepoints from the
+   enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
+   count, and includes these counts in subsequent ACK frames; see
+   Section 13.2 and Section 19.3.  Note that this requires being able to
+   read the ECN codepoints from the enclosing IP packet, which is not
+   possible on all platforms.
+
+   A packet detected by a receiver as a duplicate does not affect the
+   receiver's local ECN codepoint counts; see (Section 21.8) for
+   relevant security concerns.
+
+   If an endpoint receives a QUIC packet without an ECT or CE codepoint
+   in the IP packet header, it responds per Section 13.2 with an ACK
+   frame without increasing any ECN counts.  If an endpoint does not
+   implement ECN support or does not have access to received ECN
+   codepoints, it does not increase ECN counts.
+
+   Coalesced packets (see Section 12.2) mean that several packets can
+   share the same IP header.  The ECN counter for the ECN codepoint
+   received in the associated IP header are incremented once for each
+   QUIC packet, not per enclosing IP packet or UDP datagram.
+
+   Each packet number space maintains separate acknowledgement state and
+   separate ECN counts.  For example, if one each of an Initial, 0-RTT,
+   Handshake, and 1-RTT QUIC packet are coalesced, the corresponding
+   counts for the Initial and Handshake packet number space will be
+   incremented by one and the counts for the 1-RTT packet number space
+   will be increased by two.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 90]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+13.4.2.  ECN Validation
+
+   It is possible for faulty network devices to corrupt or erroneously
+   drop packets with ECN markings.  To provide robust connectivity in
+   the presence of such devices, each endpoint independently validates
+   ECN counts and disables ECN if errors are detected.
+
+   Endpoints validate ECN for packets sent on each network path
+   independently.  An endpoint thus validates ECN on new connection
+   establishment, when switching to a new server preferred address, and
+   on active connection migration to a new path.  Appendix B describes
+   one possible algorithm for testing paths for ECN support.
+
+   Even if an endpoint does not use ECN markings on packets it
+   transmits, the endpoint MUST provide feedback about ECN markings
+   received from the peer if they are accessible.  Failing to report ECN
+   counts will cause the peer to disable ECN marking.
+
+13.4.2.1.  Sending ECN Markings
+
+   To start ECN validation, an endpoint SHOULD do the following when
+   sending packets on a new path to a peer:
+
+   *  Set the ECT(0) codepoint in the IP header of early outgoing
+      packets sent on a new path to the peer [RFC8311].
+
+   *  If all packets that were sent with the ECT(0) codepoint are
+      eventually deemed lost [QUIC-RECOVERY], validation is deemed to
+      have failed.
+
+   To reduce the chances of misinterpreting congestive loss as packets
+   dropped by a faulty network element, an endpoint could set the ECT(0)
+   codepoint in the first ten outgoing packets on a path, or for a
+   period of three RTTs, whichever occurs first.
+
+   Implementations MAY experiment with and use other strategies for use
+   of ECN.  Other methods of probing paths for ECN support are possible,
+   as are different marking strategies.  Implementations can also use
+   the ECT(1) codepoint, as specified in [RFC8311].
+
+13.4.2.2.  Receiving ACK Frames
+
+   An endpoint that sets ECT(0) or ECT(1) codepoints on packets it
+   transmits MUST use the following steps on receiving an ACK frame to
+   validate ECN.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 91]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  If this ACK frame newly acknowledges a packet that the endpoint
+      sent with either ECT(0) or ECT(1) codepoints set, and if no ECN
+      feedback is present in the ACK frame, validation fails.  This step
+      protects against both a network element that zeroes out ECN bits
+      and a peer that is unable to access ECN markings, since the peer
+      could respond without ECN feedback in these cases.
+
+   *  For validation to succeed, the total increase in ECT(0), ECT(1),
+      and CE counts MUST be no smaller than the total number of QUIC
+      packets sent with an ECT codepoint that are newly acknowledged in
+      this ACK frame.  This step detects any network remarking from
+      ECT(0), ECT(1), or CE codepoints to Not-ECT.
+
+   *  Any increase in either ECT(0) or ECT(1) counts, plus any increase
+      in the CE count, MUST be no smaller than the number of packets
+      sent with the corresponding ECT codepoint that are newly
+      acknowledged in this ACK frame.  This step detects any erroneous
+      network remarking from ECT(0) to ECT(1) (or vice versa).
+
+   Processing ECN counts out of order can result in validation failure.
+   An endpoint SHOULD NOT perform this validation if this ACK frame does
+   not advance the largest packet number acknowledged in this
+   connection.
+
+   An endpoint could miss acknowledgements for a packet when ACK frames
+   are lost.  It is therefore possible for the total increase in ECT(0),
+   ECT(1), and CE counts to be greater than the number of packets
+   acknowledged in an ACK frame.  When this happens, and if validation
+   succeeds, the local reference counts MUST be increased to match the
+   counts in the ACK frame.
+
+13.4.2.3.  Validation Outcomes
+
+   If validation fails, then the endpoint stops sending ECN markings in
+   subsequent IP packets with the expectation that either the network
+   path or the peer does not support ECN.
+
+   Upon successful validation, an endpoint can continue to set ECT
+   codepoints in subsequent packets with the expectation that the path
+   is ECN-capable.  Network routing and path elements can change mid-
+   connection however; an endpoint MUST disable ECN if validation fails
+   at any point in the connection.
+
+   Even if validation fails, an endpoint MAY revalidate ECN on the same
+   path at any later time in the connection.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 92]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+14.  Packet Size
+
+   The QUIC packet size includes the QUIC header and protected payload,
+   but not the UDP or IP header.
+
+   A client MUST expand the payload of all UDP datagrams carrying
+   Initial packets to at least 1200 bytes, by adding PADDING frames to
+   the Initial packet or by coalescing the Initial packet; see
+   Section 12.2.  Sending a UDP datagram of this size ensures that the
+   network path from the client to the server supports a reasonable
+   Maximum Transmission Unit (MTU).  Padding datagrams also helps reduce
+   the amplitude of amplification attacks caused by server responses
+   toward an unverified client address; see Section 8.
+
+   Enforcement of the max_udp_payload_size transport parameter
+   (Section 18.2) might act as an additional limit on packet size.
+   Exceeding this limit can be avoided once the value is known.
+   However, prior to learning the value of the transport parameter,
+   endpoints risk datagrams being lost if they send packets larger than
+   1200 bytes.
+
+   Datagrams containing Initial packets MAY exceed 1200 bytes if the
+   client believes that the network path and peer both support the size
+   that it chooses.
+
+   UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4
+   [IPv4], the DF bit MUST be set to prevent fragmentation on the path.
+
+   A server MUST discard an Initial packet that is carried in a UDP
+   datagram with a payload that is less than 1200 bytes.  A server MAY
+   also immediately close the connection by sending a CONNECTION_CLOSE
+   frame with an error code of PROTOCOL_VIOLATION; see Section 10.3.1.
+
+   The server MUST also limit the number of bytes it sends before
+   validating the address of the client; see Section 8.
+
+14.1.  Path Maximum Transmission Unit (PMTU)
+
+   The Path Maximum Transmission Unit (PMTU) is the maximum size of the
+   entire IP packet including the IP header, UDP header, and UDP
+   payload.  The UDP payload includes the QUIC packet header, protected
+   payload, and any authentication fields.  The PMTU can depend on path
+   characteristics, and can therefore change over time.  The largest UDP
+   payload an endpoint sends at any given time is referred to as the
+   endpoint's maximum packet size.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 93]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   QUIC depends on a PMTU of at least 1280 bytes.  This is the IPv6
+   minimum size [RFC8200] and is also supported by most modern IPv4
+   networks.  All QUIC packets (except for PMTU probe packets) SHOULD be
+   sized to fit within the maximum packet size to avoid the packet being
+   fragmented or dropped [RFC8085].
+
+   An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery
+   ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191]
+   [RFC8201] to determine whether the path to a destination will support
+   a desired message size without fragmentation.
+
+   In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP
+   packets larger than 1280 bytes.  Assuming the minimum IP header size,
+   this results in a QUIC maximum packet size of 1232 bytes for IPv6 and
+   1252 bytes for IPv4.  A QUIC implementation MAY be more conservative
+   in computing the QUIC maximum packet size to allow for unknown tunnel
+   overheads or IP header options/extensions.
+
+   Each pair of local and remote addresses could have a different PMTU.
+   QUIC implementations that implement any kind of PMTU discovery
+   therefore SHOULD maintain a maximum packet size for each combination
+   of local and remote IP addresses.
+
+   If a QUIC endpoint determines that the PMTU between any pair of local
+   and remote IP addresses has fallen below the size needed to support
+   the smallest allowed maximum packet size, it MUST immediately cease
+   sending QUIC packets, except for PMTU probe packets, on the affected
+   path.  An endpoint MAY terminate the connection if an alternative
+   path cannot be found.
+
+14.2.  ICMP Packet Too Big Messages
+
+   PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP
+   messages (e.g., IPv6 Packet Too Big messages) that indicate when a
+   packet is dropped because it is larger than the local router MTU.
+   DPLPMTUD can also optionally use these messages.  This use of ICMP
+   messages is potentially vulnerable to off-path attacks that
+   successfully guess the addresses used on the path and reduce the PMTU
+   to a bandwidth-inefficient value.
+
+   An endpoint MUST ignore an ICMP message that claims the PMTU has
+   decreased below 1280 bytes.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 94]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The requirements for generating ICMP ([RFC1812], [RFC4443]) state
+   that the quoted packet should contain as much of the original packet
+   as possible without exceeding the minimum MTU for the IP version.
+   The size of the quoted packet can actually be smaller, or the
+   information unintelligible, as described in Section 1.1 of
+   [DPLPMTUD].
+
+   QUIC endpoints SHOULD validate ICMP messages to protect from off-path
+   injection as specified in [RFC8201] and Section 5.2 of [RFC8085].
+   This validation SHOULD use the quoted packet supplied in the payload
+   of an ICMP message to associate the message with a corresponding
+   transport connection [DPLPMTUD].
+
+   ICMP message validation MUST include matching IP addresses and UDP
+   ports [RFC8085] and, when possible, connection IDs to an active QUIC
+   session.
+
+   The endpoint SHOULD ignore all ICMP messages that fail validation.
+
+   An endpoint MUST NOT increase PMTU based on ICMP messages; see
+   Section 3, clause 6 of [DPLPMTUD].  Any reduction in the QUIC maximum
+   packet size in response to ICMP messages MAY be provisional until
+   QUIC's loss detection algorithm determines that the quoted packet has
+   actually been lost.
+
+14.3.  Datagram Packetization Layer PMTU Discovery
+
+   Section 6.3 of [DPLPMTUD] provides considerations for implementing
+   Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC.
+
+   When implementing the algorithm in Section 5 of [DPLPMTUD], the
+   initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC
+   packet size (1232 bytes for IPv6 and 1252 bytes for IPv4).
+
+   PING and PADDING frames can be used to generate PMTU probe packets.
+   These frames might not be retransmitted if a probe packet containing
+   them is lost.  However, these frames do consume congestion window,
+   which could delay the transmission of subsequent application data.
+
+   A PING frame can be included in a PMTU probe to ensure that a valid
+   probe is acknowledged.
+
+   The considerations for processing ICMP messages in the previous
+   section also apply if these messages are used by DPLPMTUD.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 95]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+14.3.1.  PMTU Probes Containing Source Connection ID
+
+   Endpoints that rely on the destination connection ID for routing
+   incoming QUIC packets are likely to require that the connection ID be
+   included in PMTU probe packets to route any resulting ICMP messages
+   (Section 14.2) back to the correct endpoint.  However, only long
+   header packets (Section 17.2) contain source connection IDs, and long
+   header packets are not decrypted or acknowledged by the peer once the
+   handshake is complete.
+
+   One way to construct a probe for the path MTU is to coalesce (see
+   Section 12.2) a Handshake packet (Section 17.2.4) with a short header
+   packet in a single UDP datagram.  If the UDP datagram reaches the
+   endpoint, the Handshake packet will be ignored, but the short header
+   packet will be acknowledged.  If the UDP datagram causes an ICMP
+   message to be sent, the first part of the datagram will be quoted in
+   that message.  If the source connection ID is within the quoted
+   portion of the UDP datagram, that could be used for routing.
+
+15.  Versions
+
+   QUIC versions are identified using a 32-bit unsigned number.
+
+   The version 0x00000000 is reserved to represent version negotiation.
+   This version of the specification is identified by the number
+   0x00000001.
+
+   Other versions of QUIC might have different properties to this
+   version.  The properties of QUIC that are guaranteed to be consistent
+   across all versions of the protocol are described in
+   [QUIC-INVARIANTS].
+
+   Version 0x00000001 of QUIC uses TLS as a cryptographic handshake
+   protocol, as described in [QUIC-TLS].
+
+   Versions with the most significant 16 bits of the version number
+   cleared are reserved for use in future IETF consensus documents.
+
+   Versions that follow the pattern 0x?a?a?a?a are reserved for use in
+   forcing version negotiation to be exercised.  That is, any version
+   number where the low four bits of all bytes is 1010 (in binary).  A
+   client or server MAY advertise support for any of these reserved
+   versions.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 96]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Reserved version numbers will never represent a real protocol; a
+   client MAY use one of these version numbers with the expectation that
+   the server will initiate version negotiation; a server MAY advertise
+   support for one of these versions and can expect that clients ignore
+   the value.
+
+   [[RFC editor: please remove the remainder of this section before
+   publication.]]
+
+   The version number for the final version of this specification
+   (0x00000001), is reserved for the version of the protocol that is
+   published as an RFC.
+
+   Version numbers used to identify IETF drafts are created by adding
+   the draft number to 0xff000000.  For example, draft-ietf-quic-
+   transport-13 would be identified as 0xff00000D.
+
+   Implementors are encouraged to register version numbers of QUIC that
+   they are using for private experimentation on the GitHub wiki at
+   https://github.com/quicwg/base-drafts/wiki/QUIC-Versions.
+
+16.  Variable-Length Integer Encoding
+
+   QUIC packets and frames commonly use a variable-length encoding for
+   non-negative integer values.  This encoding ensures that smaller
+   integer values need fewer bytes to encode.
+
+   The QUIC variable-length integer encoding reserves the two most
+   significant bits of the first byte to encode the base 2 logarithm of
+   the integer encoding length in bytes.  The integer value is encoded
+   on the remaining bits, in network byte order.
+
+   This means that integers are encoded on 1, 2, 4, or 8 bytes and can
+   encode 6, 14, 30, or 62 bit values respectively.  Table 4 summarizes
+   the encoding properties.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 97]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+          +------+--------+-------------+-----------------------+
+          | 2Bit | Length | Usable Bits | Range                 |
+          +======+========+=============+=======================+
+          | 00   | 1      | 6           | 0-63                  |
+          +------+--------+-------------+-----------------------+
+          | 01   | 2      | 14          | 0-16383               |
+          +------+--------+-------------+-----------------------+
+          | 10   | 4      | 30          | 0-1073741823          |
+          +------+--------+-------------+-----------------------+
+          | 11   | 8      | 62          | 0-4611686018427387903 |
+          +------+--------+-------------+-----------------------+
+
+                   Table 4: Summary of Integer Encodings
+
+   For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in
+   hexadecimal) decodes to the decimal value 151288809941952652; the
+   four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte
+   sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37
+   (as does the two byte sequence 40 25).
+
+   Error codes (Section 20) and versions (Section 15) are described
+   using integers, but do not use this encoding.
+
+17.  Packet Formats
+
+   All numeric values are encoded in network byte order (that is, big-
+   endian) and all field sizes are in bits.  Hexadecimal notation is
+   used for describing the value of fields.
+
+17.1.  Packet Number Encoding and Decoding
+
+   Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3).
+   When present in long or short packet headers, they are encoded in 1
+   to 4 bytes.  The number of bits required to represent the packet
+   number is reduced by including the least significant bits of the
+   packet number.
+
+   The encoded packet number is protected as described in Section 5.4 of
+   [QUIC-TLS].
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 98]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The sender MUST use a packet number size able to represent more than
+   twice as large a range than the difference between the largest
+   acknowledged packet and packet number being sent.  A peer receiving
+   the packet will then correctly decode the packet number, unless the
+   packet is delayed in transit such that it arrives after many higher-
+   numbered packets have been received.  An endpoint SHOULD use a large
+   enough packet number encoding to allow the packet number to be
+   recovered even if the packet arrives after packets that are sent
+   afterwards.
+
+   As a result, the size of the packet number encoding is at least one
+   bit more than the base-2 logarithm of the number of contiguous
+   unacknowledged packet numbers, including the new packet.
+
+   For example, if an endpoint has received an acknowledgment for packet
+   0xabe8bc, sending a packet with a number of 0xac5c02 requires a
+   packet number encoding with 16 bits or more; whereas the 24-bit
+   packet number encoding is needed to send a packet with a number of
+   0xace8fe.
+
+   At a receiver, protection of the packet number is removed prior to
+   recovering the full packet number.  The full packet number is then
+   reconstructed based on the number of significant bits present, the
+   value of those bits, and the largest packet number received on a
+   successfully authenticated packet.  Recovering the full packet number
+   is necessary to successfully remove packet protection.
+
+   Once header protection is removed, the packet number is decoded by
+   finding the packet number value that is closest to the next expected
+   packet.  The next expected packet is the highest received packet
+   number plus one.  For example, if the highest successfully
+   authenticated packet had a packet number of 0xa82f30ea, then a packet
+   containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32.
+   Example pseudo-code for packet number decoding can be found in
+   Appendix A.
+
+17.2.  Long Header Packets
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020               [Page 99]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Long Header Packet {
+     Header Form (1) = 1,
+     Fixed Bit (1) = 1,
+     Long Packet Type (2),
+     Type-Specific Bits (4),
+     Version (32),
+     DCID Length (8),
+     Destination Connection ID (0..160),
+     SCID Length (8),
+     Source Connection ID (0..160),
+   }
+
+                    Figure 12: Long Header Packet Format
+
+   Long headers are used for packets that are sent prior to the
+   establishment of 1-RTT keys.  Once 1-RTT keys are available, a sender
+   switches to sending packets using the short header (Section 17.3).
+   The long form allows for special packets - such as the Version
+   Negotiation packet - to be represented in this uniform fixed-length
+   packet format.  Packets that use the long header contain the
+   following fields:
+
+   Header Form:  The most significant bit (0x80) of byte 0 (the first
+      byte) is set to 1 for long headers.
+
+   Fixed Bit:  The next bit (0x40) of byte 0 is set to 1.  Packets
+      containing a zero value for this bit are not valid packets in this
+      version and MUST be discarded.
+
+   Long Packet Type:  The next two bits (those with a mask of 0x30) of
+      byte 0 contain a packet type.  Packet types are listed in Table 5.
+
+   Type-Specific Bits:  The lower four bits (those with a mask of 0x0f)
+      of byte 0 are type-specific.
+
+   Version:  The QUIC Version is a 32-bit field that follows the first
+      byte.  This field indicates which version of QUIC is in use and
+      determines how the rest of the protocol fields are interpreted.
+
+   DCID Length:  The byte following the version contains the length in
+      bytes of the Destination Connection ID field that follows it.
+      This length is encoded as an 8-bit unsigned integer.  In QUIC
+      version 1, this value MUST NOT exceed 20.  Endpoints that receive
+      a version 1 long header with a value larger than 20 MUST drop the
+      packet.  Servers SHOULD be able to read longer connection IDs from
+      other QUIC versions in order to properly form a version
+      negotiation packet.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 100]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Destination Connection ID:  The Destination Connection ID field
+      follows the DCID Length field and is between 0 and 20 bytes in
+      length.  Section 7.2 describes the use of this field in more
+      detail.
+
+   SCID Length:  The byte following the Destination Connection ID
+      contains the length in bytes of the Source Connection ID field
+      that follows it.  This length is encoded as a 8-bit unsigned
+      integer.  In QUIC version 1, this value MUST NOT exceed 20 bytes.
+      Endpoints that receive a version 1 long header with a value larger
+      than 20 MUST drop the packet.  Servers SHOULD be able to read
+      longer connection IDs from other QUIC versions in order to
+      properly form a version negotiation packet.
+
+   Source Connection ID:  The Source Connection ID field follows the
+      SCID Length field and is between 0 and 20 bytes in length.
+      Section 7.2 describes the use of this field in more detail.
+
+   In this version of QUIC, the following packet types with the long
+   header are defined:
+
+                   +------+-----------+----------------+
+                   | Type | Name      | Section        |
+                   +======+===========+================+
+                   |  0x0 | Initial   | Section 17.2.2 |
+                   +------+-----------+----------------+
+                   |  0x1 | 0-RTT     | Section 17.2.3 |
+                   +------+-----------+----------------+
+                   |  0x2 | Handshake | Section 17.2.4 |
+                   +------+-----------+----------------+
+                   |  0x3 | Retry     | Section 17.2.5 |
+                   +------+-----------+----------------+
+
+                     Table 5: Long Header Packet Types
+
+   The header form bit, connection ID lengths byte, Destination and
+   Source Connection ID fields, and Version fields of a long header
+   packet are version-independent.  The other fields in the first byte
+   are version-specific.  See [QUIC-INVARIANTS] for details on how
+   packets from different versions of QUIC are interpreted.
+
+   The interpretation of the fields and the payload are specific to a
+   version and packet type.  While type-specific semantics for this
+   version are described in the following sections, several long-header
+   packets in this version of QUIC contain these additional fields:
+
+   Reserved Bits:  Two bits (those with a mask of 0x0c) of byte 0 are
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 101]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      reserved across multiple packet types.  These bits are protected
+      using header protection; see Section 5.4 of [QUIC-TLS].  The value
+      included prior to protection MUST be set to 0.  An endpoint MUST
+      treat receipt of a packet that has a non-zero value for these
+      bits, after removing both packet and header protection, as a
+      connection error of type PROTOCOL_VIOLATION.  Discarding such a
+      packet after only removing header protection can expose the
+      endpoint to attacks; see Section 9.3 of [QUIC-TLS].
+
+   Packet Number Length:  In packet types which contain a Packet Number
+      field, the least significant two bits (those with a mask of 0x03)
+      of byte 0 contain the length of the packet number, encoded as an
+      unsigned, two-bit integer that is one less than the length of the
+      packet number field in bytes.  That is, the length of the packet
+      number field is the value of this field, plus one.  These bits are
+      protected using header protection; see Section 5.4 of [QUIC-TLS].
+
+   Length:  The length of the remainder of the packet (that is, the
+      Packet Number and Payload fields) in bytes, encoded as a variable-
+      length integer (Section 16).
+
+   Packet Number:  The packet number field is 1 to 4 bytes long.  The
+      packet number has confidentiality protection separate from packet
+      protection, as described in Section 5.4 of [QUIC-TLS].  The length
+      of the packet number field is encoded in the Packet Number Length
+      bits of byte 0; see above.
+
+17.2.1.  Version Negotiation Packet
+
+   A Version Negotiation packet is inherently not version-specific.
+   Upon receipt by a client, it will be identified as a Version
+   Negotiation packet based on the Version field having a value of 0.
+
+   The Version Negotiation packet is a response to a client packet that
+   contains a version that is not supported by the server, and is only
+   sent by servers.
+
+   The layout of a Version Negotiation packet is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 102]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Version Negotiation Packet {
+     Header Form (1) = 1,
+     Unused (7),
+     Version (32) = 0,
+     DCID Length (8),
+     Destination Connection ID (0..2040),
+     SCID Length (8),
+     Source Connection ID (0..2040),
+     Supported Version (32) ...,
+   }
+
+                   Figure 13: Version Negotiation Packet
+
+   The value in the Unused field is selected randomly by the server.
+   Clients MUST ignore the value of this field.  Servers SHOULD set the
+   most significant bit of this field (0x40) to 1 so that Version
+   Negotiation packets appear to have the Fixed Bit field.
+
+   The Version field of a Version Negotiation packet MUST be set to
+   0x00000000.
+
+   The server MUST include the value from the Source Connection ID field
+   of the packet it receives in the Destination Connection ID field.
+   The value for Source Connection ID MUST be copied from the
+   Destination Connection ID of the received packet, which is initially
+   randomly selected by a client.  Echoing both connection IDs gives
+   clients some assurance that the server received the packet and that
+   the Version Negotiation packet was not generated by an off-path
+   attacker.
+
+   As future versions of QUIC may support Connection IDs larger than the
+   version 1 limit, Version Negotiation packets could carry Connection
+   IDs that are longer than 20 bytes.
+
+   The remainder of the Version Negotiation packet is a list of 32-bit
+   versions which the server supports.
+
+   A Version Negotiation packet cannot be explicitly acknowledged in an
+   ACK frame by a client.  Receiving another Initial packet implicitly
+   acknowledges a Version Negotiation packet.
+
+   The Version Negotiation packet does not include the Packet Number and
+   Length fields present in other packets that use the long header form.
+   Consequently, a Version Negotiation packet consumes an entire UDP
+   datagram.
+
+   A server MUST NOT send more than one Version Negotiation packet in
+   response to a single UDP datagram.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 103]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   See Section 6 for a description of the version negotiation process.
+
+17.2.2.  Initial Packet
+
+   An Initial packet uses long headers with a type value of 0x0.  It
+   carries the first CRYPTO frames sent by the client and server to
+   perform key exchange, and carries ACKs in either direction.
+
+   Initial Packet {
+     Header Form (1) = 1,
+     Fixed Bit (1) = 1,
+     Long Packet Type (2) = 0,
+     Reserved Bits (2),
+     Packet Number Length (2),
+     Version (32),
+     DCID Length (8),
+     Destination Connection ID (0..160),
+     SCID Length (8),
+     Source Connection ID (0..160),
+     Token Length (i),
+     Token (..),
+     Length (i),
+     Packet Number (8..32),
+     Packet Payload (..),
+   }
+
+                         Figure 14: Initial Packet
+
+   The Initial packet contains a long header as well as the Length and
+   Packet Number fields.  The first byte contains the Reserved and
+   Packet Number Length bits.  Between the SCID and Length fields, there
+   are two additional fields specific to the Initial packet.
+
+   Token Length:  A variable-length integer specifying the length of the
+      Token field, in bytes.  This value is zero if no token is present.
+      Initial packets sent by the server MUST set the Token Length field
+      to zero; clients that receive an Initial packet with a non-zero
+      Token Length field MUST either discard the packet or generate a
+      connection error of type PROTOCOL_VIOLATION.
+
+   Token:  The value of the token that was previously provided in a
+      Retry packet or NEW_TOKEN frame.
+
+   Packet Payload:  The payload of the packet.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 104]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   In order to prevent tampering by version-unaware middleboxes, Initial
+   packets are protected with connection- and version-specific keys
+   (Initial keys) as described in [QUIC-TLS].  This protection does not
+   provide confidentiality or integrity against on-path attackers, but
+   provides some level of protection against off-path attackers.
+
+   The client and server use the Initial packet type for any packet that
+   contains an initial cryptographic handshake message.  This includes
+   all cases where a new packet containing the initial cryptographic
+   message needs to be created, such as the packets sent after receiving
+   a Retry packet (Section 17.2.5).
+
+   A server sends its first Initial packet in response to a client
+   Initial.  A server may send multiple Initial packets.  The
+   cryptographic key exchange could require multiple round trips or
+   retransmissions of this data.
+
+   The payload of an Initial packet includes a CRYPTO frame (or frames)
+   containing a cryptographic handshake message, ACK frames, or both.
+   PING, PADDING, and CONNECTION_CLOSE frames are also permitted.  An
+   endpoint that receives an Initial packet containing other frames can
+   either discard the packet as spurious or treat it as a connection
+   error.
+
+   The first packet sent by a client always includes a CRYPTO frame that
+   contains the start or all of the first cryptographic handshake
+   message.  The first CRYPTO frame sent always begins at an offset of
+   0; see Section 7.
+
+   Note that if the server sends a HelloRetryRequest, the client will
+   send another series of Initial packets.  These Initial packets will
+   continue the cryptographic handshake and will contain CRYPTO frames
+   starting at an offset matching the size of the CRYPTO frames sent in
+   the first flight of Initial packets.
+
+17.2.2.1.  Abandoning Initial Packets
+
+   A client stops both sending and processing Initial packets when it
+   sends its first Handshake packet.  A server stops sending and
+   processing Initial packets when it receives its first Handshake
+   packet.  Though packets might still be in flight or awaiting
+   acknowledgment, no further Initial packets need to be exchanged
+   beyond this point.  Initial packet protection keys are discarded (see
+   Section 4.11.1 of [QUIC-TLS]) along with any loss recovery and
+   congestion control state; see Section 6.5 of [QUIC-RECOVERY].
+
+   Any data in CRYPTO frames is discarded - and no longer retransmitted
+   - when Initial keys are discarded.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 105]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+17.2.3.  0-RTT
+
+   A 0-RTT packet uses long headers with a type value of 0x1, followed
+   by the Length and Packet Number fields.  The first byte contains the
+   Reserved and Packet Number Length bits.  It is used to carry "early"
+   data from the client to the server as part of the first flight, prior
+   to handshake completion.  As part of the TLS handshake, the server
+   can accept or reject this early data.
+
+   See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its
+   limitations.
+
+   0-RTT Packet {
+     Header Form (1) = 1,
+     Fixed Bit (1) = 1,
+     Long Packet Type (2) = 1,
+     Reserved Bits (2),
+     Packet Number Length (2),
+     Version (32),
+     DCID Length (8),
+     Destination Connection ID (0..160),
+     SCID Length (8),
+     Source Connection ID (0..160),
+     Length (i),
+     Packet Number (8..32),
+     Packet Payload (..),
+   }
+
+                          Figure 15: 0-RTT Packet
+
+   Packet numbers for 0-RTT protected packets use the same space as
+   1-RTT protected packets.
+
+   After a client receives a Retry packet, 0-RTT packets are likely to
+   have been lost or discarded by the server.  A client SHOULD attempt
+   to resend data in 0-RTT packets after it sends a new Initial packet.
+
+   A client MUST NOT reset the packet number it uses for 0-RTT packets,
+   since the keys used to protect 0-RTT packets will not change as a
+   result of responding to a Retry packet.  Sending packets with the
+   same packet number in that case is likely to compromise the packet
+   protection for all 0-RTT packets because the same key and nonce could
+   be used to protect different content.
+
+   A client only receives acknowledgments for its 0-RTT packets once the
+   handshake is complete.  Consequently, a server might expect 0-RTT
+   packets to start with a packet number of 0.  Therefore, in
+   determining the length of the packet number encoding for 0-RTT
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 106]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   packets, a client MUST assume that all packets up to the current
+   packet number are in flight, starting from a packet number of 0.
+   Thus, 0-RTT packets could need to use a longer packet number
+   encoding.
+
+   A client MUST NOT send 0-RTT packets once it starts processing 1-RTT
+   packets from the server.  This means that 0-RTT packets cannot
+   contain any response to frames from 1-RTT packets.  For instance, a
+   client cannot send an ACK frame in a 0-RTT packet, because that can
+   only acknowledge a 1-RTT packet.  An acknowledgment for a 1-RTT
+   packet MUST be carried in a 1-RTT packet.
+
+   A server SHOULD treat a violation of remembered limits as a
+   connection error of an appropriate type (for instance, a
+   FLOW_CONTROL_ERROR for exceeding stream data limits).
+
+17.2.4.  Handshake Packet
+
+   A Handshake packet uses long headers with a type value of 0x2,
+   followed by the Length and Packet Number fields.  The first byte
+   contains the Reserved and Packet Number Length bits.  It is used to
+   carry acknowledgments and cryptographic handshake messages from the
+   server and client.
+
+   Handshake Packet {
+     Header Form (1) = 1,
+     Fixed Bit (1) = 1,
+     Long Packet Type (2) = 2,
+     Reserved Bits (2),
+     Packet Number Length (2),
+     Version (32),
+     DCID Length (8),
+     Destination Connection ID (0..160),
+     SCID Length (8),
+     Source Connection ID (0..160),
+     Length (i),
+     Packet Number (8..32),
+     Packet Payload (..),
+   }
+
+                   Figure 16: Handshake Protected Packet
+
+   Once a client has received a Handshake packet from a server, it uses
+   Handshake packets to send subsequent cryptographic handshake messages
+   and acknowledgments to the server.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 107]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The Destination Connection ID field in a Handshake packet contains a
+   connection ID that is chosen by the recipient of the packet; the
+   Source Connection ID includes the connection ID that the sender of
+   the packet wishes to use; see Section 7.2.
+
+   Handshake packets are their own packet number space, and thus the
+   first Handshake packet sent by a server contains a packet number of
+   0.
+
+   The payload of this packet contains CRYPTO frames and could contain
+   PING, PADDING, or ACK frames.  Handshake packets MAY contain
+   CONNECTION_CLOSE frames.  Endpoints MUST treat receipt of Handshake
+   packets with other frames as a connection error.
+
+   Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames
+   for Handshake packets is discarded - and no longer retransmitted -
+   when Handshake protection keys are discarded.
+
+17.2.5.  Retry Packet
+
+   A Retry packet uses a long packet header with a type value of 0x3.
+   It carries an address validation token created by the server.  It is
+   used by a server that wishes to perform a retry; see Section 8.1.
+
+   Retry Packet {
+     Header Form (1) = 1,
+     Fixed Bit (1) = 1,
+     Long Packet Type (2) = 3,
+     Unused (4),
+     Version (32),
+     DCID Length (8),
+     Destination Connection ID (0..160),
+     SCID Length (8),
+     Source Connection ID (0..160),
+     Retry Token (..),
+     Retry Integrity Tag (128),
+   }
+
+                          Figure 17: Retry Packet
+
+   A Retry packet (shown in Figure 17) does not contain any protected
+   fields.  The value in the Unused field is selected randomly by the
+   server.  In addition to the fields from the long header, it contains
+   these additional fields:
+
+   Retry Token:  An opaque token that the server can use to validate the
+      client's address.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 108]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Retry Integrity Tag:  See the Retry Packet Integrity section of
+      [QUIC-TLS].
+
+17.2.5.1.  Sending a Retry Packet
+
+   The server populates the Destination Connection ID with the
+   connection ID that the client included in the Source Connection ID of
+   the Initial packet.
+
+   The server includes a connection ID of its choice in the Source
+   Connection ID field.  This value MUST NOT be equal to the Destination
+   Connection ID field of the packet sent by the client.  A client MUST
+   discard a Retry packet that contains a Source Connection ID field
+   that is identical to the Destination Connection ID field of its
+   Initial packet.  The client MUST use the value from the Source
+   Connection ID field of the Retry packet in the Destination Connection
+   ID field of subsequent packets that it sends.
+
+   A server MAY send Retry packets in response to Initial and 0-RTT
+   packets.  A server can either discard or buffer 0-RTT packets that it
+   receives.  A server can send multiple Retry packets as it receives
+   Initial or 0-RTT packets.  A server MUST NOT send more than one Retry
+   packet in response to a single UDP datagram.
+
+17.2.5.2.  Handling a Retry Packet
+
+   A client MUST accept and process at most one Retry packet for each
+   connection attempt.  After the client has received and processed an
+   Initial or Retry packet from the server, it MUST discard any
+   subsequent Retry packets that it receives.
+
+   Clients MUST discard Retry packets that have a Retry Integrity Tag
+   that cannot be validated, see the Retry Packet Integrity section of
+   [QUIC-TLS].  This diminishes an off-path attacker's ability to inject
+   a Retry packet and protects against accidental corruption of Retry
+   packets.  A client MUST discard a Retry packet with a zero-length
+   Retry Token field.
+
+   The client responds to a Retry packet with an Initial packet that
+   includes the provided Retry Token to continue connection
+   establishment.
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 109]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   A client sets the Destination Connection ID field of this Initial
+   packet to the value from the Source Connection ID in the Retry
+   packet.  Changing Destination Connection ID also results in a change
+   to the keys used to protect the Initial packet.  It also sets the
+   Token field to the token provided in the Retry.  The client MUST NOT
+   change the Source Connection ID because the server could include the
+   connection ID as part of its token validation logic; see
+   Section 8.1.4.
+
+   A Retry packet does not include a packet number and cannot be
+   explicitly acknowledged by a client.
+
+17.2.5.3.  Continuing a Handshake After Retry
+
+   The next Initial packet from the client uses the connection ID and
+   token values from the Retry packet; see Section 7.2.  Aside from
+   this, the Initial packet sent by the client is subject to the same
+   restrictions as the first Initial packet.  A client MUST use the same
+   cryptographic handshake message it includes in this packet.  A server
+   MAY treat a packet that contains a different cryptographic handshake
+   message as a connection error or discard it.
+
+   A client MAY attempt 0-RTT after receiving a Retry packet by sending
+   0-RTT packets to the connection ID provided by the server.  A client
+   MUST NOT change the cryptographic handshake message it sends in
+   response to receiving a Retry.
+
+   A client MUST NOT reset the packet number for any packet number space
+   after processing a Retry packet; Section 17.2.3 contains more
+   information on this.
+
+   A server acknowledges the use of a Retry packet for a connection
+   using the retry_source_connection_id transport parameter; see
+   Section 18.2.  If the server sends a Retry packet, it also
+   subsequently includes the value of the Source Connection ID field
+   from the Retry packet in its retry_source_connection_id transport
+   parameter.
+
+   If the client received and processed a Retry packet, it MUST validate
+   that the retry_source_connection_id transport parameter is present
+   and correct; otherwise, it MUST validate that the transport parameter
+   is absent.  A client MUST treat a failed validation as a connection
+   error of type PROTOCOL_VIOLATION.
+
+17.3.  Short Header Packets
+
+   This version of QUIC defines a single packet type which uses the
+   short packet header.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 110]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Short Header Packet {
+     Header Form (1) = 0,
+     Fixed Bit (1) = 1,
+     Spin Bit (1),
+     Reserved Bits (2),
+     Key Phase (1),
+     Packet Number Length (2),
+     Destination Connection ID (0..160),
+     Packet Number (8..32),
+     Packet Payload (..),
+   }
+
+                   Figure 18: Short Header Packet Format
+
+   The short header can be used after the version and 1-RTT keys are
+   negotiated.  Packets that use the short header contain the following
+   fields:
+
+   Header Form:  The most significant bit (0x80) of byte 0 is set to 0
+      for the short header.
+
+   Fixed Bit:  The next bit (0x40) of byte 0 is set to 1.  Packets
+      containing a zero value for this bit are not valid packets in this
+      version and MUST be discarded.
+
+   Spin Bit:  The third most significant bit (0x20) of byte 0 is the
+      latency spin bit, set as described in Section 17.3.1.
+
+   Reserved Bits:  The next two bits (those with a mask of 0x18) of byte
+      0 are reserved.  These bits are protected using header protection;
+      see Section 5.4 of [QUIC-TLS].  The value included prior to
+      protection MUST be set to 0.  An endpoint MUST treat receipt of a
+      packet that has a non-zero value for these bits, after removing
+      both packet and header protection, as a connection error of type
+      PROTOCOL_VIOLATION.  Discarding such a packet after only removing
+      header protection can expose the endpoint to attacks; see
+      Section 9.3 of [QUIC-TLS].
+
+   Key Phase:  The next bit (0x04) of byte 0 indicates the key phase,
+      which allows a recipient of a packet to identify the packet
+      protection keys that are used to protect the packet.  See
+      [QUIC-TLS] for details.  This bit is protected using header
+      protection; see Section 5.4 of [QUIC-TLS].
+
+   Packet Number Length:  The least significant two bits (those with a
+      mask of 0x03) of byte 0 contain the length of the packet number,
+      encoded as an unsigned, two-bit integer that is one less than the
+      length of the packet number field in bytes.  That is, the length
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 111]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      of the packet number field is the value of this field, plus one.
+      These bits are protected using header protection; see Section 5.4
+      of [QUIC-TLS].
+
+   Destination Connection ID:  The Destination Connection ID is a
+      connection ID that is chosen by the intended recipient of the
+      packet.  See Section 5.1 for more details.
+
+   Packet Number:  The packet number field is 1 to 4 bytes long.  The
+      packet number has confidentiality protection separate from packet
+      protection, as described in Section 5.4 of [QUIC-TLS].  The length
+      of the packet number field is encoded in Packet Number Length
+      field.  See Section 17.1 for details.
+
+   Packet Payload:  Packets with a short header always include a 1-RTT
+      protected payload.
+
+   The header form bit and the connection ID field of a short header
+   packet are version-independent.  The remaining fields are specific to
+   the selected QUIC version.  See [QUIC-INVARIANTS] for details on how
+   packets from different versions of QUIC are interpreted.
+
+17.3.1.  Latency Spin Bit
+
+   The latency spin bit enables passive latency monitoring from
+   observation points on the network path throughout the duration of a
+   connection.  The spin bit is only present in the short packet header,
+   since it is possible to measure the initial RTT of a connection by
+   observing the handshake.  Therefore, the spin bit is available after
+   version negotiation and connection establishment are completed.  On-
+   path measurement and use of the latency spin bit is further discussed
+   in [QUIC-MANAGEABILITY].
+
+   The spin bit is an OPTIONAL feature of QUIC.  A QUIC stack that
+   chooses to support the spin bit MUST implement it as specified in
+   this section.
+
+   Each endpoint unilaterally decides if the spin bit is enabled or
+   disabled for a connection.  Implementations MUST allow administrators
+   of clients and servers to disable the spin bit either globally or on
+   a per-connection basis.  Even when the spin bit is not disabled by
+   the administrator, endpoints MUST disable their use of the spin bit
+   for a random selection of at least one in every 16 network paths, or
+   for one in every 16 connection IDs.  As each endpoint disables the
+   spin bit independently, this ensures that the spin bit signal is
+   disabled on approximately one in eight network paths.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 112]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   When the spin bit is disabled, endpoints MAY set the spin bit to any
+   value, and MUST ignore any incoming value.  It is RECOMMENDED that
+   endpoints set the spin bit to a random value either chosen
+   independently for each packet or chosen independently for each
+   connection ID.
+
+   If the spin bit is enabled for the connection, the endpoint maintains
+   a spin value and sets the spin bit in the short header to the
+   currently stored value when a packet with a short header is sent out.
+   The spin value is initialized to 0 in the endpoint at connection
+   start.  Each endpoint also remembers the highest packet number seen
+   from its peer on the connection.
+
+   When a server receives a short header packet that increments the
+   highest packet number seen by the server from the client, it sets the
+   spin value to be equal to the spin bit in the received packet.
+
+   When a client receives a short header packet that increments the
+   highest packet number seen by the client from the server, it sets the
+   spin value to the inverse of the spin bit in the received packet.
+
+   An endpoint resets its spin value to zero when sending the first
+   packet of a given connection with a new connection ID.  This reduces
+   the risk that transient spin bit state can be used to link flows
+   across connection migration or ID change.
+
+   With this mechanism, the server reflects the spin value received,
+   while the client 'spins' it after one RTT.  On-path observers can
+   measure the time between two spin bit toggle events to estimate the
+   end-to-end RTT of a connection.
+
+18.  Transport Parameter Encoding
+
+   The extension_data field of the quic_transport_parameters extension
+   defined in [QUIC-TLS] contains the QUIC transport parameters.  They
+   are encoded as a sequence of transport parameters, as shown in
+   Figure 19:
+
+   Transport Parameters {
+     Transport Parameter (..) ...,
+   }
+
+                Figure 19: Sequence of Transport Parameters
+
+   Each transport parameter is encoded as an (identifier, length, value)
+   tuple, as shown in Figure 20:
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 113]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Transport Parameter {
+     Transport Parameter ID (i),
+     Transport Parameter Length (i),
+     Transport Parameter Value (..),
+   }
+
+                  Figure 20: Transport Parameter Encoding
+
+   The Transport Parameter Length field contains the length of the
+   Transport Parameter Value field.
+
+   QUIC encodes transport parameters into a sequence of bytes, which are
+   then included in the cryptographic handshake.
+
+18.1.  Reserved Transport Parameters
+
+   Transport parameters with an identifier of the form "31 * N + 27" for
+   integer values of N are reserved to exercise the requirement that
+   unknown transport parameters be ignored.  These transport parameters
+   have no semantics, and may carry arbitrary values.
+
+18.2.  Transport Parameter Definitions
+
+   This section details the transport parameters defined in this
+   document.
+
+   Many transport parameters listed here have integer values.  Those
+   transport parameters that are identified as integers use a variable-
+   length integer encoding; see Section 16.  Transport parameters have a
+   default value of 0 if the transport parameter is absent unless
+   otherwise stated.
+
+   The following transport parameters are defined:
+
+   original_destination_connection_id (0x00):  The value of the
+      Destination Connection ID field from the first Initial packet sent
+      by the client; see Section 7.3.  This transport parameter is only
+      sent by a server.
+
+   max_idle_timeout (0x01):  The max idle timeout is a value in
+      milliseconds that is encoded as an integer; see (Section 10.2).
+      Idle timeout is disabled when both endpoints omit this transport
+      parameter or specify a value of 0.
+
+   stateless_reset_token (0x02):  A stateless reset token is used in
+      verifying a stateless reset; see Section 10.4.  This parameter is
+      a sequence of 16 bytes.  This transport parameter MUST NOT be sent
+      by a client, but MAY be sent by a server.  A server that does not
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 114]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      send this transport parameter cannot use stateless reset
+      (Section 10.4) for the connection ID negotiated during the
+      handshake.
+
+   max_udp_payload_size (0x03):  The maximum UDP payload size parameter
+      is an integer value that limits the size of UDP payloads that the
+      endpoint is willing to receive.  UDP packets with payloads larger
+      than this limit are not likely to be processed by the receiver.
+
+      The default for this parameter is the maximum permitted UDP
+      payload of 65527.  Values below 1200 are invalid.
+
+      This limit does act as an additional constraint on datagram size
+      in the same way as the path MTU, but it is a property of the
+      endpoint and not the path.  It is expected that this is the space
+      an endpoint dedicates to holding incoming packets.
+
+   initial_max_data (0x04):  The initial maximum data parameter is an
+      integer value that contains the initial value for the maximum
+      amount of data that can be sent on the connection.  This is
+      equivalent to sending a MAX_DATA (Section 19.9) for the connection
+      immediately after completing the handshake.
+
+   initial_max_stream_data_bidi_local (0x05):  This parameter is an
+      integer value specifying the initial flow control limit for
+      locally-initiated bidirectional streams.  This limit applies to
+      newly created bidirectional streams opened by the endpoint that
+      sends the transport parameter.  In client transport parameters,
+      this applies to streams with an identifier with the least
+      significant two bits set to 0x0; in server transport parameters,
+      this applies to streams with the least significant two bits set to
+      0x1.
+
+   initial_max_stream_data_bidi_remote (0x06):  This parameter is an
+      integer value specifying the initial flow control limit for peer-
+      initiated bidirectional streams.  This limit applies to newly
+      created bidirectional streams opened by the endpoint that receives
+      the transport parameter.  In client transport parameters, this
+      applies to streams with an identifier with the least significant
+      two bits set to 0x1; in server transport parameters, this applies
+      to streams with the least significant two bits set to 0x0.
+
+   initial_max_stream_data_uni (0x07):  This parameter is an integer
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 115]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      value specifying the initial flow control limit for unidirectional
+      streams.  This limit applies to newly created unidirectional
+      streams opened by the endpoint that receives the transport
+      parameter.  In client transport parameters, this applies to
+      streams with an identifier with the least significant two bits set
+      to 0x3; in server transport parameters, this applies to streams
+      with the least significant two bits set to 0x2.
+
+   initial_max_streams_bidi (0x08):  The initial maximum bidirectional
+      streams parameter is an integer value that contains the initial
+      maximum number of bidirectional streams the peer may initiate.  If
+      this parameter is absent or zero, the peer cannot open
+      bidirectional streams until a MAX_STREAMS frame is sent.  Setting
+      this parameter is equivalent to sending a MAX_STREAMS
+      (Section 19.11) of the corresponding type with the same value.
+
+   initial_max_streams_uni (0x09):  The initial maximum unidirectional
+      streams parameter is an integer value that contains the initial
+      maximum number of unidirectional streams the peer may initiate.
+      If this parameter is absent or zero, the peer cannot open
+      unidirectional streams until a MAX_STREAMS frame is sent.  Setting
+      this parameter is equivalent to sending a MAX_STREAMS
+      (Section 19.11) of the corresponding type with the same value.
+
+   ack_delay_exponent (0x0a):  The ACK delay exponent is an integer
+      value indicating an exponent used to decode the ACK Delay field in
+      the ACK frame (Section 19.3).  If this value is absent, a default
+      value of 3 is assumed (indicating a multiplier of 8).  Values
+      above 20 are invalid.
+
+   max_ack_delay (0x0b):  The maximum ACK delay is an integer value
+      indicating the maximum amount of time in milliseconds by which the
+      endpoint will delay sending acknowledgments.  This value SHOULD
+      include the receiver's expected delays in alarms firing.  For
+      example, if a receiver sets a timer for 5ms and alarms commonly
+      fire up to 1ms late, then it should send a max_ack_delay of 6ms.
+      If this value is absent, a default of 25 milliseconds is assumed.
+      Values of 2^14 or greater are invalid.
+
+   disable_active_migration (0x0c):  The disable active migration
+      transport parameter is included if the endpoint does not support
+      active connection migration (Section 9).  Peers of an endpoint
+      that sets this transport parameter MUST NOT send any packets,
+      including probing packets (Section 9.1), from a local address or
+      port other than that used to perform the handshake.  This
+      parameter is a zero-length value.
+
+   preferred_address (0x0d):  The server's preferred address is used to
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 116]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      effect a change in server address at the end of the handshake, as
+      described in Section 9.6.  The format of this transport parameter
+      is shown in Figure 21.  This transport parameter is only sent by a
+      server.  Servers MAY choose to only send a preferred address of
+      one address family by sending an all-zero address and port
+      (0.0.0.0:0 or ::.0) for the other family.  IP addresses are
+      encoded in network byte order.
+
+      The Connection ID field and the Stateless Reset Token field
+      contain an alternative connection ID that has a sequence number of
+      1; see Section 5.1.1.  Having these values bundled with the
+      preferred address ensures that there will be at least one unused
+      active connection ID when the client initiates migration to the
+      preferred address.
+
+      The Connection ID and Stateless Reset Token fields of a preferred
+      address are identical in syntax and semantics to the corresponding
+      fields of a NEW_CONNECTION_ID frame (Section 19.15).  A server
+      that chooses a zero-length connection ID MUST NOT provide a
+      preferred address.  Similarly, a server MUST NOT include a zero-
+      length connection ID in this transport parameter.  A client MUST
+      treat violation of these requirements as a connection error of
+      type TRANSPORT_PARAMETER_ERROR.
+
+   Preferred Address {
+     IPv4 Address (32),
+     IPv4 Port (16),
+     IPv6 Address (128),
+     IPv6 Port (16),
+     CID Length (8),
+     Connection ID (..),
+     Stateless Reset Token (128),
+   }
+
+                    Figure 21: Preferred Address format
+
+   active_connection_id_limit (0x0e):  The active connection ID limit is
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 117]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      an integer value specifying the maximum number of connection IDs
+      from the peer that an endpoint is willing to store.  This value
+      includes the connection ID received during the handshake, that
+      received in the preferred_address transport parameter, and those
+      received in NEW_CONNECTION_ID frames.  The value of the
+      active_connection_id_limit parameter MUST be at least 2.  An
+      endpoint that receives a value less than 2 MUST close the
+      connection with an error of type TRANSPORT_PARAMETER_ERROR.  If
+      this transport parameter is absent, a default of 2 is assumed.  If
+      an endpoint issues a zero-length connection ID, it will never send
+      a NEW_CONNECTION_ID frame and therefore ignores the
+      active_connection_id_limit value received from its peer.
+
+   initial_source_connection_id (0x0f):  The value that the endpoint
+      included in the Source Connection ID field of the first Initial
+      packet it sends for the connection; see Section 7.3.
+
+   retry_source_connection_id (0x10):  The value that the server
+      included in the Source Connection ID field of a Retry packet; see
+      Section 7.3.  This transport parameter is only sent by a server.
+
+   If present, transport parameters that set initial flow control limits
+   (initial_max_stream_data_bidi_local,
+   initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)
+   are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on
+   every stream of the corresponding type immediately after opening.  If
+   the transport parameter is absent, streams of that type start with a
+   flow control limit of 0.
+
+   A client MUST NOT include any server-only transport parameter:
+   original_destination_connection_id, preferred_address,
+   retry_source_connection_id, or stateless_reset_token.  A server MUST
+   treat receipt of any of these transport parameters as a connection
+   error of type TRANSPORT_PARAMETER_ERROR.
+
+19.  Frame Types and Formats
+
+   As described in Section 12.4, packets contain one or more frames.
+   This section describes the format and semantics of the core QUIC
+   frame types.
+
+19.1.  PADDING Frame
+
+   The PADDING frame (type=0x00) has no semantic value.  PADDING frames
+   can be used to increase the size of a packet.  Padding can be used to
+   increase an initial client packet to the minimum required size, or to
+   provide protection against traffic analysis for protected packets.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 118]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   A PADDING frame has no content.  That is, a PADDING frame consists of
+   the single byte that identifies the frame as a PADDING frame.
+
+19.2.  PING Frame
+
+   Endpoints can use PING frames (type=0x01) to verify that their peers
+   are still alive or to check reachability to the peer.  The PING frame
+   contains no additional fields.
+
+   The receiver of a PING frame simply needs to acknowledge the packet
+   containing this frame.
+
+   The PING frame can be used to keep a connection alive when an
+   application or application protocol wishes to prevent the connection
+   from timing out.  An application protocol SHOULD provide guidance
+   about the conditions under which generating a PING is recommended.
+   This guidance SHOULD indicate whether it is the client or the server
+   that is expected to send the PING.  Having both endpoints send PING
+   frames without coordination can produce an excessive number of
+   packets and poor performance.
+
+   A connection will time out if no packets are sent or received for a
+   period longer than the time negotiated using the max_idle_timeout
+   transport parameter; see Section 10.  However, state in middleboxes
+   might time out earlier than that.  Though REQ-5 in [RFC4787]
+   recommends a 2 minute timeout interval, experience shows that sending
+   packets every 15 to 30 seconds is necessary to prevent the majority
+   of middleboxes from losing state for UDP flows.
+
+19.3.  ACK Frames
+
+   Receivers send ACK frames (types 0x02 and 0x03) to inform senders of
+   packets they have received and processed.  The ACK frame contains one
+   or more ACK Ranges.  ACK Ranges identify acknowledged packets.  If
+   the frame type is 0x03, ACK frames also contain the sum of QUIC
+   packets with associated ECN marks received on the connection up until
+   this point.  QUIC implementations MUST properly handle both types
+   and, if they have enabled ECN for packets they send, they SHOULD use
+   the information in the ECN section to manage their congestion state.
+
+   QUIC acknowledgements are irrevocable.  Once acknowledged, a packet
+   remains acknowledged, even if it does not appear in a future ACK
+   frame.  This is unlike TCP SACKs ([RFC2018]).
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 119]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Packets from different packet number spaces can be identified using
+   the same numeric value.  An acknowledgment for a packet needs to
+   indicate both a packet number and a packet number space.  This is
+   accomplished by having each ACK frame only acknowledge packet numbers
+   in the same space as the packet in which the ACK frame is contained.
+
+   Version Negotiation and Retry packets cannot be acknowledged because
+   they do not contain a packet number.  Rather than relying on ACK
+   frames, these packets are implicitly acknowledged by the next Initial
+   packet sent by the client.
+
+   An ACK frame is shown in Figure 22.
+
+   ACK Frame {
+     Type (i) = 0x02..0x03,
+     Largest Acknowledged (i),
+     ACK Delay (i),
+     ACK Range Count (i),
+     First ACK Range (i),
+     ACK Range (..) ...,
+     [ECN Counts (..)],
+   }
+
+                        Figure 22: ACK Frame Format
+
+   ACK frames contain the following fields:
+
+   Largest Acknowledged:  A variable-length integer representing the
+      largest packet number the peer is acknowledging; this is usually
+      the largest packet number that the peer has received prior to
+      generating the ACK frame.  Unlike the packet number in the QUIC
+      long or short header, the value in an ACK frame is not truncated.
+
+   ACK Delay:  A variable-length integer representing the time delta in
+      microseconds between when this ACK was sent and when the largest
+      acknowledged packet, as indicated in the Largest Acknowledged
+      field, was received by this peer.  The value of the ACK Delay
+      field is scaled by multiplying the encoded value by 2 to the power
+      of the value of the ack_delay_exponent transport parameter set by
+      the sender of the ACK frame; see Section 18.2.  Scaling in this
+      fashion allows for a larger range of values with a shorter
+      encoding at the cost of lower resolution.  Because the receiver
+      doesn't use the ACK Delay for Initial and Handshake packets, a
+      sender SHOULD send a value of 0.
+
+   ACK Range Count:  A variable-length integer specifying the number of
+      Gap and ACK Range fields in the frame.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 120]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   First ACK Range:  A variable-length integer indicating the number of
+      contiguous packets preceding the Largest Acknowledged that are
+      being acknowledged.  The First ACK Range is encoded as an ACK
+      Range; see Section 19.3.1 starting from the Largest Acknowledged.
+      That is, the smallest packet acknowledged in the range is
+      determined by subtracting the First ACK Range value from the
+      Largest Acknowledged.
+
+   ACK Ranges:  Contains additional ranges of packets which are
+      alternately not acknowledged (Gap) and acknowledged (ACK Range);
+      see Section 19.3.1.
+
+   ECN Counts:  The three ECN Counts; see Section 19.3.2.
+
+19.3.1.  ACK Ranges
+
+   Each ACK Range consists of alternating Gap and ACK Range values in
+   descending packet number order.  ACK Ranges can be repeated.  The
+   number of Gap and ACK Range values is determined by the ACK Range
+   Count field; one of each value is present for each value in the ACK
+   Range Count field.
+
+   ACK Ranges are structured as shown in Figure 23.
+
+   ACK Range {
+     Gap (i),
+     ACK Range Length (i),
+   }
+
+                           Figure 23: ACK Ranges
+
+   The fields that form each ACK Range are:
+
+   Gap:  A variable-length integer indicating the number of contiguous
+      unacknowledged packets preceding the packet number one lower than
+      the smallest in the preceding ACK Range.
+
+   ACK Range Length:  A variable-length integer indicating the number of
+      contiguous acknowledged packets preceding the largest packet
+      number, as determined by the preceding Gap.
+
+   Gap and ACK Range value use a relative integer encoding for
+   efficiency.  Though each encoded value is positive, the values are
+   subtracted, so that each ACK Range describes progressively lower-
+   numbered packets.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 121]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Each ACK Range acknowledges a contiguous range of packets by
+   indicating the number of acknowledged packets that precede the
+   largest packet number in that range.  A value of zero indicates that
+   only the largest packet number is acknowledged.  Larger ACK Range
+   values indicate a larger range, with corresponding lower values for
+   the smallest packet number in the range.  Thus, given a largest
+   packet number for the range, the smallest value is determined by the
+   formula:
+
+      smallest = largest - ack_range
+
+   An ACK Range acknowledges all packets between the smallest packet
+   number and the largest, inclusive.
+
+   The largest value for an ACK Range is determined by cumulatively
+   subtracting the size of all preceding ACK Ranges and Gaps.
+
+   Each Gap indicates a range of packets that are not being
+   acknowledged.  The number of packets in the gap is one higher than
+   the encoded value of the Gap field.
+
+   The value of the Gap field establishes the largest packet number
+   value for the subsequent ACK Range using the following formula:
+
+      largest = previous_smallest - gap - 2
+
+   If any computed packet number is negative, an endpoint MUST generate
+   a connection error of type FRAME_ENCODING_ERROR.
+
+19.3.2.  ECN Counts
+
+   The ACK frame uses the least significant bit (that is, type 0x03) to
+   indicate ECN feedback and report receipt of QUIC packets with
+   associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP
+   header.  ECN Counts are only present when the ACK frame type is 0x03.
+
+   ECN Counts are only parsed when the ACK frame type is 0x03.  There
+   are 3 ECN counts, as shown in Figure 24.
+
+   ECN Counts {
+     ECT0 Count (i),
+     ECT1 Count (i),
+     ECN-CE Count (i),
+   }
+
+                        Figure 24: ECN Count Format
+
+   The three ECN Counts are:
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 122]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   ECT0 Count:  A variable-length integer representing the total number
+      of packets received with the ECT(0) codepoint in the packet number
+      space of the ACK frame.
+
+   ECT1 Count:  A variable-length integer representing the total number
+      of packets received with the ECT(1) codepoint in the packet number
+      space of the ACK frame.
+
+   CE Count:  A variable-length integer representing the total number of
+      packets received with the CE codepoint in the packet number space
+      of the ACK frame.
+
+   ECN counts are maintained separately for each packet number space.
+
+19.4.  RESET_STREAM Frame
+
+   An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly
+   terminate the sending part of a stream.
+
+   After sending a RESET_STREAM, an endpoint ceases transmission and
+   retransmission of STREAM frames on the identified stream.  A receiver
+   of RESET_STREAM can discard any data that it already received on that
+   stream.
+
+   An endpoint that receives a RESET_STREAM frame for a send-only stream
+   MUST terminate the connection with error STREAM_STATE_ERROR.
+
+   The RESET_STREAM frame is shown in Figure 25.
+
+   RESET_STREAM Frame {
+     Type (i) = 0x04,
+     Stream ID (i),
+     Application Protocol Error Code (i),
+     Final Size (i),
+   }
+
+                    Figure 25: RESET_STREAM Frame Format
+
+   RESET_STREAM frames contain the following fields:
+
+   Stream ID:  A variable-length integer encoding of the Stream ID of
+      the stream being terminated.
+
+   Application Protocol Error Code:  A variable-length integer
+      containing the application protocol error code (see Section 20.1)
+      which indicates why the stream is being closed.
+
+   Final Size:  A variable-length integer indicating the final size of
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 123]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      the stream by the RESET_STREAM sender, in unit of bytes.
+
+19.5.  STOP_SENDING Frame
+
+   An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
+   incoming data is being discarded on receipt at application request.
+   STOP_SENDING requests that a peer cease transmission on a stream.
+
+   A STOP_SENDING frame can be sent for streams in the Recv or Size
+   Known states; see Section 3.1.  Receiving a STOP_SENDING frame for a
+   locally-initiated stream that has not yet been created MUST be
+   treated as a connection error of type STREAM_STATE_ERROR.  An
+   endpoint that receives a STOP_SENDING frame for a receive-only stream
+   MUST terminate the connection with error STREAM_STATE_ERROR.
+
+   The STOP_SENDING frame is shown in Figure 26.
+
+   STOP_SENDING Frame {
+     Type (i) = 0x05,
+     Stream ID (i),
+     Application Protocol Error Code (i),
+   }
+
+                    Figure 26: STOP_SENDING Frame Format
+
+   STOP_SENDING frames contain the following fields:
+
+   Stream ID:  A variable-length integer carrying the Stream ID of the
+      stream being ignored.
+
+   Application Protocol Error Code:  A variable-length integer
+      containing the application-specified reason the sender is ignoring
+      the stream; see Section 20.1.
+
+19.6.  CRYPTO Frame
+
+   The CRYPTO frame (type=0x06) is used to transmit cryptographic
+   handshake messages.  It can be sent in all packet types except 0-RTT.
+   The CRYPTO frame offers the cryptographic protocol an in-order stream
+   of bytes.  CRYPTO frames are functionally identical to STREAM frames,
+   except that they do not bear a stream identifier; they are not flow
+   controlled; and they do not carry markers for optional offset,
+   optional length, and the end of the stream.
+
+   The CRYPTO frame is shown in Figure 27.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 124]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   CRYPTO Frame {
+     Type (i) = 0x06,
+     Offset (i),
+     Length (i),
+     Crypto Data (..),
+   }
+
+                       Figure 27: CRYPTO Frame Format
+
+   CRYPTO frames contain the following fields:
+
+   Offset:  A variable-length integer specifying the byte offset in the
+      stream for the data in this CRYPTO frame.
+
+   Length:  A variable-length integer specifying the length of the
+      Crypto Data field in this CRYPTO frame.
+
+   Crypto Data:  The cryptographic message data.
+
+   There is a separate flow of cryptographic handshake data in each
+   encryption level, each of which starts at an offset of 0.  This
+   implies that each encryption level is treated as a separate CRYPTO
+   stream of data.
+
+   The largest offset delivered on a stream - the sum of the offset and
+   data length - cannot exceed 2^62-1.  Receipt of a frame that exceeds
+   this limit MUST be treated as a connection error of type
+   FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED.
+
+   Unlike STREAM frames, which include a Stream ID indicating to which
+   stream the data belongs, the CRYPTO frame carries data for a single
+   stream per encryption level.  The stream does not have an explicit
+   end, so CRYPTO frames do not have a FIN bit.
+
+19.7.  NEW_TOKEN Frame
+
+   A server sends a NEW_TOKEN frame (type=0x07) to provide the client
+   with a token to send in the header of an Initial packet for a future
+   connection.
+
+   The NEW_TOKEN frame is shown in Figure 28.
+
+   NEW_TOKEN Frame {
+     Type (i) = 0x07,
+     Token Length (i),
+     Token (..),
+   }
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 125]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+                     Figure 28: NEW_TOKEN Frame Format
+
+   NEW_TOKEN frames contain the following fields:
+
+   Token Length:  A variable-length integer specifying the length of the
+      token in bytes.
+
+   Token:  An opaque blob that the client may use with a future Initial
+      packet.  The token MUST NOT be empty.  An endpoint MUST treat
+      receipt of a NEW_TOKEN frame with an empty Token field as a
+      connection error of type FRAME_ENCODING_ERROR.
+
+   An endpoint might receive multiple NEW_TOKEN frames that contain the
+   same token value if packets containing the frame are incorrectly
+   determined to be lost.  Endpoints are responsible for discarding
+   duplicate values, which might be used to link connection attempts;
+   see Section 8.1.3.
+
+   Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt
+   of a NEW_TOKEN frame as a connection error of type
+   PROTOCOL_VIOLATION.
+
+19.8.  STREAM Frames
+
+   STREAM frames implicitly create a stream and carry stream data.  The
+   STREAM frame takes the form 0b00001XXX (or the set of values from
+   0x08 to 0x0f).  The value of the three low-order bits of the frame
+   type determines the fields that are present in the frame.
+
+   *  The OFF bit (0x04) in the frame type is set to indicate that there
+      is an Offset field present.  When set to 1, the Offset field is
+      present.  When set to 0, the Offset field is absent and the Stream
+      Data starts at an offset of 0 (that is, the frame contains the
+      first bytes of the stream, or the end of a stream that includes no
+      data).
+
+   *  The LEN bit (0x02) in the frame type is set to indicate that there
+      is a Length field present.  If this bit is set to 0, the Length
+      field is absent and the Stream Data field extends to the end of
+      the packet.  If this bit is set to 1, the Length field is present.
+
+   *  The FIN bit (0x01) of the frame type is set only on frames that
+      contain the final size of the stream.  Setting this bit indicates
+      that the frame marks the end of the stream.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 126]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   An endpoint MUST terminate the connection with error
+   STREAM_STATE_ERROR if it receives a STREAM frame for a locally-
+   initiated stream that has not yet been created, or for a send-only
+   stream.
+
+   The STREAM frames are shown in Figure 29.
+
+   STREAM Frame {
+     Type (i) = 0x08..0x0f,
+     Stream ID (i),
+     [Offset (i)],
+     [Length (i)],
+     Stream Data (..),
+   }
+
+                       Figure 29: STREAM Frame Format
+
+   STREAM frames contain the following fields:
+
+   Stream ID:  A variable-length integer indicating the stream ID of the
+      stream; see Section 2.1.
+
+   Offset:  A variable-length integer specifying the byte offset in the
+      stream for the data in this STREAM frame.  This field is present
+      when the OFF bit is set to 1.  When the Offset field is absent,
+      the offset is 0.
+
+   Length:  A variable-length integer specifying the length of the
+      Stream Data field in this STREAM frame.  This field is present
+      when the LEN bit is set to 1.  When the LEN bit is set to 0, the
+      Stream Data field consumes all the remaining bytes in the packet.
+
+   Stream Data:  The bytes from the designated stream to be delivered.
+
+   When a Stream Data field has a length of 0, the offset in the STREAM
+   frame is the offset of the next byte that would be sent.
+
+   The first byte in the stream has an offset of 0.  The largest offset
+   delivered on a stream - the sum of the offset and data length -
+   cannot exceed 2^62-1, as it is not possible to provide flow control
+   credit for that data.  Receipt of a frame that exceeds this limit
+   MUST be treated as a connection error of type FRAME_ENCODING_ERROR or
+   FLOW_CONTROL_ERROR.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 127]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+19.9.  MAX_DATA Frame
+
+   The MAX_DATA frame (type=0x10) is used in flow control to inform the
+   peer of the maximum amount of data that can be sent on the connection
+   as a whole.
+
+   The MAX_DATA frame is shown in Figure 30.
+
+   MAX_DATA Frame {
+     Type (i) = 0x10,
+     Maximum Data (i),
+   }
+
+                      Figure 30: MAX_DATA Frame Format
+
+   MAX_DATA frames contain the following fields:
+
+   Maximum Data:  A variable-length integer indicating the maximum
+      amount of data that can be sent on the entire connection, in units
+      of bytes.
+
+   All data sent in STREAM frames counts toward this limit.  The sum of
+   the largest received offsets on all streams - including streams in
+   terminal states - MUST NOT exceed the value advertised by a receiver.
+   An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR
+   error if it receives more data than the maximum data value that it
+   has sent, unless this is a result of a change in the initial limits;
+   see Section 7.4.1.
+
+19.10.  MAX_STREAM_DATA Frame
+
+   The MAX_STREAM_DATA frame (type=0x11) is used in flow control to
+   inform a peer of the maximum amount of data that can be sent on a
+   stream.
+
+   A MAX_STREAM_DATA frame can be sent for streams in the Recv state;
+   see Section 3.1.  Receiving a MAX_STREAM_DATA frame for a locally-
+   initiated stream that has not yet been created MUST be treated as a
+   connection error of type STREAM_STATE_ERROR.  An endpoint that
+   receives a MAX_STREAM_DATA frame for a receive-only stream MUST
+   terminate the connection with error STREAM_STATE_ERROR.
+
+   The MAX_STREAM_DATA frame is shown in Figure 31.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 128]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   MAX_STREAM_DATA Frame {
+     Type (i) = 0x11,
+     Stream ID (i),
+     Maximum Stream Data (i),
+   }
+
+                  Figure 31: MAX_STREAM_DATA Frame Format
+
+   MAX_STREAM_DATA frames contain the following fields:
+
+   Stream ID:  The stream ID of the stream that is affected encoded as a
+      variable-length integer.
+
+   Maximum Stream Data:  A variable-length integer indicating the
+      maximum amount of data that can be sent on the identified stream,
+      in units of bytes.
+
+   When counting data toward this limit, an endpoint accounts for the
+   largest received offset of data that is sent or received on the
+   stream.  Loss or reordering can mean that the largest received offset
+   on a stream can be greater than the total size of data received on
+   that stream.  Receiving STREAM frames might not increase the largest
+   received offset.
+
+   The data sent on a stream MUST NOT exceed the largest maximum stream
+   data value advertised by the receiver.  An endpoint MUST terminate a
+   connection with a FLOW_CONTROL_ERROR error if it receives more data
+   than the largest maximum stream data that it has sent for the
+   affected stream, unless this is a result of a change in the initial
+   limits; see Section 7.4.1.
+
+19.11.  MAX_STREAMS Frames
+
+   The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the
+   cumulative number of streams of a given type it is permitted to open.
+   A MAX_STREAMS frame with a type of 0x12 applies to bidirectional
+   streams, and a MAX_STREAMS frame with a type of 0x13 applies to
+   unidirectional streams.
+
+   The MAX_STREAMS frames are shown in Figure 32;
+
+   MAX_STREAMS Frame {
+     Type (i) = 0x12..0x13,
+     Maximum Streams (i),
+   }
+
+                    Figure 32: MAX_STREAMS Frame Format
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 129]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   MAX_STREAMS frames contain the following fields:
+
+   Maximum Streams:  A count of the cumulative number of streams of the
+      corresponding type that can be opened over the lifetime of the
+      connection.  This value cannot exceed 2^60, as it is not possible
+      to encode stream IDs larger than 2^62-1.  Receipt of a frame that
+      permits opening of a stream larger than this limit MUST be treated
+      as a FRAME_ENCODING_ERROR.
+
+   Loss or reordering can cause a MAX_STREAMS frame to be received which
+   states a lower stream limit than an endpoint has previously received.
+   MAX_STREAMS frames which do not increase the stream limit MUST be
+   ignored.
+
+   An endpoint MUST NOT open more streams than permitted by the current
+   stream limit set by its peer.  For instance, a server that receives a
+   unidirectional stream limit of 3 is permitted to open stream 3, 7,
+   and 11, but not stream 15.  An endpoint MUST terminate a connection
+   with a STREAM_LIMIT_ERROR error if a peer opens more streams than was
+   permitted.
+
+   Note that these frames (and the corresponding transport parameters)
+   do not describe the number of streams that can be opened
+   concurrently.  The limit includes streams that have been closed as
+   well as those that are open.
+
+19.12.  DATA_BLOCKED Frame
+
+   A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
+   to send data, but is unable to due to connection-level flow control;
+   see Section 4.  DATA_BLOCKED frames can be used as input to tuning of
+   flow control algorithms; see Section 4.2.
+
+   The DATA_BLOCKED frame is shown in Figure 33.
+
+   DATA_BLOCKED Frame {
+     Type (i) = 0x14,
+     Maximum Data (i),
+   }
+
+                    Figure 33: DATA_BLOCKED Frame Format
+
+   DATA_BLOCKED frames contain the following fields:
+
+   Maximum Data:  A variable-length integer indicating the connection-
+      level limit at which blocking occurred.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 130]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+19.13.  STREAM_DATA_BLOCKED Frame
+
+   A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
+   wishes to send data, but is unable to due to stream-level flow
+   control.  This frame is analogous to DATA_BLOCKED (Section 19.12).
+
+   An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only
+   stream MUST terminate the connection with error STREAM_STATE_ERROR.
+
+   The STREAM_DATA_BLOCKED frame is shown in Figure 34.
+
+   STREAM_DATA_BLOCKED Frame {
+     Type (i) = 0x15,
+     Stream ID (i),
+     Maximum Stream Data (i),
+   }
+
+                Figure 34: STREAM_DATA_BLOCKED Frame Format
+
+   STREAM_DATA_BLOCKED frames contain the following fields:
+
+   Stream ID:  A variable-length integer indicating the stream which is
+      flow control blocked.
+
+   Maximum Stream Data:  A variable-length integer indicating the offset
+      of the stream at which the blocking occurred.
+
+19.14.  STREAMS_BLOCKED Frames
+
+   A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when
+   it wishes to open a stream, but is unable to due to the maximum
+   stream limit set by its peer; see Section 19.11.  A STREAMS_BLOCKED
+   frame of type 0x16 is used to indicate reaching the bidirectional
+   stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates
+   reaching the unidirectional stream limit.
+
+   A STREAMS_BLOCKED frame does not open the stream, but informs the
+   peer that a new stream was needed and the stream limit prevented the
+   creation of the stream.
+
+   The STREAMS_BLOCKED frames are shown in Figure 35.
+
+   STREAMS_BLOCKED Frame {
+     Type (i) = 0x16..0x17,
+     Maximum Streams (i),
+   }
+
+                  Figure 35: STREAMS_BLOCKED Frame Format
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 131]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   STREAMS_BLOCKED frames contain the following fields:
+
+   Maximum Streams:  A variable-length integer indicating the maximum
+      number of streams allowed at the time the frame was sent.  This
+      value cannot exceed 2^60, as it is not possible to encode stream
+      IDs larger than 2^62-1.  Receipt of a frame that encodes a larger
+      stream ID MUST be treated as a STREAM_LIMIT_ERROR or a
+      FRAME_ENCODING_ERROR.
+
+19.15.  NEW_CONNECTION_ID Frame
+
+   An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide
+   its peer with alternative connection IDs that can be used to break
+   linkability when migrating connections; see Section 9.5.
+
+   The NEW_CONNECTION_ID frame is shown in Figure 36.
+
+   NEW_CONNECTION_ID Frame {
+     Type (i) = 0x18,
+     Sequence Number (i),
+     Retire Prior To (i),
+     Length (8),
+     Connection ID (8..160),
+     Stateless Reset Token (128),
+   }
+
+                 Figure 36: NEW_CONNECTION_ID Frame Format
+
+   NEW_CONNECTION_ID frames contain the following fields:
+
+   Sequence Number:  The sequence number assigned to the connection ID
+      by the sender.  See Section 5.1.1.
+
+   Retire Prior To:  A variable-length integer indicating which
+      connection IDs should be retired; see Section 5.1.2.
+
+   Length:  An 8-bit unsigned integer containing the length of the
+      connection ID.  Values less than 1 and greater than 20 are invalid
+      and MUST be treated as a connection error of type
+      FRAME_ENCODING_ERROR.
+
+   Connection ID:  A connection ID of the specified length.
+
+   Stateless Reset Token:  A 128-bit value that will be used for a
+      stateless reset when the associated connection ID is used; see
+      Section 10.4.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 132]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   An endpoint MUST NOT send this frame if it currently requires that
+   its peer send packets with a zero-length Destination Connection ID.
+   Changing the length of a connection ID to or from zero-length makes
+   it difficult to identify when the value of the connection ID changed.
+   An endpoint that is sending packets with a zero-length Destination
+   Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a
+   connection error of type PROTOCOL_VIOLATION.
+
+   Transmission errors, timeouts and retransmissions might cause the
+   same NEW_CONNECTION_ID frame to be received multiple times.  Receipt
+   of the same frame multiple times MUST NOT be treated as a connection
+   error.  A receiver can use the sequence number supplied in the
+   NEW_CONNECTION_ID frame to identify new connection IDs from old ones.
+
+   If an endpoint receives a NEW_CONNECTION_ID frame that repeats a
+   previously issued connection ID with a different Stateless Reset
+   Token or a different sequence number, or if a sequence number is used
+   for different connection IDs, the endpoint MAY treat that receipt as
+   a connection error of type PROTOCOL_VIOLATION.
+
+   The Retire Prior To field counts connection IDs established during
+   connection setup and the preferred_address transport parameter; see
+   Section 5.1.2.  The Retire Prior To field MUST be less than or equal
+   to the Sequence Number field.  Receiving a value greater than the
+   Sequence Number MUST be treated as a connection error of type
+   FRAME_ENCODING_ERROR.
+
+   Once a sender indicates a Retire Prior To value, smaller values sent
+   in subsequent NEW_CONNECTION_ID frames have no effect.  A receiver
+   MUST ignore any Retire Prior To fields that do not increase the
+   largest received Retire Prior To value.
+
+   An endpoint that receives a NEW_CONNECTION_ID frame with a sequence
+   number smaller than the Retire Prior To field of a previously
+   received NEW_CONNECTION_ID frame MUST send a corresponding
+   RETIRE_CONNECTION_ID frame that retires the newly received connection
+   ID, unless it has already done so for that sequence number.
+
+19.16.  RETIRE_CONNECTION_ID Frame
+
+   An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
+   indicate that it will no longer use a connection ID that was issued
+   by its peer.  This may include the connection ID provided during the
+   handshake.  Sending a RETIRE_CONNECTION_ID frame also serves as a
+   request to the peer to send additional connection IDs for future use;
+   see Section 5.1.  New connection IDs can be delivered to a peer using
+   the NEW_CONNECTION_ID frame (Section 19.15).
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 133]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Retiring a connection ID invalidates the stateless reset token
+   associated with that connection ID.
+
+   The RETIRE_CONNECTION_ID frame is shown in Figure 37.
+
+   RETIRE_CONNECTION_ID Frame {
+     Type (i) = 0x19,
+     Sequence Number (i),
+   }
+
+                Figure 37: RETIRE_CONNECTION_ID Frame Format
+
+   RETIRE_CONNECTION_ID frames contain the following fields:
+
+   Sequence Number:  The sequence number of the connection ID being
+      retired; see Section 5.1.2.
+
+   Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number
+   greater than any previously sent to the peer MUST be treated as a
+   connection error of type PROTOCOL_VIOLATION.
+
+   The sequence number specified in a RETIRE_CONNECTION_ID frame MUST
+   NOT refer to the Destination Connection ID field of the packet in
+   which the frame is contained.  The peer MAY treat this as a
+   connection error of type FRAME_ENCODING_ERROR.
+
+   An endpoint cannot send this frame if it was provided with a zero-
+   length connection ID by its peer.  An endpoint that provides a zero-
+   length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID
+   frame as a connection error of type PROTOCOL_VIOLATION.
+
+19.17.  PATH_CHALLENGE Frame
+
+   Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check
+   reachability to the peer and for path validation during connection
+   migration.
+
+   The PATH_CHALLENGE frame is shown in Figure 38.
+
+   PATH_CHALLENGE Frame {
+     Type (i) = 0x1a,
+     Data (64),
+   }
+
+                   Figure 38: PATH_CHALLENGE Frame Format
+
+   PATH_CHALLENGE frames contain the following fields:
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 134]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Data:  This 8-byte field contains arbitrary data.
+
+   A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is
+   sufficient to ensure that it is easier to receive the packet than it
+   is to guess the value correctly.
+
+   The recipient of this frame MUST generate a PATH_RESPONSE frame
+   (Section 19.18) containing the same Data.
+
+19.18.  PATH_RESPONSE Frame
+
+   The PATH_RESPONSE frame (type=0x1b) is sent in response to a
+   PATH_CHALLENGE frame.  Its format, shown in Figure 39 is identical to
+   the PATH_CHALLENGE frame (Section 19.17).
+
+   PATH_RESPONSE Frame {
+     Type (i) = 0x1b,
+     Data (64),
+   }
+
+                   Figure 39: PATH_RESPONSE Frame Format
+
+   If the content of a PATH_RESPONSE frame does not match the content of
+   a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint
+   MAY generate a connection error of type PROTOCOL_VIOLATION.
+
+19.19.  CONNECTION_CLOSE Frames
+
+   An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to
+   notify its peer that the connection is being closed.  The
+   CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors
+   at only the QUIC layer, or the absence of errors (with the NO_ERROR
+   code).  The CONNECTION_CLOSE frame with a type of 0x1d is used to
+   signal an error with the application that uses QUIC.
+
+   If there are open streams that haven't been explicitly closed, they
+   are implicitly closed when the connection is closed.
+
+   The CONNECTION_CLOSE frames are shown in Figure 40.
+
+   CONNECTION_CLOSE Frame {
+     Type (i) = 0x1c..0x1d,
+     Error Code (i),
+     [Frame Type (i)],
+     Reason Phrase Length (i),
+     Reason Phrase (..),
+   }
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 135]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+                  Figure 40: CONNECTION_CLOSE Frame Format
+
+   CONNECTION_CLOSE frames contain the following fields:
+
+   Error Code:  A variable length integer error code which indicates the
+      reason for closing this connection.  A CONNECTION_CLOSE frame of
+      type 0x1c uses codes from the space defined in Section 20.  A
+      CONNECTION_CLOSE frame of type 0x1d uses codes from the
+      application protocol error code space; see Section 20.1
+
+   Frame Type:  A variable-length integer encoding the type of frame
+      that triggered the error.  A value of 0 (equivalent to the mention
+      of the PADDING frame) is used when the frame type is unknown.  The
+      application-specific variant of CONNECTION_CLOSE (type 0x1d) does
+      not include this field.
+
+   Reason Phrase Length:  A variable-length integer specifying the
+      length of the reason phrase in bytes.  Because a CONNECTION_CLOSE
+      frame cannot be split between packets, any limits on packet size
+      will also limit the space available for a reason phrase.
+
+   Reason Phrase:  A human-readable explanation for why the connection
+      was closed.  This can be zero length if the sender chooses to not
+      give details beyond the Error Code.  This SHOULD be a UTF-8
+      encoded string [RFC3629].
+
+   The application-specific variant of CONNECTION_CLOSE (type 0x1d) can
+   only be sent using 0-RTT or 1-RTT packets ([QUIC-TLS], Section 4).
+   When an application wishes to abandon a connection during the
+   handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c)
+   with an error code of APPLICATION_ERROR in an Initial or a Handshake
+   packet.
+
+19.20.  HANDSHAKE_DONE frame
+
+   The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal
+   confirmation of the handshake to the client.  The HANDSHAKE_DONE
+   frame contains no additional fields.
+
+   This frame can only be sent by the server.  Servers MUST NOT send a
+   HANDSHAKE_DONE frame before completing the handshake.  A server MUST
+   treat receipt of a HANDSHAKE_DONE frame as a connection error of type
+   PROTOCOL_VIOLATION.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 136]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+19.21.  Extension Frames
+
+   QUIC frames do not use a self-describing encoding.  An endpoint
+   therefore needs to understand the syntax of all frames before it can
+   successfully process a packet.  This allows for efficient encoding of
+   frames, but it means that an endpoint cannot send a frame of a type
+   that is unknown to its peer.
+
+   An extension to QUIC that wishes to use a new type of frame MUST
+   first ensure that a peer is able to understand the frame.  An
+   endpoint can use a transport parameter to signal its willingness to
+   receive one or more extension frame types with the one transport
+   parameter.
+
+   Extensions that modify or replace core protocol functionality
+   (including frame types) will be difficult to combine with other
+   extensions which modify or replace the same functionality unless the
+   behavior of the combination is explicitly defined.  Such extensions
+   SHOULD define their interaction with previously-defined extensions
+   modifying the same protocol components.
+
+   Extension frames MUST be congestion controlled and MUST cause an ACK
+   frame to be sent.  The exception is extension frames that replace or
+   supplement the ACK frame.  Extension frames are not included in flow
+   control unless specified in the extension.
+
+   An IANA registry is used to manage the assignment of frame types; see
+   Section 22.3.
+
+20.  Transport Error Codes
+
+   QUIC error codes are 62-bit unsigned integers.
+
+   This section lists the defined QUIC transport error codes that may be
+   used in a CONNECTION_CLOSE frame.  These errors apply to the entire
+   connection.
+
+   NO_ERROR (0x0):  An endpoint uses this with CONNECTION_CLOSE to
+      signal that the connection is being closed abruptly in the absence
+      of any error.
+
+   INTERNAL_ERROR (0x1):  The endpoint encountered an internal error and
+      cannot continue with the connection.
+
+   CONNECTION_REFUSED (0x2):  The server refused to accept a new
+      connection.
+
+   FLOW_CONTROL_ERROR (0x3):  An endpoint received more data than it
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 137]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      permitted in its advertised data limits; see Section 4.
+
+   STREAM_LIMIT_ERROR (0x4):  An endpoint received a frame for a stream
+      identifier that exceeded its advertised stream limit for the
+      corresponding stream type.
+
+   STREAM_STATE_ERROR (0x5):  An endpoint received a frame for a stream
+      that was not in a state that permitted that frame; see Section 3.
+
+   FINAL_SIZE_ERROR (0x6):  An endpoint received a STREAM frame
+      containing data that exceeded the previously established final
+      size.  Or an endpoint received a STREAM frame or a RESET_STREAM
+      frame containing a final size that was lower than the size of
+      stream data that was already received.  Or an endpoint received a
+      STREAM frame or a RESET_STREAM frame containing a different final
+      size to the one already established.
+
+   FRAME_ENCODING_ERROR (0x7):  An endpoint received a frame that was
+      badly formatted.  For instance, a frame of an unknown type, or an
+      ACK frame that has more acknowledgment ranges than the remainder
+      of the packet could carry.
+
+   TRANSPORT_PARAMETER_ERROR (0x8):  An endpoint received transport
+      parameters that were badly formatted, included an invalid value,
+      was absent even though it is mandatory, was present though it is
+      forbidden, or is otherwise in error.
+
+   CONNECTION_ID_LIMIT_ERROR (0x9):  The number of connection IDs
+      provided by the peer exceeds the advertised
+      active_connection_id_limit.
+
+   PROTOCOL_VIOLATION (0xA):  An endpoint detected an error with
+      protocol compliance that was not covered by more specific error
+      codes.
+
+   INVALID_TOKEN (0xB):  A server received a Retry Token in a client
+      Initial that is invalid.
+
+   APPLICATION_ERROR (0xC):  The application or application protocol
+      caused the connection to be closed.
+
+   CRYPTO_BUFFER_EXCEEDED (0xD):  An endpoint has received more data in
+      CRYPTO frames than it can buffer.
+
+   CRYPTO_ERROR (0x1XX):  The cryptographic handshake failed.  A range
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 138]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      of 256 values is reserved for carrying error codes specific to the
+      cryptographic handshake that is used.  Codes for errors occurring
+      when TLS is used for the crypto handshake are described in
+      Section 4.8 of [QUIC-TLS].
+
+   See Section 22.4 for details of registering new error codes.
+
+   In defining these error codes, several principles are applied.  Error
+   conditions that might require specific action on the part of a
+   recipient are given unique codes.  Errors that represent common
+   conditions are given specific codes.  Absent either of these
+   conditions, error codes are used to identify a general function of
+   the stack, like flow control or transport parameter handling.
+   Finally, generic errors are provided for conditions where
+   implementations are unable or unwilling to use more specific codes.
+
+20.1.  Application Protocol Error Codes
+
+   Application protocol error codes are 62-bit unsigned integers, but
+   the management of application error codes is left to application
+   protocols.  Application protocol error codes are used for the
+   RESET_STREAM frame (Section 19.4), the STOP_SENDING frame
+   (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d
+   (Section 19.19).
+
+21.  Security Considerations
+
+21.1.  Handshake Denial of Service
+
+   As an encrypted and authenticated transport QUIC provides a range of
+   protections against denial of service.  Once the cryptographic
+   handshake is complete, QUIC endpoints discard most packets that are
+   not authenticated, greatly limiting the ability of an attacker to
+   interfere with existing connections.
+
+   Once a connection is established QUIC endpoints might accept some
+   unauthenticated ICMP packets (see Section 14.2), but the use of these
+   packets is extremely limited.  The only other type of packet that an
+   endpoint might accept is a stateless reset (Section 10.4) which
+   relies on the token being kept secret until it is used.
+
+   During the creation of a connection, QUIC only provides protection
+   against attack from off the network path.  All QUIC packets contain
+   proof that the recipient saw a preceding packet from its peer.
+
+   Addresses cannot change during the handshake, so endpoints can
+   discard packets that are received on a different network path.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 139]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The Source and Destination Connection ID fields are the primary means
+   of protection against off-path attack during the handshake.  These
+   are required to match those set by a peer.  Except for an Initial and
+   stateless reset packets, an endpoint only accepts packets that
+   include a Destination Connection ID field that matches a value the
+   endpoint previously chose.  This is the only protection offered for
+   Version Negotiation packets.
+
+   The Destination Connection ID field in an Initial packet is selected
+   by a client to be unpredictable, which serves an additional purpose.
+   The packets that carry the cryptographic handshake are protected with
+   a key that is derived from this connection ID and salt specific to
+   the QUIC version.  This allows endpoints to use the same process for
+   authenticating packets that they receive as they use after the
+   cryptographic handshake completes.  Packets that cannot be
+   authenticated are discarded.  Protecting packets in this fashion
+   provides a strong assurance that the sender of the packet saw the
+   Initial packet and understood it.
+
+   These protections are not intended to be effective against an
+   attacker that is able to receive QUIC packets prior to the connection
+   being established.  Such an attacker can potentially send packets
+   that will be accepted by QUIC endpoints.  This version of QUIC
+   attempts to detect this sort of attack, but it expects that endpoints
+   will fail to establish a connection rather than recovering.  For the
+   most part, the cryptographic handshake protocol [QUIC-TLS] is
+   responsible for detecting tampering during the handshake.
+
+   Endpoints are permitted to use other methods to detect and attempt to
+   recover from interference with the handshake.  Invalid packets may be
+   identified and discarded using other methods, but no specific method
+   is mandated in this document.
+
+21.2.  Amplification Attack
+
+   An attacker might be able to receive an address validation token
+   (Section 8) from a server and then release the IP address it used to
+   acquire that token.  At a later time, the attacker may initiate a
+   0-RTT connection with a server by spoofing this same address, which
+   might now address a different (victim) endpoint.  The attacker can
+   thus potentially cause the server to send an initial congestion
+   window's worth of data towards the victim.
+
+   Servers SHOULD provide mitigations for this attack by limiting the
+   usage and lifetime of address validation tokens; see Section 8.1.3.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 140]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+21.3.  Optimistic ACK Attack
+
+   An endpoint that acknowledges packets it has not received might cause
+   a congestion controller to permit sending at rates beyond what the
+   network supports.  An endpoint MAY skip packet numbers when sending
+   packets to detect this behavior.  An endpoint can then immediately
+   close the connection with a connection error of type
+   PROTOCOL_VIOLATION; see Section 10.3.
+
+21.4.  Slowloris Attacks
+
+   The attacks commonly known as Slowloris [SLOWLORIS] try to keep many
+   connections to the target endpoint open and hold them open as long as
+   possible.  These attacks can be executed against a QUIC endpoint by
+   generating the minimum amount of activity necessary to avoid being
+   closed for inactivity.  This might involve sending small amounts of
+   data, gradually opening flow control windows in order to control the
+   sender rate, or manufacturing ACK frames that simulate a high loss
+   rate.
+
+   QUIC deployments SHOULD provide mitigations for the Slowloris
+   attacks, such as increasing the maximum number of clients the server
+   will allow, limiting the number of connections a single IP address is
+   allowed to make, imposing restrictions on the minimum transfer speed
+   a connection is allowed to have, and restricting the length of time
+   an endpoint is allowed to stay connected.
+
+21.5.  Stream Fragmentation and Reassembly Attacks
+
+   An adversarial sender might intentionally send fragments of stream
+   data in order to cause disproportionate receive buffer memory
+   commitment and/or creation of a large and inefficient data structure.
+
+   An adversarial receiver might intentionally not acknowledge packets
+   containing stream data in order to force the sender to store the
+   unacknowledged stream data for retransmission.
+
+   The attack on receivers is mitigated if flow control windows
+   correspond to available memory.  However, some receivers will over-
+   commit memory and advertise flow control offsets in the aggregate
+   that exceed actual available memory.  The over-commitment strategy
+   can lead to better performance when endpoints are well behaved, but
+   renders endpoints vulnerable to the stream fragmentation attack.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 141]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   QUIC deployments SHOULD provide mitigations against stream
+   fragmentation attacks.  Mitigations could consist of avoiding over-
+   committing memory, limiting the size of tracking data structures,
+   delaying reassembly of STREAM frames, implementing heuristics based
+   on the age and duration of reassembly holes, or some combination.
+
+21.6.  Stream Commitment Attack
+
+   An adversarial endpoint can open lots of streams, exhausting state on
+   an endpoint.  The adversarial endpoint could repeat the process on a
+   large number of connections, in a manner similar to SYN flooding
+   attacks in TCP.
+
+   Normally, clients will open streams sequentially, as explained in
+   Section 2.1.  However, when several streams are initiated at short
+   intervals, loss or reordering may cause STREAM frames that open
+   streams to be received out of sequence.  On receiving a higher-
+   numbered stream ID, a receiver is required to open all intervening
+   streams of the same type; see Section 3.2.  Thus, on a new
+   connection, opening stream 4000000 opens 1 million and 1 client-
+   initiated bidirectional streams.
+
+   The number of active streams is limited by the
+   initial_max_streams_bidi and initial_max_streams_uni transport
+   parameters, as explained in Section 4.5.  If chosen judiciously,
+   these limits mitigate the effect of the stream commitment attack.
+   However, setting the limit too low could affect performance when
+   applications expect to open large number of streams.
+
+21.7.  Peer Denial of Service
+
+   QUIC and TLS both contain messages that have legitimate uses in some
+   contexts, but that can be abused to cause a peer to expend processing
+   resources without having any observable impact on the state of the
+   connection.
+
+   Messages can also be used to change and revert state in small or
+   inconsequential ways, such as by sending small increments to flow
+   control limits.
+
+   If processing costs are disproportionately large in comparison to
+   bandwidth consumption or effect on state, then this could allow a
+   malicious peer to exhaust processing capacity.
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 142]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   While there are legitimate uses for all messages, implementations
+   SHOULD track cost of processing relative to progress and treat
+   excessive quantities of any non-productive packets as indicative of
+   an attack.  Endpoints MAY respond to this condition with a connection
+   error, or by dropping packets.
+
+21.8.  Explicit Congestion Notification Attacks
+
+   An on-path attacker could manipulate the value of ECN codepoints in
+   the IP header to influence the sender's rate.  [RFC3168] discusses
+   manipulations and their effects in more detail.
+
+   An on-the-side attacker can duplicate and send packets with modified
+   ECN codepoints to affect the sender's rate.  If duplicate packets are
+   discarded by a receiver, an off-path attacker will need to race the
+   duplicate packet against the original to be successful in this
+   attack.  Therefore, QUIC endpoints ignore the ECN codepoint field on
+   an IP packet unless at least one QUIC packet in that IP packet is
+   successfully processed; see Section 13.4.
+
+21.9.  Stateless Reset Oracle
+
+   Stateless resets create a possible denial of service attack analogous
+   to a TCP reset injection.  This attack is possible if an attacker is
+   able to cause a stateless reset token to be generated for a
+   connection with a selected connection ID.  An attacker that can cause
+   this token to be generated can reset an active connection with the
+   same connection ID.
+
+   If a packet can be routed to different instances that share a static
+   key, for example by changing an IP address or port, then an attacker
+   can cause the server to send a stateless reset.  To defend against
+   this style of denial service, endpoints that share a static key for
+   stateless reset (see Section 10.4.2) MUST be arranged so that packets
+   with a given connection ID always arrive at an instance that has
+   connection state, unless that connection is no longer active.
+
+   In the case of a cluster that uses dynamic load balancing, it's
+   possible that a change in load balancer configuration could happen
+   while an active instance retains connection state; even if an
+   instance retains connection state, the change in routing and
+   resulting stateless reset will result in the connection being
+   terminated.  If there is no chance in the packet being routed to the
+   correct instance, it is better to send a stateless reset than wait
+   for connections to time out.  However, this is acceptable only if the
+   routing cannot be influenced by an attacker.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 143]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+21.10.  Version Downgrade
+
+   This document defines QUIC Version Negotiation packets in Section 6,
+   which can be used to negotiate the QUIC version used between two
+   endpoints.  However, this document does not specify how this
+   negotiation will be performed between this version and subsequent
+   future versions.  In particular, Version Negotiation packets do not
+   contain any mechanism to prevent version downgrade attacks.  Future
+   versions of QUIC that use Version Negotiation packets MUST define a
+   mechanism that is robust against version downgrade attacks.
+
+21.11.  Targeted Attacks by Routing
+
+   Deployments should limit the ability of an attacker to target a new
+   connection to a particular server instance.  This means that client-
+   controlled fields, such as the initial Destination Connection ID used
+   on Initial and 0-RTT packets SHOULD NOT be used by themselves to make
+   routing decisions.  Ideally, routing decisions are made independently
+   of client-selected values; a Source Connection ID can be selected to
+   route later packets to the same server.
+
+21.12.  Overview of Security Properties
+
+   A complete security analysis of QUIC is outside the scope of this
+   document.  This section provides an informal description of the
+   desired security properties as an aid to implementors and to help
+   guide protocol analysis.
+
+   QUIC assumes the threat model described in [SEC-CONS] and provides
+   protections against many of the attacks that arise from that model.
+
+   For this purpose, attacks are divided into passive and active
+   attacks.  Passive attackers have the capability to read packets from
+   the network, while active attackers also have the capability to write
+   packets into the network.  However, a passive attack may involve an
+   attacker with the ability to cause a routing change or other
+   modification in the path taken by packets that comprise a connection.
+
+   Attackers are additionally categorized as either on-path attackers or
+   off-path attackers; see Section 3.5 of [SEC-CONS].  An on-path
+   attacker can read, modify, or remove any packet it observes such that
+   it no longer reaches its destination, while an off-path attacker
+   observes the packets, but cannot prevent the original packet from
+   reaching its intended destination.  An off-path attacker can also
+   transmit arbitrary packets.
+
+   Properties of the handshake, protected packets, and connection
+   migration are considered separately.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 144]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+21.12.1.  Handshake
+
+   The QUIC handshake incorporates the TLS 1.3 handshake and inherits
+   the cryptographic properties described in Appendix E.1 of [TLS13].
+   Many of the security properties of QUIC depend on the TLS handshake
+   providing these properties.  Any attack on the TLS handshake could
+   affect QUIC.
+
+   Any attack on the TLS handshake that compromises the secrecy or
+   uniqueness of session keys affects other security guarantees provided
+   by QUIC that depends on these keys.  For instance, migration
+   (Section 9) depends on the efficacy of confidentiality protections,
+   both for the negotiation of keys using the TLS handshake and for QUIC
+   packet protection, to avoid linkability across network paths.
+
+   An attack on the integrity of the TLS handshake might allow an
+   attacker to affect the selection of application protocol or QUIC
+   version.
+
+   In addition to the properties provided by TLS, the QUIC handshake
+   provides some defense against DoS attacks on the handshake.
+
+21.12.1.1.  Anti-Amplification
+
+   Address validation (Section 8) is used to verify that an entity that
+   claims a given address is able to receive packets at that address.
+   Address validation limits amplification attack targets to addresses
+   for which an attacker is either on-path or off-path.
+
+   Prior to validation, endpoints are limited in what they are able to
+   send.  During the handshake, a server cannot send more than three
+   times the data it receives; clients that initiate new connections or
+   migrate to a new network path are limited.
+
+21.12.1.2.  Server-Side DoS
+
+   Computing the server's first flight for a full handshake is
+   potentially expensive, requiring both a signature and a key exchange
+   computation.  In order to prevent computational DoS attacks, the
+   Retry packet provides a cheap token exchange mechanism which allows
+   servers to validate a client's IP address prior to doing any
+   expensive computations at the cost of a single round trip.  After a
+   successful handshake, servers can issue new tokens to a client which
+   will allow new connection establishment without incurring this cost.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 145]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+21.12.1.3.  On-Path Handshake Termination
+
+   An on-path or off-path attacker can force a handshake to fail by
+   replacing or racing Initial packets.  Once valid Initial packets have
+   been exchanged, subsequent Handshake packets are protected with the
+   handshake keys and an on-path attacker cannot force handshake failure
+   other than by dropping packets to cause endpoints to abandon the
+   attempt.
+
+   An on-path attacker can also replace the addresses of packets on
+   either side and therefore cause the client or server to have an
+   incorrect view of the remote addresses.  Such an attack is
+   indistinguishable from the functions performed by a NAT.
+
+21.12.1.4.  Parameter Negotiation
+
+   The entire handshake is cryptographically protected, with the Initial
+   packets being encrypted with per-version keys and the Handshake and
+   later packets being encrypted with keys derived from the TLS key
+   exchange.  Further, parameter negotiation is folded into the TLS
+   transcript and thus provides the same integrity guarantees as
+   ordinary TLS negotiation.  An attacker can observe the client's
+   transport parameters (as long as it knows the version-specific keys)
+   but cannot observe the server's transport parameters and cannot
+   influence parameter negotiation.
+
+   Connection IDs are unencrypted but integrity protected in all
+   packets.
+
+   This version of QUIC does not incorporate a version negotiation
+   mechanism; implementations of incompatible versions will simply fail
+   to establish a connection.
+
+21.12.2.  Protected Packets
+
+   Packet protection (Section 12.1) provides authentication and
+   encryption of all packets except Version Negotiation packets, though
+   Initial and Retry packets have limited encryption and authentication
+   based on version-specific keys; see [QUIC-TLS] for more details.
+   This section considers passive and active attacks against protected
+   packets.
+
+   Both on-path and off-path attackers can mount a passive attack in
+   which they save observed packets for an offline attack against packet
+   protection at a future time; this is true for any observer of any
+   packet on any network.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 146]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   A blind attacker, one who injects packets without being able to
+   observe valid packets for a connection, is unlikely to be successful,
+   since packet protection ensures that valid packets are only generated
+   by endpoints which possess the key material established during the
+   handshake; see Section 7 and Section 21.12.1.  Similarly, any active
+   attacker that observes packets and attempts to insert new data or
+   modify existing data in those packets should not be able to generate
+   packets deemed valid by the receiving endpoint.
+
+   A spoofing attack, in which an active attacker rewrites unprotected
+   parts of a packet that it forwards or injects, such as the source or
+   destination address, is only effective if the attacker can forward
+   packets to the original endpoint.  Packet protection ensures that the
+   packet payloads can only be processed by the endpoints that completed
+   the handshake, and invalid packets are ignored by those endpoints.
+
+   An attacker can also modify the boundaries between packets and UDP
+   datagrams, causing multiple packets to be coalesced into a single
+   datagram, or splitting coalesced packets into multiple datagrams.
+   Aside from datagrams containing Initial packets, which require
+   padding, modification of how packets are arranged in datagrams has no
+   functional effect on a connection, although it might change some
+   performance characteristics.
+
+21.12.3.  Connection Migration
+
+   Connection Migration (Section 9) provides endpoints with the ability
+   to transition between IP addresses and ports on multiple paths, using
+   one path at a time for transmission and receipt of non-probing
+   frames.  Path validation (Section 8.2) establishes that a peer is
+   both willing and able to receive packets sent on a particular path.
+   This helps reduce the effects of address spoofing by limiting the
+   number of packets sent to a spoofed address.
+
+   This section describes the intended security properties of connection
+   migration when under various types of DoS attacks.
+
+21.12.3.1.  On-Path Active Attacks
+
+   An attacker that can cause a packet it observes to no longer reach
+   its intended destination is considered an on-path attacker.  When an
+   attacker is present between a client and server, endpoints are
+   required to send packets through the attacker to establish
+   connectivity on a given path.
+
+   An on-path attacker can:
+
+   *  Inspect packets
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 147]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Modify IP and UDP packet headers
+
+   *  Inject new packets
+
+   *  Delay packets
+
+   *  Reorder packets
+
+   *  Drop packets
+
+   *  Split and merge datagrams along packet boundaries
+
+   An on-path attacker cannot:
+
+   *  Modify an authenticated portion of a packet and cause the
+      recipient to accept that packet
+
+   An on-path attacker has the opportunity to modify the packets that it
+   observes, however any modifications to an authenticated portion of a
+   packet will cause it to be dropped by the receiving endpoint as
+   invalid, as packet payloads are both authenticated and encrypted.
+
+   In the presence of an on-path attacker, QUIC aims to provide the
+   following properties:
+
+   1.  An on-path attacker can prevent use of a path for a connection,
+       causing it to fail if it cannot use a different path that does
+       not contain the attacker.  This can be achieved by dropping all
+       packets, modifying them so that they fail to decrypt, or other
+       methods.
+
+   2.  An on-path attacker can prevent migration to a new path for which
+       the attacker is also on-path by causing path validation to fail
+       on the new path.
+
+   3.  An on-path attacker cannot prevent a client from migrating to a
+       path for which the attacker is not on-path.
+
+   4.  An on-path attacker can reduce the throughput of a connection by
+       delaying packets or dropping them.
+
+   5.  An on-path attacker cannot cause an endpoint to accept a packet
+       for which it has modified an authenticated portion of that
+       packet.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 148]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+21.12.3.2.  Off-Path Active Attacks
+
+   An off-path attacker is not directly on the path between a client and
+   server, but could be able to obtain copies of some or all packets
+   sent between the client and the server.  It is also able to send
+   copies of those packets to either endpoint.
+
+   An off-path attacker can:
+
+   *  Inspect packets
+
+   *  Inject new packets
+
+   *  Reorder injected packets
+
+   An off-path attacker cannot:
+
+   *  Modify any part of a packet
+
+   *  Delay packets
+
+   *  Drop packets
+
+   *  Reorder original packets
+
+   An off-path attacker can modify packets that it has observed and
+   inject them back into the network, potentially with spoofed source
+   and destination addresses.
+
+   For the purposes of this discussion, it is assumed that an off-path
+   attacker has the ability to observe, modify, and re-inject a packet
+   into the network that will reach the destination endpoint prior to
+   the arrival of the original packet observed by the attacker.  In
+   other words, an attacker has the ability to consistently "win" a race
+   with the legitimate packets between the endpoints, potentially
+   causing the original packet to be ignored by the recipient.
+
+   It is also assumed that an attacker has the resources necessary to
+   affect NAT state, potentially both causing an endpoint to lose its
+   NAT binding, and an attacker to obtain the same port for use with its
+   traffic.
+
+   In the presence of an off-path attacker, QUIC aims to provide the
+   following properties:
+
+   1.  An off-path attacker can race packets and attempt to become a
+       "limited" on-path attacker.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 149]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   2.  An off-path attacker can cause path validation to succeed for
+       forwarded packets with the source address listed as the off-path
+       attacker as long as it can provide improved connectivity between
+       the client and the server.
+
+   3.  An off-path attacker cannot cause a connection to close once the
+       handshake has completed.
+
+   4.  An off-path attacker cannot cause migration to a new path to fail
+       if it cannot observe the new path.
+
+   5.  An off-path attacker can become a limited on-path attacker during
+       migration to a new path for which it is also an off-path
+       attacker.
+
+   6.  An off-path attacker can become a limited on-path attacker by
+       affecting shared NAT state such that it sends packets to the
+       server from the same IP address and port that the client
+       originally used.
+
+21.12.3.3.  Limited On-Path Active Attacks
+
+   A limited on-path attacker is an off-path attacker that has offered
+   improved routing of packets by duplicating and forwarding original
+   packets between the server and the client, causing those packets to
+   arrive before the original copies such that the original packets are
+   dropped by the destination endpoint.
+
+   A limited on-path attacker differs from an on-path attacker in that
+   it is not on the original path between endpoints, and therefore the
+   original packets sent by an endpoint are still reaching their
+   destination.  This means that a future failure to route copied
+   packets to the destination faster than their original path will not
+   prevent the original packets from reaching the destination.
+
+   A limited on-path attacker can:
+
+   *  Inspect packets
+
+   *  Inject new packets
+
+   *  Modify unencrypted packet headers
+
+   *  Reorder packets
+
+   A limited on-path attacker cannot:
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 150]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Delay packets so that they arrive later than packets sent on the
+      original path
+
+   *  Drop packets
+
+   *  Modify the authenticated and encrypted portion of a packet and
+      cause the recipient to accept that packet
+
+   A limited on-path attacker can only delay packets up to the point
+   that the original packets arrive before the duplicate packets,
+   meaning that it cannot offer routing with worse latency than the
+   original path.  If a limited on-path attacker drops packets, the
+   original copy will still arrive at the destination endpoint.
+
+   In the presence of a limited on-path attacker, QUIC aims to provide
+   the following properties:
+
+   1.  A limited on-path attacker cannot cause a connection to close
+       once the handshake has completed.
+
+   2.  A limited on-path attacker cannot cause an idle connection to
+       close if the client is first to resume activity.
+
+   3.  A limited on-path attacker can cause an idle connection to be
+       deemed lost if the server is the first to resume activity.
+
+   Note that these guarantees are the same guarantees provided for any
+   NAT, for the same reasons.
+
+22.  IANA Considerations
+
+   This document establishes several registries for the management of
+   codepoints in QUIC.  These registries operate on a common set of
+   policies as defined in Section 22.1.
+
+22.1.  Registration Policies for QUIC Registries
+
+   All QUIC registries allow for both provisional and permanent
+   registration of codepoints.  This section documents policies that are
+   common to these registries.
+
+22.1.1.  Provisional Registrations
+
+   Provisional registration of codepoints are intended to allow for
+   private use and experimentation with extensions to QUIC.  Provisional
+   registrations only require the inclusion of the codepoint value and
+   contact information.  However, provisional registrations could be
+   reclaimed and reassigned for another purpose.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 151]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   Provisional registrations require Expert Review, as defined in
+   Section 4.5 of [RFC8126].  Designated expert(s) are advised that only
+   registrations for an excessive proportion of remaining codepoint
+   space or the very first unassigned value (see Section 22.1.2) can be
+   rejected.
+
+   Provisional registrations will include a date field that indicates
+   when the registration was last updated.  A request to update the date
+   on any provisional registration can be made without review from the
+   designated expert(s).
+
+   All QUIC registries include the following fields to support
+   provisional registration:
+
+   Value:  The assigned codepoint.
+
+   Status:  "Permanent" or "Provisional".
+
+   Specification:  A reference to a publicly available specification for
+      the value.
+
+   Date:  The date of last update to the registration.
+
+   Contact:  Contact details for the registrant.
+
+   Notes:  Supplementary notes about the registration.
+
+   Provisional registrations MAY omit the Specification and Notes
+   fields, plus any additional fields that might be required for a
+   permanent registration.  The Date field is not required as part of
+   requesting a registration as it is set to the date the registration
+   is created or updated.
+
+22.1.2.  Selecting Codepoints
+
+   New uses of codepoints from QUIC registries SHOULD use a randomly
+   selected codepoint that excludes both existing allocations and the
+   first unallocated codepoint in the selected space.  Requests for
+   multiple codepoints MAY use a contiguous range.  This minimizes the
+   risk that differing semantics are attributed to the same codepoint by
+   different implementations.  Use of the first codepoint in a range is
+   intended for use by specifications that are developed through the
+   standards process [STD] and its allocation MUST be negotiated with
+   IANA before use.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 152]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   For codepoints that are encoded in variable-length integers
+   (Section 16), such as frame types, codepoints that encode to four or
+   eight bytes (that is, values 2^14 and above) SHOULD be used unless
+   the usage is especially sensitive to having a longer encoding.
+
+   Applications to register codepoints in QUIC registries MAY include a
+   codepoint as part of the registration.  IANA MUST allocate the
+   selected codepoint unless that codepoint is already assigned or the
+   codepoint is the first unallocated codepoint in the registry.
+
+22.1.3.  Reclaiming Provisional Codepoints
+
+   A request might be made to remove an unused provisional registration
+   from the registry to reclaim space in a registry, or portion of the
+   registry (such as the 64-16383 range for codepoints that use
+   variable-length encodings).  This SHOULD be done only for the
+   codepoints with the earliest recorded date and entries that have been
+   updated less than a year prior SHOULD NOT be reclaimed.
+
+   A request to remove a codepoint MUST be reviewed by the designated
+   expert(s).  The expert(s) MUST attempt to determine whether the
+   codepoint is still in use.  Experts are advised to contact the listed
+   contacts for the registration, plus as wide a set of protocol
+   implementers as possible in order to determine whether any use of the
+   codepoint is known.  The expert(s) are advised to allow at least four
+   weeks for responses.
+
+   If any use of the codepoints is identified by this search or a
+   request to update the registration is made, the codepoint MUST NOT be
+   reclaimed.  Instead, the date on the registration is updated.  A note
+   might be added for the registration recording relevant information
+   that was learned.
+
+   If no use of the codepoint was identified and no request was made to
+   update the registration, the codepoint MAY be removed from the
+   registry.
+
+   This process also applies to requests to change a provisional
+   registration into a permanent registration, except that the goal is
+   not to determine whether there is no use of the codepoint, but to
+   determine that the registration is an accurate representation of any
+   deployed usage.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 153]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+22.1.4.  Permanent Registrations
+
+   Permanent registrations in QUIC registries use the Specification
+   Required policy [RFC8126], unless otherwise specified.  The
+   designated expert(s) verify that a specification exists and is
+   readily accessible.  Expert(s) are encouraged to be biased towards
+   approving registrations unless they are abusive, frivolous, or
+   actively harmful (not merely aesthetically displeasing, or
+   architecturally dubious).  The creation of a registry MAY specify
+   additional constraints on permanent registrations.
+
+   The creation of a registries MAY identify a range of codepoints where
+   registrations are governed by a different registration policy.  For
+   instance, the registries for 62-bit codepoints in this document have
+   stricter policies for codepoints in the range from 0 to 63.
+
+   Any stricter requirements for permanent registrations do not prevent
+   provisional registrations for affected codepoints.  For instance, a
+   provisional registration for a frame type Section 22.3 of 61 could be
+   requested.
+
+   All registrations made by Standards Track publications MUST be
+   permanent.
+
+   All registrations in this document are assigned a permanent status
+   and list as contact both the IESG (ietf@ietf.org) and the QUIC
+   working group (quic@ietf.org (mailto:quic@ietf.org)).
+
+22.2.  QUIC Transport Parameter Registry
+
+   IANA [SHALL add/has added] a registry for "QUIC Transport Parameters"
+   under a "QUIC" heading.
+
+   The "QUIC Transport Parameters" registry governs a 62-bit space.
+   This registry follows the registration policy from Section 22.1.
+   Permanent registrations in this registry are assigned using the
+   Specification Required policy [RFC8126].
+
+   In addition to the fields in Section 22.1.1, permanent registrations
+   in this registry MUST include the following fields:
+
+   Parameter Name:  A short mnemonic for the parameter.
+
+   The initial contents of this registry are shown in Table 6.
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 154]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+      +-------+-------------------------------------+---------------+
+      | Value | Parameter Name                      | Specification |
+      +=======+=====================================+===============+
+      | 0x00  | original_destination_connection_id  | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x01  | max_idle_timeout                    | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x02  | stateless_reset_token               | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x03  | max_udp_payload_size                | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x04  | initial_max_data                    | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x05  | initial_max_stream_data_bidi_local  | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x06  | initial_max_stream_data_bidi_remote | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x07  | initial_max_stream_data_uni         | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x08  | initial_max_streams_bidi            | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x09  | initial_max_streams_uni             | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x0a  | ack_delay_exponent                  | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x0b  | max_ack_delay                       | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x0c  | disable_active_migration            | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x0d  | preferred_address                   | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x0e  | active_connection_id_limit          | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x0f  | initial_source_connection_id        | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+      | 0x10  | retry_source_connection_id          | Section 18.2  |
+      +-------+-------------------------------------+---------------+
+
+             Table 6: Initial QUIC Transport Parameters Entries
+
+   Additionally, each value of the format "31 * N + 27" for integer
+   values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be
+   assigned by IANA.
+
+22.3.  QUIC Frame Type Registry
+
+   IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
+   "QUIC" heading.
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 155]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The "QUIC Frame Types" registry governs a 62-bit space.  This
+   registry follows the registration policy from Section 22.1.
+   Permanent registrations in this registry are assigned using the
+   Specification Required policy [RFC8126], except for values between
+   0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
+   Standards Action or IESG Approval as defined in Section 4.9 and 4.10
+   of [RFC8126].
+
+   In addition to the fields in Section 22.1.1, permanent registrations
+   in this registry MUST include the following fields:
+
+   Frame Name:  A short mnemonic for the frame type.
+
+   In addition to the advice in Section 22.1, specifications for new
+   permanent registrations SHOULD describe the means by which an
+   endpoint might determine that it can send the identified type of
+   frame.  An accompanying transport parameter registration is expected
+   for most registrations; see Section 22.2.  Specifications for
+   permanent registrations also needs to describe the format and
+   assigned semantics of any fields in the frame.
+
+   The initial contents of this registry are tabulated in Table 3.
+
+22.4.  QUIC Transport Error Codes Registry
+
+   IANA [SHALL add/has added] a registry for "QUIC Transport Error
+   Codes" under a "QUIC" heading.
+
+   The "QUIC Transport Error Codes" registry governs a 62-bit space.
+   This space is split into three spaces that are governed by different
+   policies.  Permanent registrations in this registry are assigned
+   using the Specification Required policy [RFC8126], except for values
+   between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned
+   using Standards Action or IESG Approval as defined in Section 4.9 and
+   4.10 of [RFC8126].
+
+   In addition to the fields in Section 22.1.1, permanent registrations
+   in this registry MUST include the following fields:
+
+   Code:  A short mnemonic for the parameter.
+
+   Description:  A brief description of the error code semantics, which
+      MAY be a summary if a specification reference is provided.
+
+   The initial contents of this registry are shown in Table 7.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 156]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   +------+---------------------------+----------------+---------------+
+   |Value | Error                     | Description    | Specification |
+   +======+===========================+================+===============+
+   | 0x0  | NO_ERROR                  | No error       | Section 20    |
+   +------+---------------------------+----------------+---------------+
+   | 0x1  | INTERNAL_ERROR            | Implementation | Section 20    |
+   |      |                           | error          |               |
+   +------+---------------------------+----------------+---------------+
+   | 0x2  | CONNECTION_REFUSED_ERROR  |Server refuses a| Section 20    |
+   |      |                           | connection     |               |
+   +------+---------------------------+----------------+---------------+
+   | 0x3  | FLOW_CONTROL_ERROR        | Flow control   | Section 20    |
+   |      |                           | error          |               |
+   +------+---------------------------+----------------+---------------+
+   | 0x4  | STREAM_LIMIT_ERROR        |Too many streams| Section 20    |
+   |      |                           | opened         |               |
+   +------+---------------------------+----------------+---------------+
+   | 0x5  | STREAM_STATE_ERROR        | Frame received | Section 20    |
+   |      |                           | in invalid     |               |
+   |      |                           | stream state   |               |
+   +------+---------------------------+----------------+---------------+
+   | 0x6  | FINAL_SIZE_ERROR          |Change to final | Section 20    |
+   |      |                           | size           |               |
+   +------+---------------------------+----------------+---------------+
+   | 0x7  | FRAME_ENCODING_ERROR      | Frame encoding | Section 20    |
+   |      |                           | error          |               |
+   +------+---------------------------+----------------+---------------+
+   | 0x8  | TRANSPORT_PARAMETER_ERROR | Error in       | Section 20    |
+   |      |                           | transport      |               |
+   |      |                           | parameters     |               |
+   +------+---------------------------+----------------+---------------+
+   | 0x9  | CONNECTION_ID_LIMIT_ERROR | Too many       | Section 20    |
+   |      |                           | connection IDs |               |
+   |      |                           | received       |               |
+   +------+---------------------------+----------------+---------------+
+   | 0xA  | PROTOCOL_VIOLATION        |Generic protocol| Section 20    |
+   |      |                           | violation      |               |
+   +------+---------------------------+----------------+---------------+
+   | 0xB  | INVALID_TOKEN             | Invalid Token  | Section 20    |
+   |      |                           | Received       |               |
+   +------+---------------------------+----------------+---------------+
+   | 0xC  | APPLICATION_ERROR         | Application    | Section 20    |
+   |      |                           | error          |               |
+   +------+---------------------------+----------------+---------------+
+   | 0xD  | CRYPTO_BUFFER_EXCEEDED    | CRYPTO data    | Section 20    |
+   |      |                           | buffer         |               |
+   |      |                           | overflowed     |               |
+   +------+---------------------------+----------------+---------------+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 157]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+            Table 7: Initial QUIC Transport Error Codes Entries
+
+23.  References
+
+23.1.  Normative References
+
+   [DPLPMTUD] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
+              T. Voelker, "Packetization Layer Path MTU Discovery for
+              Datagram Transports", Work in Progress, Internet-Draft,
+              draft-ietf-tsvwg-datagram-plpmtud-21, 12 May 2020,
+              <http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-
+              datagram-plpmtud-21.txt>.
+
+   [IPv4]     Postel, J., "Internet Protocol", STD 5, RFC 791,
+              DOI 10.17487/RFC0791, September 1981,
+              <https://www.rfc-editor.org/info/rfc791>.
+
+   [QUIC-RECOVERY]
+              Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
+              and Congestion Control", Work in Progress, Internet-Draft,
+              draft-ietf-quic-recovery-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-recovery-
+              latest>.
+
+   [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport
+              Layer Security (TLS) to Secure QUIC", Work in Progress,
+              Internet-Draft, draft-ietf-quic-tls-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-tls-latest>.
+
+   [RFC1191]  Mogul, J.C. and S.E. Deering, "Path MTU discovery",
+              RFC 1191, DOI 10.17487/RFC1191, November 1990,
+              <https://www.rfc-editor.org/info/rfc1191>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, DOI 10.17487/RFC3168, September 2001,
+              <https://www.rfc-editor.org/info/rfc3168>.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+              2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 158]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
+              <https://www.rfc-editor.org/info/rfc5116>.
+
+   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
+              "IPv6 Flow Label Specification", RFC 6437,
+              DOI 10.17487/RFC6437, November 2011,
+              <https://www.rfc-editor.org/info/rfc6437>.
+
+   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+              March 2017, <https://www.rfc-editor.org/info/rfc8085>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
+              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
+              DOI 10.17487/RFC8201, July 2017,
+              <https://www.rfc-editor.org/info/rfc8201>.
+
+   [RFC8311]  Black, D., "Relaxing Restrictions on Explicit Congestion
+              Notification (ECN) Experimentation", RFC 8311,
+              DOI 10.17487/RFC8311, January 2018,
+              <https://www.rfc-editor.org/info/rfc8311>.
+
+   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+23.2.  Informative References
+
+   [ALTSVC]   Nottingham, M., McManus, P., and J. Reschke, "HTTP
+              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
+              April 2016, <https://www.rfc-editor.org/info/rfc7838>.
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 159]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   [EARLY-DESIGN]
+              Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2
+              December 2013, <https://goo.gl/dMVtFi>.
+
+   [HTTP2]    Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
+              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
+              DOI 10.17487/RFC7540, May 2015,
+              <https://www.rfc-editor.org/info/rfc7540>.
+
+   [QUIC-INVARIANTS]
+              Thomson, M., "Version-Independent Properties of QUIC",
+              Work in Progress, Internet-Draft, draft-ietf-quic-
+              invariants-latest, 3 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-invariants-
+              latest>.
+
+   [QUIC-MANAGEABILITY]
+              Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
+              Transport Protocol", Work in Progress, Internet-Draft,
+              draft-ietf-quic-manageability-06, 6 January 2020,
+              <http://www.ietf.org/internet-drafts/draft-ietf-quic-
+              manageability-06.txt>.
+
+   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
+              RFC 1812, DOI 10.17487/RFC1812, June 1995,
+              <https://www.rfc-editor.org/info/rfc1812>.
+
+   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
+              Selective Acknowledgment Options", RFC 2018,
+              DOI 10.17487/RFC2018, October 1996,
+              <https://www.rfc-editor.org/info/rfc2018>.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              DOI 10.17487/RFC2104, February 1997,
+              <https://www.rfc-editor.org/info/rfc2104>.
+
+   [RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
+              Sooriyabandara, "TCP Performance Implications of Network
+              Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
+              December 2002, <https://www.rfc-editor.org/info/rfc3449>.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+              Control Message Protocol (ICMPv6) for the Internet
+              Protocol Version 6 (IPv6) Specification", STD 89,
+              RFC 4443, DOI 10.17487/RFC4443, March 2006,
+              <https://www.rfc-editor.org/info/rfc4443>.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 160]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   [RFC4787]  Audet, F., Ed. and C. Jennings, "Network Address
+              Translation (NAT) Behavioral Requirements for Unicast
+              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
+              2007, <https://www.rfc-editor.org/info/rfc4787>.
+
+   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
+              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
+              <https://www.rfc-editor.org/info/rfc5681>.
+
+   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
+              Key Derivation Function (HKDF)", RFC 5869,
+              DOI 10.17487/RFC5869, May 2010,
+              <https://www.rfc-editor.org/info/rfc5869>.
+
+   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
+              "Transport Layer Security (TLS) Application-Layer Protocol
+              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
+              July 2014, <https://www.rfc-editor.org/info/rfc7301>.
+
+   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+   [SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+              Text on Security Considerations", BCP 72, RFC 3552,
+              DOI 10.17487/RFC3552, July 2003,
+              <https://www.rfc-editor.org/info/rfc3552>.
+
+   [SLOWLORIS]
+              RSnake Hansen, R., "Welcome to Slowloris...", June 2009,
+              <https://web.archive.org/web/20150315054838/
+              http://ha.ckers.org/slowloris/>.
+
+   [STD]      Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
+              <https://www.rfc-editor.org/info/rfc2026>.
+
+Appendix A.  Sample Packet Number Decoding Algorithm
+
+   The pseudo-code in Figure 41 shows how an implementation can decode
+   packet numbers after header protection has been removed.
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 161]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
+      expected_pn  = largest_pn + 1
+      pn_win       = 1 << pn_nbits
+      pn_hwin      = pn_win / 2
+      pn_mask      = pn_win - 1
+      // The incoming packet number should be greater than
+      // expected_pn - pn_hwin and less than or equal to
+      // expected_pn + pn_hwin
+      //
+      // This means we can't just strip the trailing bits from
+      // expected_pn and add the truncated_pn because that might
+      // yield a value outside the window.
+      //
+      // The following code calculates a candidate value and
+      // makes sure it's within the packet number window.
+      // Note the extra checks to prevent overflow and underflow.
+      candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
+      if candidate_pn <= expected_pn - pn_hwin and
+         candidate_pn < (1 << 62) - pn_win:
+         return candidate_pn + pn_win
+      if candidate_pn > expected_pn + pn_hwin and
+         candidate_pn >= pn_win:
+         return candidate_pn - pn_win
+      return candidate_pn
+
+             Figure 41: Sample Packet Number Decoding Algorithm
+
+Appendix B.  Sample ECN Validation Algorithm
+
+   Each time an endpoint commences sending on a new network path, it
+   determines whether the path supports ECN; see Section 13.4.  If the
+   path supports ECN, the goal is to use ECN.  Endpoints might also
+   periodically reassess a path that was determined to not support ECN.
+
+   This section describes one method for testing new paths.  This
+   algorithm is intended to show how a path might be tested for ECN
+   support.  Endpoints can implement different methods.
+
+   The path is assigned an ECN state that is one of "testing",
+   "unknown", "failed", or "capable".  On paths with a "testing" or
+   "capable" state the endpoint sends packets with an ECT marking, by
+   default ECT(0); otherwise, the endpoint sends unmarked packets.
+
+   To start testing a path, the ECN state is set to "testing" and
+   existing ECN counts are remembered as a baseline.
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 162]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   The testing period runs for a number of packets or round-trip times,
+   as determined by the endpoint.  The goal is not to limit the duration
+   of the testing period, but to ensure that enough marked packets are
+   sent for received ECN counts to provide a clear indication of how the
+   path treats marked packets.  Section 13.4.2.2 suggests limiting this
+   to 10 packets or 3 round-trip times.
+
+   After the testing period ends, the ECN state for the path becomes
+   "unknown".  From the "unknown" state, successful validation of the
+   ECN counts an ACK frame (see Section 13.4.2.2) causes the ECN state
+   for the path to become "capable", unless no marked packet has been
+   acknowledged.
+
+   If validation of ECN counts fails at any time, the ECN state for the
+   affected path becomes "failed".  An endpoint can also mark the ECN
+   state for a path as "failed" if marked packets are all declared lost
+   or if they are all CE marked.
+
+   Following this algorithm ensures that ECN is rarely disabled for
+   paths that properly support ECN.  Any path that incorrectly modifies
+   markings will cause ECN to be disabled.  For those rare cases where
+   marked packets are discarded by the path, the short duration of the
+   testing period limits the number of losses incurred.
+
+Appendix C.  Change Log
+
+      *RFC Editor's Note:* Please remove this section prior to
+      publication of a final version of this document.
+
+   Issue and pull request numbers are listed with a leading octothorp.
+
+C.1.  Since draft-ietf-quic-transport-27
+
+   *  Allowed CONNECTION_CLOSE in any packet number space, with a
+      requirement to use a new transport-level error for application-
+      specific errors in Initial and Handshake packets (#3430, #3435,
+      #3440)
+
+   *  Clearer requirements for address validation (#2125, #3327)
+
+   *  Security analysis of handshake and migration (#2143, #2387, #2925)
+
+   *  The entire payload of a datagram is used when counting bytes for
+      mitigating amplification attacks (#3333, #3470)
+
+   *  Connection IDs can be used at any time, including in the handshake
+      (#3348, #3560, #3438, #3565)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 163]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Only one ACK should be sent for each instance of reordering
+      (#3357, #3361)
+
+   *  Remove text allowing a server to proceed with a bad Retry token
+      (#3396, #3398)
+
+   *  Ignore active_connection_id_limit with a zero-length connection ID
+      (#3427, #3426)
+
+   *  Require active_connection_id_limit be remembered for 0-RTT (#3423,
+      #3425)
+
+   *  Require ack_delay not be remembered for 0-RTT (#3433, #3545)
+
+   *  Redefined max_packet_size to max_udp_datagram_size (#3471, #3473)
+
+   *  Guidance on limiting outstanding attempts to retire connection IDs
+      (#3489, #3509, #3557, #3547)
+
+   *  Restored text on dropping bogus Version Negotiation packets
+      (#3532, #3533)
+
+   *  Clarified that largest acknowledged needs to be saved, but not
+      necessarily signaled in all cases (#3541, #3581)
+
+   *  Addressed linkability risk with the use of preferred_address
+      (#3559, #3563)
+
+   *  Added authentication of handshake connection IDs (#3439, #3499)
+
+   *  Opening a stream in the wrong direction is an error (#3527)
+
+C.2.  Since draft-ietf-quic-transport-26
+
+   *  Change format of transport parameters to use varints (#3294,
+      #3169)
+
+C.3.  Since draft-ietf-quic-transport-25
+
+   *  Define the use of CONNECTION_CLOSE prior to establishing
+      connection state (#3269, #3297, #3292)
+
+   *  Allow use of address validation tokens after client address
+      changes (#3307, #3308)
+
+   *  Define the timer for address validation (#2910, #3339)
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 164]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+C.4.  Since draft-ietf-quic-transport-24
+
+   *  Added HANDSHAKE_DONE to signal handshake confirmation (#2863,
+      #3142, #3145)
+
+   *  Add integrity check to Retry packets (#3014, #3274, #3120)
+
+   *  Specify handling of reordered NEW_CONNECTION_ID frames (#3194,
+      #3202)
+
+   *  Require checking of sequence numbers in RETIRE_CONNECTION_ID
+      (#3037, #3036)
+
+   *  active_connection_id_limit is enforced (#3193, #3197, #3200,
+      #3201)
+
+   *  Correct overflow in packet number decode algorithm (#3187, #3188)
+
+   *  Allow use of CRYPTO_BUFFER_EXCEEDED for CRYPTO frame errors
+      (#3258, #3186)
+
+   *  Define applicability and scope of NEW_TOKEN (#3150, #3152, #3155,
+      #3156)
+
+   *  Tokens from Retry and NEW_TOKEN must be differentiated (#3127,
+      #3128)
+
+   *  Allow CONNECTION_CLOSE in response to invalid token (#3168, #3107)
+
+   *  Treat an invalid CONNECTION_CLOSE as an invalid frame (#2475,
+      #3230, #3231)
+
+   *  Throttle when sending CONNECTION_CLOSE after discarding state
+      (#3095, #3157)
+
+   *  Application-variant of CONNECTION_CLOSE can only be sent in 0-RTT
+      or 1-RTT packets (#3158, #3164)
+
+   *  Advise sending while blocked to avoid idle timeout (#2744, #3266)
+
+   *  Define error codes for invalid frames (#3027, #3042)
+
+   *  Idle timeout is symmetric (#2602, #3099)
+
+   *  Prohibit IP fragmentation (#3243, #3280)
+
+   *  Define the use of provisional registration for all registries
+      (#3109, #3020, #3102, #3170)
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 165]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Packets on one path must not adjust values for a different path
+      (#2909, #3139)
+
+C.5.  Since draft-ietf-quic-transport-23
+
+   *  Allow ClientHello to span multiple packets (#2928, #3045)
+
+   *  Client Initial size constraints apply to UDP datagram payload
+      (#3053, #3051)
+
+   *  Stateless reset changes (#2152, #2993)
+
+      -  tokens need to be compared in constant time
+
+      -  detection uses UDP datagrams, not packets
+
+      -  tokens cannot be reused (#2785, #2968)
+
+   *  Clearer rules for sharing of UDP ports and use of connection IDs
+      when doing so (#2844, #2851)
+
+   *  A new connection ID is necessary when responding to migration
+      (#2778, #2969)
+
+   *  Stronger requirements for connection ID retirement (#3046, #3096)
+
+   *  NEW_TOKEN cannot be empty (#2978, #2977)
+
+   *  PING can be sent at any encryption level (#3034, #3035)
+
+   *  CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)
+
+   *  Frame encoding error conditions updated (#3027, #3042)
+
+   *  Non-ack-eliciting packets cannot be sent in response to non-ack-
+      eliciting packets (#3100, #3104)
+
+   *  Servers have to change connection IDs in Retry (#2837, #3147)
+
+C.6.  Since draft-ietf-quic-transport-22
+
+   *  Rules for preventing correlation by connection ID tightened
+      (#2084, #2929)
+
+   *  Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
+      #2541, #2688)
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 166]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Discourage regressions of largest acknowledged in ACK (#2205,
+      #2752)
+
+   *  Improved robustness of validation process for ECN counts (#2534,
+      #2752)
+
+   *  Require endpoints to ignore spurious migration attempts (#2342,
+      #2893)
+
+   *  Transport parameter for disabling migration clarified to allow NAT
+      rebinding (#2389, #2893)
+
+   *  Document principles for defining new error codes (#2388, #2880)
+
+   *  Reserve transport parameters for greasing (#2550, #2873)
+
+   *  A maximum ACK delay of 0 is used for handshake packet number
+      spaces (#2646, #2638)
+
+   *  Improved rules for use of congestion control state on new paths
+      (#2685, #2918)
+
+   *  Removed recommendation to coordinate spin for multiple connections
+      that share a path (#2763, #2882)
+
+   *  Allow smaller stateless resets and recommend a smaller minimum on
+      packets that might trigger a stateless reset (#2770, #2869, #2927,
+      #3007).
+
+   *  Provide guidance around the interface to QUIC as used by
+      application protocols (#2805, #2857)
+
+   *  Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825,
+      #2826)
+
+   *  Tighter rules about processing of rejected 0-RTT packets (#2829,
+      #2840, #2841)
+
+   *  Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
+
+   *  Cryptographic handshake needs to provide server transport
+      parameter encryption (#2920, #2921)
+
+   *  Moved ACK generation guidance from recovery draft to transport
+      draft (#1860, #2916).
+
+C.7.  Since draft-ietf-quic-transport-21
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 167]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Connection ID lengths are now one octet, but limited in version 1
+      to 20 octets of length (#2736, #2749)
+
+C.8.  Since draft-ietf-quic-transport-20
+
+   *  Error codes are encoded as variable-length integers (#2672, #2680)
+
+   *  NEW_CONNECTION_ID includes a request to retire old connection IDs
+      (#2645, #2769)
+
+   *  Tighter rules for generating and explicitly eliciting ACK frames
+      (#2546, #2794)
+
+   *  Recommend having only one packet per encryption level in a
+      datagram (#2308, #2747)
+
+   *  More normative language about use of stateless reset (#2471,
+      #2574)
+
+   *  Allow reuse of stateless reset tokens (#2732, #2733)
+
+   *  Allow, but not require, enforcing non-duplicate transport
+      parameters (#2689, #2691)
+
+   *  Added an active_connection_id_limit transport parameter (#1994,
+      #1998)
+
+   *  max_ack_delay transport parameter defaults to 0 (#2638, #2646)
+
+   *  When sending 0-RTT, only remembered transport parameters apply
+      (#2458, #2360, #2466, #2461)
+
+   *  Define handshake completion and confirmation; define clearer rules
+      when it encryption keys should be discarded (#2214, #2267, #2673)
+
+   *  Prohibit path migration prior to handshake confirmation (#2309,
+      #2370)
+
+   *  PATH_RESPONSE no longer needs to be received on the validated path
+      (#2582, #2580, #2579, #2637)
+
+   *  PATH_RESPONSE frames are not stored and retransmitted (#2724,
+      #2729)
+
+   *  Document hack for enabling routing of ICMP when doing PMTU probing
+      (#1243, #2402)
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 168]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+C.9.  Since draft-ietf-quic-transport-19
+
+   *  Refine discussion of 0-RTT transport parameters (#2467, #2464)
+
+   *  Fewer transport parameters need to be remembered for 0-RTT (#2624,
+      #2467)
+
+   *  Spin bit text incorporated (#2564)
+
+   *  Close the connection when maximum stream ID in MAX_STREAMS exceeds
+      2^62 - 1 (#2499, #2487)
+
+   *  New connection ID required for intentional migration (#2414,
+      #2413)
+
+   *  Connection ID issuance can be rate-limited (#2436, #2428)
+
+   *  The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
+
+   *  Initial packets from clients need to be padded to 1200 unless a
+      Handshake packet is sent as well (#2522, #2523)
+
+   *  CRYPTO frames can be discarded if too much data is buffered
+      (#1834, #2524)
+
+   *  Stateless reset uses a short header packet (#2599, #2600)
+
+C.10.  Since draft-ietf-quic-transport-18
+
+   *  Removed version negotiation; version negotiation, including
+      authentication of the result, will be addressed in the next
+      version of QUIC (#1773, #2313)
+
+   *  Added discussion of the use of IPv6 flow labels (#2348, #2399)
+
+   *  A connection ID can't be retired in a packet that uses that
+      connection ID (#2101, #2420)
+
+   *  Idle timeout transport parameter is in milliseconds (from seconds)
+      (#2453, #2454)
+
+   *  Endpoints are required to use new connection IDs when they use new
+      network paths (#2413, #2414)
+
+   *  Increased the set of permissible frames in 0-RTT (#2344, #2355)
+
+C.11.  Since draft-ietf-quic-transport-17
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 169]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Stream-related errors now use STREAM_STATE_ERROR (#2305)
+
+   *  Endpoints discard initial keys as soon as handshake keys are
+      available (#1951, #2045)
+
+   *  Expanded conditions for ignoring ICMP packet too big messages
+      (#2108, #2161)
+
+   *  Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
+      #2241)
+
+   *  Endpoints are permitted to discard malformed initial packets
+      (#2141)
+
+   *  Clarified ECN implementation and usage requirements (#2156, #2201)
+
+   *  Disable ECN count verification for packets that arrive out of
+      order (#2198, #2215)
+
+   *  Use Probe Timeout (PTO) instead of RTO (#2206, #2238)
+
+   *  Loosen constraints on retransmission of ACK ranges (#2199, #2245)
+
+   *  Limit Retry and Version Negotiation to once per datagram (#2259,
+      #2303)
+
+   *  Set a maximum value for max_ack_delay transport parameter (#2282,
+      #2301)
+
+   *  Allow server preferred address for both IPv4 and IPv6 (#2122,
+      #2296)
+
+   *  Corrected requirements for migration to a preferred address
+      (#2146, #2349)
+
+   *  ACK of non-existent packet is illegal (#2298, #2302)
+
+C.12.  Since draft-ietf-quic-transport-16
+
+   *  Stream limits are defined as counts, not maximums (#1850, #1906)
+
+   *  Require amplification attack defense after closing (#1905, #1911)
+
+   *  Remove reservation of application error code 0 for STOPPING
+      (#1804, #1922)
+
+   *  Renumbered frames (#1945)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 170]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Renumbered transport parameters (#1946)
+
+   *  Numeric transport parameters are expressed as varints (#1608,
+      #1947, #1955)
+
+   *  Reorder the NEW_CONNECTION_ID frame (#1952, #1963)
+
+   *  Rework the first byte (#2006)
+
+      -  Fix the 0x40 bit
+
+      -  Change type values for long header
+
+      -  Add spin bit to short header (#631, #1988)
+
+      -  Encrypt the remainder of the first byte (#1322)
+
+      -  Move packet number length to first byte
+
+      -  Move ODCIL to first byte of retry packets
+
+      -  Simplify packet number protection (#1575)
+
+   *  Allow STOP_SENDING to open a remote bidirectional stream (#1797,
+      #2013)
+
+   *  Added mitigation for off-path migration attacks (#1278, #1749,
+      #2033)
+
+   *  Don't let the PMTU to drop below 1280 (#2063, #2069)
+
+   *  Require peers to replace retired connection IDs (#2085)
+
+   *  Servers are required to ignore Version Negotiation packets (#2088)
+
+   *  Tokens are repeated in all Initial packets (#2089)
+
+   *  Clarified how PING frames are sent after loss (#2094)
+
+   *  Initial keys are discarded once Handshake are available (#1951,
+      #2045)
+
+   *  ICMP PTB validation clarifications (#2161, #2109, #2108)
+
+C.13.  Since draft-ietf-quic-transport-15
+
+   Substantial editorial reorganization; no technical changes.
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 171]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+C.14.  Since draft-ietf-quic-transport-14
+
+   *  Merge ACK and ACK_ECN (#1778, #1801)
+
+   *  Explicitly communicate max_ack_delay (#981, #1781)
+
+   *  Validate original connection ID after Retry packets (#1710, #1486,
+      #1793)
+
+   *  Idle timeout is optional and has no specified maximum (#1765)
+
+   *  Update connection ID handling; add RETIRE_CONNECTION_ID type
+      (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
+      #1821)
+
+   *  Include a Token in all Initial packets (#1649, #1794)
+
+   *  Prevent handshake deadlock (#1764, #1824)
+
+C.15.  Since draft-ietf-quic-transport-13
+
+   *  Streams open when higher-numbered streams of the same type open
+      (#1342, #1549)
+
+   *  Split initial stream flow control limit into 3 transport
+      parameters (#1016, #1542)
+
+   *  All flow control transport parameters are optional (#1610)
+
+   *  Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
+
+   *  Permit stateless reset in response to any packet (#1348, #1553)
+
+   *  Recommended defense against stateless reset spoofing (#1386,
+      #1554)
+
+   *  Prevent infinite stateless reset exchanges (#1443, #1627)
+
+   *  Forbid processing of the same packet number twice (#1405, #1624)
+
+   *  Added a packet number decoding example (#1493)
+
+   *  More precisely define idle timeout (#1429, #1614, #1652)
+
+   *  Corrected format of Retry packet and prevented looping (#1492,
+      #1451, #1448, #1498)
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 172]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
+      #1514, #1621)
+
+   *  Permit Retry in response to 0-RTT (#1547, #1552)
+
+   *  Looser verification of ECN counters to account for ACK loss
+      (#1555, #1481, #1565)
+
+   *  Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
+
+C.16.  Since draft-ietf-quic-transport-12
+
+   *  Changes to integration of the TLS handshake (#829, #1018, #1094,
+      #1165, #1190, #1233, #1242, #1252, #1450, #1458)
+
+      -  The cryptographic handshake uses CRYPTO frames, not stream 0
+
+      -  QUIC packet protection is used in place of TLS record
+         protection
+
+      -  Separate QUIC packet number spaces are used for the handshake
+
+      -  Changed Retry to be independent of the cryptographic handshake
+
+      -  Added NEW_TOKEN frame and Token fields to Initial packet
+
+      -  Limit the use of HelloRetryRequest to address TLS needs (like
+         key shares)
+
+   *  Enable server to transition connections to a preferred address
+      (#560, #1251, #1373)
+
+   *  Added ECN feedback mechanisms and handling; new ACK_ECN frame
+      (#804, #805, #1372)
+
+   *  Changed rules and recommendations for use of new connection IDs
+      (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465)
+
+   *  Added a transport parameter to disable intentional connection
+      migration (#1271, #1447)
+
+   *  Packets from different connection ID can't be coalesced (#1287,
+      #1423)
+
+   *  Fixed sampling method for packet number encryption; the length
+      field in long headers includes the packet number field in addition
+      to the packet payload (#1387, #1389)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 173]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Stateless Reset is now symmetric and subject to size constraints
+      (#466, #1346)
+
+   *  Added frame type extension mechanism (#58, #1473)
+
+C.17.  Since draft-ietf-quic-transport-11
+
+   *  Enable server to transition connections to a preferred address
+      (#560, #1251)
+
+   *  Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
+      #990, #734, #1317, #1267, #1079)
+
+   *  Packet numbers use a variable-length encoding (#989, #1334)
+
+   *  STREAM frames can now be empty (#1350)
+
+C.18.  Since draft-ietf-quic-transport-10
+
+   *  Swap payload length and packed number fields in long header
+      (#1294)
+
+   *  Clarified that CONNECTION_CLOSE is allowed in Handshake packet
+      (#1274)
+
+   *  Spin bit reserved (#1283)
+
+   *  Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
+
+   *  A more complete connection migration (#1249)
+
+   *  Refine opportunistic ACK defense text (#305, #1030, #1185)
+
+   *  A Stateless Reset Token isn't mandatory (#818, #1191)
+
+   *  Removed implicit stream opening (#896, #1193)
+
+   *  An empty STREAM frame can be used to open a stream without sending
+      data (#901, #1194)
+
+   *  Define stream counts in transport parameters rather than a maximum
+      stream ID (#1023, #1065)
+
+   *  STOP_SENDING is now prohibited before streams are used (#1050)
+
+   *  Recommend including ACK in Retry packets and allow PADDING (#1067,
+      #882)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 174]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Endpoints now become closing after an idle timeout (#1178, #1179)
+
+   *  Remove implication that Version Negotiation is sent when a packet
+      of the wrong version is received (#1197)
+
+C.19.  Since draft-ietf-quic-transport-09
+
+   *  Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
+      Data and PONG frame.  Changed ACK frame type from 0x0e to 0x0d.
+      (#1091, #725, #1086)
+
+   *  A server can now only send 3 packets without validating the client
+      address (#38, #1090)
+
+   *  Delivery order of stream data is no longer strongly specified
+      (#252, #1070)
+
+   *  Rework of packet handling and version negotiation (#1038)
+
+   *  Stream 0 is now exempt from flow control until the handshake
+      completes (#1074, #725, #825, #1082)
+
+   *  Improved retransmission rules for all frame types: information is
+      retransmitted, not packets or frames (#463, #765, #1095, #1053)
+
+   *  Added an error code for server busy signals (#1137)
+
+   *  Endpoints now set the connection ID that their peer uses.
+      Connection IDs are variable length.  Removed the
+      omit_connection_id transport parameter and the corresponding short
+      header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
+
+C.20.  Since draft-ietf-quic-transport-08
+
+   *  Clarified requirements for BLOCKED usage (#65, #924)
+
+   *  BLOCKED frame now includes reason for blocking (#452, #924, #927,
+      #928)
+
+   *  GAP limitation in ACK Frame (#613)
+
+   *  Improved PMTUD description (#614, #1036)
+
+   *  Clarified stream state machine (#634, #662, #743, #894)
+
+   *  Reserved versions don't need to be generated deterministically
+      (#831, #931)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 175]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  You don't always need the draining period (#871)
+
+   *  Stateless reset clarified as version-specific (#930, #986)
+
+   *  initial_max_stream_id_x transport parameters are optional (#970,
+      #971)
+
+   *  Ack Delay assumes a default value during the handshake (#1007,
+      #1009)
+
+   *  Removed transport parameters from NewSessionTicket (#1015)
+
+C.21.  Since draft-ietf-quic-transport-07
+
+   *  The long header now has version before packet number (#926, #939)
+
+   *  Rename and consolidate packet types (#846, #822, #847)
+
+   *  Packet types are assigned new codepoints and the Connection ID
+      Flag is inverted (#426, #956)
+
+   *  Removed type for Version Negotiation and use Version 0 (#963,
+      #968)
+
+   *  Streams are split into unidirectional and bidirectional (#643,
+      #656, #720, #872, #175, #885)
+
+      -  Stream limits now have separate uni- and bi-directional
+         transport parameters (#909, #958)
+
+      -  Stream limit transport parameters are now optional and default
+         to 0 (#970, #971)
+
+   *  The stream state machine has been split into read and write (#634,
+      #894)
+
+   *  Employ variable-length integer encodings throughout (#595)
+
+   *  Improvements to connection close
+
+      -  Added distinct closing and draining states (#899, #871)
+
+      -  Draining period can terminate early (#869, #870)
+
+      -  Clarifications about stateless reset (#889, #890)
+
+   *  Address validation for connection migration (#161, #732, #878)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 176]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
+
+   *  negotiated_version is sent in server transport parameters (#710,
+      #959)
+
+   *  Increased the range over which packet numbers are randomized
+      (#864, #850, #964)
+
+C.22.  Since draft-ietf-quic-transport-06
+
+   *  Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
+
+   *  Split error code space between application and transport (#485)
+
+   *  Stateless reset token moved to end (#820)
+
+   *  1-RTT-protected long header types removed (#848)
+
+   *  No acknowledgments during draining period (#852)
+
+   *  Remove "application close" as a separate close type (#854)
+
+   *  Remove timestamps from the ACK frame (#841)
+
+   *  Require transport parameters to only appear once (#792)
+
+C.23.  Since draft-ietf-quic-transport-05
+
+   *  Stateless token is server-only (#726)
+
+   *  Refactor section on connection termination (#733, #748, #328,
+      #177)
+
+   *  Limit size of Version Negotiation packet (#585)
+
+   *  Clarify when and what to ack (#736)
+
+   *  Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
+
+   *  Clarify Keep-alive requirements (#729)
+
+C.24.  Since draft-ietf-quic-transport-04
+
+   *  Introduce STOP_SENDING frame, RESET_STREAM only resets in one
+      direction (#165)
+
+   *  Removed GOAWAY; application protocols are responsible for graceful
+      shutdown (#696)
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 177]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Reduced the number of error codes (#96, #177, #184, #211)
+
+   *  Version validation fields can't move or change (#121)
+
+   *  Removed versions from the transport parameters in a
+      NewSessionTicket message (#547)
+
+   *  Clarify the meaning of "bytes in flight" (#550)
+
+   *  Public reset is now stateless reset and not visible to the path
+      (#215)
+
+   *  Reordered bits and fields in STREAM frame (#620)
+
+   *  Clarifications to the stream state machine (#572, #571)
+
+   *  Increased the maximum length of the Largest Acknowledged field in
+      ACK frames to 64 bits (#629)
+
+   *  truncate_connection_id is renamed to omit_connection_id (#659)
+
+   *  CONNECTION_CLOSE terminates the connection like TCP RST (#330,
+      #328)
+
+   *  Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
+
+C.25.  Since draft-ietf-quic-transport-03
+
+   *  Change STREAM and RESET_STREAM layout
+
+   *  Add MAX_STREAM_ID settings
+
+C.26.  Since draft-ietf-quic-transport-02
+
+   *  The size of the initial packet payload has a fixed minimum (#267,
+      #472)
+
+   *  Define when Version Negotiation packets are ignored (#284, #294,
+      #241, #143, #474)
+
+   *  The 64-bit FNV-1a algorithm is used for integrity protection of
+      unprotected packets (#167, #480, #481, #517)
+
+   *  Rework initial packet types to change how the connection ID is
+      chosen (#482, #442, #493)
+
+   *  No timestamps are forbidden in unprotected packets (#542, #429)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 178]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Cryptographic handshake is now on stream 0 (#456)
+
+   *  Remove congestion control exemption for cryptographic handshake
+      (#248, #476)
+
+   *  Version 1 of QUIC uses TLS; a new version is needed to use a
+      different handshake protocol (#516)
+
+   *  STREAM frames have a reduced number of offset lengths (#543, #430)
+
+   *  Split some frames into separate connection- and stream- level
+      frames (#443)
+
+      -  WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450)
+
+      -  BLOCKED split to match WINDOW_UPDATE split (#454)
+
+      -  Define STREAM_ID_NEEDED frame (#455)
+
+   *  A NEW_CONNECTION_ID frame supports connection migration without
+      linkability (#232, #491, #496)
+
+   *  Transport parameters for 0-RTT are retained from a previous
+      connection (#405, #513, #512)
+
+      -  A client in 0-RTT no longer required to reset excess streams
+         (#425, #479)
+
+   *  Expanded security considerations (#440, #444, #445, #448)
+
+C.27.  Since draft-ietf-quic-transport-01
+
+   *  Defined short and long packet headers (#40, #148, #361)
+
+   *  Defined a versioning scheme and stable fields (#51, #361)
+
+   *  Define reserved version values for "greasing" negotiation (#112,
+      #278)
+
+   *  The initial packet number is randomized (#35, #283)
+
+   *  Narrow the packet number encoding range requirement (#67, #286,
+      #299, #323, #356)
+
+   *  Defined client address validation (#52, #118, #120, #275)
+
+   *  Define transport parameters as a TLS extension (#49, #122)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 179]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  SCUP and COPT parameters are no longer valid (#116, #117)
+
+   *  Transport parameters for 0-RTT are either remembered from before,
+      or assume default values (#126)
+
+   *  The server chooses connection IDs in its final flight (#119, #349,
+      #361)
+
+   *  The server echoes the Connection ID and packet number fields when
+      sending a Version Negotiation packet (#133, #295, #244)
+
+   *  Defined a minimum packet size for the initial handshake packet
+      from the client (#69, #136, #139, #164)
+
+   *  Path MTU Discovery (#64, #106)
+
+   *  The initial handshake packet from the client needs to fit in a
+      single packet (#338)
+
+   *  Forbid acknowledgment of packets containing only ACK and PADDING
+      (#291)
+
+   *  Require that frames are processed when packets are acknowledged
+      (#381, #341)
+
+   *  Removed the STOP_WAITING frame (#66)
+
+   *  Don't require retransmission of old timestamps for lost ACK frames
+      (#308)
+
+   *  Clarified that frames are not retransmitted, but the information
+      in them can be (#157, #298)
+
+   *  Error handling definitions (#335)
+
+   *  Split error codes into four sections (#74)
+
+   *  Forbid the use of Public Reset where CONNECTION_CLOSE is possible
+      (#289)
+
+   *  Define packet protection rules (#336)
+
+   *  Require that stream be entirely delivered or reset, including
+      acknowledgment of all STREAM frames or the RESET_STREAM, before it
+      closes (#381)
+
+   *  Remove stream reservation from state machine (#174, #280)
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 180]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Only stream 1 does not contribute to connection-level flow control
+      (#204)
+
+   *  Stream 1 counts towards the maximum concurrent stream limit (#201,
+      #282)
+
+   *  Remove connection-level flow control exclusion for some streams
+      (except 1) (#246)
+
+   *  RESET_STREAM affects connection-level flow control (#162, #163)
+
+   *  Flow control accounting uses the maximum data offset on each
+      stream, rather than bytes received (#378)
+
+   *  Moved length-determining fields to the start of STREAM and ACK
+      (#168, #277)
+
+   *  Added the ability to pad between frames (#158, #276)
+
+   *  Remove error code and reason phrase from GOAWAY (#352, #355)
+
+   *  GOAWAY includes a final stream number for both directions (#347)
+
+   *  Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
+      consistent offset (#249)
+
+   *  Defined priority as the responsibility of the application protocol
+      (#104, #303)
+
+C.28.  Since draft-ietf-quic-transport-00
+
+   *  Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
+
+   *  Defined versioning
+
+   *  Reworked description of packet and frame layout
+
+   *  Error code space is divided into regions for each component
+
+   *  Use big endian for all numeric values
+
+C.29.  Since draft-hamilton-quic-transport-protocol-01
+
+   *  Adopted as base for draft-ietf-quic-tls
+
+   *  Updated authors/editors list
+
+   *  Added IANA Considerations section
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 181]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Moved Contributors and Acknowledgments to appendices
+
+Contributors
+
+   The original design and rationale behind this protocol draw
+   significantly from work by Jim Roskind [EARLY-DESIGN].
+
+   The IETF QUIC Working Group received an enormous amount of support
+   from many people.  The following people provided substantive
+   contributions to this document:
+
+   *  Alessandro Ghedini
+
+   *  Alyssa Wilk
+
+   *  Antoine Delignat-Lavaud
+
+   *  Brian Trammell
+
+   *  Christian Huitema
+
+   *  Colin Perkins
+
+   *  David Schinazi
+
+   *  Dmitri Tikhonov
+
+   *  Eric Kinnear
+
+   *  Eric Rescorla
+
+   *  Gorry Fairhurst
+
+   *  Ian Swett
+
+   *  Igor Lubashev
+
+   *  奥 一穂 (Kazuho Oku)
+
+   *  Lucas Pardue
+
+   *  Magnus Westerlund
+
+   *  Marten Seemann
+
+   *  Martin Duke
+
+   *  Mike Bishop
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 182]
+
+Internet-Draft           QUIC Transport Protocol               June 2020
+
+
+   *  Mikkel Fahnøe Jørgensen
+
+   *  Mirja Kühlewind
+
+   *  Nick Banks
+
+   *  Nick Harper
+
+   *  Patrick McManus
+
+   *  Roberto Peon
+
+   *  Ryan Hamilton
+
+   *  Subodh Iyengar
+
+   *  Tatsuhiro Tsujikawa
+
+   *  Ted Hardie
+
+   *  Tom Jones
+
+   *  Victor Vasiliev
+
+Authors' Addresses
+
+   Jana Iyengar (editor)
+   Fastly
+
+   Email: jri.ietf@gmail.com
+
+
+   Martin Thomson (editor)
+   Mozilla
+
+   Email: mt@lowentropy.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson        Expires 5 December 2020              [Page 183]
diff --git a/jri/mustnot/index.html b/jri/mustnot/index.html
new file mode 100644
index 0000000000..df1b731492
--- /dev/null
+++ b/jri/mustnot/index.html
@@ -0,0 +1,107 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>quicwg/base-drafts jri/mustnot preview</title>
+    <meta name="viewport" content="initial-scale=1.0">
+    <style type="text/css">/*<![CDATA[*/
+      body { font-family: "Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif; }
+      h1, h2, td { font-family: "Helvetica Neue","Roboto Condensed","Open Sans",Helvetica,Calibri,sans-serif; }
+      h1 { font-size: 20px; } h2 { font-size: 16px; }
+      table { margin: 5px 10px; border-collapse: collapse; }
+      th, td { font-weight: normal; text-align: left; padding: 2px 5px; }
+      a:link { color: #000; } a:visited { color: #00a; }
+    /*]]>*/</style>
+  </head>
+  <body>
+    <h1>Editor's drafts for jri/mustnot branch of <a href="https://github.com/quicwg/base-drafts/tree/jri/mustnot">quicwg/base-drafts</a></h1>
+    <p>View <a href="issues.html">saved issues</a>,
+      or the latest GitHub <a href="https://github.com/quicwg/base-drafts/issues">issues</a>
+      and <a href="https://github.com/quicwg/base-drafts/pulls">pull requests</a>.</p>
+    <table id="branch-jri/mustnot">
+      <tr>
+        <th>draft-ietf-quic-http</th>
+        <td><a href="./draft-ietf-quic-http.html"
+           class="html draft-ietf-quic-http">html</a></td>
+        <td><a href="./draft-ietf-quic-http.txt"
+           class="txt draft-ietf-quic-http">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-http.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-http.txt" class="diff draft-ietf-quic-http">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-invariants</th>
+        <td><a href="./draft-ietf-quic-invariants.html"
+           class="html draft-ietf-quic-invariants">html</a></td>
+        <td><a href="./draft-ietf-quic-invariants.txt"
+           class="txt draft-ietf-quic-invariants">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-invariants.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-invariants.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-invariants.txt" class="diff draft-ietf-quic-invariants">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-qpack</th>
+        <td><a href="./draft-ietf-quic-qpack.html"
+           class="html draft-ietf-quic-qpack">html</a></td>
+        <td><a href="./draft-ietf-quic-qpack.txt"
+           class="txt draft-ietf-quic-qpack">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-qpack.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-qpack.txt" class="diff draft-ietf-quic-qpack">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-recovery</th>
+        <td><a href="./draft-ietf-quic-recovery.html"
+           class="html draft-ietf-quic-recovery">html</a></td>
+        <td><a href="./draft-ietf-quic-recovery.txt"
+           class="txt draft-ietf-quic-recovery">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-recovery.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-recovery.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-recovery.txt" class="diff draft-ietf-quic-recovery">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-tls</th>
+        <td><a href="./draft-ietf-quic-tls.html"
+           class="html draft-ietf-quic-tls">html</a></td>
+        <td><a href="./draft-ietf-quic-tls.txt"
+           class="txt draft-ietf-quic-tls">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-tls.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-tls.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-tls.txt" class="diff draft-ietf-quic-tls">
+          diff with last submission</a></td>
+      </tr>
+      <tr>
+        <th>draft-ietf-quic-transport</th>
+        <td><a href="./draft-ietf-quic-transport.html"
+           class="html draft-ietf-quic-transport">html</a></td>
+        <td><a href="./draft-ietf-quic-transport.txt"
+           class="txt draft-ietf-quic-transport">plain text</a></td>
+        <td><a href=https://tools.ietf.org/rfcdiff?url1=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-transport.txt>diff with master</a></td>
+        <td><a href="https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport.txt&amp;url2=https://quicwg.github.io/base-drafts/jri/mustnot/draft-ietf-quic-transport.txt" class="diff draft-ietf-quic-transport">
+          diff with last submission</a></td>
+      </tr>
+    </table>
+    <script>
+// @licstart
+//  Any copyright is dedicated to the Public Domain.
+//  http://creativecommons.org/publicdomain/zero/1.0/
+// @licend
+window.onload = function() {
+  var referrer_branch = 'master';
+  // e.g., "https://github.com/user/repo/tree/master"
+  var chunks = document.referrer.split("/");
+  if (chunks[2] === 'github.com' && chunks[5] === 'tree') {
+    referrer_branch = chunks[6];
+  }
+  let branch = document.querySelector('#branch-' + referrer_branch);
+  let h = document.location.hash.substring(1);
+  if (h === 'show') {
+    document.location.hash = '#' + branch.id;
+  } else if (branch && h.startsWith('go')) {
+    let e = branch.querySelector(h.substring(2));
+    if (e && e.href) {
+      document.location = e.href;
+    }
+  }
+};
+    </script>
+  </body>
+</html>